The Future of Perl
This is a good &quot;patch the holes&quot; plan, but I think it needs to be followed up in short order by some deeper thinking. And some very painfully honest thinking.<p>Paul Graham, whom some of you may have heard of, once wrote an essay about &quot;What Languages Fix&quot;: <a href="http:&#x2F;&#x2F;paulgraham.com&#x2F;fix.html" rel="nofollow">http:&#x2F;&#x2F;paulgraham.com&#x2F;fix.html</a><p>I think of it a bit differently, which is that languages have a <i>thesis</i>. (Not quite the same but a lot of overlap.) Paul writes that what Perl fixes is &quot;Shell scripts&#x2F;awk&#x2F;sed are not enough like programming languages.&quot; I would personally rephrase it to something like &quot;There isn&#x27;t(&#x2F;wasn&#x27;t) a language dedicated enough to Getting It Done.&quot;<p>If you put yourself in the context of the time, this was absolutely true. Most languages for getting things done involved a lot of drama and boilerplate. Popular languages of the day would require you to implement your own hash table for a quick script, if you didn&#x27;t have one on hand. Libraries for that existed of course, but the Internet wasn&#x27;t really up and running the way it is now yet, and things were hard to find. Perl came in and provided a great Get It Done languages.<p>However, landscapes evolve over time and so do language theses. C++ is a great example of something that has changed, going from &quot;C should have great support for object orientation&quot; to something more like &quot;C++ should be the choice for programmers who want zero-cost abstractions&quot;. Part of the reason for that change is that the former thesis is no longer a compelling one, on the grounds that &quot;great object orientation support&quot; is now simply table stakes for that sort of language. C++ could not drive forward on that thesis in 2021.<p>That is also Perl&#x27;s <i>real</i> problem right now. It lacks a thesis. It has very narrow advantages in text munging still, but for almost anything else, I now have an abundance of languages that &quot;get it done&quot; just as well or better. For context, I&#x27;ve got about 15 years of Perl being my <i>primary</i> language under my belt, so that means something; it&#x27;s not a secondary or tertiary language for me, and I still have plenty of choices to reach for. (Heck, I&#x27;ve even come to prefer Go for JSON munging quite a lot of the time, because with the right tooling it&#x27;s really easy to parse JSON straight into objects that I can call methods on meaningfully, which is actually more convenient and useful to me than presenting me with a generic hashtable&#x2F;array representation that I then have to write a lot of code to crawl over from the &quot;outside&quot;.) The world has moved on, and Perl&#x27;s problem isn&#x27;t necessarily that it lost but that it <i>won</i>. It has successfully convinced the world that Getting It Done doesn&#x27;t need to come with all the drama and paperwork and complexity of its late 1990s peers. But that means that just like C++ won and it couldn&#x27;t continue operating on its &quot;good OO&quot; thesis, Perl needs a new thesis.<p>Moreover, it&#x27;s going to have to be brutally honest in the selection of that thesis, because a lot of the obvious ones are already covered by Python, and trying to chase Python on its own turf is going to be a losing game. Perl 6&#x2F;Raku also has its own thesis, which is now also essentially unavailable to Perl 5. Unfortunately, choosing a thesis successfully isn&#x27;t necessarily about what the Perl team &quot;wants&quot; so much as where there is space in the programming language market, and in the intervening, gosh, <i>decade</i> or so that Perl 5 has been floating along without a thesis, a lot of the easy or obvious answers have been fairly well covered by other languages.<p>One thesis option is &quot;Old perl code should degrade gracefully&quot;, which is the &quot;declare victory and walk off into the sunset&quot; option. To be honest, it&#x27;s one that should be seriously considered. I think graceful retirement is a test a lot of language committees fail. Here I&#x27;d look for improved refactoring tools to help automatically translate old code into better code to modern standards and other such things being the standard, for instance.<p>But if the Perl 5&#x2F;7 team wants a different thesis, it&#x27;s something I think they need to decide consciously. I don&#x27;t have a suggestion. But I can offer this word of hope; the space of possible theses is really quite large. The point of view where it looks like every possible language exists already is a point of view that is too narrowly stuck in the details of today. With just a bit of change in perspective, there&#x27;s a lot of untapped fields.<p>Tempering that hope a bit, Perl&#x27;s new thesis really needs to be something that Perl&#x27;s existing code and community brings something powerful to. If you come up with a possible thesis, but look at it honestly and say &quot;That&#x27;s probably something better done with a brand new language entirely&quot;, it&#x27;s probably not a functional thesis for Perl. And this does cut the space back somewhat. But some persistent thought may still find something interesting.<p>Personally, I&#x27;d also be looking carefully and honestly at what Perl is still doing and consider shedding old use cases&#x2F;theses. For example, while Python is not experiencing a popularity crisis, consider a hypothetical world in which the only people still using Python were basically NumPy users. It would be a valid choice to move forward with Python development in a way that privileged such use, at the expense of &quot;general purpose&quot; use going forward. I&#x27;m not involved enough with Perl to know what that would be, just offering a meta-option to consider.<p>And let me close on what I opened with... this is a good &quot;patch the holes&quot; plan that should be all means moved forward with, to give space to breathe. I&#x27;m positive on the plan, not critical of it.