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.
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.
I would never consider perl for anything new in 2024. I still use awk very regularly.
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.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Javascript is maybe 150% on average and C++ is maybe 200%.
If they're ever gonna do this P7 thing, it would be nice if there was a slight runtime improvement. There's some room available.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
If you already know Perl, you already know if it’s right for you. If you don’t, you’re probably better off learning Ruby instead.
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.
I, too, have 20 year old perl scripts that still run fine.
I randomly have to bang my head on my desk over bs with python and php incompatibilities between versions.
Pets perl
Over 25 years of Perl experience. Still writing new stuff daily, both for work and personal use.
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.
Perl just works.
To say "This isn't going to work in 7 years", and be taken seriously would be a welcome reversion to current practices against good engineering.
For reference, PHP at the time was at version 4, Python was around 1.6, and noone had heard of Ruby.
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.
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.
Major version changes are easy and rare.
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.
As a result, threaded Perl code or frameworks are extremely uncommon, even relative to Python.
I guess some people just want to stick with what they know, and refuse to learn anything new.
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).
And Laravel is a very good framework.
I really don't have much issue with modern PHP either, it gets the job done and unlike Perl is still very much evolving.
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 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.)
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.
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.
Now UNIX scripting that has no place being a bunch of sh scripts, definitely.
1. you like perl and enjoy coding with it
2. you are good with perl so internet criticisms don't impact your decision
3. you don't care about contributions from other people
Definitely not a dead language. A mature and stable language, which won't surprise you.