|
Lover of Perl and JavaScript alike here. It is a weird comparison. The two languages are used in very different ways; I guess the author is saying JavaScript will be supplanted by something nicer, like Perl has been. But Perl hasn’t been. Python and Ruby are cohabitors, not usurpers. A sizable chunk of the web’s infrastructure is still Perl, and that is unlikely to change. To give you an idea of the language, Perl is very easy to use, and very hard to grok. The language is large and complex, but most of the size and complexity have to do with being as helpful to the programmer as possible. If you use things in a way that seems plausible, your expectations probably won’t be violated. But if you want to deeply understand how something works, be prepared to discover many details you didn’t expect about how the language is silently helping you out. It’s a relatively painless experience, even if you don’t know a lot of Perl, to glue a few CPAN modules together and get something working. In that respect it’s similar to writing a Node.js application, though the set of Node libraries is, last I knew, laughably small by comparison. Having maintained both large-scale JavaScript and Perl codebases, I can tell you that it’s much easier to deal with Perl. Having a proper module system is a huge boon, as well as sane handling of types, and some compile-time checking. Perl is dynamic, yes, but types are explicit by way of sigils—in Perl 5, essentially typed dereferencing operators. The main difficulty in Perl is the same as in any dynamic language: refactoring. It can be a pain to change things, because many of the resulting errors are not checked till runtime. A comprehensive test suite helps with this; Perl’s testing culture is very good, and comparable to that of Ruby. JavaScript developers tend not, in my experience, to write tests. So not everybody hates Perl, and not everybody hates JavaScript. People who’ve actually used a language tend not to hate it as much as those who haven’t. This article is, in that regard, just plain silly. |
I thought so too. JavaScript seems like it's filling a gap, and by doing that it's ensuring its own survival. Either that, or we're forcing it into a specific purpose (i.e event based manipulation, animation, data i/o), but the end result will probably be the same. I have a hard time imagining something else coming along, at least not as long as JavaScript is... well, everywhere.
Thank you for explaining Perl to me. A proper module system, compile-time checking and the sort has, with JavaScript, been solved by using JSLint and AMD. Well, almost. It makes the code easier to maintain. Although I'm sure Perl is superior in that regard, it still works - and it works really well.