Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Okay, you're trying to explain the success of modules on CPAN; that is, why do certain modules become more popular.

    What isn't clear to me is: since hardware is increasingly powerful, why is the size in memory of a module important? It's not as if different "species" of a module are competing for limited memory in a literal sense. Something like DBI is quite large, but it's undeniably more successful than database-specific modules were (you're not going to use an XS wrapper around libpq, even if it was t

    • The reason we've gotten away with using a lot of memory for so long is exactly because hardware is getting more powerful. In times of plenty, waste or resource usage is not an selection factor.

      But the time frames I'm talking about here are quite long. I'm looking at evolution of module usage over 3-10 year periods.

      Memory does eventually become important, if only for a subset of people. (Think mobile phones)

      I have one monstrous private application that uses 80-90 meg of RAM B to load, before doing any work of allocating any memory to data. Until very recently that's been a real problem, and the startup time is still longer than I'd like.

      Every time I can cut 3 meg off that number (which is on average what a ::Tiny module saves) it's a good thing.

      Wetware issues (APIs, familiarity, etc) are absolutely important. But they tend to be important in the short term (months or years).

      Over longer periods, if someone eventually creates something equally usable, and smaller and faster, it will gradually win.

      I think the island rule is more complex, since there's different factors at play.

      For creatures without natural predators, such as the dwarf elephants, resources would seem to be the more obvious direct approach.

      For rats, perhaps it was something different, such as a lack of the predators that were formerly killing off the larger and juicier rats.

      With regards to size, the place I see the most striking example is in the C libs. For particularly complex tasks that are strongly encapsulatable, we see a tendancy towards small, tight, fast C library integration. The fact that this means that memory gets shared with other non-Perl applications adds to the factor.

      Look at the examples such as libxml, libgif, libsyck and so on.

      Because the smallest, and fastest, way to implement these strongly encapsulated functions is in C (if done right, note expat) you might suggest that over time there will be selective pressure towards the use of sufficiently robust C libs.

      For the DBI case, I would suggest a different evolutionary factor would be more dominant here, that being flexibility.

      While the C libs are small and fast, they are resistant to change. Which is why you'll note the areas where they are used the most are for long-standardised functionality that isn't changing often (xml, image processing etc).

      The example of expat is a good one, it may be that it was just implemented too early, while XML was still something of a moving target.

      Because different databases come and go, it is far more important that DBI be flexible. You first have to achieve continuity to survive. Once the problem of continuity is solved, THEN the more long-term issues like compactness start to become an issue.

      Part of what excites me about Haskell conceptually (I still haven't had time to do more than skim the surface) is that it implements the fast/small concepts rigourously and with mathematical precision.

      I'm somewhat curious how big haskell code is. If it's fairly small and memory efficient, then we may well be looking at a long-term successor to C.

      This is one of the other interesting things about Parrot and multiple languages.

      If a language in one language compiles to Parrot smaller and faster than another, will precompiled versions of those modules become popular with users from the other languages? I can't wait to see :)