While the authors accusation audit is impressive, I can assure you, as a CPAN contributor and someone who has launched some very successful Perl web apps, that Perl is in fact, completely and utterly dead. It died well over a decade ago when all focus moved to Perl 6 which didn’t emerge until recently. Everyone moved on except a hardcore group of advocates. They aren’t coming back. If a new language and community emerges that happens to have the same name, I’ll certainly take a look. That hasn’t happened yet. And it’s a damn shame because the mod_perl list and community had some killer talent in it that was creating the most innovative and heigh performance web applications out there. I created WorkZoo in Perl which was a very high performance job meta search engine and was one of Time Magazines top 50 sites in 2005.
What happened to Perl is a damn shame. Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.
>Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.
Funny as, quite similar to Perl, it took about a decade for a new major version (v. 7) and in the meantime there was a failed experiment (v. 6). And, quite similar to Perl, people were saying PHP is a dying language only alive thanks to some old major projects (WordPress, ...) that are written in it. Moreover, exactly like this very blog post, there were articles written saying that PHP is not dead.
You also had facebook pumping resources into PHP with HPHPc, HHVM, trying to compile a spec, etc.
That definitely would have helped keep PHP alive through the period between PHP 5 and PHP 7.
Additionally, PHP's releases of 5.3, 5.4, and 5.5 introduced enough new functionality that the bump was more than incremental. It had backwards-breaking changes, which should have warranted a new major release if PHP followed semver.
What's missing from Perl 5, would you say, that's holding it back? Performance? Language features? The "line noise" stigma? (yet, Haskell is trendy and it's at least as "line noise" looking to me, in typical use, as typical Perl is...) Package management and other tools?
This is a bit like asking what's wrong with your ranch by describing the grass. The problem is there's no cows on it.
You might argue that sufficiently appealing grass might persuade cows on other ranches to jump the fence and come over, but the reality is that the grass on those other ranches is very nice at this point and getting greener faster than the grass on Perl Ranch.
The users are gone and aren't coming back. Without those, you don't have a language.
I have a tattoo of a Perl camel, and of a Ruby ruby. I loved Perl, but to me anyway, Ruby was 95% of the good stuff of Perl, with 5% of the downsides. Some of that last 5% of good stuff was things that you could even argue isn't actually good stuff, but I like it anyway. ($_ is my go-to example for this.)
"Why not {Ruby,Python,PHP,JavaScript}?" is imho the question that Perl has to answer, and hasn't found one that enough folks find compelling, it seems.
This thread is making me so nostalgic... it's hard to overstate how influential Perl was on me.
I'd definiely switch to Roby anytime now that it's also faster, post 2.5. But our codebase is written in Perl 5. Why now Perl 6/Raku? Because it's slow and also has a smaller community around it.
I like your analogy. But the more accurate statement is that perl has a fraction as many cows as it once had, but still more cows than other not-dead languages. It still gets more daily uploads to CPAN than Haskell gets to hackage.haskell.org packages, for instance.
Perl spent almost 20 years with a new version looming over its head. It was known from the start that Perl 6 would be incompatible. This meant it always seemed to be a bad time to get into Perl. You were committing to having to do a partial re-write whenever Perl 6 happened to come.
As more time passed and the differences between 5 and 6 became bigger, companies that had been holding out for Perl 6 started to ask "If I'm going to have to do a re-write, why not re-write in something else?". Which is what we ended up doing.
I think there are various other warts in Perl compared to other languages in its niche, but I don't think they killed the language.
I think you are absolutely right. The warts only exacerbated the process you describe, because when potential new users checked out Perl and saw the warts, it seemed a lot easier to wait for the new version that was supposed to address many of them. So new users as well as existing users put off investing in Perl until the next version. In the early 2000s, it didn't make sense to learn Perl 5 unless you had an pressing need, because Perl 6 would be out soon and would have a much easier learning curve.
Perl 6 has to be one of the most destructive failures ever committed by the stewards of a popular programming language.
It feels like it almost did. There was a pretty frustrating couple of years there where it wasn't clear if 2.x or 3.x was going to be the winning version and the Python community seemed to have a lot of disagreement on that subject. My team invested heavily in alternatives like Node.js at the time to hedge against Python dying.
However, Python 3 did at least eventually have a reasonable backwards compatibility story which Perl 6 never really seemed to have. It's a bit harder to do now since Python 3 has marched on while Python 2 is formally unsupported now, but for a while in the 2.7/3.3 days, it was relatively straightforward--if a bit icky at times--to have a single code base that would support either version of Python, and many library and app developers took advantage of that to allow as-seamless-as-possible transitions, rather than the whole community having to immediately spend a ton of effort porting their entire code bases to an incompatible language. Mechanical code rewriting tools which were introduced during that period like 2to3 also helped ease the transition for many use cases and code bases, too.
The downside of all that is related: Since source compatibility was possible, the package distribution method remained the same, and at the same time for all the usual reasons, some useful packages never got updated with Python 3 compatibility changes. Today, there are still libraries in PyPI which can be pip installed with Python 3, but you can't actually use them because they never got the attention needed to be compatible with it. If the package is a pure Python code base, you might not even find out until you try to import the library or call a function, class, or method. Then you get to spend time in your favorite search engine trying to hunt down an alternative. Very annoying.
First, Python 3 wasn't intended to be a significantly different and superior language. It was always intended to be a one-time chance to fix warts and unfortunate decisions, not change the look of the language. For a beginner, the difference would look superficial, even though some of the changes were deep. One of the most fundamental, valuable, though ultimately troublesome changes was to change the string type from byte strings to Unicode strings, a change that to a beginner looks like a simple upgrade. You could start learning Python 2 and switch to Python 3 later at very little cost, or, as an experienced Python 2 programmer, you could feel at home writing Python 3 very quickly. You could also learn Python 3 and then go interview for a Python 2 job, because nobody would worry about your ability to adapt.
Second, Python 3 existed, which renders every other comparison hypothetical. For example, the Perl 6 project was supposed to deliver a language-agnostic runtime that would run Perl 5 code and allow it to be used by and used from Perl 6 code. Hypothetically, that might have been a superior way of providing continuity to the community than what Python 3 did, but we'll never know.
If you went looking for the best practices, you would find a few things but mostly you would find garden path tutorials leading you through many suboptimal ways of doing things and then finally recommending a final, also suboptimal, way. There was a book on Perl best practices that was full of recommendations on how to do things, and after not too long many of the techniques were deprecated. In other words the book was wrong yet it was the go-to book when it came out. Sure it’s normal for tech books to get outdated but this seemed to be a different level.
Then you hop over to the Python docs and see this phrase, paraphrasing here, “there should (generally) be one preferred way to do it.”
This is what kills it for me more than anything else.
Perl's syntax is incredibly unintuitive. People joke about it being the only "write-only" language because you can write some code and 6 months later come back to it and have no idea how any of it works.
Code is read far more often than it is written, so readability is important, and Perl lacks it.
You can, but you don't have to. With some self discipline, Perl can be very readable. The only problem is that actually requires skill and agreement in development team. Perl Best Practices helps with that.
The strict guidelines followed by the one Perl shop I worked at briefly kept things very simple, but also very different from the "Modern Perl" revival that was being pushed back then, in the early 2010s.
The company I worked at maintained some ETL pipeline on behalf of Yahoo, and the strict guidelines from the client and the ones developed internally stayed you from using anything coming from CPAN.
That means that you didn't get to have function signatures, as those were a package back then, you had to declare all your arguments at the beginning of the subroutine body by taking them off the implicit parameter variables.
Programming in it wasn't crazy for sure, but it just felt like a really clunky Python. The split between the data structures that could be handled by reference and the ones that didn't was very unfortunate, Yahoo mandated that you only use the ref-type, and you had to be converting back and forth.
Well, that was part of my experience working for some 6 months at a team where strict discipline kept a big system working, but there was little upside to using Perl. The worst was the error handling in this scheme, keeping your own makeshift stack trace with backing up the error variables was a hassle.
A reasonable syntax, try/catch/finally built in, subroutine signatures as a default feature (not 'experimental') and a sane class system would be a start.
The class/package system is actually my favorite part of the language, and the reason I put up with the syntax warts. It goes one step better than JavaScript by putting methods and attribute storage into separate namespaces, and supports multiple inheritance, and lets you modify the method tables on the fly.
Why do you believe Haskell is trendy? I love it as a language but it seems very much not trendy in terms of usage vs something like rust where a lot of people seem to be doing things.
It can matter, since companies want to see experience with what they're using, when they hire, so developers don't want to get stuck in something that's declining. Hype and perceived popularity-trajectory definitely matter for keeping a language alive, and for hiring (devs will tend not to want to take your job if they'll be working with things they consider to be legacy and trending downward).
>>Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.
Who uses php these days?
I haven't heard any one start a new php project in years. Ruby seems to have gone the same way.
Python seems to have won the backend game, which actually makes sense as Python today is bloated like how Perl was once. And these days it feels like Perl with tab indentation. No wonder it fanatic following these days.
Frontend game is now owned by Node, ReactJS, JS etc.
Who uses php to do anything? In fact I don't know of a single college kid I've hired who has even looked at php let alone used it.
Why is "college kid skills" relevant for anything? Do you make tech and business decisions based on what your incoming jr people want to do?
Many people in my circles use PHP for ... lots of stuff. I just got back from a PHP conference, and saw hundreds of people there are using it.
"Python seems to have won the backend game" - I'm really curious where you get that impression from. I can't imagine it's relating to publicly available web servers. That's not a total view of everything, of course, but... absent other numbers/studies/reports, it's really hard to draw any conclusions that aren't just based on personal experience.
WordPress, Drupal, Magento, Joomla, OpenCart and lots of other open source community CMS and online web-store type things are built on it. Sadly it will never die because it has Facebook pouring money into it.
The real problem with these kinds of posts is the equivocation in the word "dead".
People wanting to defend languages (also APL lately) want to implicitly use a definition something like "0 people are using it and no work is being done in it", but by that standard you can't ever declare anything dead. That doesn't make the definition "wrong" but it does make it not useful. The purpose of a definition is to split the relevant set of possibly values into at least two non-empty sets.
Other people are looking at the first and second derivatives of how many people are using it, how popular it is now compared to its height (in the programming language world it's already a problem if your "height" of usage isn't right now), and the likelihood of it ever coming back.
From that point of view, Perl 5 is, if not dead, certainly very close. To me, most tellingly, Perl 5 has no plausible path that I've heard for acquiring some unique value proposition that can give it a new lease on life. As I said in https://news.ycombinator.com/item?id=26567151 , in a lot of ways Perl's biggest problem right now is that it won. It convinced people that its way was good, and as a result, Perl's previous value proposition has been incorporated wide and far in other languages. The only time I pick up Perl now is when I have the need for a seriously heavy-duty string munging task that fits into about 200 lines, and I get huge wins from the RE syntax in Perl. And by time-of-use, Perl is probably my "best" language, the one I've used for more clock time than any other. Even so, that's where I am in 2021.
I would encourage the community to either decide that it's OK just continuing on as it is, or decide that it wants to try to find that new unique value proposition that will give it some sort of unique value in 2023 or 2024. But there isn't an option where Perl continues along as it is and it experiences some sort of burst in growth. You have to pick one, you can't get the advantages of both.
This sort of absolutism is so frustrating. If the term doesn’t describe something 100.00% right, someone’s going to nitpick. Analogies suffer the same fate.
> I would encourage the community to either decide that it's OK just continuing on as it is, or decide that it wants to try to find that new unique value proposition that will give it some sort of unique value in 2023 or 2024
But that's what Perl 6/Raku was supposed to be, right? And that turned out to be a disaster.
I don't guarantee the success of an effort to find a new value proposition! It is necessary, not sufficient.
And it broke away so far from Perl 5 that it is no longer Perl 5's new value proposition. The Perl 5 community will need to come up with one of their own.
In time it broke away but ~20 years ago, the promise was backwards compatibility. Looking back, that's madness, but it's one of the decisions that totally grounded development of Perl 5.
What I wish would die is discussions of the death of languages. It's as useful as classifying people as good and bad athletes. Everyone is better or worse at some sports, and the threshold for switching from good to bad is purely arbitrary.
It's better to have discussions with substance. "Perl job advertisements are down 34% in the last five years" might be useful. "Perl lacks libraries to do [task]" might be useful. "Perl is dying" isn't.
If you have to write forceful "It's not dead! Really!" blog posts, it kind of gives away the Weekend at Bernie's game.
Snark aside, to try and add something more useful, having seen languages rise and fall, it seems that "not growing" or "gradually losing ground" are kind of what people label as "dead". If lots of people aren't regularly starting new projects with it... it's not healthy.
Heh, I wrote "Redux - Not Dead Yet!" in 2018 [0] to counteract FUD from the Twitterati, and updated it again in 2020. If nothing else, it's saved me from having to rewrite the exact same answer hundreds of times in separate replies.
Happily, threads like this recent "Redux Toolkit is awesome!" Reddit thread [1] show that our efforts to keep improving Redux and let people know about "Modern Redux" (the combo of Redux Toolkit + React-Redux hooks) [2] have been bearing fruit.
Because "we're active" is something you want to see in a language - even if the language has little adoption, being active is positive.
"We're not dead" on the other hand is defensive. Even if the language has a big community still, it means people are leaving.
And the thing is new users seldom go to big but dying languages. They'd rather go to small but growing languages (which at least are more exciting), but even more probably, they'll go to medium to big but growing languages.
I love perl and simultaneously totally at-peace with it being "dead"...but it really isn't. Packages I care about are updated regularly. The core release is deployed regularly. There are numerous meaningful improvements discussed on p5p.
Fastmail, my email provider, runs on perl. You can get perl jobs in 2021.
The community is smaller now but more dedicated - not growing, but not dead either.
In any case, none of the moderately popular languages will die anytime soon...between the platforms that still run on them, and the geezers who have the time in retirement to volunteer, tools will survive
> none of the moderately popular languages will die anytime soon
Correct. As long as people are using stuff in production, the high costs of switching ensure that some maintenance will keep happening. That's why we still have things like COBOL, even though I don't think much of anyone is all that enthusiastic about it.
Perl is simply a tool. I still use it all the time for small scripts and automation.
I know Python, Go, C#, and a bunch more....but I reach for Perl when the task calls for processing lots of text, or quick automation. Others might reach for Python or Ruby or Go.
For me it's a better bash script, a better grep, a better awk, a better sed. That's what Perl was designed to be, and I don't think any other scripting language matches it for that purpose.
It is not a tool to build desktop applications or the first choice for web applications in 2021.
But it is still extremely useful for its niche...processing data/logs/text, or system administration tasks. It really shines there and that's how I use it.
It's another tool in my toolbox, and learning Perl has made me more productive and I still reach for it today.
The tool analogy is flawed. Languages that move fast and break backward compatibility are tools, but organic. If you leave them in your toolbox for too long they start to rot.
This does not apply to those languages that do not get updated (bash?) and that does not break backwards compatibility (perl? but without CPAN modules). I know that my PHP tool has rotted even though I was actively using it. It moves too fast and the frameworks I was using are no longer any popular - should've learned symfony instead of yii, now laravel is taking over
The only reason I know Perl is because I'm old enough to have started in the 90s when it was the new hotness. Starting today I'd obviously have learned JS or Go or Java or Rust or Python instead. Perl in 2021 probably seems like some curious antique like AWK, if they've even heard of it.
That is the real problem I think. There is just no good reason to use it, and thus learn it. It doesn't do anything better than the alternatives. It's not "dead" but there is very little new blood entering the scene. It's a retirement home.
> Perl in 2021 probably seems like some curious antique like AWK
Sure you can call awk an antique tool being 44 years old, but its available on almost all unix-like systems even on router running busybox or bare minimum containers using alphine.
So its definitely a personal nitpick of mine calling a very relevant tool an antique.
Awk is handy for bash programming. It's one of those weird tools in the box that is extremely useful in a very few specific scenarios, and that's what is keeping it alive.
No sane person is going to write an entire application in Awk anymore. But there are certainly 20 years old there who will encounter Awk while doing some command line data munging via SO and it will slowly become a tool in their toolbox.
Perl doesn't really have that. Sure you can ` | perl -e "..."` but honestly, I can do that with python/PHP too. I haven't encountered an SO answer for command line data processing hacks that have used perl in ages.
There is a book, "Minimal Perl", that is entirely about that usecase. I found it convincing, 15 years ago, and the only Perl I use are those terse command line snippets it teached, when others might use some combination of grep, sed and awk. I don't know if it is the best tool for the job, but it has worked for me.
I wrote an Awk script a few weeks ago precisely because I needed to filter some text. Python would be more verbose than I needed, Sed would become a write-only mess, but Awk in a Bash wrapper was just right.
AWK is sweet for big/streaming data analysis operations because by default awk/sed handle data without allocating memory. They're still highly used in these use cases just because it's typically easier to munge a gargantuan CSV file using command line tools that zip fast as fuck through it to get to the data. These tools come from days when malloc wasn't just an expensive bottleneck computationally, but expensive in terms of like 32MB of RAM or way less. If I need an application to get to data that huge (And there is PLENTY OF IT and more to come in these days, so it's pretty dope and groovy that this tool from the 70s is one of my best friends still -- care for your elders), I will get all modern or whatever and write one in go.
Somewhere, I've got a book for programming awk. It's got some really neat things in there that are non-trivial awk scripts from yesteryear.
I could see that being useful in the 70s or 80s... but not today. No-one writes awk more than a line or two today that's nestled in some ci script that is never looked at again.
Yes, the tool is ubiquitous - its everywhere. It also happens to be part of the standard of what is on a machine which keeps it being used for those two liners.
However, people aren't writing applications in awk anymore.
Similarly, perl is going to go the same way. It's going to be useful for those 10-20 line data transformations that are in some data pipeline for munging data. But its not something that's continuing to grow and find its way as a first choice.
Writing a new application in awk is something that people do for the exercise - much like going and doing your own primitive photography with a cyanotype. It's done as a "yes, I understand it enough to do this complex thing." Perl is a bit further back... it's developing your own film. There are still some people who do that as a matter of their business - but its not a first choice anymore.
Cyanotypes and doing your own darkroom work are things of antiques in today's age. They're not gone - but doing things in them is more like going to the pioneer town and seeing how it used to be done rather than a practical choice for today.
It's still a popular tool in the data processing realm. It's crazy to think that bash scripts using pipes is still one of the most memory efficient ways of processing file-based data. Even tools like Apache Airflow just went ahead and incorporated bash for this exact reason.
I imagine the old "Command Line Tools can be 235x faster than your Hadoop Cluster" story still applies. That is, there's probably a fair amount of data processing that could be done well with Perl (or awk, etc).
>> The only reason I know Perl is because I'm old enough to have started in the 90s when it was the new hotness.
It was _the_ choice to use to write web pages in at one point. I remember installing RedHat Linux, writing a support 'forum' message board thing in Perl, then chucking it away as everyone was starting to use ColdFusion, PHP and .NET
I’ve coded in Perl since the late 90’s up until about 3 years ago. Thought Dancer and Dancer2 were awesome web frameworks. Especially loved making my own app-specific DSL.
Then I took a consulting gig and the framework server side was Laravel. I switched and never looked back. I’m even porting one of my Dancer2 backends to Laravel.
My main reasons:
1. Laravel has so much momentum, the tooling is so superior to Dancer2 that the Dancer2 crew will never catch up. The schema migration management alone is a killer app that will drive switching. And tons more.
2. In patio11’s post about selling Bingo Card Creator, he indicated implementation language is a key consideration for a buyer. They want to be able to draw from a larger and possibly less expensive talent pool for maintaining and extending the software. PHP wins on both of those metrics.
3. I’ve reached the point in my life where I want to do stuff WITH as opposed to do stuff TO my applications. Size and cost of the Talent pool is relevant in this way to me for the simple reason I know there aren’t enough hours in the day to do it solo.
I always wanted Perl to make it back into the mainstream. It will never die. But to me at this point, Perl is as impractical as some of my crazy ex-girlfriends. I bid it the same affectionate farewell.
Perl isn't dead but its usage is not growing and I don't see any reason it will ever grow again. Unless you're an old school Perl hacker there's little reason to start a green field project with it today.
I say that as someone that has written a lot of Perl over the years. It turned out to be an awesome language for CGI apps in the early days of the web (the reason I learned it). It was also a better system administration/automation language than some bash/awk/sed/grep amalgamation.
For me at least it fell down once you got over a few hundred lines. The TMTOWTDOI led to your own (or at least my) code being internally inconsistent and the lure of its shorthand meant coming back to old code took some effort to understand.
I moved from Perl to Python and it helped immensely with both those problems. Once I grokked Python's regex I could do everything in Python I used to do in Perl with the same speed but half the effort.
I don't see any attraction of going back to Perl. It was a nice tool for a time but now there's better tools (IMO). So once old deployments of Perl apps/tools are replaced I really don't think they're going to be replaced with Perl.
On my Linux system I could, if I wanted to, write programs in (the subset of bash that is) Bourne shell, awk, plain old 1970s vintage C, implement text filters in sed... all these are antique things that don't need a vibrant user community. They just need to work well enough to support existing stuff written in them, and for an occasional quickie script by old farts who know how to use them.
Why should Perl be any different? It'll be decades before a practical system won't have a Perl 5 compatible /bin/perl on it. So if I know Perl well enough that I can hack something up in 5 minutes, and Perl is there and works, how is it alive or dead? It just is. And that suits me just fine.
Good point. The alive / dead metaphor is not so useful to descibe the language itself. Perhaps it is the community that should be described as alive or dead. The language itself is just a tool. It never was alive, but as long as it works, it is useful for those that choose to use it. Just like a hammer can be useful long after the toolsmith that made it died.
I use Perl all the time for short programs, up to a few hundred lines. The main advantages of Perl are that it's already installed on all the systems I use and the language itself is not changing: Perl scripts I wrote 20 years ago still work, and I have a vague hope that Perl scripts I write today will still work in 20 years' time.
Maybe Python is now stable enough for me to consider it as an alternative to Perl but I've bad experiences trying to run Python scripts from 20 years ago. In any case, Python is less concise for the sort of programs I write, and although Perl has a reputation for being unreadable it really depends on who's writing it. I write in a subset of Perl, with "use strict", that I find to be readable. I find Perl stops being convenient at about the point where you need complex data structures and modules.
The only reasons I could think to use perl over Python are regex execution speed and 'maybe' infeasibility of accessing PyPI so you'd need more built-ins, but still have plenty of disk space... though I haven't done any feature parity comparisons there.
Am I missing anything?
I liked Perl back in the day and used it a lot but even my old sweet-jesus-what-was-I-thinking Python code is a LOT more readable than my cleanest old Perl code.
I'd be curious to hear from folks who've also been deep in Python and Perl but stuck with Perl rather than Python— different use cases? Coding styles?
My job is split between maintaining a giant legacy perl codebase and doing new dev work in python. I vastly prefer python overall, but perl's still the best when you need quick one-off scripts to tear through log files or do some quick regex subs on a bunch of files.
I don't think python has an equivalent of 'perl -p -i.bak -e 's/foo/bar/g' *', for example (which will do in-place regex substitutions on whichever files are passed in, additionally copying the original files to 'original.ext.bak').
The regex syntax is also bit more streamlined in perl, so I find it quicker and easier to throw together a script that's just doing regex stuff in it. A simple example:
Of course, the same magic that makes perl great for those one-off kinds of scripts makes it less than ideal for complex or long-living scripts that need to be maintained by multiple people, in my opinion.
No doubt: the regex syntax in Perl is most efficient. I can envision using Perl more if I ever got back into a command line focused text manipulation workflow. I tend to use lighter-weight tools for things like your one-liner— I believe `sed -i '.bak' "s/foo/bar/" *` is equivalent, but I disagree with the neckbeard purists who say you should always use the lightest-weight tool possible. If you're using Perl anyway and Perl can get the job done with the smallest cognitive load, that's the correct tool.
You're right— I didn't say what I really meant there. It's not the regex syntax itself, but the syntax surrounding the use of regex's which is more efficient. Compare the number of keystrokes in his examples above (e.g. $string =~ s/search pattern/replacement string/g;) with what you'd have to do using nearly any other language. In Python for example, remember that you'd need to precompile the regex to even approach 8x slower speeds.
Well, that was inspired by sed. I have to do a test in Ruby too see how fast regexos are, being spoiled by Perl usage and all. What I don't like is this:
my $a = 'Perl';
my $b = $a;
$b =~ s/pe/ea/i;
Why not do something to $a and obtain $b, just like js does with Array.map. Why the need to copy $a into to $b and then replace? Much more ellegant in Ruby:
oh— for regex performance Perl blows Swift, Java, Python, Ruby, Go, and C++ out of the water. For simple string manipulation— substring replacement, string reversal, etc. it's never the worst but never the best. Scroll down to the bottom of this paper where they test actual regexes though and the difference is pretty stunning.
I still love Perl. If I had the opportunity to work on an existing Perl project, I would relish the nostalgia.
I would never, ever use Perl for a greenfield project unless there was a library that was absolutely crucial to the development, for many reasons.
Perl 6 was so disastrous to the ecosystem that it effectively killed the language. If 20% of the effort that went into Perl 6 had gone into keeping the language fresh, I think Perl would still be part of the conversation today.
I still use Perl all the time for random tasks. It is exceedingly fast and simple to create very powerful programs using stable libraries, and all the legacy code still works. It's the most handy general purpose scripting language, period. And you can run it anywhere.
I don't use it for "portable" things, which is funny because it's more portable than any language I can think of. I write things in Python if anyone other than me has to support it or run it, and Bash if it's just going to be embedded in a system where I don't want to make Perl a dependency. But to do something powerful and fast just for myself? It's Perl, baby.
There should be a convention where the APL people, the LISP people, the Perl people, and the Pascal people get together and talk about the good old days.
(Seriously, though - in retrospect, it feels like most of the complexity that the language was criticized for is standard fare in PLs of today, often in the same shape.)
We managed a several thousands node cluster of perl services. We took several years, but we recently finished migrated all of this off from stateful Perl to stateless Go all the while growing rps volume 40% yoy and migrating datastores as we scaled those too, continually improving stability and availability, adding features, and scaling the org from a few hundred people to a few thousand. We are now 100% off perl for our critical path.
Stateful means state is stored in memory or on disk by the processing service. Stateless means that state is stored distributed to multiple nodes and can be recreated or that there is a design such that no state is needed. In the first case, a node dies and information is lost, in the latter, no information is lost. This allows for greater scale by often saving resources per request and increasing resilience.
A concrete and simple example: an api request comes in and you call n dependent services before responding. If any of those calls fail, the entire response 500s, if ok, respond 200. Instead, make this a job with a 202 response with an id returned and use a distributed queue and workers to async process the request and allow the job results to be queried by job id. Now any node failures are invisible to the client.
Billion dollar companies have been built on perl[0]. So let us not seek to fix the blame for the past, let us accept our own responsibility for the future.
Seriously though, how large a collection of programming language ecosystems does the world want or need? How many equivalent stacks, all solving the same problems with more or less the same patterns and concepts?
Just a thought: Open source communities could benefit from less dispersion of energy and talent, less endless re-invention of the wheel, less endless "not-invented here syndrome"...
There’s far more venture capital than innovative ideas and the business problems are rarely hard to solve. Engineers get bored so we have a constant flow of new languages, frameworks, and lately, an overwhelming focus on tooling and infrastructure.
At the end of the day, most companies are just generating dynamic HTML after performing some rudimentary CRUD database operations. It’s disappointing so
much time and money is spent only to arrive at the same place that /cgi-bin/ and a perl script solved over two decades ago.
The open source ecosystem is concentrated. There are far more OSS packages for javascript or C++ than, say, Rust.
Less popular programming languages are talked about much more than they are contributed to, but they're talked about precisely because they're often solving problems that are major pain points in people's lives.
I'm personally rooting for OCaml, assuming some current efforts bear fruit I'd love a language with the following properties:
- An extremely expressive type system with type inference
- Incremental builds so compiling is fast
- Good compile to JS story so frontend/backend share types as well as serializers and deserializers
- Only slightly slower than C (think Java perf)
- Good multicore, perhaps even with typed effects
- Can be run in a unikernel so I can ship my program as a simple image
Any language with this feature list would solve a lot of personal and organizational problems for me and many other programmers I know. None of the really popular languages I'm familiar with can achieve these goals due to backward compatibility requirements.
>how large a collection of programming language ecosystems does the world want or need?
There are many problem domains that can be solved by computers, and having a language specific or well suited to that niche can be a productivity boon.
As long as humans continue to discover new problem domains in computing, they will continue to develop new programming languages to work in them more efficiently (and existing languages will expand to try and fill that niche).
yes, I am not arguing for a single language. But many of the domains you mention are actually intrinsically similar once you map them to the underlying information flows. This explains for example the extreme ubiquity and longevity of things like relational databases and SQL.
There are several genuine and orthogonal domain "dimensions", e.g real time systems or parallel processing etc, but I would say that is a handful, not the multiple dozens even hundreds of idioms we use to program digital devices...
What I would like to see in posts like this is a description of the kinds of programs the author thinks are great candidates for this language over others, maybe with an acknowledgement of the other options and a comparison of why (in this case) Perl might be a better choice. I see a lot of the things listed that they think are strengths, but many of them are shared by other languages that don't have the negatives (even if a lot of those negatives are just perceived) - so why should I choose Perl in 2021?
I have professionally written a few languages in my life that the zeitgeist would consider "dead" - what I always see in those communities is a lot of people crying that they aren't dead like something out of monty python - and that its "actually a great language", but no real pitch about _how_ that would apply to the prospective people who might pick it up. These conversations always come across as delusional, fan-boyish, and the opinions of people who feel pot committed to the language they've spent so much time in and are not willing or able to pivot, begging people not to think that they chose poorly.
I truly don't know if this applies to Perl, I certainly have opinions long held and maybe things have changed over the years, but in a world with so many great options today, to make a dent you have to paint a picture for people to convince them to give it a shot.
And yet, the “nonsense” you see is the object paradigm I love the best out of any language I’ve ever used. It’s what keeps me on perl instead of moving on to other more trendy (and restricted) languages.
I didn't say you couldn't, just that the 'nonsense' is actually quite nice to use in practice.
Lets play Rosetta Code for lazy attributes:
package Something;
use Moo;
has hostname => ( is => 'lazy' );
sub _build_hostname { chomp(my $x= `hostname -f`); $x }
How would those look in Python or Ruby?
Meanwhile there are many things not on that page which Perl can do and Python and Ruby can't. (most related to taboo runtime changes of global state which are not recommended, but come in very handy when debugging)
class Something:
@cached_property
def hostname(self):
return socket.gethostname()
I guess, kind of hard to tell what your code does because it is honestly indirect nonsense where you need to know details about some specific library that implements some specific form of objects written in a language that is not exactly well regarded for it's legibility. Meanwhile the code above is clearly readable by anyone with even a modicum of programming experience.
There's also nothing on that page that I can see which Ruby and Python couldn't do. Both are exceptionally good at taboo runtime changes of global state.
Interesting, I hadn't seen @cached_property before. I was expecting you to have to muck around with __getattr__. The lazy attribute in Perl is simply one whose constructed value is deferred until the first time it is used.
For an example of taboo runtime changes, suppose you have one module which operates on a tree of data, like converting to JSON, and another type of object within that tree which does not have a built-in serialization to JSON, like DateTime. (there is really no way to universally serialize a DateTime to JSON because JSON only supports strings arrays and objects, and representation of dates will be application-specific). Perl lets you temporarily inject a method into a class for the duration of a scope, in this case the TO_JSON method which the JSON module looks for:
sub export_as_json($data) {
local *DateTime::TO_JSON= sub($date) { $date->ymd };
JSON->new->convert_blessed->encode($data);
}
After that scope, the DateTime package is restored to normal, without a TO_JSON method. How would Python solve this problem?
So firstly, it's not up to an object to know how it should be serialized to JSON. It's up to the serializer, and that can be trivially done with the `default` argument:
In Python your code above can usually be done with:
date = datetime.date.today()
date.foo = lambda self: print("hello!")
date.foo()
And this will work on any object that's not defined in C (which unfortunately datetime objects are):
class Omg: pass
Omg.foo = 123
print(Omg.foo)
If you wanted that reverted after a block is finished, you'd use a with statement:
with patch(date, "foo", some_value):
date.foo()
There is rarely a need for this outside of tests though.
More generally, you can modify any non-c Python object in any way you want. Nothing is private or protected.
If you're thinking that Perl is special because it has reflection and a dynamic object model, or lazy properties, you've been asleep for quite a while. These have been table stakes for a very long time.
Maybe so. for some reason I thought Python made it hard to modify a class after declaration. I might be thinking of PHP, or maybe I tested something on a C-backed object without realizing.
For what it's worth, Perl lets you freely mix C methods with pure-perl methods in the same object. I also don't think Python has an equivalent for Inline::C
Getting back to the Moo topic though, you seem to hate the idea of reading user-module documentation to use an object system, but I see that as one of Perl's strengths. Perl's native object system is nothing more than data elements (usually hashrefs, aka dicts) "blessed" with a method table, and the method tables are nothing more than a dict of methods and variables. And you can use user-written modules to generate those packages, and create whatever syntax you like with the user-written modules without depending on core perl to add features. Reading the @cached_property Stackoverflow pages, it sounds like the way to implement this has changed several times over the past decade of Python versions. Moo works as-is on all perls since 5.8, released in 2002.
The ability to take some basic mechanics and build on top of that is what I like. There are dozens of object systems available in Perl because people were free to experiment. Moose was the first one that gained a lot of traction because it solved a lot of common needs. Moo gained a lot of traction for solving most of the same problems while being much lighter weight. I don't think it's any worse to read the manual for Moo than to read the manual for the decorators that Python provides.
There are quite a few packages you can use to build functions in C that operate with Python. Cython is probably the most popular.
Under the hood Python objects are very similar. Classes are mostly just hashmaps (obj.__dict__) and you can easily build something similar to moo in Python. In fact you’d just need some code to convert a module to a class, which is pretty trivial as they are very similar things.
Except you wouldn’t, because it’s madness. The closest you need to come to that is using metaclasses to build some kind of DSL, particularly common in ORMs.
I’ve got nothing against Perl, really, I’m against arguments that say “this language is wonderful because it can do X”, where X is something:
1. Every other language of that type has
2. Every other language does better
Yes, it’s cool you can build your own object model in a package. No, that’s not unique to Perl (Ruby does this more than Python). Yes, it’s a shame you have to.
I rewrote all my Perl app code in JS to run entirely on the client side years ago but Perl is still my go to server side tool. For example, I used to use HTML:Template, now I use Mustache.js.
I'm quite sure I could do most anything I do with Perl with Python instead but since that would be pretty much the only thing I'd use Python for I'd spend more time learning how to do it than is necessary.
I still use CGI.pm for a lot of what I do on the server side, which is not very much anymore. But for what I do use it for it's very good at and I've never had a problem with it.
What's the replacement for Perl based Verilog metaprogramming in the Intel (I think) style?
I'm being a little cheeky, but that is a use-case for perl at a few of the places that make the processors that the web-frameworks that no longer use perl run on. I no longer work at a semiconductor company, maybe they're moving away from that, but I'm not sure what would replace the in-line perl in verilog files that use perl as a pre-processor.
Perl is used in the background for lots of glue, and integrations.
But I don't think it was python that took over from Perl. When I think of the kinda web-applications I was writing they got replaced by Rails, PHP, and similar.
Eventually every technology will age and die after some time. Today, you may be proud of your intimate knowledge of Python, Golang, C++ or even JavaScript. But in 20 years from now people will have gone on and you might be left behind. So to all young and smug whippersnappers here: Memento mori!
What you need to find is a willing host to totally monopolize. JavaScript just isn't going away from the browser in my lifetime and JavaScript started out as a completely hobbled language that still has major warts.
Perl doesn't have that. Reads in strings, do stuff, outputs strings? Welcome to Unix!
Numpy/Scipi/Pandas/tensorflow etc all did for scientific/analytics but web frameworks also helped. Today what makes python so easy to use is the fact that there is multiple modules for everything.
Yet, deployment/versioning of python remains a shit show. Just the other day, I ran into an issue with the setproctitle package where certain implementations exposed a method via CPython while others didn't. So not only did it matter which version of python you used, but it mattered how it was compiled. The kicker is, the official OSX build from python.org doesn't work, you have to use a version that comes with OSX.
Only Python would have such a ridiculous problem in 2021.
I love Python, but it's best left in the data science space. Maybe the odd micro-service in Flask.
I would love to see more innovation in scripting languages. Nothing (I've seen) comes as close to perl for swizzling together a decent, capable, handy programming language with a variety of system binaries & other shell scripts.
There's a couple efforts like shell.js[1] or the far simpler/more-contemporary zx[2] to give shell-scripting like ease to js. zx's core is just at tagged template string for running system() calls, basically, ex: $`echo 2+2`. I still find the experience pretty sub-par compared to how shell & scripting first languages like Perl are.
Perl is just super powerful, keeping a foot in a more user-land like environment, versus the totalizing experience of libraries. Why do you need to pick a http client library to use when everyone is already quite intimate with curl & it's already on the system? Somehow coding keeps taking more turf, but I feel like Perl's scripting was extremely glorious & largely un-reproduced. Perl is still some of the best "glue" the planet has seen. And glue, as we've read a couple times on HN[3][4], & which I agree with, is really important, dominates what we build.
To the topic itself, as a Debian user, I appreciate Perl, but I wish it weren't on my OS taking up ~20MB of space & being more & more offbeat, but it's probably never going away. Not sure why it irks me that my computers will all need that ~20MB of Perl + Debian perl libraries. And it is pretty cool how debuggable & visible the Debian tools often are, because they're scripts, not compiled programs, by & large. But there's a lot of operators to lookup & a lot of implicit variables to remember in Perl programs, and it's a reminder how offbeat Perl is, every time I poke my head in.
I haven't used Perl in ages. Seeing all these new features in Perl 5, I want to use it again. I've looked at Raku and didn't like it. I think it went astray and it doesn't fit the spirit of Perl (being practical).
I think the business life cycle is also a useful analogy for languages
at some point no new software should be developed in a given language and you should just be maintaining existing code bases corresponding to managed .decline
Weird timing considering the community is actually dying right now - lots of talented people have left recently and many of my pro-Perl friends have stopped using for good.
Don't know exactly who you mean, but while sawyer x has stepped down recently, the dev team seems to be in good shape-- they've adopted the steering committee idea, and are using an informal RFC process to make decisions about new features.
The list is based on search engine hits for "x programming".
That's probably fine for comparing c to c++ or perl. Searches for "scripting" or "coding" instead are not counted, which probably explains shell scripting below languages 20x less popular if you search by the name alone.
Powershell at ~40, bash not even top 50. You'd assume both are dead from this list.
What happened to Perl is a damn shame. Many of us went over to PHP which is vibrant, keeps getting faster and better and is as practical as Perl was and hasn’t stalled.