Ten years ago Rudolf Winestock wrote The Lisp Curse, an essay that “attempt[ed] to reconcile the power of the Lisp programming language with the inability of the Lisp community to reproduce their pre-AI Winter achievements.”
His conclusion? The power and expressiveness of Lisp have conspired to keep its developers individually productive, but collectively unable to organize their work into complete, standardized, well-documented, ‑tested, and ‑maintained packages that they could coalesce into interoperable and widely-adopted solutions. Everything from object systems to types to asynchronous non-blocking programming and concurrency is up for grabs and has multiple competing implementations.
These social effects have doomed Lisp to also-ran status in an industry where “employers much prefer that workers be fungible, rather than maximally productive.” Free tooling support has lagged; although Emacs can be hacked endlessly to do anything, there is no out-of-the-box integrated development environment or batteries-included defaults to immediately ease new programmers into their job.
Does this all sound familiar to Perl developers?
Perl is renowned for its expressive capabilities , enshrined in the TIMTOWTDI (There Is More Than One Way To Do It) design principle. Stories abound of the productivity achieved by Perl programmers stitching together modules from CPAN with their own code. Select an object system (or don’t), maybe throw in an exception handler (or don’t), and you too can have a codebase that fellow developers critique for not following their favored techniques. Meanwhile, managers are struggling to fill the rest of the team with new programmers looking for IDE support and finding only a grab-bag of Vim extensions.
But there’s hope.
Perl has started incorporating features expected of modern programming languages into its core while making room for further experimentation via CPAN. The Language Server Protocol (from Microsoft of all places!) has enabled Perl IDE features in text editors to boost productivity for new and experienced developers alike. And there’s a pilot Request For Comment process for further improvements.
These efforts point to a future where Perl’s expressive strength is married with sensible defaults and features without breaking backward compatibility. Maybe the curse can be overcome.
Top comments (0)