Python killed Perl by being actually readable. So much that sometimes it is easier to read someone else's Python than your own Perl. And if you got some legacy Perl to refactor oh boy let me tell you a story. I once had to rewrite an legacy Perl script to Python and had to debug it with strace to see which file it was opening. Imagine using tools designed for compiled binaries because it was easier than reading the source code. To top it off my python version was 20x faster. Not because python is fast but because a clean language allows you to make good architecture decisions.
It's kind of funny that in some contexts (basically not "data" contexts), Python is today where Perl was then, e.g. moving from Python to Go or even Typescript for readability and/or performance.
Agreed. Python is anything but a "clean" language at this point, its popularity is entirely driven by ecosystem, not first principles or adherence to them
While I frequently see moving to Go (or Rust) for performance I have never seen anyone move from Python to Typescript. JavaScript/Typescript ecosystem seems to be there only there because it is in the browser. Otherwise these are horrible languages even worse than Perl.
I don't negate that python has meh performance but if you are making a rewrite targeting performance might as well go with Go or Rust to get 100-1000x performance instead of 2-3x with JavaScript/Typescript. Especially since Go is much more readable and developer friendly language than JavaScript/Typescript. Rust has a harder learning curve but is safe and performance is even better than Go though that is seldom required as Go is also quite good.
I like Typescript for frontend/BFF, but yeah for backend and tooling that doesn't require the data wrangling ecosystem of python, Go is my preference. It is the most readable language at scale and over time IME, and the learning curve is great
I fully agree that Go is very readable. Python is probably the champion of readability and Go is a very close second. It also strikes a very good balance on ease of use and speed. I also like the approach of static linking binaries and their portability though in the age of containers it is a bit less relevant now.
Python is excessively magical in 2025 to be the readability champ. There are too many competing styles and redundant language features that have built up over time.
Maybe your preferred flavor of python is readable to you. There are at least 3 ways to define something akin to an interface, as an example. The OO story in general is bad and yet is the dominant paradigm. Nested comprehensions, which arguably shouldn't be syntactictly allowed, messed up the ordering. Dunder methods everywhere. The problem with python async isnt even readability, its the fact that most of the ecosystem formed before asyncio etc and the compatibility story is trash.
In the long ago, the way I hear it was that as others say mod_php killed perl for web, and as you say python killed perl for admin stuff. However, I would contest "readability", since early days python was also a bit rough.
What I saw more often however was that the python standard library was actually usable to craft whole sets of tools. Like, in perl I regularly remember not having basic file parsers for INI, XML, etc built in. And often, you weren't in a position to demand some CPAN package get installed on all the systems the script needed to run on. Also similar to php vs perl at the time, python was reasonably documented: I don't recall html files, I know on windows we had .chm and *nix users had something else alike that was equally reasonable to read/use. Not too far into py2 they started hosting online like php (though, no comments, which at the time I found to be a bummer, hindsight was probably a good idea to not have them...)
There is definitely some truth to having a decent standard library helped python a lot compared to perl. Especially in the early days when internet access was not as widespread in enclosed corporate environments in sectors like finance etc. While python clearly took the admin stuff and data processing, the web got taken over partly by PHP partly also by Python. Django was a huge breakthrough with the autogenerated site admin panel. The most basic dynamic sites also got swallowed up by WordPress. You might call it PHP but a lot of those deployments did not write much code if any.
There are two kinds of features in programming languages: explicit and magical. Explicit is what we are writing in the program, things like if, for, of a = 2; Magical things happen by, well, magic. Like when in C++ a variable of a programmer defined type goes out of scope, its destructor gets called. You need to know it, you do not write it.
Magic is pretty, but it makes the process of learning new languages more difficult. One common question is "are there destructors in Java?" meaning "I have this magic here, does it happen there?".
There is too much magic in Perl, thus few people used it as a secondary tool. The similar thing now happens with Kotlin, it is a good language, but it has too many magic inside.
Too much magic makes it very difficult to get into an established project. My Perl experience has been limited to a Catalyst project, and it was very hard to work which parts of the code did various things because it lacks explicit connections between files. Modifying a function is fine. Working out which function to change was pain.
In java the garbage collector looks to have less constraints than in C#, so you don't know when the destructor will be called and you can do some bad things like recreate a reference to your object to avoid the releasing.
If try with resources isn't enough, handle manually your resource or create your own pattern.
But I don't see how a destructor can handle patterns that a try with resources can't. Both are scope based ressource management.
There is not even a guarantee that destructors/finalizers will definitely be called. It is entirely possible for a Java program to terminate normally without ever calling any finalizers.
This is why they were ultimately deprecated. As a way of ensuring that some cleanup code runs, they are completely useless.
I agree but I think some magic is good. When I define a variable I expect the language to find the place on RAM to store it. Garbage collection is another type of magic that actually just makes programming simpler. You intuitively expect variables to return their memory when they go out of scope. So it's a little subjective, but I do agree with your point. Too much magic is gross. IMO a good language prioritizes consistency, simplicity, readability over "magic" that makes code easier to write, but harder for others to understand.
Garbage collection is more magical than destructors imho and I think it's probably harder to understand memory leaks related to garbage collection, but I'll concede that's subjective and probably depends on the codebase.
I think the problem with your statement is you start from the premise that "memory leaks are going to happen." They do, but it isn't a guarantee. Modern garbage-collected languages often carry on without a single memory leak while under normal operation.
From the position of "garbage collection works as intended," destructors in C++ are simply more work. The problem with garbage collection only appears when it doesn't work as intended, and now you need to unravel the magic.
The two garbage collection issues I have seen presented as real world examples of normal usage are:
It happened when I wasn't expecting it to
It didn't happen when I expected it to
The first is the classic "stop the world" GC problem. In those scenarios, you can have odd, and unexamined halts to your application that you only understand after lots of monitoring over a long period of time. Up until that body of evidence is amassed, it seems like the system breaks when no one is looking.
The second is typical in heavy load scenarios. Many GCs will attempt to avoid the first problem by looking for a window of opportunity where a global pause won't negatively impact user experience. But if the system is constantly under heavy load, then a necessary GC operation might be postponed well past the point it should have triggered. This can lead to OOM errors in the worst case, or far more severe denial of service due to an extra long GC cycle.
Modern garbage-collected languages often carry on without a single memory leak while under normal operation.
Would the following be considered "normal operation"?
public static void leak() {
new FileReader("filename.txt");
}
Some might point out the above isn't strictly a memory leak, but I'd argue an unimportant distinction - file handles are in-memory objects after all, and can be exhausted, just like memory.
The above might seem like an obvious anti-pattern, but if the function instead had just new SomeObject();, whether or not it'd be a leak is less obvious.
I think the problem with your statement is you start from the premise that "memory leaks are going to happen." They do, but it isn't a guarantee.
The bigger thing is that apparent memory leaks do happen even though the memory is not technically leaked.
Think things like cycles that the GC can't prove are freeable, the large dicts that don't get freed because there's still a local var referencing it bundled in a closure object somewhere, that kind of thing.
I'm sorry but being able to tell the difference between an actual memory leak and ever-increasing memory usage that simply seems like a leak is just an example of the very "magic" being discussed.
I've never really understood the obsession with C++ destructors being "magic" because they really aren't. They run when the object goes out of scope. End of. It's a simple equation compared to garbage collection, where the time where it happens is mysterious and unpredictable.
What's actually in the destructor is a different question, of course, but that's just as true whether the destructor is Foo::~Foo() or EVP_MD_CTX_free. Nothing from the outside says the latter operates straightforwardly but not the former.
Like, of all the C++ features destructors are among the least magical. Custom deleters, custom allocators in container objects, the fact that two declarations of the exact same lambda will compare unequal, there's a whole list of oolies with C++ that can be strange, but destructors as a language mechanism are even simpler than defer.
I wanted to add that memory leaks do still happen in GC languages. However, they are usually tracked as defects of the runtime, not with the application in question.
However, there are ways to create memory leaks in GC languages, and they are usually called out as anti-patterns. In other words, the memory leak occurred because you used the language in a way the designer did not intend, and that led to unexpected behavior.
JavaScript is the language I've been using at work the most, and I have had to learn that there are some memory leak pitfalls to watch out for. For instance, buffers of bytes should be carefully managed, and not passed around without care. Closures containing these large arrays can cause dangling references that aren't cleared after the scope exits, because the closure (like a callback function) might still be within scope, even if it is never called again. Closures and typed arrays are normal parts of the language, but sharing state across threads can make an ambiguous refcount that the GC is unsure when to clear.
Python found an excellent middle ground for 'magic' I think. Where almost everything 'magical' is tied to explicit keyword usage (so nothing magical happens implicitly).
This way, someone brand new to the programming language can get going quickly using only familiar C-like syntax. And over time, 'magic' can be added to make it more concise and easier to read.
Any magic that is added is clearly visible and developers can either accept that something magical is happening and trust that it is working as intended, or dig into the magic to understand it.
Magic can be hard to read - I write perl with a lot of explicitness (extra verbosity) and it becomes pretty damn readable and maintainable. Lots of people don't, which makes it hard to figure out what's going on.
Yup. Finding the right amount of magic for a language is tricky.
For example, C# and Swift keep adding features, including lots of magic (type inference, for example), and for newcomers, it's got to be increasingly baffling.
But then OTOH, for a seasoned developer, it makes it easier to see what's important about a file full of code.
Whatever it was I'm so happy this horrid language went out of style. Sure there are still unrepentant perl terrorists out there but in the grand scheme of things it's dead
It works the same everywhere, is pretty much always installed by default, and has sane regex. sed’ OTOH isn’t cross-platform (-Iworks different on Linux vs. Mac and other Unix) and is limited to basic/extended regex. So I’ve switched fromsedto perl for script string twiddling. (Replacesed ‘…’withperl -pe ‘…’` and most things work the same.)
Uh, perl in r/programming. To preempt the usual idiotic comments:
No, perl is not line noise, you can program perl pretty much exactly as structured and safe as python, since the languages are very similar. Python gains with better type hinting and a richer standard library for containers, perl gains with saner lexical declarations and list processing.
Good to see I had to go down this far for the token "yoU CAn WrITe BaD coDE in Any LAnGUaGe" nonsense. It misses the point and missing that point is why perl is dead: if a language makes it easy to write bad code and hard to write good code, that's a bad language. Yes, it's possible to write perl that can more or less be read but it takes tremendous effort compared to, say, python. In a good language, you have to go out of your way to write bad code.
And yes, I know, if you have 50 `use` statements at the top every file and a 3 gig IDE you can make it all almost bearable. In a good language I can write it in notepad if I have to and be ok.
It is equally difficult to write good code in both Python and Perl. If you only argued it's easier to write bad code in Perl then I may agree. However it is because Perl simply has more syntax features than Python - it's way easier to not break things if you find yourself in a straitjacket.
Also, the Python I'm seeing lately is far from readable. Bunch of shortcuts taken, code compressed to minimize the amount of lines used, postfix fors all over the place mixed with those ifs that are supposed to work as a ternary but with more thought cycles required. So the readability argument only resonates with people because they already know Python and they don't know Perl. It's not all sunshine and rainbows for someone who did not pay attention to Python lately.
Straight up disagree. In fact I'd say practice has proven this wrong. For a long time Python had "One Way to Do it". Perl was so bad that I saw a case where a maintainer fixed a bug and found out people were using it as a feature and had to put it back. They famously used to say the only way to know if a file is a valid Perl 5 program is to run it.
Python has broken their original promise about one way to do it so it's deteriorating but it's still better than Perl 5 ever was.
Perl has implemented pretty much all of the C standard library as far as I can tell. The couple of times I've had to maintain it in the past I just turned "use strict" on and treated it more-or-less like an interpreted C.
I did run across a program where someone was reading undocumented data into an undocumented 11 dimensional array of arrays that turned out to be thoroughly unmaintainable, but that code would have been unmaintainable in any language. Same dude was doing matrix multiplies in perl and I'm still about 80% sure that one of the matrixes he was multiplying into the set was not initialized anywhere in the code. It wasn't the language that was shit, it was his code, and converting it from perl to C++ when it became impossible to add more features to it reduced the run time from 11-12 hours in some cases to under a second.
Autovivification is sub arrays is a thing, yeah. You can just $array[2][4][7] = 1; and voilà, there's your 3d array.
Speed on the other hand - yeah, perl is slow, even in comparison to other scripting languages, especially for number crunching. The op overhead makes integer arithmetic around 20x slower than C, and that's before cache locality. For numeric calculation there would have been PDL though, which is the numpy equivalent of perl and would have been available to your example too.
Slower than C/Go/Rust/Java - certainly. But it is still far faster than Ruby and Python in many areas - especially in terms of cold start time, which is useful for places where you might be tempted to pick something like Bash. I still think the advice of “<X lines use Bash, X*10 use anything else” is still pretty relevant today for your preferred value of X between 1-50.
I still think the advice of “<X lines use Bash, <10X lines use Perl, >10X use anything else” is still pretty relevant today for your preferred value of X between 1-50.
Sure, but most of us operate with a more generic variant I think, as in, shell/script/compiled, where
shell is likely Posix sh or bash, but might be zsh, fish, etc; might even be task runners like just
script is likely typed Python or Typescript, or untyped Python or Javascript, but might be Ruby, Perl, etc
compiled depends a lot
and in all cases I suspect rigour and project management is as much a factor in picking a category as performance.
That's one way of writing it, called "baby perl". Absolutely valid if you're not adept at using it. Though more advanced style can be significantly more readable if done right.
Yeah, those were all maintenance projects. If I'd written the code base myself and had been forced to use perl to do it, my approach would have been different. These days I mostly just write C++ code and export APIs to Python or Javascript or both.
There’s an argument that PHP killed Perl for making websites. Not only was it easy to move from one to the other, but Perl required you to buy a fat expensive book while PHP had good documentation online.
It was so much easier to manage, and was much easier for shared hosting providers to work with in (relatively) safely sharing server resources, enforcing quotas, etc
In 1995 Perl was the only practical option for writing portable web apps. By 2000 it was the crappiest of several practical options. I'd agree mod_php was the primary killer of Perl.
On shared web hosts you not only didn't have admin access to the machine you rarely even had shell access. Deploying a non-trivial Perl app was a PITA as it all had to live in some cgi-bin directory (nowhere else had ExecCGI enabled) and many hosts did not bother with any Perl modules besides CGI and maybe a database connector, which meant no good templating modules. Managing a Perl deployment via FTP could be a hassle. Unless a host enabled mod_rewriteand allowed for it in an .htaccess file you might not have even been able to have a dynamic main page.
Meanwhile mod_php would run files as long as the handler was set up right. PHP was also itself essentially a templating language. You could pepper some <? php ?> tags in your output from DreamWeaver/Fromtpage/Whatever and have a dynamic site. Naming your main file index.php was often enough to have a fully dynamic page since most hosts supporting PHP included it in the DirectoryIndex.
I say this having written a lot of Perl and originally learning it specifically to write web apps. I migrated to PHP because its deployment story was so much easier and for doing web apps was not too much worse of a language than Perl. In the early 00s people that just a few years earlier would have learned Perl instead learned PHP because they could easily write a web app and get it deployed on pretty much any web host easily.
I think what is interesting is your opening paragraph only hints at the rapid innovation of the web at the turn of the century and everything was being reinvented overnight.
We could argue that PHP did replace Perl, but you have to submit that Java replaced PHP. Simply based on numbers alone, each succession produced a niche language after the change. JavaScript languages replaced anything-Java on the front end and now we have Python almost preferred in Data Science and Systems administration.
All in all, the web upheaval took down many languages trying to find that sweet spot, IMO. Pretty cool period of transformation.
As a Java dev: Did it really? In certain environments (enterprise, corporate) I'll give you that. But unlike Perl, PHP still is widely used today (Wiki's, online shops, CMS, etc.).
In these spaces - I'd argue - it's rather NodeJS that is (slowly) eating away PHP's cake.
Well, it displaced a large portion of Enterprise development. There is no denying that. Whether it took it away from PHP or created a whole new, previously undefined, field of development, sure “replaced” is too strong. But you can argue it stifled that field and moved resources away from it.
Thinking back, I‘m not even sure, which came first. I think Java had already „conquered“ the enterprise, before PHP came around.
I remember however, how PHP (the entire LAMP stack actually) took off like a rocket somewhen in the early 2000s. Every village web hoster offered it for free.
Java always had a higher entry bar. You‘d basically had to maintain your own servers to run Java web app.
Java and PHP mostly moved in different circles. While social media and web 2.0 (remember that? lol) embraced PHP, there wasn’t a lot of enterprise and banking using it. Even Java in the browser was in its way out by the time PHP’s popularity was exploding—Flash had killed it long before JavaScript’s renaissance. Java for websites crept in alongside (but a little after) Java for enterprise backends. Enterprises apps were being created and rewritten in Java but I doubt many were being rewritten from PHP, more likely they were rewriting Perl.
Perl did not even include any function for encoding text into html or handling URLs. It was like the perl developers was stuck in the past and thinking: real developers don't make web sites.
If the developers of Perl had acknowledged the web and added all the stuff needed to support web well, then PHP would never have happened.
They also prioritized language constructs like "code executed at compile time" rather than making it possible to compile perl code to machine language.
The OO syntax introduced in Perl 5 was even more verbose than Java !
Perl was a first-class citizen in all the early web servers: mod_cgi, mod_fcgi, mod_perl meant the Perl was *the* way to make dynamic websites.
I wrote tons of Perl code for the web. The web server I worked on literally had a fully Perl UI. I wrote a web UI for an FTP file manager, a load balancer, a global load balancer, web-based UIs for more than one telecoms company, various website backends, online publishing systems, …
I was beginner back in early 2000-ies and first tried with Perl, but after I saw how things are easier with PHP I just went to it. It was the time with global variables directly (which is bad ofc) from the url but that was probably what helped many beginners.
I did tech support for web hosting back in the late 90's --- we had to know all three (PHP, Perl and ASP) and I was never a fan of Perl. PHP certainly had more easier to find documentation and ASP was just super easy to read and understand (but stupid levels of slow).
We supported Chili!Soft ASP on Linux... which turned up debugging to 11 since it was not 100% compatible and things like directory paths could break a script.
I still use php (new version) when I can decide the stack. On my full time job we work on .net off-course, but I really like php on back and React or even vanilla DOM manipulation on front. Php is now quite good and fast.
For my project I just go with php, unfortunately I work for enterprise company and there MS is untouchable. I still can’t grasp people writing backend in JS, but I guess their story is similar to mine - it was easy to setup when they started.
When I worked for corporate we had some stuff in .net -- then it was up to whoever started the project to pick how it started unless there was some outside requirement.
I used to really rag on JS/TS --- especially for people that wanted to use it as a backend.
Then I got handed a small ExpressJS project and was kind of like -- why is this making sense. WTF is this making sense?! I think my biggest issue with JS on the backend was always like - where is the server to serve up the JS and not wanting to believe that JS is the server, your not using Apache or Nginx to "serve" the files any more unless your load balancing or need to proxy the requests. That little Express JS project just ran and was wicked fast. The idea that the front and backend could be completely in TS/JS was something else too.
Of course now we have pure PHP as the backend server -- no more Apache, Nginx or Lightspeed needed so I guess PHP caught up with JS in that regards.
mod_perl was a hassle to install and operate, while mod_php was very smooth. I think that alone explains PHP's success. The other factor is mentioned in the article: Perl was designed as an easy upgrade from shell scripts, and lots of syntax and features present in very simple Perl scripts are great for that but only confusing when you're not coming from there or going there. If the Perl community had created a 'simplified sub-Perl for web programming', and eased the use of mod-perl, it might have nipped PHP in the bud.
mod_perl was a hassle to install and operate, while mod_php was very smooth. I think that alone explains PHP's success.
More generally,
you write a PHP file,
you upload it on a server somewhere (or write it right on the server in the first place),
there is no step three
had a huge impact on initial success. Sure, that's not how you're supposed to develop software (no continuous deployment, implied no version control, etc.), but coupled with the many, many web hosts that just let you use PHP, it's an extremely easy way to get started.
Add to that "what is a PHP file?":
you take an HTML file, perhaps written in FrontPage or something else that might make people shudder
you rename it to .php
you sprinkle in <?php tags where you like
The only contemporary thing with the same easy of use was Apache's SSI, which wasn't as powerful.
Perl offered far better ways to do the same thing;
I still love the CGI module and its HTML generating functions; I thin kthe approach is vastly superior way to the "HTML with code holes" approach used by PHP and I have no idea why it was deprecated by its own authors
I used Mason for a while, it was proper component-based web technology
And I think mod_perl existed before mod_php. But mod_php was so much easier to install that it started to become with webserver installations by default; and PHP was so ridiculously simplistic and lacking in power that its learning curve was also very small. It started out as a Perl script! Subsequently, PHP went through pretty much exactly all of the maturing steps Perl had already gone through. The waste of development effort is staggering.
By the way, the exact thing happened when MySQL arose while the much superior Postgres was already there. That's IT in a nutshell: people just keep inventing wheels, whether they have been invented before or not.
By the way, the exact thing happened when MySQL arose while the much superior Postgres was already there.
that seems anachronistic, as far as I can tell, MySQL was released first (1995 according to Wikipedia) and one year later Postgres got released (1996 according to Wikipedia)
Chili! Soft ASP... man those were the days. Worked web server hosting support and Windows hosting was super expensive, but Linux hosting was a fraction of the cost so everyone was trying to get Chili! Soft ASP working with scripts that were developed for Windows. A ton of the script just worked but some.... nightmares trying to troubleshoot all the while thinking WTF am I debugging a ASP script as a T2 phone support tech...
It was crazy the amount of support we gave back then compared to the zero support off script allowed today.
Yes, Matt's Script Archive and quite a bit of proprietary Perl code was Perl 4 running on a perl 5 runtime, but that was a choice, not because Perl 5 wasn't available.
OO in Perl5 was a page of code to implement classes. OO was something you chose to follow, not something you were forced to (like java).. python follow the same philosophy. You don’t have to write classes if you don’t want to.
PHP core's documentation is not bad, I'll give it that. But neither is Perl's - documentation is first-class citizen there. Took a quick look at 5.04 from 1997, it seems to have a decent documentation. It also came with perldoc tool to view it in the terminal, as well as installed manpages for unix. So I don't think the book was mandatory in any way, though it's a fun read.
However, PHP comes with more web-related builtin functions, can be freely mixed with HTML, and has a bit easier to grasp syntax. Easier to set up, made it possible to build webpages without thinking about external dependencies. That surely made a difference.
This. Loved that stuff. It was pre Stackoverflow. But you could look for the docs for a method and people had entire programs written using the method. There was so much signal, so little noise.
Now I wonder why and how was it so good. The community made it, of course. But maybe it was also moderated?
As someone who tried in the late 1990s, let me tell you that it really, really wasn’t that simple and those man pages really weren’t that easy to read.
There’s a reason why the Camel book sold so many copies.
PHP's documentation was closer to an unmoderated stack overflow. They might be better now but the problem was it wasn't just a description of what the API but it had examples and they may or may not be good or safe. A new user wouldn't know that either.
When I discovered Perl I fell in love with it as my scripting language: no more awk, sed, shell scripts, I could do everything in one place. It became my goto-language for all my quick and dirty scripting.
Then Perl 5 came along with its classes and blessing and the Programming Perl book doubled in size. To me the language started to feel like Frankenstein's monster with many disparate parts glued together and harder to grok.
So I started looking for alternatives, tried out Python and Ruby, liked Ruby and went with that.
Exactly. I'm surprised to see so many people mentioning python. Ruby killed perl because it's just a better perl (it's literally where the name came from) with some smalltalk inspiration on top.
I had to do something similar when I joined Booking and I nope’d the fuck out in a year to a different team which was working on greenfield java services.
And I’ve seen so many perl devs moving out or being forced out in the last 5 years.
I’m pretty sure most of the heavyweight services have been phased out of perl. A lot of our analytic workflows were in perl previously, and almost all of them have been migrated to python-based Airflow DAGs
Perl is still alive and well, as a compile-time dependency in many FOSS projects. Nothing wrong with it, as long as the programmer wasn't trying to be too clever.
The same thing that killed PHP, itself. These languages were both very great to use for specific purpose, and not very great at other things, and both languages attempted to become the World's Most Widely Used General Purpose Language, and both did so poorly. For Perl, most people don't really appreciate brevity in their large programs. That brevity was a great thing when Perl was being used by system administrators as a replacement for bash. Not so much everywhere else.
I have around 50K lines of Perl that's been live and evolving since 1995. I once rewrote a large part in C++ and to my surprise it ran much slower. Every operation on every object was a separate piece of code so the core operations no longer fit into the L1 CPU cache.
It was maybe 20+ years ago. I asked a question about Perl, and got a bunch of people screaming at me and calling me an idiot. I asked a question about Python and got a number of helpful replies.
I propose that maybe it wasn't technical issues that killed Perl.
For one, there's the practical problem others have pointed out: hiring Perl programmers has gotten tricky. Which in part is a chicken and egg problem, but also in part… it just isn't that compelling a language any more.
Which brings me to the second point. Other ecosystems have gotten better while Perl just hasn't.
For example! .NET now has a regex source generator (a form of macros/metaprogramming). I write a method stub with metadata containing the regex:
a generated API comment explaining what the source generator thinks the regex does; in the above example, it generates:
/// ○ Match if at the beginning of the string.
/// ○ Match if at anything other than a word boundary.
/// ○ Match the string "abc".
/// ○ Match if at anything other than a word boundary.
/// ○ Match if at the end of the string or if before an ending newline.
for non-complex regex cases, the entire regex is actually broken down into a parser at compile time
The above example, at runtime, doesn't actually use a regex engine at all; instead, the source generator just synthesized code that walks the string.
So it's safer, faster, and more convenient (because the comment explains whether my pattern makes sense).
I don't see how "yeah, or we could use Perl 5 from the 1990s" is going to compete with that.
When has it mattered that it was broken down into a parser at compile time?
BTW, that's not megaprogramming, at least by the definition we've been using since Simonyi. It's just programming, like you say it's like a macro.
I don't use Perl anymore and the first one would be enough for me for any code I share with others (work/open projects) even if I hadn't already gotten away from Perl.
It's still useful for one liners like awk is. That's about it for me.
When has it mattered that it was broken down into a parser at compile time?
Performance?
BTW, that's not megaprogramming, at least by the definition we've been using since Simonyi. It's just programming, like you say it's like a macro.
Per Wikipedia:
"Metaprogramming is a computer programming technique in which computer programs have the ability to treat other programs as their data. It means that a program can be designed to read, generate, analyse, or transform other programs, and even modify itself, while running."
A source generator is a program (technically, a dynamic library loaded by the compiler) that goes through my source code, treating it as data (namely, as an AST), and transforming it.
They also specifically list macros as first example of metaprogramming.
I don't use Perl anymore and the first one would be enough for me for any code I share with others (work/open projects) even if I hadn't already gotten away from Perl.
I could also add "I don't want to do non-trivial stuff in dynamically-typed languages ever again" to my list of reasons.
It's not clear to me an inline parser would be faster than a compiled regex. Regex libraries are designed to be fast. So even if it calls to the regex library instead of being an inline parser, why would it be slow for a simple regex?
Metaprogramming is a computer programming technique in which computer programs have the ability to treat other programs as their data.
Interesting, not the definition I'm used to. It's not clear how that definition applies here either though.
source generator is a program
A compiler is also a program and it is treating that input as "another program" in the same way you say this megaprogramming does. You above talk about .NET producing an inline parser from your input. What you are doing here isn't really different enough from that to be meta anything. IMHO.
I guess my real issue is if that is metaprogramming then maybe C is metaprogramming because compilers can convert it to assembly and feed it to an assembler. I just don't see how that definition of metaprogramming is useful.
They also specifically list macros as first example of metaprogramming.
So? Then the C preprocessor is metaprogramming to. And that's part of C, so C is metaprogramming?
Like I said, I just don't see how that's a useful definition. It just is so close to regular programming that is basically is describing the same thing.
Part of the issue is simply that ever since Von Neumann architecture came along like 80 years ago now programs are data. You load them into memory like data because they are data and then it just so happens processor can execute certain forms of the data.
The massive overreach that was Perl 6 killed it really. Probably would have continued growing a lot longer if Larry had used a more incremental approach.
The last company I worked for as a Perl coder transitioned away from Perl because they struggled to find enough talent. It's a vicious cycle: fewer people learn Perl because there aren't jobs in it, and there are fewer Perl jobs because companies can't find skilled Perl developers.
Of course, that doesn't answer what initiated that cycle.
I suspect Perl is still used a lot more for non-commercial projects by individuals or small open source project teams, than it is for "enterprise software".
Perl still has a ton of use on the engineering side. My company is at about 180k and contracts out to at least 200k additional folks. All of them spend their whole day running perl scripts. Most are writing one liners and scripts without knowing the actual language they are executing because there's decades of junk that's layered over the interpreter. If you asked most of them what they are coding in, they'd give you a name of some internal company tool someone made up in the 2000's, but it's just running perl with extra global definitions.
My last company had over 100k employees and was the same way. I suspect most old engineering companies do it that way.
None of those people, though, see themselves as programmers. Even if they spend their entire day writing scripts and applications, they still see it as engineering. They wouldn't go fill out stack overflow surveys or anything that tries to track language popularity. If they did, they wouldn't say they exclusively program with perl anyways.
I worked for a team that used perl extensively and this is how I feel about it after I had to work with it for years.
Perl's cryptic syntax does it no favors and makes it extremely hard to pick up.
People that use perl absolutely *love* to use it in ways that make it even harder to understand what the hell is going on. Just because you *can* do something on one line does not mean it should be done on one line. I'd much rather use a more verbose language that makes it easier to understand than get something done on one line. This isn't a CLI and we shouldn't treat it like a CLI.
There isn't first class tooling to help debug perl, which continues to make it harder to understand what the hell is going on. This is exacerbated by point #2.
The people who designed the codebase that my old team used should be locked in a prison for how they abused hard coded data structures. I worked in files that were 60,000 lines long with full ass data bases stored in hashes and arrays and arrays of hashes and hashes of arrays and hashes of hashes and I wanted to rip my fucking hair out after working with it. Either use a database or store these in files that aren't code, you absolute fools!
Point #4 may have influenced my opinions on the rest of the language.
My shop uses Perl for some production code along with a lot of infrastructure and config stuff. I learned enough to be able to fix bugs, but honestly I was told by the old guard that learning more than necessary would be a step backwards.
Honestly it was a big debate when we were planning a REST API for one of our legacy products on whether to do C, Perl, or Python. I ended up winning my bid for Python on the fact that the old timers are going to be retiring soon and anyone else we hire straight up won't know Perl. And if we say, sure, we can teach you -- I really don't think there will be many new grads gunning to take that on.
The last time I saw Perl in a corporate setting was the early 2010s. It was the developers in India churning out the Perl programs because it could be compiled to an executable and it was what they knew. Updating that ten years later to Python so we could actually iterate on those original programs was a personal hell of mine for six months.
i tried to find perl jobs back in the day. never got one despite experience. so i switched to Java. (not saying i was the reason for perls "death" :)
last time i applied i was rejected and then learned from someone who used to work there that it was rigged. they rejected every single person. because they wanted to switch to Ruby and needed the "no people" 'excuse'. and that was when perl was popular.
I suspect Perl is still used a lot more for non-commercial projects by individuals or small open source project teams, than it is for "enterprise software".
But when was the last time you've heard of a new OSS project that was written in Perl?
Back in the 90s we joked that Perl is a write-only language ie the effort it took to read Perl code was bigger than simply re-writing it.
I don‘t think it ever recovered from that.
Personally, coming from a sysadmin background, I mostly used Perl in a barely-capable-programmer way, very stringly typed, and mostly using regexes to parse ad-hoc structured output from something else. I think I went more and more to Python as my workflow drifted towards json.load (and, these days, BaseModel.model_validate_json).
At the same time I think a lot of us just didn't pay attention to Perl's upgrades, or worked on servers where they weren't accessible. Just basic stuff like being able to do
def foo(bar, baz):
…
rather than
sub foo {
my $bar = shift;
my $baz = shift;
…
is part of the difference in feeling like a normal programming language vs some hacky bash++.
Lots of us also started moving away from languages that are sloppy by default, i.e. I don't want to deal with programs written without "use strict" and I don't want to deal with implicit conversion errors.
Also:
The people who grew up on Unixy systems in the 1990s and early 2000s would know shell, C, awk, sed, Vim, etc. To these people, Perl is a natural extension of what they were already doing.
I'm included in that generation; Perl was actually the first programming language I learned, and I still learned Java at uni; likely somewhere around Java 1.4 or Java 1.5.
These days Perl is becoming a foggy memory for me. I know if I do the "use 5.04x;" incantation I get access to stuff like function definitions actually taking a parameter list and a variant of the print function that automatically inserts a newline at the end (\~ooh\~), but I haven't kept up, and my memories of the language tell me the style I program in these days isn't suited for Perl.
My memories are highly likely outdated, but at the same time, I'm not really on the hunt for a scripting language. Typed Python does that job for me, and Python in general has been doing that job for well over a decade.
i used perl until python came around, because with python i had less special characters and hashes and arrays had the same brackets... yes i am that superficially. but otherwise, perl was really core and dependable.
Some people seem to think Raku (formerly known as “Perl 6”) sucked momentum out of Perl, but I don’t believe that. Everyone I talked to back then knew Perl wasn’t going anywhere. Humanity had chained too much of the infrastructure of the growing internet to it. Even if Raku turned out to be a wild success, someone would have to keep maintaining Perl for many years to come. There was never any danger of obsolescence in starting a new project in Perl.
One of my first jobs was programming perl and that was not my memory of it. My memory of it was that Larry Wall and all the major perl contributors were working on Perl 6 which was going to be a completely different language that was not backward compatible(though some automatic translation tools were I believe promised), so the attitude was more like 'perl is in maintenance mode now so eventually we'll have to switch to a completely new language or be stuck with this moribund one, in which case, why not just switch to Python or PHP?)
Combine that with weak typing. Google blessing Python as a production language giving it credibility, perl not really competing with Rails or Django in the new web framework space, other languages realizing they needed package repositories and starting to catch up to CPAN, and PHP becoming the de facto shared hosting language and there was a lot working against perl.
My memory of it was that Larry Wall and all the major perl contributors were working on Perl 6 which was going to be a completely different language that was not backward compatible
For the large part: PHP killed perl because of the ease if adding backend data lookup to web pages.
These days, I’d rather reach for python for scripting and data analysis and typescript fot webpages. Backend data lookup is done through lambda functions and decoupled and can be done in whatever (which ends up being javascript or python)
I do encounter Perl in the wild on occasion (I’m a consultant) and I may be one of the few who actually like the language.
Perl is still around. Still by far the best programmatic extraction and reporting language out there.
Its implementation of regex is the best. Made me hate using python’s implementation, although python’s implementation is much better than it used to be. Still bad though.
Not comparable. Perl 6 (now Raku) is a completely different language.
Scala 3 was more like Python 3, but on a lesser scale. Python 3 broke source compatibility in several key places and didn't provide much help with porting code. Most Scala 2.13 code works as-is in Scala 3, the only problem was that several widely used libraries relied on compiler macros, and that was the one thing that changed as Scala 2 macros are just a way to access the compiler internals and Scala 3 uses a completely different compiler. Unfortunately, the Scala community is smaller than Python's, and that means it took some time until all the major libraries were ported.
Everyone I talked to back then knew Perl wasn’t going anywhere. Humanity had chained too much of the infrastructure of the growing internet to it.
Ehhhhhhhh.
That was the case in the 1990s, sure, but when was the last time you've heard of new, significant software that uses Perl of all things? Is Perl among the top five languages used at AWS, Azure, Cloudflare, Google, Oracle? FAANG in general?
Besides, Raku was first announced in 2000, and the major burst of activity around Raku implementations seems to have been at the end of that decade. Through that period, Perl grew rapidly, as indicated by the graph.
Yeah, but that graph is missing a key slice: how rapidly did everything else grow? What about PHP? Java? .NET? Python? JS/Node?
And "people were unsure where Perl was headed given Perl 6 was in no one's land for two decades, then rebranded as Raku, and took all the air out of both Perl 5 and Raku in the process" is absolutely my perception. Call it second-system effect, Osborne effect, Spolsky's "Things You Should Never Do", whatever; Perl had momentum, then took the baby out with the bathwater.
I've had the luck to work with Perl codebases 20+ years ago when I started my career.
Its syntax seemed deliberately hostile, a forest of sigils and magical variables that most of the times not even my veteran collegause were able to decipher, but even if they could, then none of them could agree on what "idiomatic Perl" actually meant. Error messages were cryptic, context sensitivity was unpredictable, function argument handling was incosistent, the ecosystem was fragmented, and it was full of context-sensitive behavior that would silently change. Working in Perl-based projects felt less like programming and more like solving a crossword puzzle someone set on fire.
Even PHP 4 had a wastly better development experience, no wonder Perl died. Well, maybe it became better later, but I am sure no one sane wanted to tuch it who knew even a little bit about it from the days it was more or less "popular".
reveil@reddit
Python killed Perl by being actually readable. So much that sometimes it is easier to read someone else's Python than your own Perl. And if you got some legacy Perl to refactor oh boy let me tell you a story. I once had to rewrite an legacy Perl script to Python and had to debug it with strace to see which file it was opening. Imagine using tools designed for compiled binaries because it was easier than reading the source code. To top it off my python version was 20x faster. Not because python is fast but because a clean language allows you to make good architecture decisions.
WoodyTheWorker@reddit
Also Perl killed Perl. For being a fugly bastard child of Bash and Tcl.
ub3rh4x0rz@reddit
It's kind of funny that in some contexts (basically not "data" contexts), Python is today where Perl was then, e.g. moving from Python to Go or even Typescript for readability and/or performance.
ashultz@reddit
Python lost its own "one way to do things" principle.
Kered13@reddit
How many ways do we have to format strings now?
ub3rh4x0rz@reddit
Agreed. Python is anything but a "clean" language at this point, its popularity is entirely driven by ecosystem, not first principles or adherence to them
reveil@reddit
While I frequently see moving to Go (or Rust) for performance I have never seen anyone move from Python to Typescript. JavaScript/Typescript ecosystem seems to be there only there because it is in the browser. Otherwise these are horrible languages even worse than Perl.
ub3rh4x0rz@reddit
Node/typescript has had a better concurrency story than native python from day 1, and for I/O bound workloads, that is a performance win
reveil@reddit
I don't negate that python has meh performance but if you are making a rewrite targeting performance might as well go with Go or Rust to get 100-1000x performance instead of 2-3x with JavaScript/Typescript. Especially since Go is much more readable and developer friendly language than JavaScript/Typescript. Rust has a harder learning curve but is safe and performance is even better than Go though that is seldom required as Go is also quite good.
ub3rh4x0rz@reddit
I like Typescript for frontend/BFF, but yeah for backend and tooling that doesn't require the data wrangling ecosystem of python, Go is my preference. It is the most readable language at scale and over time IME, and the learning curve is great
reveil@reddit
I fully agree that Go is very readable. Python is probably the champion of readability and Go is a very close second. It also strikes a very good balance on ease of use and speed. I also like the approach of static linking binaries and their portability though in the age of containers it is a bit less relevant now.
ub3rh4x0rz@reddit
Python is excessively magical in 2025 to be the readability champ. There are too many competing styles and redundant language features that have built up over time.
reveil@reddit
Python is very readable unless you are using async. Then again same can be said for basically any language that has async support.
ub3rh4x0rz@reddit
Maybe your preferred flavor of python is readable to you. There are at least 3 ways to define something akin to an interface, as an example. The OO story in general is bad and yet is the dominant paradigm. Nested comprehensions, which arguably shouldn't be syntactictly allowed, messed up the ordering. Dunder methods everywhere. The problem with python async isnt even readability, its the fact that most of the ecosystem formed before asyncio etc and the compatibility story is trash.
admalledd@reddit
In the long ago, the way I hear it was that as others say mod_php killed perl for web, and as you say python killed perl for admin stuff. However, I would contest "readability", since early days python was also a bit rough.
What I saw more often however was that the python standard library was actually usable to craft whole sets of tools. Like, in perl I regularly remember not having basic file parsers for INI, XML, etc built in. And often, you weren't in a position to demand some CPAN package get installed on all the systems the script needed to run on. Also similar to php vs perl at the time, python was reasonably documented: I don't recall html files, I know on windows we had .chm and *nix users had something else alike that was equally reasonable to read/use. Not too far into py2 they started hosting online like php (though, no comments, which at the time I found to be a bummer, hindsight was probably a good idea to not have them...)
reveil@reddit
There is definitely some truth to having a decent standard library helped python a lot compared to perl. Especially in the early days when internet access was not as widespread in enclosed corporate environments in sectors like finance etc. While python clearly took the admin stuff and data processing, the web got taken over partly by PHP partly also by Python. Django was a huge breakthrough with the autogenerated site admin panel. The most basic dynamic sites also got swallowed up by WordPress. You might call it PHP but a lot of those deployments did not write much code if any.
hoppersoft@reddit
I have a friend who called Perl a “write-only language.” Spot on.
jpakkane@reddit
This!
Dedushka_shubin@reddit
There are two kinds of features in programming languages: explicit and magical. Explicit is what we are writing in the program, things like if, for, of a = 2; Magical things happen by, well, magic. Like when in C++ a variable of a programmer defined type goes out of scope, its destructor gets called. You need to know it, you do not write it.
Magic is pretty, but it makes the process of learning new languages more difficult. One common question is "are there destructors in Java?" meaning "I have this magic here, does it happen there?".
There is too much magic in Perl, thus few people used it as a secondary tool. The similar thing now happens with Kotlin, it is a good language, but it has too many magic inside.
curiousdannii@reddit
Too much magic makes it very difficult to get into an established project. My Perl experience has been limited to a Catalyst project, and it was very hard to work which parts of the code did various things because it lacks explicit connections between files. Modifying a function is fine. Working out which function to change was pain.
Worth_Trust_3825@reddit
I'm glad we finally got rid of destructors in java.
KryptosFR@reddit
How do you clean native/unmanaged resources in a safe way? Asking as a .NET where this is the main use (combined with the Dispose pattern).
Kered13@reddit
Try-with-resources. A class should implement the
Closeableinterface in order to support try-with-resources.Finalizers were never a safe way to clean up resources, which is why they were deprecated.
barmic1212@reddit
Try with resources https://www.baeldung.com/java-try-with-resources
KryptosFR@reddit
That's the same as the Dispose pattern in C#, but it doesn't solve all cases.
barmic1212@reddit
In java the garbage collector looks to have less constraints than in C#, so you don't know when the destructor will be called and you can do some bad things like recreate a reference to your object to avoid the releasing.
If try with resources isn't enough, handle manually your resource or create your own pattern.
But I don't see how a destructor can handle patterns that a try with resources can't. Both are scope based ressource management.
Kered13@reddit
There is not even a guarantee that destructors/finalizers will definitely be called. It is entirely possible for a Java program to terminate normally without ever calling any finalizers.
This is why they were ultimately deprecated. As a way of ensuring that some cleanup code runs, they are completely useless.
grauenwolf@reddit
Finalizers in .NET were a mistake. They aren't reliable and they end up just obfuscating resource management bugs.
Worth_Trust_3825@reddit
try with resources, and java.lang.ref.Cleaner
matjoeman@reddit
It looks like there's a feature called "Cleaners" that still let you do that kind of thing.
BobSacamano47@reddit
I agree but I think some magic is good. When I define a variable I expect the language to find the place on RAM to store it. Garbage collection is another type of magic that actually just makes programming simpler. You intuitively expect variables to return their memory when they go out of scope. So it's a little subjective, but I do agree with your point. Too much magic is gross. IMO a good language prioritizes consistency, simplicity, readability over "magic" that makes code easier to write, but harder for others to understand.
Dedushka_shubin@reddit
I've never said that magic is bad. It is useful and sometimes necessary, but it it is good in proportion to everything else.
fredisa4letterword@reddit
Garbage collection is more magical than destructors imho and I think it's probably harder to understand memory leaks related to garbage collection, but I'll concede that's subjective and probably depends on the codebase.
Solonotix@reddit
I think the problem with your statement is you start from the premise that "memory leaks are going to happen." They do, but it isn't a guarantee. Modern garbage-collected languages often carry on without a single memory leak while under normal operation.
From the position of "garbage collection works as intended," destructors in C++ are simply more work. The problem with garbage collection only appears when it doesn't work as intended, and now you need to unravel the magic.
The two garbage collection issues I have seen presented as real world examples of normal usage are:
The first is the classic "stop the world" GC problem. In those scenarios, you can have odd, and unexamined halts to your application that you only understand after lots of monitoring over a long period of time. Up until that body of evidence is amassed, it seems like the system breaks when no one is looking.
The second is typical in heavy load scenarios. Many GCs will attempt to avoid the first problem by looking for a window of opportunity where a global pause won't negatively impact user experience. But if the system is constantly under heavy load, then a necessary GC operation might be postponed well past the point it should have triggered. This can lead to OOM errors in the worst case, or far more severe denial of service due to an extra long GC cycle.
YumiYumiYumi@reddit
Would the following be considered "normal operation"?
Some might point out the above isn't strictly a memory leak, but I'd argue an unimportant distinction - file handles are in-memory objects after all, and can be exhausted, just like memory.
The above might seem like an obvious anti-pattern, but if the function instead had just
new SomeObject();, whether or not it'd be a leak is less obvious.fredisa4letterword@reddit
If I wanted to talk to an LLM I'd create a ChatGPT account.
mpyne@reddit
The bigger thing is that apparent memory leaks do happen even though the memory is not technically leaked.
Think things like cycles that the GC can't prove are freeable, the large dicts that don't get freed because there's still a local var referencing it bundled in a closure object somewhere, that kind of thing.
I'm sorry but being able to tell the difference between an actual memory leak and ever-increasing memory usage that simply seems like a leak is just an example of the very "magic" being discussed.
I've never really understood the obsession with C++ destructors being "magic" because they really aren't. They run when the object goes out of scope. End of. It's a simple equation compared to garbage collection, where the time where it happens is mysterious and unpredictable.
What's actually in the destructor is a different question, of course, but that's just as true whether the destructor is
Foo::~Foo()orEVP_MD_CTX_free. Nothing from the outside says the latter operates straightforwardly but not the former.Like, of all the C++ features destructors are among the least magical. Custom deleters, custom allocators in container objects, the fact that two declarations of the exact same lambda will compare unequal, there's a whole list of oolies with C++ that can be strange, but destructors as a language mechanism are even simpler than
defer.Solonotix@reddit
I wanted to add that memory leaks do still happen in GC languages. However, they are usually tracked as defects of the runtime, not with the application in question.
However, there are ways to create memory leaks in GC languages, and they are usually called out as anti-patterns. In other words, the memory leak occurred because you used the language in a way the designer did not intend, and that led to unexpected behavior.
JavaScript is the language I've been using at work the most, and I have had to learn that there are some memory leak pitfalls to watch out for. For instance, buffers of bytes should be carefully managed, and not passed around without care. Closures containing these large arrays can cause dangling references that aren't cleared after the scope exits, because the closure (like a callback function) might still be within scope, even if it is never called again. Closures and typed arrays are normal parts of the language, but sharing state across threads can make an ambiguous refcount that the GC is unsure when to clear.
SputnikCucumber@reddit
Python found an excellent middle ground for 'magic' I think. Where almost everything 'magical' is tied to explicit keyword usage (so nothing magical happens implicitly).
This way, someone brand new to the programming language can get going quickly using only familiar C-like syntax. And over time, 'magic' can be added to make it more concise and easier to read.
Any magic that is added is clearly visible and developers can either accept that something magical is happening and trust that it is working as intended, or dig into the magic to understand it.
gimpwiz@reddit
Magic can be hard to read - I write perl with a lot of explicitness (extra verbosity) and it becomes pretty damn readable and maintainable. Lots of people don't, which makes it hard to figure out what's going on.
What's the old joke?
Good perl is indistinguishable from line noise.
nightwood@reddit
Dude that's such a good insight!
blowmage@reddit
This comment ^ is getting downvoted for being correct
chucker23n@reddit
Yup. Finding the right amount of magic for a language is tricky.
For example, C# and Swift keep adding features, including lots of magic (type inference, for example), and for newcomers, it's got to be increasingly baffling.
But then OTOH, for a seasoned developer, it makes it easier to see what's important about a file full of code.
PrimozDelux@reddit
Whatever it was I'm so happy this horrid language went out of style. Sure there are still unrepentant perl terrorists out there but in the grand scheme of things it's dead
cosmic-parsley@reddit
I like Perl one liners in shell scripts!
It works the same everywhere, is pretty much always installed by default, and has sane regex.
sed’ OTOH isn’t cross-platform (-Iworks different on Linux vs. Mac and other Unix) and is limited to basic/extended regex. So I’ve switched fromsedto perl for script string twiddling. (Replacesed ‘…’withperl -pe ‘…’` and most things work the same.)Never actually written a perl file, though.
LoopVariant@reddit
Perl was killed by PHP for web stuff and Python for everything else.
LoopVariant@reddit
Python.
Dreamtrain@reddit
one day you just saw the very last cgi-bin url and didnt think about it
personally glancing '->'s outside of lambdas (which yes didn't exist back then) just trips me
aanzeijar@reddit
Uh, perl in r/programming. To preempt the usual idiotic comments:
No, perl is not line noise, you can program perl pretty much exactly as structured and safe as python, since the languages are very similar. Python gains with better type hinting and a richer standard library for containers, perl gains with saner lexical declarations and list processing.
nicheComicsProject@reddit
Good to see I had to go down this far for the token "yoU CAn WrITe BaD coDE in Any LAnGUaGe" nonsense. It misses the point and missing that point is why perl is dead: if a language makes it easy to write bad code and hard to write good code, that's a bad language. Yes, it's possible to write perl that can more or less be read but it takes tremendous effort compared to, say, python. In a good language, you have to go out of your way to write bad code.
And yes, I know, if you have 50 `use` statements at the top every file and a 3 gig IDE you can make it all almost bearable. In a good language I can write it in notepad if I have to and be ok.
brtastic@reddit
It is equally difficult to write good code in both Python and Perl. If you only argued it's easier to write bad code in Perl then I may agree. However it is because Perl simply has more syntax features than Python - it's way easier to not break things if you find yourself in a straitjacket.
Also, the Python I'm seeing lately is far from readable. Bunch of shortcuts taken, code compressed to minimize the amount of lines used, postfix fors all over the place mixed with those ifs that are supposed to work as a ternary but with more thought cycles required. So the readability argument only resonates with people because they already know Python and they don't know Perl. It's not all sunshine and rainbows for someone who did not pay attention to Python lately.
nicheComicsProject@reddit
Straight up disagree. In fact I'd say practice has proven this wrong. For a long time Python had "One Way to Do it". Perl was so bad that I saw a case where a maintainer fixed a bug and found out people were using it as a feature and had to put it back. They famously used to say the only way to know if a file is a valid Perl 5 program is to run it.
Python has broken their original promise about one way to do it so it's deteriorating but it's still better than Perl 5 ever was.
FlyingRhenquest@reddit
Perl has implemented pretty much all of the C standard library as far as I can tell. The couple of times I've had to maintain it in the past I just turned "use strict" on and treated it more-or-less like an interpreted C.
I did run across a program where someone was reading undocumented data into an undocumented 11 dimensional array of arrays that turned out to be thoroughly unmaintainable, but that code would have been unmaintainable in any language. Same dude was doing matrix multiplies in perl and I'm still about 80% sure that one of the matrixes he was multiplying into the set was not initialized anywhere in the code. It wasn't the language that was shit, it was his code, and converting it from perl to C++ when it became impossible to add more features to it reduced the run time from 11-12 hours in some cases to under a second.
aanzeijar@reddit
Autovivification is sub arrays is a thing, yeah. You can just
$array[2][4][7] = 1;and voilà, there's your 3d array.Speed on the other hand - yeah, perl is slow, even in comparison to other scripting languages, especially for number crunching. The op overhead makes integer arithmetic around 20x slower than C, and that's before cache locality. For numeric calculation there would have been PDL though, which is the numpy equivalent of perl and would have been available to your example too.
colemaker360@reddit
Slower than C/Go/Rust/Java - certainly. But it is still far faster than Ruby and Python in many areas - especially in terms of cold start time, which is useful for places where you might be tempted to pick something like Bash. I still think the advice of “<X lines use Bash,X*10 use anything else” is still pretty relevant today for your preferred value of X between 1-50.
syklemil@reddit
Sure, but most of us operate with a more generic variant I think, as in, shell/script/compiled, where
justand in all cases I suspect rigour and project management is as much a factor in picking a category as performance.
aanzeijar@reddit
Oh yeah, startup time is very fast, as is most string manipulation. I was talking about runtime, especially number crunching.
brtastic@reddit
That's one way of writing it, called "baby perl". Absolutely valid if you're not adept at using it. Though more advanced style can be significantly more readable if done right.
FlyingRhenquest@reddit
Yeah, those were all maintenance projects. If I'd written the code base myself and had been forced to use perl to do it, my approach would have been different. These days I mostly just write C++ code and export APIs to Python or Javascript or both.
frou@reddit
3 "write-only"s and counting subsequently posted :)
sambeau@reddit
There’s an argument that PHP killed Perl for making websites. Not only was it easy to move from one to the other, but Perl required you to buy a fat expensive book while PHP had good documentation online.
pitiless@reddit
mod_php killed perl imo.
It was so much easier to manage, and was much easier for shared hosting providers to work with in (relatively) safely sharing server resources, enforcing quotas, etc
giantsparklerobot@reddit
In 1995 Perl was the only practical option for writing portable web apps. By 2000 it was the crappiest of several practical options. I'd agree mod_php was the primary killer of Perl.
On shared web hosts you not only didn't have admin access to the machine you rarely even had shell access. Deploying a non-trivial Perl app was a PITA as it all had to live in some
cgi-bindirectory (nowhere else had ExecCGI enabled) and many hosts did not bother with any Perl modules besidesCGIand maybe a database connector, which meant no good templating modules. Managing a Perl deployment via FTP could be a hassle. Unless a host enabledmod_rewriteand allowed for it in an.htaccessfile you might not have even been able to have a dynamic main page.Meanwhile
mod_phpwould run files as long as the handler was set up right. PHP was also itself essentially a templating language. You could pepper some<? php ?>tags in your output from DreamWeaver/Fromtpage/Whatever and have a dynamic site. Naming your main fileindex.phpwas often enough to have a fully dynamic page since most hosts supporting PHP included it in theDirectoryIndex.I say this having written a lot of Perl and originally learning it specifically to write web apps. I migrated to PHP because its deployment story was so much easier and for doing web apps was not too much worse of a language than Perl. In the early 00s people that just a few years earlier would have learned Perl instead learned PHP because they could easily write a web app and get it deployed on pretty much any web host easily.
jayde2767@reddit
I think what is interesting is your opening paragraph only hints at the rapid innovation of the web at the turn of the century and everything was being reinvented overnight.
We could argue that PHP did replace Perl, but you have to submit that Java replaced PHP. Simply based on numbers alone, each succession produced a niche language after the change. JavaScript languages replaced anything-Java on the front end and now we have Python almost preferred in Data Science and Systems administration.
All in all, the web upheaval took down many languages trying to find that sweet spot, IMO. Pretty cool period of transformation.
KrakenOfLakeZurich@reddit
As a Java dev: Did it really? In certain environments (enterprise, corporate) I'll give you that. But unlike Perl, PHP still is widely used today (Wiki's, online shops, CMS, etc.).
In these spaces - I'd argue - it's rather NodeJS that is (slowly) eating away PHP's cake.
jayde2767@reddit
Well, it displaced a large portion of Enterprise development. There is no denying that. Whether it took it away from PHP or created a whole new, previously undefined, field of development, sure “replaced” is too strong. But you can argue it stifled that field and moved resources away from it.
KrakenOfLakeZurich@reddit
Thinking back, I‘m not even sure, which came first. I think Java had already „conquered“ the enterprise, before PHP came around.
I remember however, how PHP (the entire LAMP stack actually) took off like a rocket somewhen in the early 2000s. Every village web hoster offered it for free.
Java always had a higher entry bar. You‘d basically had to maintain your own servers to run Java web app.
jayde2767@reddit
That, and it took 74,000 lines of code to write “Hello World!”
Hyperbolic, I know, but IYKYK.
sambeau@reddit
Java and PHP mostly moved in different circles. While social media and web 2.0 (remember that? lol) embraced PHP, there wasn’t a lot of enterprise and banking using it. Even Java in the browser was in its way out by the time PHP’s popularity was exploding—Flash had killed it long before JavaScript’s renaissance. Java for websites crept in alongside (but a little after) Java for enterprise backends. Enterprises apps were being created and rewritten in Java but I doubt many were being rewritten from PHP, more likely they were rewriting Perl.
flif@reddit
The developers of Perl ignored the web.
Perl did not even include any function for encoding text into html or handling URLs. It was like the perl developers was stuck in the past and thinking: real developers don't make web sites.
If the developers of Perl had acknowledged the web and added all the stuff needed to support web well, then PHP would never have happened.
They also prioritized language constructs like "code executed at compile time" rather than making it possible to compile perl code to machine language.
The OO syntax introduced in Perl 5 was even more verbose than Java !
sambeau@reddit
>The developers of Perl ignored the web.
Perl was a first-class citizen in all the early web servers: mod_cgi, mod_fcgi, mod_perl meant the Perl was *the* way to make dynamic websites.
I wrote tons of Perl code for the web. The web server I worked on literally had a fully Perl UI. I wrote a web UI for an FTP file manager, a load balancer, a global load balancer, web-based UIs for more than one telecoms company, various website backends, online publishing systems, …
Jeff_Johnson@reddit
I was beginner back in early 2000-ies and first tried with Perl, but after I saw how things are easier with PHP I just went to it. It was the time with global variables directly (which is bad ofc) from the url but that was probably what helped many beginners.
jexmex@reddit
I think register globals probably nearly killed PHP back then, such a security hole (you also had to screw up other ways too, but still).
Jeff_Johnson@reddit
With 7 layers of validation it can be solved ;)
txmail@reddit
I did tech support for web hosting back in the late 90's --- we had to know all three (PHP, Perl and ASP) and I was never a fan of Perl. PHP certainly had more easier to find documentation and ASP was just super easy to read and understand (but stupid levels of slow).
Jeff_Johnson@reddit
And for ASP you needed windows hosting which was more expensive at least then.
txmail@reddit
We supported Chili!Soft ASP on Linux... which turned up debugging to 11 since it was not 100% compatible and things like directory paths could break a script.
Jeff_Johnson@reddit
I still use php (new version) when I can decide the stack. On my full time job we work on .net off-course, but I really like php on back and React or even vanilla DOM manipulation on front. Php is now quite good and fast.
txmail@reddit
I am a full time PHP developer... so I reach for PHP every time -- though type script has certainly caught my eye more than once.
Plenty of PHP work out there so never had a problem finding a project or trying to complete one of my own.
Jeff_Johnson@reddit
For my project I just go with php, unfortunately I work for enterprise company and there MS is untouchable. I still can’t grasp people writing backend in JS, but I guess their story is similar to mine - it was easy to setup when they started.
txmail@reddit
When I worked for corporate we had some stuff in .net -- then it was up to whoever started the project to pick how it started unless there was some outside requirement.
I used to really rag on JS/TS --- especially for people that wanted to use it as a backend.
Then I got handed a small ExpressJS project and was kind of like -- why is this making sense. WTF is this making sense?! I think my biggest issue with JS on the backend was always like - where is the server to serve up the JS and not wanting to believe that JS is the server, your not using Apache or Nginx to "serve" the files any more unless your load balancing or need to proxy the requests. That little Express JS project just ran and was wicked fast. The idea that the front and backend could be completely in TS/JS was something else too.
Of course now we have pure PHP as the backend server -- no more Apache, Nginx or Lightspeed needed so I guess PHP caught up with JS in that regards.
roadit@reddit
mod_perl was a hassle to install and operate, while mod_php was very smooth. I think that alone explains PHP's success. The other factor is mentioned in the article: Perl was designed as an easy upgrade from shell scripts, and lots of syntax and features present in very simple Perl scripts are great for that but only confusing when you're not coming from there or going there. If the Perl community had created a 'simplified sub-Perl for web programming', and eased the use of mod-perl, it might have nipped PHP in the bud.
chucker23n@reddit
More generally,
had a huge impact on initial success. Sure, that's not how you're supposed to develop software (no continuous deployment, implied no version control, etc.), but coupled with the many, many web hosts that just let you use PHP, it's an extremely easy way to get started.
Add to that "what is a PHP file?":
.php<?phptags where you likeThe only contemporary thing with the same easy of use was Apache's SSI, which wasn't as powerful.
roadit@reddit
Perl offered far better ways to do the same thing;
And I think mod_perl existed before mod_php. But mod_php was so much easier to install that it started to become with webserver installations by default; and PHP was so ridiculously simplistic and lacking in power that its learning curve was also very small. It started out as a Perl script! Subsequently, PHP went through pretty much exactly all of the maturing steps Perl had already gone through. The waste of development effort is staggering.
By the way, the exact thing happened when MySQL arose while the much superior Postgres was already there. That's IT in a nutshell: people just keep inventing wheels, whether they have been invented before or not.
By
RealKingChuck@reddit
that seems anachronistic, as far as I can tell, MySQL was released first (1995 according to Wikipedia) and one year later Postgres got released (1996 according to Wikipedia)
roadit@reddit
Yes, if you look at it that way, but PostgreSQL was based on the much older POSTGRES.
Kered13@reddit
I'll confess that Postgres is older than I thought, but it looks like MySQL is still about a year older.
chucker23n@reddit
For like three years, sure. Then came PHP, ASP, and others.
txmail@reddit
Chili! Soft ASP... man those were the days. Worked web server hosting support and Windows hosting was super expensive, but Linux hosting was a fraction of the cost so everyone was trying to get Chili! Soft ASP working with scripts that were developed for Windows. A ton of the script just worked but some.... nightmares trying to troubleshoot all the while thinking WTF am I debugging a ASP script as a T2 phone support tech...
It was crazy the amount of support we gave back then compared to the zero support off script allowed today.
flif@reddit
That was what the web servers provided, not the developers of Perl or the Perl language itself.
jonathancast@reddit
Perl 5 was released in 1994.
Yes, Matt's Script Archive and quite a bit of proprietary Perl code was Perl 4 running on a perl 5 runtime, but that was a choice, not because Perl 5 wasn't available.
sambeau@reddit
Even the CGI.pm nodule was around before 1998.
heisthedarchness@reddit
Just making up your own facts, huh?
frogking@reddit
OO in Perl5 was a page of code to implement classes. OO was something you chose to follow, not something you were forced to (like java).. python follow the same philosophy. You don’t have to write classes if you don’t want to.
briandfoy@reddit
The docs that came with Perl were basically the same thing as the Camel, both having the same author. You didn't have to buy a book.
brtastic@reddit
PHP core's documentation is not bad, I'll give it that. But neither is Perl's - documentation is first-class citizen there. Took a quick look at 5.04 from 1997, it seems to have a decent documentation. It also came with perldoc tool to view it in the terminal, as well as installed manpages for unix. So I don't think the book was mandatory in any way, though it's a fun read.
However, PHP comes with more web-related builtin functions, can be freely mixed with HTML, and has a bit easier to grasp syntax. Easier to set up, made it possible to build webpages without thinking about external dependencies. That surely made a difference.
sambeau@reddit
PHP's original online docs were amazing compared to everyone else's.
RadicalDwntwnUrbnite@reddit
Especially the community comments, often my questions and issues were solved within them.
surely_not_a_bot@reddit
This. Loved that stuff. It was pre Stackoverflow. But you could look for the docs for a method and people had entire programs written using the method. There was so much signal, so little noise.
Now I wonder why and how was it so good. The community made it, of course. But maybe it was also moderated?
kimble85@reddit
That was really good! It was also super easy to download
ignacekarnemelk@reddit
Nonsense. Perl has extensive manpages you can learn the language from.
sambeau@reddit
As someone who tried in the late 1990s, let me tell you that it really, really wasn’t that simple and those man pages really weren’t that easy to read.
There’s a reason why the Camel book sold so many copies.
PeretzD@reddit
I used one line of PHP in a web page I created and it was perfect! That was the only line of PHP I ever used
franklindstallone@reddit
PHP's documentation was closer to an unmoderated stack overflow. They might be better now but the problem was it wasn't just a description of what the API but it had examples and they may or may not be good or safe. A new user wouldn't know that either.
jonathancast@reddit
That made PHP more popular, though. Give people examples and 99% of people won't care if copy-pasting them is dangerous.
Bowgentle@reddit
The original vibe coding...
jonathancast@reddit
Thank you, I was looking for a "humans are just LLMs" joke and couldn't find it!
CanvasFanatic@reddit
Camel book. ❤️
sambeau@reddit
I think I have all 3 (4?) of the Perl books (Llama, Camel, err jaguar?), plus the one on regular expressions.
bavotto@reddit
What animal was on the Perl book? That will tell you more than you need to know to know about Perl.
CanvasFanatic@reddit
Don’t you fucking dare diss the camel book.
briandfoy@reddit
You can also see this discussion on /r/perl: What Killed Perl?
weevyl@reddit
I know what killed Perl for me, Perl 5. & Ruby.
When I discovered Perl I fell in love with it as my scripting language: no more awk, sed, shell scripts, I could do everything in one place. It became my goto-language for all my quick and dirty scripting.
Then Perl 5 came along with its classes and blessing and the Programming Perl book doubled in size. To me the language started to feel like Frankenstein's monster with many disparate parts glued together and harder to grok.
So I started looking for alternatives, tried out Python and Ruby, liked Ruby and went with that.
MagicalVagina@reddit
Exactly. I'm surprised to see so many people mentioning python. Ruby killed perl because it's just a better perl (it's literally where the name came from) with some smalltalk inspiration on top.
jns111@reddit
Booking.com is a heavy user of perl (at least what they state in conference talks)
my_beer@reddit
Their core hotel booking system has been migrating to Java from Perl for at least 10 years
disposablevillain@reddit
Man I just got stressed out on someone else's behalf
katal_11@reddit
I had to do something similar when I joined Booking and I nope’d the fuck out in a year to a different team which was working on greenfield java services.
And I’ve seen so many perl devs moving out or being forced out in the last 5 years.
I’m pretty sure most of the heavyweight services have been phased out of perl. A lot of our analytic workflows were in perl previously, and almost all of them have been migrated to python-based Airflow DAGs
2rad0@reddit
Perl is still alive and well, as a compile-time dependency in many FOSS projects. Nothing wrong with it, as long as the programmer wasn't trying to be too clever.
nicheComicsProject@reddit
Still having a Perl dependency is a good indicator the FOSS project is also dead or dying.
funny_falcon@reddit
Tell it to PostgreSQL
dontyougetsoupedyet@reddit
The same thing that killed PHP, itself. These languages were both very great to use for specific purpose, and not very great at other things, and both languages attempted to become the World's Most Widely Used General Purpose Language, and both did so poorly. For Perl, most people don't really appreciate brevity in their large programs. That brevity was a great thing when Perl was being used by system administrators as a replacement for bash. Not so much everywhere else.
mgb5k@reddit
I have around 50K lines of Perl that's been live and evolving since 1995. I once rewrote a large part in C++ and to my surprise it ran much slower. Every operation on every object was a separate piece of code so the core operations no longer fit into the L1 CPU cache.
ggchappell@reddit
It was maybe 20+ years ago. I asked a question about Perl, and got a bunch of people screaming at me and calling me an idiot. I asked a question about Python and got a number of helpful replies.
I propose that maybe it wasn't technical issues that killed Perl.
tswaters@reddit
The dream of the 90s is alive in Portland. Something similar to that, but with Perl... It is still used.
maximumdownvote@reddit
Comparing perl to PHP is like comparing a Swiss army knife to a sawed off shotgun.
maximumdownvote@reddit
He's not dead yet. He's feeling quite better.
TCIHL@reddit
I still use it!
Cacoda1mon@reddit
Why?
wildjokers@reddit
Probably to process files.
chucker23n@reddit
It's still fairly good at string processing.
But… I still wouldn't use it for a new project.
wildjokers@reddit
why?
chucker23n@reddit
For one, there's the practical problem others have pointed out: hiring Perl programmers has gotten tricky. Which in part is a chicken and egg problem, but also in part… it just isn't that compelling a language any more.
Which brings me to the second point. Other ecosystems have gotten better while Perl just hasn't.
For example! .NET now has a regex source generator (a form of macros/metaprogramming). I write a method stub with metadata containing the regex:
…and I get two things:
a generated API comment explaining what the source generator thinks the regex does; in the above example, it generates:
for non-complex regex cases, the entire regex is actually broken down into a parser at compile time
The above example, at runtime, doesn't actually use a regex engine at all; instead, the source generator just synthesized code that walks the string.
So it's safer, faster, and more convenient (because the comment explains whether my pattern makes sense).
I don't see how "yeah, or we could use Perl 5 from the 1990s" is going to compete with that.
happyscrappy@reddit
When has it mattered that it was broken down into a parser at compile time?
BTW, that's not megaprogramming, at least by the definition we've been using since Simonyi. It's just programming, like you say it's like a macro.
I don't use Perl anymore and the first one would be enough for me for any code I share with others (work/open projects) even if I hadn't already gotten away from Perl.
It's still useful for one liners like awk is. That's about it for me.
chucker23n@reddit
Performance?
Per Wikipedia:
"Metaprogramming is a computer programming technique in which computer programs have the ability to treat other programs as their data. It means that a program can be designed to read, generate, analyse, or transform other programs, and even modify itself, while running."
A source generator is a program (technically, a dynamic library loaded by the compiler) that goes through my source code, treating it as data (namely, as an AST), and transforming it.
They also specifically list macros as first example of metaprogramming.
I could also add "I don't want to do non-trivial stuff in dynamically-typed languages ever again" to my list of reasons.
Yup.
happyscrappy@reddit
It's not clear to me an inline parser would be faster than a compiled regex. Regex libraries are designed to be fast. So even if it calls to the regex library instead of being an inline parser, why would it be slow for a simple regex?
Interesting, not the definition I'm used to. It's not clear how that definition applies here either though.
A compiler is also a program and it is treating that input as "another program" in the same way you say this megaprogramming does. You above talk about .NET producing an inline parser from your input. What you are doing here isn't really different enough from that to be meta anything. IMHO.
I guess my real issue is if that is metaprogramming then maybe C is metaprogramming because compilers can convert it to assembly and feed it to an assembler. I just don't see how that definition of metaprogramming is useful.
So? Then the C preprocessor is metaprogramming to. And that's part of C, so C is metaprogramming?
Like I said, I just don't see how that's a useful definition. It just is so close to regular programming that is basically is describing the same thing.
Part of the issue is simply that ever since Von Neumann architecture came along like 80 years ago now programs are data. You load them into memory like data because they are data and then it just so happens processor can execute certain forms of the data.
mpyne@reddit
You could do that with Perl 5 from the 1990s, though the Perl people will tell you they really don't recommend doing so.
FWIW Perl 5 has started moving again, but it's probably too little, too late.
TCIHL@reddit
Need to process a stream inside a container that has limited packages and no root access. Bit it’s got good ole Perl
jimmoores@reddit
The massive overreach that was Perl 6 killed it really. Probably would have continued growing a lot longer if Larry had used a more incremental approach.
SpaceMonkeyAttack@reddit
The last company I worked for as a Perl coder transitioned away from Perl because they struggled to find enough talent. It's a vicious cycle: fewer people learn Perl because there aren't jobs in it, and there are fewer Perl jobs because companies can't find skilled Perl developers.
Of course, that doesn't answer what initiated that cycle.
I suspect Perl is still used a lot more for non-commercial projects by individuals or small open source project teams, than it is for "enterprise software".
Kyrox6@reddit
Perl still has a ton of use on the engineering side. My company is at about 180k and contracts out to at least 200k additional folks. All of them spend their whole day running perl scripts. Most are writing one liners and scripts without knowing the actual language they are executing because there's decades of junk that's layered over the interpreter. If you asked most of them what they are coding in, they'd give you a name of some internal company tool someone made up in the 2000's, but it's just running perl with extra global definitions.
My last company had over 100k employees and was the same way. I suspect most old engineering companies do it that way.
None of those people, though, see themselves as programmers. Even if they spend their entire day writing scripts and applications, they still see it as engineering. They wouldn't go fill out stack overflow surveys or anything that tries to track language popularity. If they did, they wouldn't say they exclusively program with perl anyways.
thetreat@reddit
I worked for a team that used perl extensively and this is how I feel about it after I had to work with it for years.
Perl's cryptic syntax does it no favors and makes it extremely hard to pick up.
People that use perl absolutely *love* to use it in ways that make it even harder to understand what the hell is going on. Just because you *can* do something on one line does not mean it should be done on one line. I'd much rather use a more verbose language that makes it easier to understand than get something done on one line. This isn't a CLI and we shouldn't treat it like a CLI.
There isn't first class tooling to help debug perl, which continues to make it harder to understand what the hell is going on. This is exacerbated by point #2.
The people who designed the codebase that my old team used should be locked in a prison for how they abused hard coded data structures. I worked in files that were 60,000 lines long with full ass data bases stored in hashes and arrays and arrays of hashes and hashes of arrays and hashes of hashes and I wanted to rip my fucking hair out after working with it. Either use a database or store these in files that aren't code, you absolute fools!
Point #4 may have influenced my opinions on the rest of the language.
SweetOnionTea@reddit
My shop uses Perl for some production code along with a lot of infrastructure and config stuff. I learned enough to be able to fix bugs, but honestly I was told by the old guard that learning more than necessary would be a step backwards.
Honestly it was a big debate when we were planning a REST API for one of our legacy products on whether to do C, Perl, or Python. I ended up winning my bid for Python on the fact that the old timers are going to be retiring soon and anyone else we hire straight up won't know Perl. And if we say, sure, we can teach you -- I really don't think there will be many new grads gunning to take that on.
lilgreenthumb@reddit
Perl +Tcl/tck
Halkcyon@reddit
The last time I saw Perl in a corporate setting was the early 2010s. It was the developers in India churning out the Perl programs because it could be compiled to an executable and it was what they knew. Updating that ten years later to Python so we could actually iterate on those original programs was a personal hell of mine for six months.
Pttrnr@reddit
i tried to find perl jobs back in the day. never got one despite experience. so i switched to Java. (not saying i was the reason for perls "death" :)
last time i applied i was rejected and then learned from someone who used to work there that it was rigged. they rejected every single person. because they wanted to switch to Ruby and needed the "no people" 'excuse'. and that was when perl was popular.
still using Perl 5 and Raku :)
chucker23n@reddit
But when was the last time you've heard of a new OSS project that was written in Perl?
Ronin-s_Spirit@reddit
So what you're saying is "it got old"? For instance - what tf even is Pearl?
rv77ax@reddit
That one comment in the article explains the reasons better than the article itself.
digidavis@reddit
Python as a glue took over.
Pip vs cpan
Explicit better the implicit.
Nothing worse then debugging perl 'black magic' written by someone with more time then sense.
ZZartin@reddit
There was just nothing particularly special about it the trends moved on.
beders@reddit
Back in the 90s we joked that Perl is a write-only language ie the effort it took to read Perl code was bigger than simply re-writing it. I don‘t think it ever recovered from that.
grumpy999@reddit
Perl died because it is a write-only language
syklemil@reddit
Personally, coming from a sysadmin background, I mostly used Perl in a barely-capable-programmer way, very stringly typed, and mostly using regexes to parse ad-hoc structured output from something else. I think I went more and more to Python as my workflow drifted towards
json.load(and, these days,BaseModel.model_validate_json).At the same time I think a lot of us just didn't pay attention to Perl's upgrades, or worked on servers where they weren't accessible. Just basic stuff like being able to do
rather than
is part of the difference in feeling like a normal programming language vs some hacky bash++.
Lots of us also started moving away from languages that are sloppy by default, i.e. I don't want to deal with programs written without "use strict" and I don't want to deal with implicit conversion errors.
Also:
I'm included in that generation; Perl was actually the first programming language I learned, and I still learned Java at uni; likely somewhere around Java 1.4 or Java 1.5.
These days Perl is becoming a foggy memory for me. I know if I do the "use 5.04x;" incantation I get access to stuff like function definitions actually taking a parameter list and a variant of the print function that automatically inserts a newline at the end (\~ooh\~), but I haven't kept up, and my memories of the language tell me the style I program in these days isn't suited for Perl.
My memories are highly likely outdated, but at the same time, I'm not really on the hunt for a scripting language. Typed Python does that job for me, and Python in general has been doing that job for well over a decade.
look@reddit
Someone finally code golfed all possible applications down to a Perl one-liner so there was no need to write anything more.
EverythingsBroken82@reddit
i used perl until python came around, because with python i had less special characters and hashes and arrays had the same brackets... yes i am that superficially. but otherwise, perl was really core and dependable.
sisyphus@reddit
One of my first jobs was programming perl and that was not my memory of it. My memory of it was that Larry Wall and all the major perl contributors were working on Perl 6 which was going to be a completely different language that was not backward compatible(though some automatic translation tools were I believe promised), so the attitude was more like 'perl is in maintenance mode now so eventually we'll have to switch to a completely new language or be stuck with this moribund one, in which case, why not just switch to Python or PHP?)
Combine that with weak typing. Google blessing Python as a production language giving it credibility, perl not really competing with Rails or Django in the new web framework space, other languages realizing they needed package repositories and starting to catch up to CPAN, and PHP becoming the de facto shared hosting language and there was a lot working against perl.
chucker23n@reddit
This. Almost Osborne effect vibes.
duva_@reddit
Itself
frogking@reddit
For the large part: PHP killed perl because of the ease if adding backend data lookup to web pages.
These days, I’d rather reach for python for scripting and data analysis and typescript fot webpages. Backend data lookup is done through lambda functions and decoupled and can be done in whatever (which ends up being javascript or python)
I do encounter Perl in the wild on occasion (I’m a consultant) and I may be one of the few who actually like the language.
JimroidZeus@reddit
Perl is still around. Still by far the best programmatic extraction and reporting language out there.
Its implementation of regex is the best. Made me hate using python’s implementation, although python’s implementation is much better than it used to be. Still bad though.
vortex_nebula@reddit
Perl 6 and Scala 3 should be an educational content.
ultrasneeze@reddit
Not comparable. Perl 6 (now Raku) is a completely different language.
Scala 3 was more like Python 3, but on a lesser scale. Python 3 broke source compatibility in several key places and didn't provide much help with porting code. Most Scala 2.13 code works as-is in Scala 3, the only problem was that several widely used libraries relied on compiler macros, and that was the one thing that changed as Scala 2 macros are just a way to access the compiler internals and Scala 3 uses a completely different compiler. Unfortunately, the Scala community is smaller than Python's, and that means it took some time until all the major libraries were ported.
hissing-noise@reddit
"Programming language design - what not to do (Step 1 out of 20)"
chucker23n@reddit
Ehhhhhhhh.
That was the case in the 1990s, sure, but when was the last time you've heard of new, significant software that uses Perl of all things? Is Perl among the top five languages used at AWS, Azure, Cloudflare, Google, Oracle? FAANG in general?
Yeah, but that graph is missing a key slice: how rapidly did everything else grow? What about PHP? Java? .NET? Python? JS/Node?
And "people were unsure where Perl was headed given Perl 6 was in no one's land for two decades, then rebranded as Raku, and took all the air out of both Perl 5 and Raku in the process" is absolutely my perception. Call it second-system effect, Osborne effect, Spolsky's "Things You Should Never Do", whatever; Perl had momentum, then took the baby out with the bathwater.
malvagius@reddit
Perl itself
HazelCuate@reddit
it was never alive
zhivago@reddit
People just got used to less ridiculous languages.
charlyAtWork2@reddit
ColdFusion and PHP, for sure.
The MySQL+PHP combo too
brtastic@reddit
You've made a fatal mistake of posting about Perl in a programming sub! You shall now be downvoted to oblivion and beyond!
Jokes aside, I like this analysis, even if a bit shallow, but this sub can't be arsed about anything perl-related. r/perl may like it better.
jailbird@reddit
I've had the luck to work with Perl codebases 20+ years ago when I started my career.
Its syntax seemed deliberately hostile, a forest of sigils and magical variables that most of the times not even my veteran collegause were able to decipher, but even if they could, then none of them could agree on what "idiomatic Perl" actually meant. Error messages were cryptic, context sensitivity was unpredictable, function argument handling was incosistent, the ecosystem was fragmented, and it was full of context-sensitive behavior that would silently change. Working in Perl-based projects felt less like programming and more like solving a crossword puzzle someone set on fire.
Even PHP 4 had a wastly better development experience, no wonder Perl died. Well, maybe it became better later, but I am sure no one sane wanted to tuch it who knew even a little bit about it from the days it was more or less "popular".