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.
Good food for thought!
I sure hope so!
Mark, somewhat related to “sensible defaults” is the way there basically is no easy way to wade through thousands and thousands of CPAN modules, many of which are crufty, in order to determine which module provides the best solution for a particular problem. The size of CPAN and lack of rankings or some sort of “best practices” guide to them is a liability in a sense, because it makes Perl as a language feel complicated and unstandardized. Task::Kensho is a big step in the right direction. More is needed. I’m not sure exactly what that would look like. Maybe an online community-written version of the Perl Cookbook (the second edition of which is unfortunately now many years old).
FWIW MetaCPAN has rankings in the form of the “favorites” button and the graph indicating a module’s position in the river of CPAN. Maybe they could be more obvious?
I usually use a combination of recent date, and popularity [via number of times favourited, etc] to guide me.
Thanks!
I am not seeing such a graph anywhere on a module’s page (e.g., CGI.pm).
Or a favorites button.
Could you elaborate?
Gawd. I have never noticed those. I’ve probably used metacpan hundreds of times. THANKS, Mark.
The problem with IDEs is that people become LAZY. I can’t tell you the number of times I’ve had to work on code developed in an IDE, where the user either didn’t know how to configure the IDE to show warnings or explicitly configured it NOT to show warnings.
Consequently, I end up spending the first few increments of time cleaning up all the warnings. Yes, I’m old school… NOTHING leaves my shop with with anything other than debug info showing up in the logs or on a console.