The reports of Perl’s death have been greatly exaggerated
phoenixtrap.com
phoenixtrap.com
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.
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).
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.
"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.
Also that "RUST CRAB" would fit on my knuckles...
It may still have a lot of cows, but it clearly doesn't have many calves and that's the statistic that speaks to the eventual fate of the language.
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.
Perl 6 has to be one of the most destructive failures ever committed by the stewards of a popular programming language.
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.
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.
Why would I want to go back to Perl when I could use a language that’s more popular and well-established now?
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.
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.
Many still hold it up as a model PL in various ways. I'm always promoting it myself ;)
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.
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.
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.
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.
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.
many packages I rely on have weekly updates
But that's what Perl 6/Raku was supposed to be, right? And that turned out to be a disaster.
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.
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.
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...
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
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.
How is this different from modern languages making similar posts about how they're very active?
"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.
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...
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.
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
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.
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
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 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.
A short example of that type of thing - https://people.sc.fsu.edu/~sshanbhag/awk-shell/histogram.awk
For the time, that was likely a very reasonable solution. But for today's world, there are better solutions.
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.
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.
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.
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.
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.
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?
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.
my $a = 'Perl';
my $b = $a;
$b =~ s/pe/ea/i;
a = 'Ruby'
b = a.gsub(/ru/i, 'mo') my $a = 'Perl';
my $b =~ s/pe/ea/ir; % perl -MData::Dumper=Dumper -e 'my $a = 'Perl'; my $b =~ s/pe/ea/ir; print Dumper $b;'
$VAR1 = undef;
my $a = 'Perl';
my $b = $a =~ s/pe/ea/ir;
I'm surprised there's no example in perlre(1); perhaps I can get that corrected.
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 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.
(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.)
Perl is not on my resume :)
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.
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"...
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.
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).
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...
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.
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.
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.
Lets play Rosetta Code for lazy attributes:
package Something;
use Moo;
has hostname => ( is => 'lazy' );
sub _build_hostname { chomp(my $x= `hostname -f`); $x }
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()
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.
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);
}
def encode(obj):
if isinstance(obj, datetime.datetime):
return obj.isoformat()
raise ValueError()
json.dumps(..., default=encode)
date = datetime.date.today()
date.foo = lambda self: print("hello!")
date.foo()
class Omg: pass
Omg.foo = 123
print(Omg.foo)
with patch(date, "foo", some_value):
date.foo()
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.
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
https://metacpan.org/pod/Inline
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.
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'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.
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.
Python took over.
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.
Perl doesn't have that. Reads in strings, do stuff, outputs strings? Welcome to Unix!
Are there equivalents for Perl?
Perl was my first love, but I rarely reach for it now, since I spend most of my time data munging and doing Tensorflow.
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.
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.
[1] https://github.com/shelljs/shelljs
[2] https://github.com/google/zx
[3] https://news.ycombinator.com/item?id=27486706 https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft...
[4] https://news.ycombinator.com/item?id=27880183 https://www.oreilly.com/radar/thinking-about-glue/
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
Is Perl dead? No, it's still among the top-20 programming languages.
Is Perl dying? Yes; it dropped 8 places among the top-20 programming languages.
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.