What Modern JavaScript Can Learn from Modern Perl

If you look at it long enough, JavaScript will remind you of Perl.

I don't mean the language's syntax per se, though everyone who attends Algol family reunions looks vaguely similar. JavaScript is similar to Perl in that it's a language that's been around a while, that's accreted new features, that's showing some limitations of its original design decisions, and that has tremendous backwards compatibility concerns that make addressing the previous points difficult. Like Perl, it's a language that's seen a lot of programming novices pick it up to get things done, but it's also a language that rewards this whipupitude and lack of ceremony with the potential to make great messes.

(Don't worry, Perl fans: even if you don't ever use JavaScript, looking at Perl through the lens of another language will give you a better perspective on our favorite little powerhouse of a language.)

JavaScript reminds me of Perl 4 with a slightly better syntax and a couple of additional features (basic lexical scoping, higher order functions, and method dispatch, not to mention competing implementations with a lot of effort spent on optimizing away efficiencies inherent in some of the poorest misfeatures of the language's design).

JS has blatantly stolen some of Perl's better ideas, such as strict mode for JavaScript as well as some of Perl's worse ideas (for the sake of backwards compatibility, you enable strict mode in JavaScript by embedding a magic string literal in your code).

Even with the revival of server-side JavaScript in projects like Node.js as well as client-side, single-page applications, the language still has a ways to go before it can realize its true potential.

In one way, you can trace the rise of modern JavaScript to Douglas Crockford's book JavaScript: The Good Parts as well as libraries like jQuery, which take so much of the pain out of writing cross-platform JavaScript that you might say that people write more jQuery code than they do JavaScript, at least on the browser side.

(Fun fact: I modeled Modern Perl: the book after JavaScript: The Good Parts.)

If the idea of modern Perl has brought new energy into Perl (and I believe it has) and new perspectives on improving Perl 5 (and I believe it has), perhaps some of the lessons of the Perl Renaissance are valuable to other languages, such as JavaScript.

Embrace Modularity

Perl 5 is alive and well thanks to the CPAN. Without the CPAN, it's an interesting language with some great features and some flaws. With the CPAN, it's a toolchest full of precision instruments that good programmers can wield to make great things.

JavaScript has no real module system. Using various libraries and files in a single JavaScript project requires clever gyrations or at least rigorous pattern adherence, which fortunately the language supports. (I'm aware of npm. It's a start.)

For all of the flaws with Perl 5's import() mechanism, the compilation-time use and import() led directly to the creation of and growth of the CPAN. Libraries will happen without explicit language support, but explicit language support in Perl made something amazing and transformative happen.

Embrace Quality

I use Perl because it's so very well tested and verified. In fact, I believe that Perl's testing culture has no parallel in other languages. In a very real way, the entirety of the CPAN is a smoke testing system for the core language development.

The closest thing I've seen to a rigorous approach to writing high-quality JavaScript code with serious testing is my friend and colleague Jim Shore's Let's Code: Test-Driven JavaScript. (Disclaimer: I supported his project on KickStarter.)

Unlike big-A Agile, which is a morass of training and certification and books with too little focus on delivering successful projects or little-a agile which is like flossing: something everyone says they do but you know only happens a couple of times a week, at most, Jim's test-driven development gets done and actually works.

If the JavaScript world started to embrace a similar testing revolution, it'd be in a much better place. Couple that with a better library ecosystem—one encouraged by the language itself, and....

Reduce Technical Debt

(alternate heading: Reduce Crazy)

People who complain that "You can't change JavaScript! You'll break countless existing runtimes!" have a point. Waiting for whatever the oldest version of Internet Explorer you have to support to go away before you can take advantage of something designed and standardized in recent memory is a real hassle. (Thanks to Dave's hard work and not mine, ClubCompy supports old versions of IE, but it's a huge amount of work for little payoff.)

Sometimes you have to keep around the cruft, but you can't limit yourself to what was valid in old code if it will prevent you from producing new code.

What I wrote in Safety in (Version) Numbers is still true in Perl, and it's probably true in JavaScript. Only by explicitly documenting the version of the parser you want to use on a particular piece of code can you explicitly document your expectations, and only with explicit declaration does the parser have any hope of figuring out what you mean.

Even if the semantics of features change, the surface syntax of the language can upgrade slowly and deliberately if and only if programs written in the language make explicit their requirements.

Put another way, HTTP makes you say HTTP/1.0 or HTTP/1.1 for a reason.

JavaScript could fix some of its syntactic weirdnesses (lexical hoisting, automatic semicolon insertion) and add missing features (trailing commas in list literals, library use and dependency management, namespacing) with a strategy like this. For as much as I dislike "use strict" as a magic string constant, at least it works.

Documentation Guidelines

For as much as people complain that even decent Perl code can be inscrutable, Perl has copious internal documentation (see perldoc.perl.org for an online version of the docs which you most likely already have installed on your machine right now). The CPAN also has strong cultural guidelines for how to document modules and distributions. Even though these are community guidelines, projects adhere to them.

(I have lost track of how many patches I've sent to rephrase an unclear piece of documentation or add something missing or even to fix a typo; thank goodness for Git and Github, I say.)

Building a culture of communication and documentation is not easy, but the results are wonderful. I expect that any good library I use in Perl has decent tests, has a working installer, and has at least basic API documentation. I'm rarely disappointed.

Conclusion

I could write more about community management and expectations, but that's a non-technical subject with fluffier answers you can guess at anyhow.

JavaScript the language has a tremendous opportunity to learn from what Perl's done well and poorly. Stealing our better ideas will help it avoid some of the problems other languages get caught up in, and refining our best ideas will give us even better ideas to borrow back from.

Who knows? Maybe together we'll make programming easier, more pleasant, more reliable, and even more secure.