10 ms·

The backwards incompatibility of Perl 6 absolutely killed Perl. There are many languages still in use today that have all kinds of warts and ugliness, but they

by orev 11mo ago

The backwards incompatibility of Perl 6 absolutely killed Perl. 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.

jjcc 11mo ago
What we can learn is: evolution is a better choice over revolution given that there's no extreme internal or external pressure.
- cogman10 11mo ago
  You can co-exist. That's the best path forward for breaks IMO. 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.
  - creer 11mo ago
    To be fair, you still have a choice to start new projects in (still progressing) perl 5 or in perl 6. Perl 5 is not abandonned. I second your perplexity on perl 6 vs CPAN. I still don't get it. It's still a problem.
kaashif 11mo ago
> Python only just barely survived the jump from 2 to 3. 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.
- zahlman 11mo ago
  > There was always a clear way forward and people were actually moving. 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.
  - masklinn 11mo ago
    > the movement not nearly as difficult as people claimed. 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).
    - zahlman 11mo ago
      I started on 3.2 and found it reasonably smooth (dealing with encodings in 2.x was also not pleasant IMX if you also cared about universal newline support at the same time), but I will definitely cede that 3.0 and 3.1 were Not Ready.
- 11mo ago
cogman10 11mo ago
You can break backwards compatibility, if you are careful. 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.
- MegaDeKay 11mo ago
  A completely different language, a decade of development to Perl 6, and Python eating its lunch in the meantime. Perl is often called a write only language, and there's Python with for line in file: If you were new to the field at that time, Python seemed like a no-brainer.
  - afc 11mo ago
    Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer. 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.
    - bombcar 11mo ago
      When you have advantages that often come down to "it works great on a teletype over 150 baud" (read, compressed syntax, regex, etc) you will eventually be beaten by something that is easier to read at a glance. 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.
bloomca 11mo ago
> JavaScript can only survive this because there’s no other option in a browser. JS 100% respects compatibility, they even avoided some methods because some popular libraries in the past used to extend the Prototype for arrays
danudey 11mo ago
There are also a lot of things about Perl that prevented new developers from choosing it when other options were available. 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.
- sltkr 11mo ago
  > when I asked on IRC the only answer I got was 'man perldoc' 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 Also, `man perl` gives a great overview of the extensive number of Perl-related manpages. I think any person that starts from `man perl` will be able to answer a lot of their questions, but part of the problem was that around the millennium, people stopped reading man-pages, and started looking for information on the web. perl was one of those old-school tools that were documented extensively in man-pages, but past 1995 ~nobody bothered to read man-pages anymore.
chemotaxis 11mo ago
> There are many languages still in use today that have all kinds of warts and ugliness, Right, but there aren't many with the kind of ugliness associated with real-world Perl code.
- yehat 11mo ago
  Well, what Perl code is not real-world? And by ugly you mean what - not verbose or what? Something is ugly for ones, but nice to others. I doubt that really is a factor driving a demise of language, otherwise features like regexes would be non-existent today.
  - bonzini 11mo ago
    It's just a completely different model. Scalar context vs list context. @x returning length vs $x[0] accessing the list. It has a logic but it's its own logic. Not unlike Rust's borrow checker but at least with Rust you know what you're being promised.
    - kstrauser 11mo ago
      And at least with Rust, even if you don't love it, you can appreciate that there's a compelling reason for it to be that way. I wrote a lot of Perl, but never reached the aha moment where I understand why its sigils were so deliberately odd.
      - shagie 11mo ago
        They were inherited from even older languages and meant pretty much the same thing there. https://en.wikipedia.org/wiki/AWK#Match_pattern_from_command_line https://en.wikipedia.org/wiki/AWK#Match_pattern_from_command... #!/bin/sh pattern="$1" shift awk '/'"$pattern"'/ { print FILENAME ":" $0 }' "$@" The $ notation for a variable in bash and awk... and BASIC... RIGHTS imm & def RIGHT$ (sexpr, aexpr) ... PRINT RIGHT$ ("APPLESOFT" + "WARE", 8) SOFIWARE One might make the claim that EWD498 was correct... https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498... > 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/ 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.
wk_end 11mo ago
Not to dispute the overall premise that Perl 6 did enormous damage to Perl, I want to interrogate this a little bit: > 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.
- flomo 11mo ago
  My take is a lot of that Web 1.0 stuff was total spaghetti code, hardcoded to a table layout, full of injection holes, etc etc. (It was like everyone did my first CGI script x 100.) So in that sense Perl wasn't any different than classic ASP or cold fusion or etc, it became associated with bad legacy code. And because there was no 'Perl 6', people had to choose something else. (There's stuff about the perl language, but that's probably secondary.)
- SmirkingRevenge 11mo ago
  Yea, Perl thrived while there was no real alternative. 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
- kamaal 11mo ago
  >>Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake; 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.
makr17 11mo ago
> it was a good decade before they even admitted Perl 6 might take longer than expected 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."
- Taikonerd 11mo ago
  > well, we never specified _which_ Christmas. 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.
- graemep 11mo ago
  The First World War was supposed to be over by Christmas. Is it possible that it was a deliberate reference?
michaelcampbell 11mo ago
> The backwards incompatibility of Perl 6 absolutely killed Perl. 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.
- cestith 11mo ago
  I think more specifically it was the hesitance to move Perl 5 significantly forward in the meantime that caused the damage. That has been decidedly changed the last few years, with great strides being made. That time in between is lost, though.
  - bombcar 11mo ago
    This is the key - you need to cannibalize from the "new" for the "old" if you're making a grandiose change with no set release date. Perl 5 continuing to get some "back ported" improvements from Perl 6 would have kept it alive for quite a lot longer. You run the risk of killing the new in the cradle, though, and often that scares people. from __future__ import coolshit that's the way you wanna roll
- Bratmon 11mo ago
  > For what seemed like "Duke Nukem Forever" time 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
  - michaelcampbell 11mo ago
    hah! How about "Star Citizen", then?
antonvs 11mo ago
> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use 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.
- autarch 11mo ago
  > 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? 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.
  - anta40 11mo ago
    I think PHP in general is still popular... even though some of the devs switch to Go...
- daotoad 11mo ago
  You say it was a "bad language" for projects of any real size. But I've worked on large systems written in perl maintained by multiple teams. Perl wasn't the source of our difficulties. 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.
Scubabear68 11mo ago
I got into Perl in the early 90s in the Perl4 days, watched the very weird but necessary Perl5 come into focus, then I saw Larry and the community in the 2000s get stars in their eyes and just throw it all away for the dream of Perl6. 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.
- actionfromafar 11mo ago
  And killing Perl 5 in the process. If Perl would have kept going in its own pace and Perl 6 would have been named Rapture or Raku from day one, Perl would have been fine. 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.
  - bombcar 11mo ago
    CPAN and similar things like CTAN were simply phenomenal in a way that really is hard to explain today; since everything has it now. 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.
- atherton94027 11mo ago
  It's interesting because you can still find interviews of Larry online how Perl is the first postmodern programming language but for perl6 they came up with a very top-down, modernist project
- turnsout 11mo ago
  I had a similar experience. It was so disappointing to watch them bike shed Perl 6 endlessly while Python was gradually taking over. 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.
bsder 11mo ago
> Python only just barely survived the jump from 2 to 3. 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.
- bombcar 11mo ago
  If you had a hard, one-time problem, you always went to the perl wizard; he could do anything to anything given a bit of time. 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.
jitl 11mo ago
I think it really comes down to, do new young users want to use your language? I don't think perl5 vs perl6 scared off those users. I think the language design is outdated for what people want from computers today.
- jz391 11mo ago
  Indeed. Coming from UNIX tools (sed/awk/sh/grep/tr etc), perl had a lot of appeal and almost intuitive syntax - alternatives in the '80s being C, awk, or if you were unlucky, FORTRAN IV without string type :-). The benefit of having a single language with all of the functionality of these tools was amazing at the time and ability to use familiar syntax was a benefit. However expectations for programming languages grew somewhat since...
pimlottc 11mo ago
> Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. 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.
thayne 11mo ago
I don't think it was just the backwards incompatibility on its own. I think perl would have had a much better chance if perl 6 had been ready sooner. The long period of time between perl 5 development stopping and perl 6/Raku being ready for production made the transition much, much rougher than if perl 6 was ready from the beginning, or if perl 5 development had continued, and moved closer to what perl 6 would be while perl 6 was still in the works.
davorg 11mo ago
> The backwards incompatibility of Perl 6 absolutely killed Perl. 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).
drzaiusx11 11mo ago
I feel like time and again language designers don't properly uphold backwards compatibility as a high enough priority, to their and their users detriment. 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.)
- josefx 11mo ago
  > from Java's book and maintain backwards compatibility Didn't they start breaking things between Java 8 and 9? Modules, Reflection Access, JavaEE, ... .
  - drzaiusx11 11mo ago
    Nope, the closest thing to a a breaking javalang change is adding new keywords like var. Outside of the language itself, java's standard libraries have undergone some depreciations and packaging moves (moving javafx, etc.), but absolutely nothing like breaking core language constructs, syntax or behaviors across revisions. I would expect standard libraries to have some deprecations across a 20+ year span. 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...
deleted 11mo ago
[deleted]

by orev 11mo ago

jjcc 11mo ago

What we can learn is: evolution is a better choice over revolution given that there's no extreme internal or external pressure.

cogman10 11mo ago
You can co-exist. That's the best path forward for breaks IMO. 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.
- creer 11mo ago
  To be fair, you still have a choice to start new projects in (still progressing) perl 5 or in perl 6. Perl 5 is not abandonned. I second your perplexity on perl 6 vs CPAN. I still don't get it. It's still a problem.

kaashif 11mo ago

> Python only just barely survived the jump from 2 to 3. 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.

zahlman 11mo ago
> There was always a clear way forward and people were actually moving. 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.
- masklinn 11mo ago
  > the movement not nearly as difficult as people claimed. 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).
  - zahlman 11mo ago
    I started on 3.2 and found it reasonably smooth (dealing with encodings in 2.x was also not pleasant IMX if you also cared about universal newline support at the same time), but I will definitely cede that 3.0 and 3.1 were Not Ready.
11mo ago

cogman10 11mo ago

You can break backwards compatibility, if you are careful. 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.

MegaDeKay 11mo ago
A completely different language, a decade of development to Perl 6, and Python eating its lunch in the meantime. Perl is often called a write only language, and there's Python with for line in file: If you were new to the field at that time, Python seemed like a no-brainer.
- afc 11mo ago
  Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer. 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.
  - bombcar 11mo ago
    When you have advantages that often come down to "it works great on a teletype over 150 baud" (read, compressed syntax, regex, etc) you will eventually be beaten by something that is easier to read at a glance. 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.

bloomca 11mo ago

> JavaScript can only survive this because there’s no other option in a browser. JS 100% respects compatibility, they even avoided some methods because some popular libraries in the past used to extend the Prototype for arrays

danudey 11mo ago

There are also a lot of things about Perl that prevented new developers from choosing it when other options were available. 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.

sltkr 11mo ago
> when I asked on IRC the only answer I got was 'man perldoc' 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 Also, `man perl` gives a great overview of the extensive number of Perl-related manpages. I think any person that starts from `man perl` will be able to answer a lot of their questions, but part of the problem was that around the millennium, people stopped reading man-pages, and started looking for information on the web. perl was one of those old-school tools that were documented extensively in man-pages, but past 1995 ~nobody bothered to read man-pages anymore.

chemotaxis 11mo ago

> There are many languages still in use today that have all kinds of warts and ugliness, Right, but there aren't many with the kind of ugliness associated with real-world Perl code.

yehat 11mo ago
Well, what Perl code is not real-world? And by ugly you mean what - not verbose or what? Something is ugly for ones, but nice to others. I doubt that really is a factor driving a demise of language, otherwise features like regexes would be non-existent today.
- bonzini 11mo ago
  It's just a completely different model. Scalar context vs list context. @x returning length vs $x[0] accessing the list. It has a logic but it's its own logic. Not unlike Rust's borrow checker but at least with Rust you know what you're being promised.
  - kstrauser 11mo ago
    And at least with Rust, even if you don't love it, you can appreciate that there's a compelling reason for it to be that way. I wrote a lot of Perl, but never reached the aha moment where I understand why its sigils were so deliberately odd.
    - shagie 11mo ago
      They were inherited from even older languages and meant pretty much the same thing there. https://en.wikipedia.org/wiki/AWK#Match_pattern_from_command_line https://en.wikipedia.org/wiki/AWK#Match_pattern_from_command... #!/bin/sh pattern="$1" shift awk '/'"$pattern"'/ { print FILENAME ":" $0 }' "$@" The $ notation for a variable in bash and awk... and BASIC... RIGHTS imm & def RIGHT$ (sexpr, aexpr) ... PRINT RIGHT$ ("APPLESOFT" + "WARE", 8) SOFIWARE One might make the claim that EWD498 was correct... https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498... > 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/ 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.

wk_end 11mo ago

Not to dispute the overall premise that Perl 6 did enormous damage to Perl, I want to interrogate this a little bit: > 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.

flomo 11mo ago
My take is a lot of that Web 1.0 stuff was total spaghetti code, hardcoded to a table layout, full of injection holes, etc etc. (It was like everyone did my first CGI script x 100.) So in that sense Perl wasn't any different than classic ASP or cold fusion or etc, it became associated with bad legacy code. And because there was no 'Perl 6', people had to choose something else. (There's stuff about the perl language, but that's probably secondary.)
SmirkingRevenge 11mo ago
Yea, Perl thrived while there was no real alternative. 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
kamaal 11mo ago
>>Nothing forced anyone to abandon Perl 5 code, and I suspect most Perl 5 wasn't abandoned for its own sake; 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.

makr17 11mo ago

> it was a good decade before they even admitted Perl 6 might take longer than expected 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."

Taikonerd 11mo ago
> well, we never specified _which_ Christmas. 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.
graemep 11mo ago
The First World War was supposed to be over by Christmas. Is it possible that it was a deliberate reference?

michaelcampbell 11mo ago

> The backwards incompatibility of Perl 6 absolutely killed Perl. 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.

cestith 11mo ago
I think more specifically it was the hesitance to move Perl 5 significantly forward in the meantime that caused the damage. That has been decidedly changed the last few years, with great strides being made. That time in between is lost, though.
- bombcar 11mo ago
  This is the key - you need to cannibalize from the "new" for the "old" if you're making a grandiose change with no set release date. Perl 5 continuing to get some "back ported" improvements from Perl 6 would have kept it alive for quite a lot longer. You run the risk of killing the new in the cradle, though, and often that scares people. from __future__ import coolshit that's the way you wanna roll
Bratmon 11mo ago
> For what seemed like "Duke Nukem Forever" time 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
- michaelcampbell 11mo ago
  hah! How about "Star Citizen", then?

antonvs 11mo ago

> There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use 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.

autarch 11mo ago
> 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? 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.
- anta40 11mo ago
  I think PHP in general is still popular... even though some of the devs switch to Go...
daotoad 11mo ago
You say it was a "bad language" for projects of any real size. But I've worked on large systems written in perl maintained by multiple teams. Perl wasn't the source of our difficulties. 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.

Scubabear68 11mo ago

I got into Perl in the early 90s in the Perl4 days, watched the very weird but necessary Perl5 come into focus, then I saw Larry and the community in the 2000s get stars in their eyes and just throw it all away for the dream of Perl6. 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.

actionfromafar 11mo ago
And killing Perl 5 in the process. If Perl would have kept going in its own pace and Perl 6 would have been named Rapture or Raku from day one, Perl would have been fine. 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.
- bombcar 11mo ago
  CPAN and similar things like CTAN were simply phenomenal in a way that really is hard to explain today; since everything has it now. 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.
atherton94027 11mo ago
It's interesting because you can still find interviews of Larry online how Perl is the first postmodern programming language but for perl6 they came up with a very top-down, modernist project
turnsout 11mo ago
I had a similar experience. It was so disappointing to watch them bike shed Perl 6 endlessly while Python was gradually taking over. 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.

bsder 11mo ago

> Python only just barely survived the jump from 2 to 3. 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.

bombcar 11mo ago
If you had a hard, one-time problem, you always went to the perl wizard; he could do anything to anything given a bit of time. 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.

jitl 11mo ago

I think it really comes down to, do new young users want to use your language? I don't think perl5 vs perl6 scared off those users. I think the language design is outdated for what people want from computers today.

jz391 11mo ago
Indeed. Coming from UNIX tools (sed/awk/sh/grep/tr etc), perl had a lot of appeal and almost intuitive syntax - alternatives in the '80s being C, awk, or if you were unlucky, FORTRAN IV without string type :-). The benefit of having a single language with all of the functionality of these tools was amazing at the time and ability to use familiar syntax was a benefit. However expectations for programming languages grew somewhat since...

pimlottc 11mo ago

> Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. 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.

thayne 11mo ago

I don't think it was just the backwards incompatibility on its own. I think perl would have had a much better chance if perl 6 had been ready sooner. The long period of time between perl 5 development stopping and perl 6/Raku being ready for production made the transition much, much rougher than if perl 6 was ready from the beginning, or if perl 5 development had continued, and moved closer to what perl 6 would be while perl 6 was still in the works.

davorg 11mo ago

> The backwards incompatibility of Perl 6 absolutely killed Perl. 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).

drzaiusx11 11mo ago

I feel like time and again language designers don't properly uphold backwards compatibility as a high enough priority, to their and their users detriment. 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.)

josefx 11mo ago
> from Java's book and maintain backwards compatibility Didn't they start breaking things between Java 8 and 9? Modules, Reflection Access, JavaEE, ... .
- drzaiusx11 11mo ago
  Nope, the closest thing to a a breaking javalang change is adding new keywords like var. Outside of the language itself, java's standard libraries have undergone some depreciations and packaging moves (moving javafx, etc.), but absolutely nothing like breaking core language constructs, syntax or behaviors across revisions. I would expect standard libraries to have some deprecations across a 20+ year span. 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...

deleted 11mo ago

[deleted]