Language Kumquat Count Comparisons

Counting Perl Modules is half serious and half satire. I should know better than to publish satire. (Someday someone will invent an Internet populated only by people who know that Jonathan Swift was not the Western world's best known host of Donner dinner parties, but that hasn't happened yet.)

Getting an accurate count of the number of distinct modules on the CPAN is useful, but it's insufficient to compare the awesomeness of Perl to the fauxhawked machismo of Ruby to the humorless pseudocode-spewing Cylonification of Python to the cubist performance art of PHP.

Why?

Because what is a module and what does it represent?

In Perl 5, a module is a namespace. It may or may not contain code. It may or may not contain data. It may or may not exist in its own file. It may or may not be part of a bundle of other modules. It may or may not be useful on its own.

Count all of those up on the CPAN and compare them to the count of classes or packages or gems or eggs or copy and paste snippets for other languages, and you can learn... well, not nothing but not much useful.

You may as well compare the utility of (say) code written in Java to the same code written in Forth, despite the fact that Java's capability for abstraction begins and ends with the idea that everything in the world is a class or an instance of a class (except for those nasty primitives, and what are you, some sort of anti-business Smalltalk hippie anyway!) and that Forth's capability for abstraction is really good Forth programmers who create their own little languages that look and act like Forth but better, at least for their specific problem domains.

Oh, and a Perl 5 module may or may not be a class and it may or may not export a procedural interface and it may or may not be primarily documentation.

You may as well compare the goodness of two comparable modules chosen randomly from two languages with regard to use of standard language features, standard library features, and re-use of other modules, because ... well, it all depends, doesn't it? Sometimes the standard library is weak in one area, or one language lacks a feature of abstraction critical to another language, or there's clearly one really good way to do something in one language (Perl's DBI) and someday a standard might evolve and slowly spread through the ecosystem including a morass of hosting providers (PHP's database access layers).

... or what if one language has one more-or-less blessed way of doing something (Python's Django) and a small handful of alternate approaches or one obvious first choice to consider to do things (Perl's Catalyst) and a larger handful of worthy approaches or is in fact itself the primary way people do things (PHP) or overshadows other projects in the language so dramatically (Rails)?

... or what if one repository is primarily applications and one is reusable components, or one is a vast swath of untested abandonware ripped out of three-commit Git projects and another has an annual refresh rate of 30% and millions of test reports every year?

If you still insist on measuring your value as a person by comparing incomparables between your favorite language and the barbarian mutterings of those unwashed Philistines who {like sigils|hate sigils|love blocks|couldn't indent their code with a tab key and a flashlight|smell of body spray|know how to read documentation|haven't upgraded to a newer version yet|deprecated an insecure feature you relied on anyway|do it like Java|don't do it like Java|have a mustache|aren't Danish|aren't Dutch}, you might despair and consider returning to the time-honored practice of counting the number of mentions on the Internet of a random moniker sometimes and somehow related to the name of your languages—but resist that temptation, for That Is Obviously Bad Epistemology.

You might as well count the lines of code written in each language to find the bestest, most gratifyingest language in which only real, true programmers program.

I hope to see you all at Yet Another COBOL Conference 2011.