Posted on
by
jack skelington vinyl figure
Photo by Toni Cuenca on Pexels.com

Ten years ago Rudolf Winestock wrote The Lisp Curse, an essay that ​“attempt[ed] to rec­on­cile the pow­er of the Lisp pro­gram­ming lan­guage with the inabil­i­ty of the Lisp com­mu­ni­ty to repro­duce their pre-AI Winter achievements.”

His con­clu­sion? The pow­er and expres­sive­ness of Lisp have con­spired to keep its devel­op­ers indi­vid­u­al­ly pro­duc­tive, but col­lec­tive­ly unable to orga­nize their work into com­plete, stan­dard­ized, well-​documented, ‑test­ed, and ‑main­tained pack­ages that they could coa­lesce into inter­op­er­a­ble and widely-​adopted solu­tions. Everything from object sys­tems to types to asyn­chro­nous non-​blocking pro­gram­ming and con­cur­ren­cy is up for grabs and has mul­ti­ple com­pet­ing implementations.

These social effects have doomed Lisp to also-​ran sta­tus in an indus­try where ​“employ­ers much pre­fer that work­ers be fun­gi­ble, rather than max­i­mal­ly pro­duc­tive.” Free tool­ing sup­port has lagged; although Emacs can be hacked end­less­ly to do any­thing, there is no out-​of-​the-​box inte­grat­ed devel­op­ment envi­ron­ment or batteries-​included defaults to imme­di­ate­ly ease new pro­gram­mers into their job.

Does this all sound famil­iar to Perl developers?

Perl is renowned for its expres­sive capa­bil­i­ties, enshrined in the TIMTOWTDI (There Is More Than One Way To Do It) design prin­ci­ple. Stories abound of the pro­duc­tiv­i­ty achieved by Perl pro­gram­mers stitch­ing togeth­er mod­ules from CPAN with their own code. Select an object sys­tem (or don’t), maybe throw in an excep­tion han­dler (or don’t), and you too can have a code­base that fel­low devel­op­ers cri­tique for not fol­low­ing their favored tech­niques. Meanwhile, man­agers are strug­gling to fill the rest of the team with new pro­gram­mers look­ing for IDE sup­port and find­ing only a grab-​bag of Vim extensions.

But there’s hope.

Perl has start­ed incor­po­rat­ing fea­tures expect­ed of mod­ern pro­gram­ming lan­guages into its core while mak­ing room for fur­ther exper­i­men­ta­tion via CPAN. The Language Server Protocol (from Microsoft of all places!) has enabled Perl IDE fea­tures in text edi­tors to boost pro­duc­tiv­i­ty for new and expe­ri­enced devel­op­ers alike. And there’s a pilot Request For Comment process for fur­ther improvements.

These efforts point to a future where Perl’s expres­sive strength is mar­ried with sen­si­ble defaults and fea­tures with­out break­ing back­ward com­pat­i­bil­i­ty. Maybe the curse can be overcome.

9 thoughts on “Perl can escape the Lisp Curse”

  3. Mark, some­what relat­ed to ​“sen­si­ble defaults” is the way there basi­cal­ly is no easy way to wade through thou­sands and thou­sands of CPAN mod­ules, many of which are crufty, in order to deter­mine which mod­ule pro­vides the best solu­tion for a par­tic­u­lar prob­lem. The size of CPAN and lack of rank­ings or some sort of ​“best prac­tices” guide to them is a lia­bil­i­ty in a sense, because it makes Perl as a lan­guage feel com­pli­cat­ed and unstan­dard­ized. Task::Kensho is a big step in the right direc­tion. More is need­ed. I’m not sure exact­ly what that would look like. Maybe an online community-​written ver­sion of the Perl Cookbook (the sec­ond edi­tion of which is unfor­tu­nate­ly now many years old).

  4. The prob­lem with IDEs is that peo­ple become LAZY. I can’t tell you the num­ber of times I’ve had to work on code devel­oped in an IDE, where the user either did­n’t know how to con­fig­ure the IDE to show warn­ings or explic­it­ly con­fig­ured it NOT to show warnings.

    Consequently, I end up spend­ing the first few incre­ments of time clean­ing up all the warn­ings. Yes, I’m old school… NOTHING leaves my shop with with any­thing oth­er than debug info show­ing up in the logs or on a console.

Comments are closed.