in reply to Re: Improve Perl's marketing position by making Perlmonks more discoverable for automated "popularity contests"
in thread Improve Perl's marketing position by making Perlmonks more discoverable for automated "popularity contests"
That is very interesting and effective. What interests me about this, though, is more than just the superficial notion that “Perl shows 7% whereas Python shows 30% and Java shows 26%. Here are some things that come to mind, and I’d like to know what you think about any of them. (These are not argument points; they are discussion points.)
- The source, codeeval.com, superficially appears to be a programming contest/show-off site. If this is where they are getting their numbers, there are several natural sources of behavioral bias here.
- Some language implementations surface their applications; others do not. You cannot tell easily what language a web-site is written in, for example.
- What is the metric being used? Lines-of-code? Size-and- number-of-files? How unbiased would these metrics most naturally be? Was #include considered?
- Does the metric discuss new code being written today, or does it consider legacy code also? (“Legacy,” in this case, not meaning that the software is horrid, but only that it’s a freight-train out there on the track right now bringing home the freight every day.)
- What is the actual take-away here, in terms of a decision-maker. Let’s all tell The Huffington Post that Perl (drives Moveable Type™ drives their website drives their world) really sucks and that they should rewrite their world in Java or Python. Software development has a hideous front-load investment of time=money that has to be amortized away, and all of today’s “new today” applications will be in the same boat tomorrow. Is this merely a self-reported metric of, well, exactly what it promises to be ... popularity ... and if so, how and why should this drive present or future decisions? Also, what decisions should it and should it not drive?
- What about “equality of choice?” If you’re writing for Android right now, you must use Java.
- What about the fact that most production work is dealing with existing, not new, systems. You are almost never starting with a blank slate and with no other production systems in sight. You might be dealing with, say, a $$ military $$ contract $$ for which such parameters are strictly dictated. (Were this not so, then no one in their right mind would use Ada ... wink wink.)
- Programming languages, being rather specialized tools, are not fungible. The choice of which language to use, or to continue using, is heavily influenced by applications that are already in service, and by external packages (such as CPAN modules) which it is desirable or necessary to use. Some languages are extremely specialized, such as Gnu Prolog or “R.” Some of the languages listed, such as Clojure, definitely are. And yet, here they all are on the graph ... all circles ... but actually apples and oranges.
Again ... for discussion.