Are there any circumstances where starting a new project with perl makes sense today? I am curious because I only encountered perl in legacy codebases.
Perl as a scripting language remains undefeated. As in, let's say you are considering Awk for some task. It's probably worth learning how to do that task in Perl instead. The same applies to many classic uses of bash scripts: today, the biggest reason to choose to write a shell script is to provide some service which will be universally available on plausible platforms, and Perl isn't that ubiquitous any longer. But for most of what shell scripting was intended for, Perl is a more powerful and less, let's say idiosyncratic, choice.
Of course, with a bit more verbosity, any such script could be written in Python. Perl was designed to fit this exact niche, so it has a bunch of small affordances for doing script munging eloquently (not to say elegantly!) but Python, or Ruby for that matter, can also get the job done. Most people who know either of those languages thoroughly would pick what they know: they'll do the job, and that spares learning another language, which is indeed a quirky one.
But for those who do know Perl, it remains a very good fit for a Practical Extraction and Reporting Language. For those who do a lot of 'scripting' tasks in the original sense, it's worth learning imho.
Except, I know how to slice and dice text with awk, and can do it without leaning on ChatGPT or studying language documentation. Never made the leap to perl, the few times I tried I was put off because to a newbie the language looks like gibberish.
I would never consider perl for anything new in 2024. I still use awk very regularly.
> Except, I know how to slice and dice text with awk
I meant to say something more like "if you need to learn awk to do it, you may as well learn Perl instead". I figured from context that if you're "considering using awk", you don't know it, or you'd be "using awk". But no matter.
Perl can do everything Awk can, at least as well if not better. As fiddly, arbitrary, and limited, as Awk is, it's a lot less language, and that does come with advantages.
But I know from experience that you can learn the Awk subset of Perl as easily as you can learn Awk, and then you have a basis for extension to more tasks of a similar nature. If you want to see what I mean, there's a utility a2p[0] which translates Awk to Perl, this suffers slightly from machine translation, but it's a good demonstration that Perl can do everything Awk can in not just a trivial sense, but in the sense that it's designed to make Awk unnecessary.
So if you can get over whatever aesthetic hangup you have about Perlian line noise, you might discover you like it. Anyone using Awk "very regularly" is leaving a lot of potential on the table by refusing to learn Perl. Then again, sometimes it's best to stick with what you know.
I've started to write my one off scripts with an AI prompt, and Python as a simpler and more verbose language with a bigger training corpus is easier for that. Or I ask for a bash script! Still writing my one liners in Perl but they're getting shorter and shorter.
Ok, but if you’re comfortable using it, Perl is really fun, pleasant, and easy to quickly express ideas in. One of its conscious design decisions is to be flexible enough to rapidly bang out some quick hack you’ll never look at again in absolute incomprehensible gibberish shorthand, or to use in a very methodical, disciplined, and structured way — so if you write something unmaintainable, that’s because you chose to.
I haven’t turned to it as my first choice in years, but it still has a place in my back pocket for if I ever need a quick and dirty text munging Swiss Army knife.
I've used Perl extensively for a few years professionally. For prototyping, say text-processing stuff, I reach out for awk/sh, which are usually sufficient.
If I need more than a prototype, I reach out for Go. I have two major complains with Perl:
- it's more difficult to deploy (Go can be cross-compiled to a single binary which can then be scp(1)'d around, solid stdlib, no need to deal with dependencies on the remote, or modules split in multiple files);
- lack of static typing. You can get away with writing additional tests, but at the end of the day, that's just more work.
So despite being quite confortable with a fair subset of Perl, I (genuinely) can't think of a reason as to why I'd want to use it.
I have perl stuff written literally 20 years ago, that still works without issues, even on modern computers. If you need something to do the job and in ten years be called "legacy codebase", then do it in perl... because if you did it in python, you'd have to fix the 2.6->2.7 stuff, then 2.7->3.x stuff, and maybe even more than that. If you did what people here on HN like, so, use a 'language of the day', you'd have code written in ruby (now rust or go or whatever), which very few machines have installed by default now.
In a previous company, I had to support TypeScript code that wouldn't even survive 12 months without something breaking upstream. Granted there were a lot of other things that company did wrong...a hell of a lot! But it's insane how little importance people seem to place on code longevity these days.
I’m not on about fixing tech debt. That’s a completely different problem to picking boring technologies that don’t need constant ongoing maintenance just to keep running.
Tech debt is going to happen regardless of the technologies you pick. But some technologies require more effort to keep up-to-date than others.
I’d also argue that keeping technologies up-to-date isn’t “tech debt”. It’s operational overhead. Tech dept is something else entirely.
In my experience, tech debt often requires too great an investment to fix so the team just ends up bikeshedding to show progress but without real benefits.
Look at C. Each revision has added a bunch of minor fixes but has never addressed the core issues of the language that realistically require a rewrite (function pointer syntax, undefined behavior, null safety).
And there’s the fact that features bring in money and tech debt simply doesn’t. It’s still a business at the end of the day.
Right. I started a perl codebase in 1999, which has slowly evolved and is still one of my main projects to this day. The language has slowly improved, there are decent libraries for everything you might want to do, and I've basically never had to rework or throw away my code because of incompatible changes in the language.
For reference, PHP at the time was at version 4, Python was around 1.6, and noone had heard of Ruby.
I have perl code I wrote in 1992 that still works properly, without changes. The binary executables have changed ISA from MIPS 4 to x86_64, and are compiled fortran (gfortran). There's even a switch I use to be able to read the large endian binary files in gfortran.
My c code from 1996 requires rework. My C++ code from 2014 requires rework (I had to do this with others code as well to use a std capability). Python code rarely survives 3.6 -> 3.12 never mind 2.7 to 3.x. I worked at a company that had (very unwisely) written a massive part of its infrastructure in Py2.7, and was using it a decade past its expiration date.
Are you kidding? Python code bases break week-to-week because pip is full of unversioned transitive dependencies, broken distro nonsense, and who knows what else.
As of 3.13, Python doesnt have a GIL either. JVM-based Ruby implementations don't have a GIL. Perl on the other hand never had a GIL, it just more or less defeated the purpose of threading by copying the entire interpreter state including all variables in every thread. Modules that explicitly work with threading are as rare as hens teeth on CPAN, it's almost always some flavor of async like Coro (hell I bet POE still works too).
python 3.13 most certainly has a GIL, it can just be optionally disabled, and this feature is in experimental status. see https://peps.python.org/pep-0703/
Oh, I thought the experimental state was earlier and that 3.13 was the official no-GIL release. Presumably it's going to eventually drop the GIL entirely (probably Python 4 if there ever is such a thing) but nonetheless I stand corrected, thank you.
I was curious about this and did some casual googling. It spawns an interpreter per thread. However, it seems this is not advantageous performance wise. From docs [1]
The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that makes them easy to misuse. Few people know how to use them correctly or will be able to provide help.
No, instead they have subinterpteters with all of the massive overhead that brings re: data sharing. And even fewer CPAN modules are remotely thread safe than PyPi modules, probably in absolute as well as relative terms. That’s a low bar.
As a result, threaded Perl code or frameworks are extremely uncommon, even relative to Python.
I guess if the team is (only?) familiar with Perl. But then again, its the same with PHP. Even IF you know PHP you would not pick it over the more modern alternatives in 2024.
I guess some people just want to stick with what they know, and refuse to learn anything new.
> Even IF you know PHP you would not pick it over the more modern alternatives in 2024.
That really depends on the use-case. If you need a batteries-included web framework, the top 3 that come to mind are Spring (Java), Django (Python) and Laravel (PHP).
I recently read a new idea of why PHP is useful to people - it's the lowest-overhead server-side Web page language available. If you want a tiny amount of functionality, you write a tiny amount of PHP and don't have to do anything else. So it scales much, much better in the tiny-to-medium-sized project range.
(I can't personally vouch for the claim but it's the best explanation I've heard for how such a reviled language has survived this long.)
I run a WordPress site for my wife's business. Would I pick it up again in 2024? Absolutely. It has nothing to do with what I "know", there's still no better CMS/ small diy e-commerce solution for, frankly, peanuts in hosting.
I really don't have much issue with modern PHP either, it gets the job done and unlike Perl is still very much evolving.
I think there are worse things than modern PHP (speaking as somebody whose primary contact with PHP is being traumatized by legacy PHP 7 projects). Afaik, the only places that will start a new PHP application today are places where the expertise is in PHP and Laravel/Symfony. I don't see a big enough benefit from migrating to a whole new stack that wouldn't be accomplished by some focused maintenance and refactoring if you're already working with PHP 8.1.
I write PHP for a living and I only write headless apps with Symfony and Laravel. Blade is an awful template engine with a primitive parser. Twig is tolerable, but for me nothing beats the DX of Inertia with Vue.
You are most likely right. I just fear spreading complexity everywhere. But I also want to take advantage of the vast compute available at clients. So, I am conflicted. Vue is probably a good compromise. Please share your best references on Inertia/Vue.
Only deployments of Inertia I have are internal code I can't readily share, but all it does is replace the very typical pattern of passing json-encoded props to a a blade template that contains a single React/Vue/Svelte component. Now you just return Inertia::render('My/Component', $arr) from your controller or route handler function, and you're good to go.
It also has various magic for router links that do partial refreshes and working with classic (non-json) forms and whatnot. I use none of those, I'm all about json and useFetch() instead, and Inertia's pretty good about getting out of your way when you don't need it. It lets you write as much or as little in SPA style as you want, it's more or less your favorite JS framework as a view layer directly without having to interpose another view as a middleman (the middleman is there, but it's all implicit: you add the @inertia directive inside your <div id="app">, and that's it)
I don't "start a new project" in Perl, but I certainly write a lot of Perl. Mostly one-liners and small scripts, and mostly throwaway. Perl is a very efficient language for string processing, thanks mostly to its built-in regex engine.
Once it grows a little bit more and starts requiring maintenance, I tend to rewrite it in a more maintenable language. Preferably a statically-typed language.
I'm considering it. It might be a language that does not need constant changes because of useless churn. Especially now, with the Raku split worked out.
On the other hand, the changes in my Ruby project have always been very manageable. Both the language and the ecosystem were reasonable those last years.
It's been my first choice for 30 years for anything involving a lot of non-trivial work with textual data (Including xml, json, etc.). And one-liners and any quick throwaway script, of course.
All Perl code I have ever seen, has been "write-only". Just completely unreadable and it was easier to just look at the output instead of the code when converting it to Python to get actual maintainability.
You are getting downvoted, but for me, it is the same experience. It's a dead language, and we are switching to Python, that is far better to maintain for me and for all our new hires. I mean, Perl doesn't even has a debugger on Windows.
Not true by any stretch. I've used komodo[1] for more than 2 decades as a debugger in Linux, Mac, and Windows. More recently VSCode on all 3, for debugging.
Definitely not a dead language. A mature and stable language, which won't surprise you.
