Comments on Javascript being the "new" Perl

This has been making the rounds on Hacker News, Slashdot and others. The author’s central thesis is that Javascript has become something akin to the swiss army knife of cool programming, though its missing bits. He then compares this to Perl. He notes:

Hot is subjective, and in a very real sense, just last year, a teenager in his bedroom not only built a very cool tool, and company, but he sold it. Companies are using it. Just an example, but the point is that cool, sexy, hip, whatever … is in the eye of the beholder. But back to the article. The author states (with neither context, nor data) that

I think its probably time to call BS on this. We don’t see working Perl code being ripped out and replaced by Python or Ruby. We see application specific code being developed to standard APIs and definitions of APIs (REST, etc.) that enable programmers to use whatever tool they are most comfortable with expressing their algorithms with. Moreover, we see companies, such as Red Hat, actually shipping Perl code (albeit with a completely EOL/outdated version of Perl … seriously guys?) for various functions in their virtualization stack and other places. We see lots of development in Perl, across many disciplines. In many cases, you really cannot beat the power code and depth of the CPAN libraries. The code is clean, and quite easily maintained, there are lots of tools that work well for development and debugging. Modern technologies abound within it, we make extensive use of Mojolicious as the basis for our Web GUIs. That is, despite the occasional howls of derision from certain groups expressing their opinions of their non-favorite languages, its actually strong, vibrant, and growing. While automated counters such as this make rough estimates, the web sites of each of the module repositories tell a very different story. CPAN with 116k modules (often with multiple modules packaged together into a number of distribution files), Ruby with 49k gems, Python with 27k packages (according to pypi.python.org). Thats the thing about facts … you can have your own opinions, but you really can’t have your own facts. Facts tend to be objective measures. Perl is a very powerful language. Of this there is no doubt. Detractors like to claim “hard to maintain” or “line noise” or other such nonsense. Again, they are entitled to their opinions, but if it were so hard to maintain and write in then why is it positively dominating all the other languages, combined, for module counts? This just doesn’t make sense if people are running away from it as quickly as possible. Thats why I called BS on the article. It reads more like wishful thinking w.r.t. this than reality. But onto Javascript, as the question is, is Javascript the “new” Perl, with the authors' own bias on what it means to be Perl, quite evident. The author obviously dislikes both languages, and infers that Coffeescript, or Dart, or (insert some other random obscure language fad here) will take over. Um … yeah. And fortran is dead too, right? Cobol as well? Perl is vibrant and robust. About the only one comparable to this is Javascript, which is most definitely vibrant and rapidly developing (you can’t read a page of HN without seeing some new module). Javascript, via the V8 engine and node.js is positively amazing. Everything I like about the simplicity and power of getting stuff done in Perl, I can do in Javascript, and darn it, the JIT compiler in V8 renders code that is about as fast as C/C++. On everything, including numerical work. This is sick. I mean, seriously seriously evil (in a good sense of the word evil). This doesn’t mean I am giving up my Perl code, but it does mean I am starting to get more serious about writing javascript, and more specifically, node.js stuff. Some stuff, Perl is unmatched in (at the moment), and its much easier to express a process there. Some stuff, fits very naturally in node.js (Javascript), which makes it a very natural fit there. And they can play together easily, passing JSON and BSON back and forth. Right now, npm has something like 20k modules. Give it time, and it will rival Perl’s (its growing faster). Like Perl’s modules, node.js (Javascript) modules are usually non-trivial, often solving useful problems, have lots of examples. So in this regard, yes, Javascript, and more specifically, node.js, is definitely “like” Perl. Its a powerful expressive language, with very rapid and useful module development going forward. One shouldn’t assume that simply because a few developers, unhappy with the adoption rates of their preferred platform, writing articles setting up effectively passive aggressive strawmen “X is the new Y, and X is doomed because I say Y is doomed”, that their thesis lemmas are correct. That is, they assume that javascript is doomed (silly to think so, but ok, they can hope). The author calls out Google as a big python shop (GvR was there until recently), and in an ironical turnabout, completely omitting the fact that it is a very big javascript (and V8) shop. Which makes sense, as Google developed V8. It would not surprise me in the least to learn that they were using node.js (as node.js is built atop V8). If you read the author’s bio, you get an inkling of where they are coming from. What their biases might be. Basically at the end of this, he waves his hand dismissively on the future of javascript. Based upon what I see, this is done at one’s own peril. What opened my eyes to the possibility of using Javascript (far outside of what it was originally designed for) was the JIT performance table on the Julia Language site. There you see computational kernels and benchmarks … floating point and integer computational codes, being run on Javascript and “real” computational platforms. And apart from statically compiled fortran, and JITed Julia, the rest of the Rapid application development tools faired … well … rather poorly. Inclusive of Python, with only a single test having Python faster than Javascript, and that is likely to be one where Python calls an external function, while Javascript does not, and the optimizer failed badly. That the developer could express these algorithms reasonably in Javascript definitely opened my eyes significantly. Previously the surprise to me was the Javascript google molecular visualization engine. I wrote converter from an arbitrary chemical format to VRML for visualization (along with bond calculation, etc.) more than a decade ago. Most of it was in Perl and CGI driven. The bond calculations were expensive in time, so I rewrote those in C or C++ (I don’t remember). Integrated it all, and generated lots of little VRML files you could use to visualize your molecules. Here’s an example one from my thesis data sets. These aren’t precisely trivial problems to solve. And they are solvable in Javascript. More to the point, very powerful visualization tools are being built upon various javascript code, including web based 3D toolkits. No, I think not only can we call BS on the article, most of its points, but we can point out that Javascript and node.js are growing daily, in power, in reach, in utility. Much like Perl is. So in that regard, they are similar. But the authors seeming desire for them to be on the wane, with obscure languages replacing them … yeah … not so much.