Venerable Perl, a language that you either love or love to hate, has just had its 34th birthday. In celebration we look at its recent past, the milestones that defined it and look forward to a bright future. 

If you missed it this birthday it happened on December 18th, I have to admit I missed it until I was notified by this HackerNews thread which records the initial commit by Larry Wall. Scouring through it you'll find the usual arguments; some are enthusiastic and wish Perl Happy Birthday while others claim that it's a dead language. Unfortunately that is the situation and has been as such for some years.

The problem is that not being popular is treated by many as synonymous to being dead. While admittedly not popular anymore, it couldn't be farther from dead.The proof of that fact are the regular version releases, the number of new modules added to CPAN every day, the events and gatherings, and a wealth of ideas for evolving the language like the addition of Futures, Ovid's new OO system Corinna or the plans for Perl7.

But the most valued aspect of it all, is the stellar backwards compatibility. Businesses rely on it and are not keen on updating versions. "Don't break what works" is the moto. It's a notion close to Java, the dinosaur which nevertheless has got the Fortune 500s' backs; for a bank breaking loose it's a no no. And it certainly looks like it from the fact that many can't, or don't want to, move from Java version 8 to the newest counterparts, despite the goodies and upgrades that they bring. As such 20-year old Perl glue CGI code works today as it did back then. So it might not be the language of the cool kids, but it's certainly the language of the maintainers.

That aside, you've got to weigh in the utility of the tool. Back in the 2000's it was the right tool for the job at hand, that is gluing the web together. But after the rest synced in there's been fierce competition from Python, PHP, Ruby and the likes. Its versatile but idiomatic syntax certainly played a role in the declining of Perl's popularity because it was tough to master. Therefore there was need for a killer app or framework that would rejuvenate the landscape around Perl.

The Perl Ecosystem

Catalyst, Dancer and Mojolicious sprang up, with Mojo finally prevailing as the most valued of them. But things are not as they used to be, and the market is now being saturated with little space to grow. About Mojo being the "Killer" I don't know, but great it certainly is.

Don't get me wrong. I use the Spring framework and Java for writing REST APIs at work, but that's not because I love Java; it is because the Spring framework takes care of a lot that the programmer would otherwise do manually. Plus, it can be easily integrated with modules like Hibernate, Security, OAth etc and with it you can also build Microservices with reactivity and so on. I would love to do the same with Mojo, but I'm not in a position to experiment when business requests are pressing, taking into account that the surrounding environment is governed by Java anyway. This is as an example of why Perl, while loved, can't be readily endorsed in a business environment.

But as the wise say, choose the right tool for the right job. So for tasks like manipulating text (try to parse an XML file in Java) XML, Unicode, ETL interacting with web services, even as a basis for a reactive database CDC  I go for Perl.

Well what about other tasks like GUI apps? Surely Perl is not thread safe! Perl can do that too. For example, I've built a Win32 App that unrars RAR files in batches using a worker thread that communicates with the Main/GUI thread through a message queue and, by utilizing Win32 kernel events, you could even pause and resume the worker. No freezing windows, just stellar performance. It is open source and the code is available at Launchpad Unrar Extract and Recover  (Findmysoft review here). It has accumulated great reviews for its functionality over the years, despite sporting a "hässlich" (terrible in German) UI. While I loved every second of putting my language of preference into producing a concrete outcome, it was not the best tool for the job; thus the porting of the humble Perl app to . NET Windows Forms for a native Win32 experience and cleaner UI.The result was Ultimate Extract and Recover (Softpedia review here) which I'm planning to open source too.