Perl can escape the Lisp Curse
Tags: perl, lisp, cpan
Published: 2021-06-22 14:19:19

---
title: Perl can escape the Lisp Curse
published: true
date: 2021-06-22 14:00:00 UTC
tags: Perl,Lisp,CPAN
canonical_url: https://phoenixtrap.com/2021/06/22/perl-lisp-curse/?utm_source=rss&utm_medium=rss&utm_campaign=perl-lisp-curse
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/urvnkuii0uwov07eomlx.jpeg
---

Ten years ago Rudolf Winestock wrote [The Lisp Curse](http://winestockwebdesign.com/Essays/Lisp_Curse.html), an essay that “attempt[ed] to reconcile the power of the [Lisp programming language](https://lisp-lang.org/) with the inability of the Lisp community to reproduce their pre-[AI Winter](http://c2.com/cgi/wiki?AiWinter) 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](http://www.gnu.org/software/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](https://en.wikipedia.org/wiki/There's_more_than_one_way_to_do_it) (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](https://www.cpan.org/) with their own code. Select an [object](https://metacpan.org/pod/Moose) [system](https://metacpan.org/pod/Moo) (or [don’t](https://perldoc.pl/perlobj)), maybe throw in an [exception](https://metacpan.org/pod/Syntax::Keyword::Try) [handler](https://metacpan.org/pod/Try::Tiny) (or [don’t](https://perldoc.pl/functions/eval)), 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](https://www.vim.org/) extensions.

But there’s hope.

Perl has started **[incorporating](https://perldoc.pl/perlsyn#Try-Catch-Exception-Handling) [features](https://github.com/Ovid/Cor/wiki) expected of modern programming languages** into its core while [making room](https://metacpan.org/pod/XS::Parse::Keyword) for further experimentation via CPAN. The [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) (from Microsoft of all places!) has [enabled Perl IDE features](https://metacpan.org/pod/Perl::LanguageServer) in text editors to **boost productivity for new and experienced developers** alike. And there’s a [pilot Request For Comment process](https://github.com/Perl/RFCs/blob/master/docs/process.md) 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](https://www.nntp.perl.org/group/perl.perl5.porters/2021/05/msg260068.html). Maybe the curse can be overcome.