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.
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?
>>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.
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.
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.
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
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.
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.
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.
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).
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.
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.
[+] [-] mmaunder|4 years ago|reply
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.
[+] [-] forgotpwd16|4 years ago|reply
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.
[+] [-] handrous|4 years ago|reply
[+] [-] kamaal|4 years ago|reply
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.
[+] [-] jerf|4 years ago|reply
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.
[+] [-] notreallyserio|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] justinator|4 years ago|reply
But that's what Perl 6/Raku was supposed to be, right? And that turned out to be a disaster.
[+] [-] newaccount2021|4 years ago|reply
https://metacpan.org/recent
many packages I rely on have weekly updates
[+] [-] bachmeier|4 years ago|reply
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.
[+] [-] davidw|4 years ago|reply
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.
I wrote something similar about Tcl years ago: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
[+] [-] acemarke|4 years ago|reply
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.
[0] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...
[1] https://www.reddit.com/r/reactjs/comments/px6kxy/redux_toolk...
[2] https://redux.js.org/tutorials/essentials/part-2-app-structu...
[+] [-] forgotpwd16|4 years ago|reply
How is this different from modern languages making similar posts about how they're very active?
[+] [-] newaccount2021|4 years ago|reply
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
[+] [-] bloblaw|4 years ago|reply
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.
[+] [-] brtastic|4 years ago|reply
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
[+] [-] pram|4 years ago|reply
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.
[+] [-] oneweekwonder|4 years ago|reply
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.
[+] [-] tyingq|4 years ago|reply
[+] [-] bluedino|4 years ago|reply
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
[+] [-] CodeWriter23|4 years ago|reply
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.
[+] [-] giantrobot|4 years ago|reply
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.
[+] [-] MarkusWandel|4 years ago|reply
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.
[+] [-] mongol|4 years ago|reply
[+] [-] bloak|4 years ago|reply
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.
[+] [-] chefandy|4 years ago|reply
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?
[+] [-] extortionist|4 years ago|reply
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:
>> $string =~ m/(pattern)/i;
>> my $match_text = $1 || '';
>> $string =~ s/pattern//gi;
>> import re
>> match_obj = re.find(r'(pattern)', string, flags=re.I)
>> match_text = ''
>> if match_obj is not None:
>> match_text = match.group(1)
>> string = re.sub(r'pattern', '', string, flags=re.I)
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.
[+] [-] debacle|4 years ago|reply
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.
[+] [-] 0xbadcafebee|4 years ago|reply
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.
[+] [-] Animats|4 years ago|reply
[+] [-] int_19h|4 years ago|reply
(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.)
[+] [-] justin66|4 years ago|reply
[+] [-] manbart|4 years ago|reply
[+] [-] sethammons|4 years ago|reply
Perl is not on my resume :)
[+] [-] arunix|4 years ago|reply
[+] [-] streamofdigits|4 years ago|reply
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"...
[0] https://www.slideshare.net/cmnunes/bookingcom-perl
[+] [-] dreyfan|4 years ago|reply
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.
[+] [-] Hermitian909|4 years ago|reply
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.
[+] [-] mywittyname|4 years ago|reply
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).
[+] [-] netcraft|4 years ago|reply
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.
[+] [-] orf|4 years ago|reply
Look at the first code snippet. Complete and utter nonsense. Or this other golden child of “advanced object systems”: https://github.com/moose/Moose
Dead. As a doorknob.
Sorry. Languages come and go. Perl has gone.
[+] [-] oblib|4 years ago|reply
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.
[+] [-] uxp100|4 years ago|reply
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.