There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Once you need to rewrite everything, there’s no reason to stay with something you know since you need to fully retool anyway.
As a Perl programmer since v5 was released, the confusion around 6 completely destroyed almost everyone’s enthusiasm, and immediately caused all new projects to avoid Perl. It seemed like 5 had reached the end of the line, and 6 was nowhere to be found. Nobody wants to gamble so many hours of their lives, and the future of their business, on such an uncertain environment.
If Perl 6 had any visible movement within the first few years, it might have survived, but it was a good decade before they even admitted Perl 6 might take longer than expected, and then more time after that before they admitted it should have been a new language. 6 was interesting for language geeks, and they probably did some cool things, but you can’t run a large popular project like it’s a small research project. That completely destroyed all momentum in the community. Perl 5 development only resumed far too late, after the writing was already on the wall.
Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. Python only just barely survived the jump from 2 to 3. JavaScript can only survive this because there’s no other option in a browser.
I really don't think this is true at all.
Python 2 to 3 took a really long time, it was a real struggle, lots of people stayed on 2 for a really long time.
But I really don't think Python was close to dying the same way Perl has/is. There was no risk of Python not "surviving" in my opinion.
There was always a clear way forward and people were actually moving. The mass migration of millions or billions of lines of code from 2 to 3 actually happened and has many high profile million+ line migrations, like Yelp or Dropbox.
There was never anything similar for Perl 5 to 6, totally different situation.
In fact, Perl even had the tools to break backwards compatibility baked in from the v5 days.
I agree that Perl 6 is why perl died, but I think the thing that really killed it is what you mentioned. It was a completely different language that spend over a decade with a release date of "soon".
Who wants to work on a language that isn't being worked on because the next thing is AND where from what you know of the next thing everything will be a complete rewrite.
Rust does this with "editions". That's where they can make breaks to the language. 2021 can still call 2017 edition code.
Perl actually had this as well with Perl 5. You could specify the version of the perl file and work from there.
Why they didn't do that with 6 was entirely bizarre. They basically promised to throw out all of CPAN with the next perl version.
JS 100% respects compatibility, they even avoided some methods because some popular libraries in the past used to extend the Prototype for arrays
I learned Python from reading a pocket language reference that just described the syntax and standard library, because the language was simple and easy to understand and everything made sense.
Conversely, I was trying to debug a script someone else ran and came across a line that said '$|++'; it was impossible to search for on the web, and when I asked on IRC the only answer I got was 'man perldoc' which also did not answer my question in any reasonable way.
For anyone wondering: `$|` is an alias for `$OUTPUT_AUTOFLUSH`; it defaults to 0 (line-buffered) but any non-zero value means 'flush output immediately'. Thus '$|++' changes 0 to 1 (or 1 to 2, etc), which means that '$|++' means 'turn off output buffering'. No one could be bothered to say that; if you had questions about the language you clearly didn't RTFM well enough so that became the default/only answer I ever saw.
Meanwhile, the PHP community was often welcoming and helpful to newcomers, despite most of them being bad at programming and giving bad advice, and the Python community produced a language that was so often self-explanatory that new user questions were more about how Python did things or asking about how to implement things they didn't realize were in the standard library.
So yeah, lots of things contributed to Perl's decline, but the community being a bunch of elitist toxic dicks sure didn't help matters and it meant that as the set of people looking to learn how to do programming on Linux grew past the neckbeards looking for any metric to show that they were better than other people then Perl's growth potential was finite.
I was always of the impression that people were very reluctant to move even though the benefits were clear and the movement not nearly as difficult as people claimed. But I still hear people complain about, for example, how you can't run CPython 2.x bytecode on a modern CPython runtime even though you can't run CPython 3.13 bytecode on a CPython 3.14 runtime, either and that hasn't slowed anyone down at all.
I think another saving grace was, when considering Python 3, one's choice was between "easy-ish migration to best in class" and "difficult rewrite into second-best". Meanwhile with Perl 5/6 it was "two moderately hard migrations into metastasized shell-script has-been language" and "difficult rewrite into best-in-class with lots of upside".
Right, but there aren't many with the kind of ugliness associated with real-world Perl code.
It absolutely was. What saved it was:
1. The data science / AI crowd that was gathering momentum any many only used Python 3.
2. No popular alternative. Perl got python as an alternative.
Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.
> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake; it was a Cambrian explosion of new greenfield projects rising out of the ashes of Web 1.0 that brought Python and Ruby and PHP to the forefront. It's just that a lot of the Perl 5 code out there in the world was quick and dirty CGI scripts that died naturally after the dotcom crash and as the web became more sophisticated.
Your overall point notwithstanding, this was just bad advice. What you want is `man perlvar` (or equivalently `perldoc perlvar`) which documents this and other predefined variables:
HANDLE->autoflush( EXPR )
$OUTPUT_AUTOFLUSH
$| If set to nonzero, forces a flush right away and after every
write or print on the currently selected output channel.
Default is 0 (regardless of whether the channel is really
buffered by the system or not; $| tells you only whether you've
asked Perl explicitly to flush after each write). STDOUT will
typically be line buffered if output is to the terminal and
block buffered otherwise. Setting this variable is useful
primarily when you are outputting to a pipe or socket, such as
when you are running a Perl program under rsh and want to see
the output as it's happening. This has no effect on input
buffering. See "getc" in perlfunc for that. See "select" in
perlfunc on how to select the output channel. See also
IO::Handle.
Mnemonic: when you want your pipes to be piping hot
When I asked a question on the PERL Usenet group in the 90s, I used the word "newbie" to describe my skill level. I got an automated email explaining why I shouldn't use that word.
I was there at OSCon when Larry announced Perl6, and that it would be "out by Christmas". And I was there the next year, when he was asked about that, and cheekily replied "well, we never specified _which_ Christmas."
man perldoc
perldoc -v '$|'
So it was actually reasonable advice.
for line in file:
The insane lead time of Perl 6 to even get to a point of backwards incompatibility was it for me.
I'd started on an early version of perl 4 and went through the 5 transition and was excited about 6. For what seemed like "Duke Nukem Forever" time, and finally my fickleness drew me to other languages and frameworks.
There, the problem illustrated
"You are not serrious" is a downright hostile attitude
"man perldoc" as an answer can be translated as "f*^&%k off you stupid...."
None of my projects needed to worry much about char encoding, and I'd used logging extensively starting under 2.6 or so.
Big players, like Django or SQLAlchemy, kept versions both for 2.x and 3.x for quite some time. This allowed for a smooth transition, when all of your dependencies finally had good versions for 3.x.
The difference between Python 2.x and Python 3.x was not dramatic. I would say it was mostly cosmetic up until 3.5 when async landed. Even with these small changes, the splitting of byte strings and character strings alone (an obvious move towards sanity) was plenty annoying for many projects.
Communities and ecosystems are fragile; sharp turns can easily break them.. Even careful maneuvering, like the Python 2 → 3 transition, put very visible strain on the community. A crazy jump that was Perl 6 was not survivable, even though Raku may be a fine language.
In the millennial web forum world, a n00b would ask "what does $| do?" and the answer would be "it disables output buffering", which is what the n00b wanted to know in the first place. It's the Stack Overflow model of giving men fish, instead of teaching them how to fish.
And in today's LLM-powered world that's only more true. If you ask ChatGPT "In a Perl script, what does $|++ do?" it will immediately give you a correct and concise answer, not make you read `man perldoc` first.
If anything might have killed python it was not python 3 per se but shipping a "beta" version of Py3 as 3.0
Python 3 only got usable really around 3.3 or maybe 3.4
man perldocSo no, I don't think AI saved Python; it was fine before then.
I mention this on light of the article's claim that this has to do with "a new generation of programmers brought up on … I don’t know, Microsoft systems, Visual Basic and Java". No. The new languages that appeared were just so much much better.
Original was really rough because the core team had gone in the wrong direction on migration, and the Python io module was hell as well.
By 3.3-3.4 it was relatively smooth sailing but that took a lot of work from the community and core team both (reminder that Python 2.7 was released after 3.1, backporting a number of features to make compatibility easier, and old features were reintroduced as late as 3.5).
Granted, this is coming from a relative noob who read and followed a couple of "how to set up Python properly" articles and that's about it. But I pretty much decided to spend my time on JavaScript, despite its cumbersomeness for implementing simple utilities.
I can easily imagine a scenario where Julia could have taken the data science crowd and Node.js could have taken everyone else. People like Python, I guess.
(There's stuff about the perl language, but that's probably secondary.)
3. six
`six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.
I don't think that RTFM is the best form to answer, but those who auto-reject "man" as an answer are definitely missing something important
Hey you're writing perl already! ;)
Sorry for being salty earlier, but learning a language still takes at least a day or two of solid reading of the official manuals. https://perldoc.perl.org if you want a web version.
Eventually, a website more tailored to such questions was created - Stack Overflow - and there things were very different than in subject-specific communities: there was no "community", there were no discussions, just a big mess of questions. It had a purpose and it served it well. Now it's dying too because of LLMs, but I digress.
Now, in a different scenario, say a colleague asking you that question at work, a direct answer is warranted, but without letting the colleague know that this information and a lot more is a just a few keypresses away would be a wasted opportunity, and not particularly a good way to help that colleague progress.
You can only spoon feed people so much. At a certain point relying on other people to just give you the answer every time you don't know something is lazy. It's like you have no respect for their time.
The wider Perl community adopted that, and for years it was a running joke that Perl 6 would be "out by Christmas."
Of course, people outside the Perl community didn't get the joke. They just perceived it as the Perl community making promises about release dates and then missing them. That was some self-inflicted damage.
But I also burned out relatively quickly. I’d happily answer new questions nicely, but the third or fourth time I saw the same question I spent much less effort to give a welcoming answer than I had the first time I saw it.
Of course, getting the same question repeatedly may suggest something should be redesigned.
I don’t know any good way to keep helpful volunteers helpful for a long time. The best idea I have is constantly recruiting new experts to continually replace the ones that burn out and chase off newbies.
What's an example of a language that's as bad as Perl, that's used as widely as Perl was, that's still in use today?
Perl died because everyone who mattered knew it was a bad language, knew it had to undergo drastic changes, but that essentially meant implementing a new language.
Perl 6 was the symptom, not the cause.
---
Note: by "bad language", I mean bad for anything much beyond the kind of thing you might use awk for. It was bad not because of subjective aesthetic issues, but because it was difficult to maintain non-trivial code bases. Its "write only" reputation was well-deserved - the original author of a non-trivial Perl program might be able to maintain it, but once a team is involved, forget it.
In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.
There was a fifteen year period where the best way of finding out what something meant in a programming language was to Google it. Pre-AI, post the predominance of newsgroups and offline documentation.
Try googling "$|++". It just doesn't work. Never has.
Now Google "file.flush". First hit is the answer you need on SO.
PHP arrived and ate into it's web app use-cases. Modperl wasn't great for hosted environments, to say the least.
Python matured and started eating into it's systems use-cases and eventually the web use-cases as well. And was just so much easier to work with and learn.
Perl was left with no real niche where it really shined, except one-liners and making poetry I guess
Python had a history of tooling/libraries that made it well ingrained into academia
It took AdaCore so long to port the plugin system of the GNAT Studio (GPS) to Python 3 (which seems to be a fraction of the whole code base), that even conservative Debian had to remove the whole GNAT-GPS package.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082332
Not unlike Rust's borrow checker but at least with Rust you know what you're being promised.
I turned down one of those companies because I didn’t want to deal with that migration in 2021
https://gregoryszorc.com/blog/2020/01/13/mercurial's-journey...
Part of me even wonders if the transition had any role to play in why Mercurial gradually lost whatever foothold it had in the DVCS ecosystem.
Perl had and still has truly AMAZING documentation (and far better in perl 5 than Perl 6 - where the documentation's search function is regularly broken for example). And out of this world bring-up tutorials. But if the bar is at "I want to be up to speed after reading a short booklet" - well, that's not gonna work. For me I have programmed in perl for decades and I still get the occasional deep plunge in a feature area that I never used before... And the various docs and books still come through.
On top of that, Perl 5 had an amazing community ready to help - but understandably annoyed with constantly re-quoting the AMAZING documentation. It could have gone either way, it just went the way it did: experts present and ready to answer. But there too - if you expect the community to constantly answer the most basic questions, well, Perl was not for you.
As a tradeoff perhaps, that expert community also spent a lot of effort on the AMAZING module library.
Perl 5's thorough documentation, plus splendid course book, plus all the books, plus CPAN, PLUS the expert help producing fantastic rabbit holes to learn more about your PROFESSIONAL MEDIUM. THAT was the reason for choosing perl.
If anything, newcomers don't go to the documentation because they are not aware that documentation can be THAT good. That was, still is, a marketing error.
I second your perplexity on perl 6 vs CPAN. I still don't get it. It's still a problem.
If they had just done this from the beginning there wouldn't even have been such upgrade drama in the first place... like, as an obvious example, removing u'' syntax for unicode strings immediately at 3.0 was just idiotic: if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all (a la Ruby 2's Unicode reboot, which concerned a lot of people but was a nothing-burger next to the insanity of Python 3).
For a professional medium, the only lack that I can tell is from a marketing point of view: installing the distribution for example, probably did not highlight enough how extensive the documentation was.
I still to this day stumble upon code I have to use 2.7 on, thankfully things like pipx make it easy these days. but still,switching back and forth could be a pain.
But you're right, it wasn't like Perl 6. People moved to python and php mostly from perl. what were going to move to from python 2? Ruby?
No need for google. (And google was run by python fans; probably saw no need to support searching for '$|++'.)
And I notice "post the predominance of offline doc". Well that's one problem right there: As of 2025, there is still nothing that beats perl 5 docs as ~260 man pages. Probably LLM-based AI is getting there, at least for people who have difficulty with text. But for the rest of us, it's VERY useful to know that there is solid (offline) doc.
After that, each section is long but very searchable.
But I can see how many people never even noticed."Man page? what's that? what for?"
Yes! There was a lesson in that and we all missed it. That was probably one of the failings of perl. It ran into a generation of people who never knew about "man pages", or couldn't read (jk - but only somewhat: for some people reading is very hard because various flavors of ADHD, dyslexia, executive disfunction, whatever) and the man page is then useless, or they go to google first and '$|++' failed (because google was raised on python).
Better marketing of the documentation would have helped.
I would say "we'll do better next time" but then perl 6... I'm not happy with perl 6 documentation. There is a lot of it - no problem there. But it insists on living online which necessitates a hosted search function. Which is always broken. And there is still no "local doc" solution.
Which is covered in the very first section of the course book? Yes it has its own logic. So do lots of programming languages.
How far do we need to take "not reading the doc"? That the very first chapter is too far? People who gave up on perl because of that... really would not have survived the rest of the course anyway?
I too was rather upset about the Python 2->3 shenanigans and I was working on much smaller projects.
The real issue is not just that Perl6 wasn’t backwards compatible, it was that Perl6 basically did not exist for real for many, many years. People got tired of waiting, and the lack of backwards compatibility did not help.
Also Perl6 was just more weird on top of weird from a mainstream perspective. Making it even harder to justify.
In the timeframe we're talking here (late 1990s), that transition was Python1 to Python2! A couple Linux distributions were on Python 1.5.2 for a very, very long time. All y'all forget that what Guido, et al. did for the Python 2 to Python 3 transition was informed by the grief they hit in the Python 1 to Python 2 transition!
I would argue that really "What killed Perl" was that people started writing bigger scripts than one-liners. Perl has a well-deserved reputation for being a "Write Only(tm)" language. Python (and really just about every scripting language of the time) was simply better for containing complexity and easier for a newbie to understand.
I remember taking printouts of Perl and Python scripts for the same task to job interviews. The Perl one always had some surprise for the interviewer no matter how hard I tried to remove them. The Python one ... was simply straightforward.
Nowadays when everyone and their dog (vcpkg) have a package system, it’s easy to overlook how magical CPAN was. A solution to the weirdest problem, just a package away.
Fun fact: The amount of time it took Perl 6 to come out after being announced was actually longer than the amount of time it took Duke Nukem Forever to come out after being announced
It was a magical time.
If they hadn't done Perl 6 the way they did, it'd still be around. Perl 5 was fine but the impending doom gradually let it be overcome.
Non-programmers read python and sometimes even Java and say "huh, this is something that could be figured out" - reading perl was reading line noise.
APL is probably one of the most powerful languages out there, but the characters in the syntax scare most away.
You run the risk of killing the new in the cradle, though, and often that scares people.
from __future__ import coolshit
Grab a snippet of Java or Python and you can google it pretty easily, grab some line noise from perl and you would first need something to translate it into idiomatic text - search engines would search for "OUTPUT_AUTOFLUSH" but would often discard things like "$|++"
I remember learning my use of perl from a red book - probably "Perl 5 by Example" - everything was in books back then, and you read them. Now you learn programming via searches and LLMs, so the languages that win going forward are going to be the ones optimized for that.
Even build an entire web-based GUI for a product.
But eventually you realized that if you wanted to reuse the code, or have others work on it, the downsides of Python began to pale.
PHP? I don't know how widely it's still used, but I'd guess it's more widely used than Perl. Also, PHP is not "as bad" as Perl. It's much, much, much worse. It's Perl without the charm.
Expected to know it's there, navigate through it to find the operators or system variables and that you can search through the thing. There are ~260 perl man pages on this computer - not expected to read them. For damn sure expected to use them.
Do read one more section from top to bottom now and then - if the thing is the one fundamental tool in your job!
$|++ is arcane to anyone not steeped in Perl
The newbies could be warmly welcomed and shown respect.
But no, RTFM.
That is rude to somebody drowning in newness. If you do not want to answer their question, then don't. But some people seem to get a kick out of being rude to weaker people
All the times it happened to me, back in the '90s this made life really much harder than it needed to be.
For all the ones who bum me out
For all the ones who fill my head with doubt
For all the squares who get me pissed
You've made my shitlist
FreeBSD has the same problem: plenty of its new exploring users dismiss the most well-intentioned advice to read its excellent Handbook as a sort of joke.
There must be a reason why they made sigils more "traditional" in Perl 6, for example.
> People who gave up on perl because of that... really would not have survived the rest of the course anyway?
I didn't give up on it, I just didn't feel the need to stick with it. I switched to something else that required less of a context switch when going back, awk or jq or Python.
Now, jq is something that throws me off every time I use it. But it's a completely different processing model, whereas lists and hashes are not specific to Perl.
In 2018, I don't know if Go was a major player, both it and rust were still new-ish languages. There was still a concern of being able to hire devs if you used them, where as not so much in the past 4-5 years.
So, to touch on that, no contest that for a while now, you can have a well paying job only writing python. (And perhaps even never going through a formal course on it.) That has worked for many people.
> There must be a reason why they made sigils more "traditional" in Perl 6, for example.
Eh. Sigils are even more present / visible in perl 6. And other compact notation devices. All the way to making up your own unicode-based line noise when it serves. Which it does.
> This ground rule meant that a mass insertion of b'' prefixes everywhere was not desirable, as that would require developers to think about whether a type was a bytes or str, a distinction they didn't have to worry about on Python 2 because we practically never used the Unicode-based string type in Mercurial.
> In addition, there were some other practical issues with doing a bulk b'' prefix insertion. One was that the added b characters would cause a lot of lines to grow beyond our length limits and we'd have to reformat code.
I wonder if their line length was arbitrarily 80chars or some silly serial terminal like limit.
> It is now 2020 and Python 2 support is now officially dead from the perspective of the Python language maintainers. Linux distributions are starting to rip out Python 2. Packages are dropping Python 2 support in new versions. The world is moving to Python 3 only. But Mercurial still officially supports Python 2
To me it doesn't matter what pain points there were between 2/3, or that it was even python.
That is just the classic way any modernization effort fails. IMHO those failures are almost completely tool agnostic and are cultural failures.
I will always bang the drum for Java for doing this well. Making changes to a heavily used language is _hard_. Sure, the speed of progress can be slow, but Java has managed to introduce major improvements (and deprecations) without causing a schism. That deserves respect.
'$' guarantees a scalar. Then it either alphanumeric id, or a single non-alphanumeric symbol. And the latter means you deal with a 'special' var which with 100% certainty has a documentation entry.
It was not for not reading the full manual. It was for not using the manual. Somewhere between "not at all", "not competently", "not persistently". And he was pointed to a perl-specific tool which is made for searching the doc. Not the same thing?
And he/they had missed an entire category of symbols. That none of the responses pointed at - their bad on that. That is, all these symbols are described in the same manual section. And used in illustrative examples all over the place. They are not exactly a deep hidden thing.
Also, regarding "flamed". No. Not really. They were handed the same response that countless other questions were getting. Anyone frequenting these forums saw them countless times. It is quite possible that it was their first time on that forum / chat and then that the answer was shocking and traumatic. Yes to that. So that in hindsight, the standard response should have included a pointer to a "how to use the doc" doc. That would have helped. Since it was a generation was seemed unaware of the man pages.
If only you had read the manual...
Seriously though, of course I wasn't advocating for rudeness, and trust me, I remember how rude some people were back then in tech-related boards, this was not a unique Perl thing. I'm advocating for pointing people to the sources of information they're looking for.
> You've made my shitlist
Well then I hope it's posted somewhere I can refer to at will so that I don't have to ask you on a message board like a noob.
~3.8 at the time, not 3.0. 3.0 was a mess.
There's always Tauthon (Python 2.8), lol.
In this case, you would have to already know about the existence of eui-64 to know that is what you want. I've seen this many times, you have to know what the thing is already, or know what the answer is to your problem, in order to find it in the man page.
Total waste of my time. I don't care if it's free or was created by volunteers, that isn't absolution of criticism when it represents something and fails to deliver it.
It was methodical and deliberate, but slow.
But I think it really happened because developers wanted to move to 3. There was enough momentum and upside for moving to 3 that the Python core developers could keep the migration on track without having to drag people along from 2 -> 3 before they were ready. Making sure that the transition was optional for a long time helped tremendously.
I was quite happy working in Python 2 for a long time and only transitioned over to 3 for new projects or code that I thought would have a long lifetime. This was very much a reason why I moved to 3 instead of to another language.
At the same time, I'm not sure what language I would have switched to for the things I was using Python for... Perl was out as it had it's own disastrous migration. Ruby was an option, but never really hit the general-purpose scripting language mark for me.
Perl, Lisp, Haskell, Prolog etc.
I was there when Perl ruled the world, I used it myself to rule the world. The scene was always managers going to the C++/Java teams and asking them an estimate to a get a project done. They would often come back with timeline spanning 1 - 3 years.
Perl teams would get it done in like a week.
Needless to say most non-Perl programmers wanted Perl gone for this one reason alone. Too powerful, people who know how to use it make too much progress compared to everyone else. Smaller teams making larger progress shrinking the head counts, which top bosses didn't like.
Programming world is a sea of mediocrity, good things mostly don't make it here.
https://en.wikipedia.org/wiki/AWK#Match_pattern_from_command...
#!/bin/sh
pattern="$1"
shift
awk '/'"$pattern"'/ { print FILENAME ":" $0 }' "$@"
RIGHTS imm & def
RIGHT$ (sexpr, aexpr)
...
PRINT RIGHT$ ("APPLESOFT" + "WARE", 8)
SOFIWARE
> It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
https://www.perl.com/pub/2007/12/06/soto-11.html/
> Now, however it was initially intended, I think BASIC turned out to be one of the first major scripting languages, especially the extended version that DEC put onto its minicomputers called BASIC/PLUS, which happily included recursive functions with arguments. I started out as a BASIC programmer. Some people would say that I’m permanently damaged. Some people are undoubtedly right.
... but it wasn't without previous examples that Perl went the way that it did with sigils.
I was able to reason my way through these things and had luck writing reasonably large Perl programs. It did absolutely zero to help make devs' lives easier, though.
> if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all
Having been there and done that, nah, the text model changes alone required significant work to square up in most packages. And there were plenty of other semantics changes.
It's hot garbage for writing simple cross-platform utilities because of the need for an elaborate environment setup, painful dependency management, and constant compatibility breaks.
I would also contend that given the tools at the time (vt100 terminals without syntax highlighting being prevalent systems) sigils made it easier to write more on a line, provided easier visual recognition (for those familiar with the language) about the syntax, and provided for a more easily written lexer.
Uh.. You've started in the middle. Python 3.0, 3.1, and 3.2 were insufficiently compatible to support a migration. If not for the effort to reduce 2 to 3 incompatibility by shipping 2.7 and 3.3, 3 could really have failed. I'd say the initial plan was not so good but then the _replan_ after the first setbacks was good.
Django absolutely would have been ported: it was ported without six by Vinay Sajip (building on an earlier work of Martin von Löwis). In fact a limited shim layer was initially committed based on Vinay’s efforts: https://github.com/django/django/commit/5e6ded2e58597fa324c5...
The team ultimately decided to use and re-export six for the convenience of the ecosystem, not out of any sort of necessity.
Out of curiosity, I tried
perl "$|"
The real issue was ugly code that was in the product when it was acquired--you can write 2000 line methods in any language if you are cursed enough. Believe me, if you do this, you will be cursed.
We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.
I'd go so far as to argue that the expressiveness and flexibility of the language was an asset that helped us in our refactoring. For example, we built instrumentation that took advantage of Perl's unusual semantics for dynamic "local" variables to create flexible instrumentation that could have log levels enabled based on the call stack--if you turned on aggressive logging in function A, it would propagate to A's calls into functions B and C, while other calls to B and C would be logged at normal levels.
Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context, but the dynamic scoping gave us the tools we needed to build something powerful with only a small amount of clear, commented code.
I think the backwards incompatibility was a minor issue compared to how long it took for Perl 6 to be released. It was eighteen years from the announcement to the first (just barely) usable release. And for a lot of that time, I was hearing tech leads say things like "we don't want to start this project in Perl 5 if Perl 6 is just around the corner."
At some point, they changed the narrative from "Perl 6 is the next version of Perl" to "Perl 6 is a sister language to Perl" - but they should have renamed it at that point instead of waiting another 5 years.
It's worth remembering that the Perl 6 project was started because Perl usage was stagnating. But the project was so badly managed that it killed off both Perl 5 and Perl 6 (now renamed Raku).
> The real issue was ugly code that was in the product when it was acquired
IME, this was the norm for Perl projects, not the exception. And you explain the reason for that:
> We dealt with the flexibility of the language by defining clear guidelines on what approaches were recommended and what misfeatures were banned.
Yes, it's true that a disciplined, mature, skilled team can write good code in any mainstream language. But in practice, there are far more teams that lack enough of those qualities, that using what I'm calling a bad language will contribute to them producing hard to maintain, buggy code.
If you're defining a subset of a language as being good, you're proving the point about the overall language not being good. This is why Perl failed - because its real-world use more often than not produced poor outcomes.
> Yes, it's possible to do this sort of thing in other languages using a singleton that tracks logging context
That doesn't sound like the right approach - it sounds like you really want the opposite of a singleton. In most languages, you'd just pass a different logger instance, either as an argument or in an object field.
Bugs in Perl modules that are documentation related are normal bugreports and patches in the normal patch flow because documentation is embedded as POD within the source code.
Your example is very specific and weird (and maybe not even Perl-related). From which you deduce that it is OK to waste the time of volunteers because once one manpage failed you and you decided to never read any manpages again. You only seem to care about your own time, not anyone else's. That is not how anything works on this planet, either you deal with volunteers, where you have to make them care about your query by being considerate, friendly and respect their time as well as you would like yours respected. Or you are dealing with paid support, in which case you have to make them care by paying them for their time by the hour.
the entire tech industry is driven by humans and we're really bad at everything. once the AIs take over things should be much better, except for the occasional hallucination.
My team has recently ported 14 Ruby services along with over 50 separate Gem libraries from ruby2 to ruby3 where THEY CHANGED HOW FUNCTIONS INTERPRET ARGUMENTS! Older code run on newer runtimes _change behavior_ for the same code by treating splatted arguments differently, which was _very_ annoying to figure out and reason over for codebases that _heavily_ used '*' splatted arguments.
I feel like folks need to take page from Java's book and maintain backwards compatibility as a core tenet of their language. I've done perl4 -> perl5 -> raku, python2 -> python3, ruby2 -> ruby3, and rewriten a handful of c++, rust and node applications because everything in those landscapes seems to be in constant flux...
I just want to write software that will continue to work after it's been written, without having to use an older CVE-ridden language runtime every time. From personal experience, only java seems to 'get it.' (I'm sure there are others that do get it, but sadly I've had little opportunity to use them.)
Its got a big standard library so you can do a lot by just installing Python. On a lot of *nix systems it will all be installed already. For simple use cases you do not have to have the environment manager.
I have had few problems with virtualenv in any case.
Where you are most likely to have problems is cross platform deployment. If you are going to package it as an exe for Windows users, and package it for major Linux distros, and whatever you need to do for MacOS etc. its going to be a pain. In that case there are multiple languages that might suit you better than JS.
Python 2 had both, it was a rename, not a split. unicode -> str, and str -> bytes. The "u" string prefix was also removed, which made migration of string-heavy code more of a pain than it needed to be, until it was added back in in 3.3
Even as a die-hard mod_perl fan, I never even tried Perl 6. The language had gone from the most concise and efficient way to process text streams to an incredibly complex OOP language that for some reason had an experimental Haskell implementation, its own custom VM and multiple compilers.
chromatic's https://modernperlbooks.com site is nearly unmaintained now, but still contains some good links to tutorials and whatnot on the obvious subject. Including a pretty recent retrospective: https://outspeaking.com/words-of-technology/why-perl-didnt-w...
Of course, you aren't under any obligation to spend time helping people who you don't want to, but if a community as a whole reacts this way when someone asks a question, they're making the bet that the there are enough people who are similar enough to them to sustain things in the future. Given that this both happened years ago to the parent commenter and now again when they tell the story again, it's not really that hard to believe that this might have been common enough that a lot of people experienced it. The entire point of this thread is discussing why Perl has faltered, and your explanation in the last paragraph comes across as basically saying "kids these days..." in slightly different words. I'd argue that even if the kids loved man pages, having a condescending attitude towards them would probably still come through in other ways, and that would have had pretty much the same effect.
I agree with you that this probably was a contributor in some people giving up perl quickly. For python or php.
Like I mentioned elsewhere, for people for whom using a book would be a barrier - perl would have been a poor choice anyway. You can't program in perl without using the man pages and books. It's a large language, with lots of features purposely made less visible to the newcomer.
In addition, many people were exposed to perl from web scripts. And it was sooo tempting to just paste in a perl script, and then want to modify it, without spending any time on learning the language. Perl makes that frustrating (and compensates with a stellar course book). I still defend perl by arguing that (in perl) there is no point in discussing what $| might mean even before having covered the basics, for example sigils. The course book is layered, and for good reason: to let you write a program in useful order, fundamentals first. The special variables come up fairly early but then again the course book had an extensive index which includes these special variables first in a symbol section, and then again in the alphabetical order for their wordy version $| or $OUTPUT_AUTOFLUSH. I'm not trying to beat you over the head with the manual. Just pointing out that the course book was throrough and intelligently written.
I'll point out that throwing a question at a forum without poking around it a little to figure out the local mores - well, still now, that will get you barked at. Lesson: Forums would do well to provide a more useful paste-in than "RTFM" - ready to go for their users. Instead of "RTFM". At least if they want to foster adoption. Does any forum do that particiularly well, that you have noticed? Most discords for example, do NOT do that well: it's possible to create stickies and they are really not visible. So people create onboarding documents which then get too long and get skipped. A problem not solved there.
Actual language standards that multiple stakeholders agree on are a much better approach.
Platforms should absorb pain, not multiply it across all developers that use the platform. (I wish Apple would learn this lesson.)
Imo the coding part is fine. I have no mayor complains about it. I even like indentation as syntax as long as you use tabs :)
Python is the modern day BASIC. Slow interpreted lingua franca. As long as you are ok with its speed I say go for it. Python is the only scripting language where I maintain constant lingering awareness that every single line of code adds milliseconds to run time. As bad as instantiating new variable costing single digit ms on a GHz CPU. This quickly adds up the more you are trying to achieve.
Example benchmark, Python 3.4:
# Direct Access d['key']: 3.3710 seconds
# Direct Enum Access d[enum.key]: 157.9954 seconds
Didn't they start breaking things between Java 8 and 9? Modules, Reflection Access, JavaEE, ... .
However, I'm of the opinion that "standard libraries" should be much more minimalist and than javas: move as much as you can into a "core" library that isn't necessarily part of the language, just an optional runtime component following semver so you can be sure pinning a major version will work for essentially forever. Java isn't perfect in this regard, but it sure as hell better than what perl, ruby and python have done in significantly less time than javas...
"Having no popular alternative" is not something that was close to not happening.