Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Joel "The Joel" Spolsky advises against such 80/20 behavior.

    You and your experience with successful ::Tiny projects are cast into oblivion, never to be discussed again as a viable solution to many problems!!

    • I suspect that the key to ::Tiny is two-fold.

      Firstly it has to be 90% cheaper, or at least "transformatively cheaper".

      Secondly that it should really supplement the more expensive solutions, not be a replacement or a leader into a new area.

      If you try to write a ::Tiny module while also breaking new ground, the exploration process itself will drive you towards bloat. Because you have a monopoly on the area at that point, you have to serve everybody.

      It is only once a field is well understood that you know where the core of the demand is. You can focus on the most important area, while turning away people that need the additional features and sending them to the more expensive and complete alternative.

      The Tata Nano might be cute, but clearly it's not going to be enough to drive around fat businessmen or store 3 kids worth of hockey equipment or camping gear.

      • Agreed.

        I still believe that while it's not a new-ground 80/20, it's still some type of 80/20, or even 90/10.

        You still make the assumption that "after working with the technology for a while, we have a fair grasp of what core functionalities of it is really required and others can be supplemented much later or not at all" to make the ::Tiny module.

        So in the end - whether on new grounds or after extensively exploring an already existing ground - you make a distinction of certain features you care about, wheth