[HN Gopher] What Killed Perl?
___________________________________________________________________
What Killed Perl?
Author : speckx
Score : 119 points
Date : 2025-11-19 10:25 UTC (12 hours ago)
(HTM) web link (entropicthoughts.com)
(TXT) w3m dump (entropicthoughts.com)
| cafard wrote:
| About a dozen years ago, I noticed that the young all seemed to
| know Python, and did not seem to know Perl. Given that they would
| be maintaining such code as I wrote and was worth keeping around,
| I moved to writing in Python. Now when I write Perl, I do silly
| things like forget semicolons.
|
| Perl can be very well written. I deeply regret not encountering
| _Perl Best Practices_ when it came out.
| brianhorakh wrote:
| Raku
| rwky wrote:
| I still use perl. It's my go to for string parsing (think pipe
| log file, do something with it and send it to stdout). It's also
| my go to for anything that I still want to work in 10 years.
| crmd wrote:
| I heard a fascinating theory a few years ago on the decline of
| Perl:
|
| In the early aughts, Google SRE recruiting had such a strong,
| selective focus on A-player sysadmins with Perl expertise that it
| drained the market of top talent. Within google these people
| began to adopt, and eventually create and evangelize newer,
| Googlier programming languages.
|
| In other words, Perl expertise was the skills filter, and Perl
| itself a technological ancestor of certain modern languages like
| Go.
| rurban wrote:
| Nonsense. Google only ever hired one perl5 committer, who never
| actually committed anything.
| maxlybbert wrote:
| I don't think Google was ever a Perl shop. eBay and Amazon
| were, apparently. Netscape wrote Bugzilla in Perl. I'm sure
| there were others.
| spudlyo wrote:
| I worked at Booking.com for a year or so around 10 years or
| so, and most of their stack was in Perl. Folks there had
| mixed feelings about it, I'm not sure what things are like
| now, but I assume they're working to replace it.
| steveklabnik wrote:
| IMDB is the one I always think of.
| colinstrickland wrote:
| chunks of Amazon were still in Perl while we were building
| out IMDb.
| darrenf wrote:
| Yahoo! had a shitload of Perl.
| hn_acc1 wrote:
| Ah yes, that's it. I had to hack on Bugzilla to customize it
| for our start-up.. Back in the day BEFORE they added a lot of
| end-user customization... UGH..
| bhaak wrote:
| Easier to learn languages came along.
|
| Perl stems from a time where COBOL, FORTRAN, and SQL made sense
| and it was already mind bending for those accustomed to those old
| languages.
|
| Modern minds can't comprehend Perl.
| HumanOstrich wrote:
| I learned and used Perl professionally from around 2005-2015 and
| experienced first-hand the ossification, fear of change, and lack
| of innovation in Perl 5 development. It seems all the talent and
| effort started being wasted on making Perl 6 the bestest, most
| elegant, most useful programming language in the world. Just
| seeing the neglect of Perl 5 kept me from ever considering Perl 6
| and motivated me to move to other languages.
| jmclnx wrote:
| I started learn Perl 5 right before 6 was announced. When I saw
| what was happening with Perl 6, I decided just to stick with
| sh, awk and friends.
|
| IIRC, The Perl 6 development thing went on for a very long time
| and got nothing but bad press. That took the wind out of my
| sails.
| 7thaccount wrote:
| It's been discussed before, but Python just seemed more
| straightforward to a lot of people. It had a built-in object
| oriented model as well when that was the rage instead of the weak
| default one and dozen modules on CPAN to do object oriented
| programming. There was generally one way to do something and that
| was easier to learn than TIMTOWTDI.
| cestith wrote:
| One of Python's killer features is how easy it is to find a
| Python library wrapping some native code library written in C
| or Fortran. Those used to be notoriously difficult to write for
| Perl.
| autarch wrote:
| I was writing a comment asking if it was really easier. Then
| I took a look at Cython. Yes, this looks easier than Perl's
| XS, which I have some experience with! There are ways to do
| something similar in Perl these days, notably
| https://metacpan.org/pod/FFI::Platypus. But these are
| relatively new (starting in the 2010s) compared to the
| history of Perl, and Cython goes back to the early 2000s.
| cestith wrote:
| Somewhere in the continuum from SWIG through XS and on to
| Platypus there are also the Inline modules these days. They
| allow one to put inline sections of other languages into
| Perl code the way many language tools used to allow one to
| inline assembly into C or Pascal code.
|
| There are some of these modules for other languages than
| those listed here, a lot of them as high level as Perl
| (including Raku and even another Perl system for some
| reason).
|
| https://metacpan.org/dist/Inline-C/view/lib/Inline/C.pod
|
| https://metacpan.org/dist/Inline-ASM/view/ASM.pod
|
| https://metacpan.org/dist/Inline-
| CPP/view/lib/Inline/CPP.pod
|
| https://metacpan.org/dist/Inline-CPR/view/CPR.pod
|
| https://metacpan.org/pod/Inline::Lua
|
| https://metacpan.org/dist/Inline-
| Java/view/lib/Inline/Java.p...
|
| https://metacpan.org/pod/Inline::Guile
|
| https://metacpan.org/dist/Inline-SLang/view/SLang.pod
|
| There are even tools to convert from Inline to XS for C and
| C++.
|
| https://metacpan.org/dist/InlineX-CPP2XS/view/CPP2XS-
| Cookboo...
|
| https://metacpan.org/pod/InlineX::XS
| autarch wrote:
| True. For whatever reason, these never displaced XS. For
| wrapping C libraries in particular, it's not clear to me
| how much Inline::C helps with this. You're still stuck
| using a lot of Perl C API calls, AFAICT, which I think is
| the biggest challenge of using XS (I still have
| nightmares from trying to figure out where and when to
| add `sv2mortal` in my XS code).
| cestith wrote:
| I haven't done nearly as much of this as you.
|
| One or two calls into a library with a simple C interface
| isn't that bad with Inline. You just use Inline to handle
| the Perl to C to Perl part, and actually do the
| interfacing in the inline C. It's a lot more mess if
| you're doing complex things and bringing complex data
| structures back to Perl, or having Perl make a lot of
| intermediate decisions and doing a lot of round trips. So
| if you use Perl to get the data ready to pass in, pass it
| in, do all the work in C that you need the library for,
| then pass the results back to Perl once it's not
| terrible.
|
| I've tried not to get into XS, so I couldn't really
| compare.
|
| Using Inline::C with your own C code in places where Perl
| is too much overhead is certainly easier than wrapping a
| complex existing library with a lot of interactions
| across the boundary.
|
| FFI::Platypus or something like it really is the way of
| the future though for existing C calling convention
| libraries in other languages.
| BeetleB wrote:
| Yes, the answer is Python, Python, Python.
|
| There's a reason the Zen of Python includes this:
|
| "There should be one-- and preferably only one --obvious way to
| do it."
|
| It also came with batteries included, which really lowered the
| learning curve.
|
| Perl was well known for being a pain to read months after you
| wrote it. Most Python code in those days was readable by people
| who did not even know Python.
|
| When I started my job in 2010, I took a class at work on Perl.
| I had done some Perl years before and had grown sick of it, but
| I thought I was just doing it "wrong" so I thought the course
| would tell me how to code in Perl "properly".
|
| Nope - I'd been doing it "right" all along. I just hated the
| language. At the end of the course, I told the instructor (a
| graybeard) that he should just use Python, and that one day I'd
| teach the Python course and he should attend. He scoffed at the
| notion: "Languages will come and go, but Perl will always
| prevail!"
|
| I never did teach that course, but I bumped into him about 7
| years later. He had completely (and willingly) abandoned Perl
| for Python, and was a big Python advocate.
| liveoneggs wrote:
| if only python stuck to any of those ideals
| BeetleB wrote:
| Python has grown some warts, but I can still read code I
| wrote 20 years ago.
|
| People who don't know Python will have a harder time
| reading modern Python, though.
| ok123456 wrote:
| TIMTOWTDI broke down with trying to do OOP in Perl. You could
| either bless a hash, or use a meta-object framework (moose?).
| You could end up with hierarchies of different types of objects
| with their own behavior.
| pjmlp wrote:
| As someone that was already working during the dotcom wave, Perl
| is a tool I would still reach for, given the problem I might
| trying to sort out, if on an UNIX like platform.
|
| > Binary package managers that chase down dependencies on their
| own weren't a thing until the early 2000s, I think?
|
| UNIX package managers started to be made available during the
| 1990's.
| kqr wrote:
| Yes, but they were either source package managers or they
| didn't resolve dependencies transitively, only complained about
| missing direct dependencies.
| pjmlp wrote:
| I might be using strange versions of Red-Hat, Mandrake, SuSE,
| Aix and Solaris, then.
| dspillett wrote:
| I definitely had Debian installs pulling binary package
| dependencies automagically via apt-get in 1999, and I think
| similar with RedHat a year or so before that.
|
| Though that doesn't cover _much_ of the 90s.
| JSR_FDED wrote:
| Is it worth learning Perl 5 these days? Maybe to use as a better
| Bash?
| cestith wrote:
| It's strong as a better shell. Perl is even getting an
| increasingly good and complete default object model in the core
| language. One of the big complaints was always that the
| TIMTOWTDI included object libraries, of which there are many.
| Most of the popular ones are working on becoming wrappers
| around the new core one, and you can write new code directly
| with what's in core.
| spudlyo wrote:
| It's definitely more powerful and has less foot guns than bash,
| the problem is the _stigma_ is worse than bash. You will face
| more scrutiny and possible derision from your colleagues for
| using Perl than bash. It 's not just questioning your taste or
| style either, it's because of the fear they might have to one
| day maintain or try to understand your Perl.
|
| I speak from some experience. Because I'm a 90s UNIX nerd, I
| quickly hacked up a a bunch of stuff in Perl maybe 6 years ago
| to solve some text processing tasks for a compliance audit. It
| worked well and got the job done within the time constraints. I
| actually got some kudos for getting our team out of a jam and
| doing grungy work people weren't keen to do. My teammates
| though, they lost no opportunity to dunk on the fact that it
| was done in Perl, and questioned my decision at every
| opportunity. I ended up rewriting the whole thing in Python for
| our next audit.
| JSR_FDED wrote:
| The opinion of coworkers is not a factor - but I have a
| friend who says that he has to relearn Perl every time he
| needs to use it. Do you have to use it every day to maintain
| fluency?
| spudlyo wrote:
| It doesn't take too long to get back into the swing of
| things. After a while, if you learn enough programming
| languages, they all tend to meld together in your brain,
| and the cost of switching isn't too disruptive. You know
| what you want to do, it's just the details that temporarily
| get in your way.
| hn_acc1 wrote:
| Yeah, as someone who occasionally had to hack on perl
| scripts - and I mean, maybe add/modify a hundred lines to
| add a new feature, then nothing for a few months, I found
| this too. Stop doing it for a while, and I had to relearn
| it all over.
|
| I'd probably have an easier time getting back into REXX
| that I last used in 1992 or something..
| BeetleB wrote:
| > Maybe to use as a better Bash?
|
| If you know Python, just switch to xonsh (https://xon.sh/).
| I've been using it as my primary shell since 2018.
| shagie wrote:
| The question is "what do you want to use it for?"
|
| There are a few places where you might dig and find a perl
| script under the covers. Some that aren't replaceable with bash
| (and sed and awk).
|
| I suspect that my "diff these two java deployments and create a
| file by file update script to run on the remote machine" in
| perl is still running for doing incremental deployments... and
| if someone uncovers it its still something reasonable to
| understand.
|
| However, if I was tasked with that today... dunno. I'm not sure
| I'd reach for the same tools as I did then.
|
| > In devops is turtle all way down but at bottom is perl
| script.
|
| https://x.com/DEVOPS_BORAT/status/248770195580125185 (2013)
|
| > If you can not able use Perl for answer, you are ask wrong
| question.
|
| https://x.com/DEVOPS_BORAT/status/280900066682757120 (2012)
|
| ... and while I can't find the original - this might be your
| answer.
|
| > We have 3 strike rule for devops: 1 strike we are take away
| Perl. 2 strike we are take away bash. 3 strike we are give
| PowerShell.
|
| https://gist.github.com/textarcana/676ef78b2912d42dbf355a2f7...
| SanjayMehta wrote:
| Python.
| antfarm wrote:
| And PHP.
| mono442 wrote:
| I think it is due to the fact that Perl has some confusing bits
| like those variable prefixes ($@%), the lack of function
| arguments (I know that this has changed recently), not really
| great error handling, etc and so people started using languages
| which seemed easier to use like Python.
| throwway120385 wrote:
| The variable prefixes are just the tip of the iceberg. The real
| problem with those prefixes is that they, themselves, are
| context-dependent on attributes associated with the underlying
| data type at run time. So you can find yourself in a situation
| where the behavior of the syntax differs in ways that are
| difficult to control for during development.
| mono442 wrote:
| Yep, there're all sorts of things like this in Perl. Its
| semantics has always been confusing to me.
| zbentley wrote:
| Strongly agree. A language which has something like
| "wantarray" as a first-class feature is
| semantically...unique, at best, probably more like "flawed by
| design". All the oddness with typing and sigls descends from
| that.
|
| Same for autovivification. Insane feature. Useful for some
| problems but causes many more.
|
| Which is a shame, because perl5 semantics had some nice
| features too! But there's only so much you can do with a
| structure whose foundation is so wacky.
| zahlman wrote:
| I remember trying to use the new "reference" feature (when
| it was new), with "blessing" and so on and so forth, to try
| to create real data structures, and finding in some way or
| another that it was just not _regular_. I can 't recall the
| details, but something along the lines of a feeling that
| the syntax worked differently for, say, the top level of a
| tree (or first index of a multidimensional array, etc.) vs
| the rest of the structure.
| darrenf wrote:
| In the main, the sigil refers to the type of the eventual
| value, regardless of what contains it. The tl;dr is that
| you mostly use `$` unless you're wanting more than one
| value, or to dereference (when you use the sigil for the
| type of reference). Some examples:
| @array = ("a", "b", "c", "d"); # @array contains scalars
| $array[0]; # use `$` for a single
| element @array[0..2]; # use `@`
| for an array slice @array = ( [1..5], [6..10] );
| # @array now contains array references $array[0];
| # use `$` still because references are scalars
| $array[0][1]; # still use `$` even when
| going multidimensional @{ $array[0] };
| # use `@` to dereference an array ref to array
| %hash = ( a => "b", c => "d"); # % for hash of key/value
| pairs $hash{a}; # `$`
| because you're getting a single scalar
| @hash{"a","c"}; # `@` because you're
| getting an array of values
|
| Where things become a bit less regular is the difference
| between reference and non-reference for hashes and arrays
| when they are top level. At the top level, you need a
| `->` but that becomes optional at levels below (because
| at levels below, they _have to be_ references).
| $arrayref = [1,1,2,3,5]; # `$` because we're
| creating an array reference $arrayref->[0];
| # `->` because top level $arrayref = [ [ 1 ], [ 2
| ] ]; # arrayref of arrayrefs $arrayref->[0][0];
| # no second `->` $arrayref->[0]->[0]; #
| ... but you can use it if you want!
|
| And then there's stuff like getting a slice out of an
| arrayref $arrayref = [1,1,2,3,5];
| $arrayref->@[0..3]; # oh dear. get a real array with an
| `@` but not at the start!
|
| So... yeah.
| zahlman wrote:
| > Where things become a bit less regular is the
| difference between reference and non-reference for hashes
| and arrays when they are top level. At the top level, you
| need a `->` but that becomes optional at levels below
|
| Yes, that's probably what I was remembering. Thanks for
| the exposition.
| karel-3d wrote:
| You unlocked hidden memories within me.
|
| I never understood why Perl has all these crazy features.
| It feels like someone going "hah it would be funny if it
| worked like this..." but actually really implementing it.
|
| People always said "it's because Larry Wall is a linguist!"
| as if it explains anything!
|
| You always go from "this is neat" to "...but why" quickly
| with perl.
| tasty_freeze wrote:
| > the lack of function arguments (I know that this has changed
| recently)
|
| Real arguments were added as of perl 5.20, which was in 2014.
| layer8 wrote:
| That's "recently", relative to Perl's heyday.
| zahlman wrote:
| Yes, that's almost as old as some currently-hyped programming
| languages. But it's quite new compared to the natural
| behaviour of some developers (a fact that I used to find
| surprising and now just find disappointing).
|
| Comparably: today, in the Python world, people are praising
| tools like uv because now they "don't have to understand
| virtual environments". And continuously since the
| introduction of PEP 668 three years ago, people have been
| grumbling about the expectation to leave "externally managed
| environments" alone. But uv still _uses_ virtual
| environments; and `venv` has been in the standard library
| since 2012, and the third-party `virtualenv` that it 's based
| on has been available since 2007.
| poke646 wrote:
| As an experimental feature, with no guarantees it would
| remain in the language. It wasn't marked a stable feature
| until v5.36 (2022).
| mkehrt wrote:
| Sure, but perl was already dying by like 2005.
| 12_throw_away wrote:
| Yep. Perl the first language I ever used to professionally do
| something approximating "real programming" (as opposed to one-
| off scripting). And then I learned Python and never touched
| Perl again ... at least at the time, to my very inexperienced
| self, it felt like an improvement on every single axis.
|
| In retrospect, probably 90% of my enthusiasm for python over
| perl was just "if you use python, you never have to think about
| variable sigils ever again." That and `string.split()`.
| HeinzStuckeIt wrote:
| Already in the very early millennium, jokes like "Perl is an
| explosion in an ASCII factory" were going around the computer-
| nerd community, while several publishers were putting out
| affordable and fun and engaging books to learn Python. No
| surprise that Perl quickly declined in popularity for scripting.
| It has been amusing to watch the continual waves of reawakened
| interest in awk, while Perl seems to remain perennially
| marginalized now.
| RodgerTheGreat wrote:
| The value proposition for AWK is very different from Perl. AWK
| is a _tiny_ language that can be learned quickly, and it 's
| ubiquitous: a hard requirement for even the most bare-bones
| POSIX environment. AWK is on your machine already; Perl may not
| be. If you have to install Perl, you could just as easily
| install any one of hundreds of alternative scripting languages.
|
| AWK scripts don't have any kind of dependency management
| features, so they naturally lend themselves toward being
| freestanding and self-contained. Perl, on the other hand, has a
| massive package ecosystem with transitive dependencies and
| widely varied quality and design aesthetic, amplified by the
| baroque design of the language. AWK is as close as a language
| can be to immune to dependency hell.
|
| When Perl was new, perhaps many people saw it as "a better
| AWK", but I suspect most of the newcomers to AWK today don't
| see it in relation to Perl _at all_.
| gwbas1c wrote:
| For me, Awk is this awesome tool for quick and dirty 1-3 line
| scripts to transform textual information. I hardly use it,
| but when I do, it serves its purpose well. It's also
| relatively easy to read and understand.
|
| I remember learning most of Awk from a long, single web page
| that appeared to come from one of the official authors.
| bluedino wrote:
| Nobody we've hired in the last 10 years wants to touch anything
| Perl.
|
| That said, we re-wrote all of our monitoring scripts in....Bash.
|
| Ugh.
| woof wrote:
| It was never about Perl, it was the plethora of alternatives.
|
| Python evolved, PHP had 1000 times more "how to get started"
| articles, Node happened. And LAMP became the default for noobs.
| stickfigure wrote:
| Perl is powerful, expressive, and cryptic. Its popularity faded
| during a time when the popular trend of programming languages was
| towards simplicity and legibility. C++ gave way to Java and C#.
|
| Also, Perl's strength was text processing in a world where data
| was moving out of simple columnar text formats and into
| databases, xml, json, and other formats better represented by
| object models than lines of text.
| autarch wrote:
| As a very long-time Perl developer and FOSS contributor, I think
| this blog post is incorrect about whether Perl 6/Raku was a
| factor in Perl's decline. I think Perl 6/Raku did a few things
| that hurt Perl 5:
|
| 1. It pulled away folks who would otherwise have spent time
| improving Perl 5 (either the core or via modules).
|
| 2. It discouraged significant changes to the Perl 5 language,
| since many people figured that it wasn't worth it with Perl 6
| just around the corner.
|
| 3. It confused CTO/VP Eng types, some of whom thought that they
| shouldn't invest in Perl 5, since Perl 6 was coming soon. I've
| heard multiple people in the Perl community discuss hearing this
| directly from execs.
|
| Of course, hindsight is 20/20 and all that.
|
| Also, even if Perl 6 had never happened the way it did and
| instead we'd just had smaller evolutions of the language in major
| versions, I think usage would still have shrunk over time.
|
| A lot of people just dislike Perl's weird syntax and behavior.
| Many of those people were in a position to teach undergrads, and
| they chose to use Python and Java.
|
| And other languages have improved a lot or been created in the
| past 20+ years. Java has gotten way better, as has Python.
| JavaScript went from "terribly browser-only language" to "much
| less terrible run anywhere language" with a huge ecosystem. And
| Go came along and provided an aggressively mediocre but very
| usable strongly typed language with super-fast builds and easy
| deploys.
|
| Edit: Also PHP was a huge factor in displacing Perl for the quick
| and dirty web app on hosted services. It was super easy to deploy
| and ran way faster than Perl without mod_perl. Using mod_perl
| generally wasn't possible on shared hosting, which was very
| common back in the days before everyone got their own VM.
|
| All of those things would still have eaten some of Perl's lunch.
| runjake wrote:
| I was a Perl programmer from the early 1990s until into the
| 2000s and I mostly agree with you. It was a variety of factors.
|
| The point where I disagree is I think Perl 6/Raku played a
| significant role in Perl's decline. It really gave me the
| perception that they were rudderless and that Perl probably had
| no future.
|
| Other than that, I absolutely loved Perl. I love the language.
| It's super expressive. I never took a liking to CPAN. And I
| wonder if it could make a comeback given better dependency
| management.
|
| I think Perl with tooling similar to uv would cause me to
| switch back today.
| autarch wrote:
| > The point where I disagree is I think Perl 6/Raku played a
| significant role in Perl's decline. It really gave me the
| perception that they were rudderless and that Perl probably
| had no future.
|
| I assume you disagree with the blog post, not with my
| comment, since this is exactly what my comment says too!
| cestith wrote:
| Have you tried cpanm?
| Taikonerd wrote:
| I would also say -- in the late 90s, Perl's claim to fame was
| that _it had CPAN_. At the time, CPAN was revolutionary: a big,
| centralized repo of open-source libraries, which you could
| install with a single command.
|
| Now, of course, that's a common and maybe even expected thing
| for a library to have: Python has Pypi, Javascript has NPM,
| etc.
| roryirvine wrote:
| And the whole culture around CPAN, too, with the likes of
| Module::Build and Test::Harness and the strong expectations
| around POD documents. Nothing like that existed for the other
| scripting languages of the time.
|
| There was a well-trodden path from writing a hacky one-off
| script to deal with a specific task, to realising "hey! this
| might be useful for others too!" and trying to make it a bit
| more generic, to checking in with your local Perl Mongers for
| advice, to turning it into a well-tested, well-documented
| CPAN module.
|
| That was the route I followed as an early-career sysadmin in
| the dying days of the dotcom boom - it helped me take on much
| more of an "engineering" mindset, and was an important
| foundation for my later career.
|
| I can't have written more than a few dozen lines of Perl in
| the last 15 years, but do I owe that community and culture a
| lot.
| fithisux wrote:
| Tcl/Tk is still behind,
| hylaride wrote:
| I think this is mostly the correct take. Perl's strength is
| that it was really good and quick and dirty one-offs,
| especially with text manipulation. This made it particularly
| popular with UNIX sysadmins and sometimes network admins. This
| was helped by the fact that CPAN made it easy to share a lot of
| these, which added to its popularity (it can't be overstated
| how revolutionary CPAN was).
|
| The 1980s/1990s was full of many different data formats in a
| time before XML/JSON, often by long dead companies. Many a tech
| person was in a situation where "Oh fuck, how do I get this
| data out of some obscure database from some dead company from
| Boston that only ran on SCO UNIX into SAP/Oracle/etc" only to
| see somebody else already done it and made a CPAN module.
|
| But stories like that became less common as DBs converged into
| a few players.
| worik wrote:
| > quick and dirty one-offs,
|
| Then used for huge GUI apps that run slow like a wet week,
| unreliably
|
| The same thing is happening with Python.
| sleepybrett wrote:
| Yeah i'll say, even to this day, when I need a quick script
| and bash just isn't doing it for me I'll just write it in the
| same perl I used regularly as far back as 1998... but it
| never goes further than that. If I have to take that script
| and build it into anything that will ever leave my laptop
| it's going to get rewritten in something else (probably
| golang since it is universal on my team).
| ajross wrote:
| You mention it last, but I think PHP was most of it. PHP was
| the first and best-integrated technology for this world, which
| was huge and impactful. The "center of thought" in the text
| processing problem area moved hard to web development. And so
| the ideas about what needs to be improved or changed rapidly
| centered themselves around "Things PHP Did Badly". And that
| begat Ruby and Node, not a fixed-up Perl.
|
| Perl remained (and remains!) eminently useful in its original
| domain of Unix system automation glue and ad-hoc text analysis.
| But it was denied a path to the future by PHP, and by the time
| PHP was itself replaced it was too late.
|
| Finally everyone else (python in particular) sorta caught up to
| the "clever systems glue" feature set, and the world moved on
| entirely. Perl is mostly forgotten now except by those of us
| who lived it.
| ramses0 wrote:
| Great point! Confluence of simultaneous factors.
|
| PERL tripped over it's own feet (too clever, line-noise,
| unmaintainable).
|
| Java(TM) being "guaranteed to be business-like" sucked the
| serious use cases away.
|
| PHP was easier to grok, had "editable man pages" (ie: comment
| forum attached to each built-in), and didn't have "slow CGI
| overhead" or "FastCGI complexity".
|
| Python was waaaay easier to read/write/maintain, and was a
| serious alternative (except for trickier process-control
| integration, you couldn't just "$XYZ = `ls -al`" like you
| could in perl).
|
| ...and then "PERL6 will be gloriously filled with rainbows,
| butterflies, will be backwards incompatible, and will be
| released Any Day Now(tm)" sucked alll the oxygen out of a
| developer investing in perl.
|
| By the time nodejs became another contender for server-side
| languages, there was no place for PERL as it's effectively
| become kindof a COBOL for unix systems. Don't touch it if you
| can avoid it, and it requires expensive, difficult-to-find
| specialists to maintain it if you need to.
| pantalaimon wrote:
| PHP was jokingly expanded to 'People hate Perl' back in the
| day
| dspillett wrote:
| _> A lot of people just dislike Perl 's weird syntax and
| behavior._
|
| As much as I liked Perl back in the day, it did sometimes earn
| its reputation as a write-only language!
| danudey wrote:
| Not to mention that trying to understand existing Perl by
| asking the community 'what does this do' or 'how does this
| work' often (in my experience) resulted in 'RTFM' or 'man
| perldoc' rather than someone taking any time to actually
| answer the question, whereas other communities were more
| welcoming and helpful to each other. That made it difficult
| to learn Perl through other people's code compared to other
| languages.
| wredcoll wrote:
| I had the complete opposite experience. Perlmonks and irc
| were amazing resources for a budding developer.
| sleepybrett wrote:
| agreed
| dspillett wrote:
| I think that depended on where you were looking and how you
| were asking.
|
| My main source of support back when I did much Perl (late
| 90s, early 00s) was usenet, and while some groups were very
| snubby and elitist others were very helpful and encouraging
| for a young budding programmer.
| Tubelord wrote:
| My impression was experienced Perl programmers took pride in
| making the smallest code possible, all in one line.
|
| At my company they really locked in the project being dead if
| the original contributors left.
|
| Perl propped up regex (JavaScript regex is based off of it),
| so I get the impression Perl practitioners tried to make all
| the code regex-y as possible as a cultural thing.
| sleepybrett wrote:
| There was a regular feature in the perl community for
| 'golf' or 'crazy one liners' but almost no one used that
| shit in any actual code that left their user directory.
| brightball wrote:
| All good points. There was a solid talk on modern web dev with
| Perl at the Carolina Code Conference last year.
|
| Created some interest in several people who talked to me about
| experimenting with it for a while afterwards.
|
| https://youtu.be/ommhbiRx-vI?si=qwkdU1Wo7uVBVse9
| cogman10 wrote:
| > Also, even if Perl 6 had never happened the way it did and
| instead we'd just had smaller evolutions of the language in
| major versions, I think usage would still have shrunk over
| time.
|
| Maybe. I mean the whole point of 6 was to modernize perl.
|
| Perl needed efforts like 6 to happen, but it needed them
| delivered in smaller chunks over the years rather than as a big
| decade long "And now 6 is here".
|
| Java learned this lesson after Java 8 and 9 which took multi-
| year effort to deliver 1 or 2 big changes to the language and
| the JVM. Now Java has multiple efforts in flight which have
| trickled in over the years (tickling me as a dev). Every 6
| month release is a little better which makes the multi-year
| efforts seem all that much more worth it when they land.
| Joker_vD wrote:
| > And Go came along and provided an aggressively mediocre but
| very usable
|
| See, that's one of the things lots of people who enjoy Perl
| and/or Ruby in the comments around in this thread don't quite
| grasp: some languages require programmers possessing a somewhat
| special state of mind to read and write productively, and some
| languages allow pretty much every mediocre programmer to read
| and write, and still produce a manageable program.
|
| The other thing is the information density. In my experience,
| most people after graduating high school have experience with
| reading mainstream fiction and school textbooks, and those
| things you can half-skim/half-read and still get out most of
| the meaning. Then those people hit the college-/university-
| level textbooks and screech and crash because those books, you
| have to read them sentence by sentence; not everyone can get
| get used to it (or even realize they have to do that in the
| first place). And similar observations hold for programming
| languages: Perl and APL are just way too dense compared to Go
| and Python; if you're used to reading code line-by-line
| (skimming over half of them), then it's really bloody annoying
| to switch to reading sigil-by-sigil (as for writing, well, we
| all know that typing speed was never really a bottleneck for
| programmers).
| DonHopkins wrote:
| >It confused CTO/VP Eng types
|
| I wouldn't call making the right decision confused. It
| clarified and justified their desire not to use Perl. Only a
| confused CTO/VP Eng type would choose to use Perl in spite of
| all its entrenched disadvantages and much better more popular
| alternatives.
| autarch wrote:
| I was just saying that they were confused about what was
| going on with Perl because if the Perl 6 effort. I don't
| think that they were confused or wrong in their decision
| making.
| huherto wrote:
| True. Adding to these. Perl6/Raku suffered from the second
| system effect. Described in the Mythical Man Month. Larry and
| company were over confident with their previous success.
| unop wrote:
| I spent 10 years in perl and created a lot in it - it taught me a
| lot about code as a culture,importance of tests, TIMTOWTDI, etc.
| I think I owe a lot to it.
|
| I found myself defending it more and more online against the
| folks who were nay sayers - those who complained about its syntax
| and it's quirks - but that wasn't a problem for unixers who used
| sed/awk/vim and all the other arcane tools. Perl wawa means to
| and end and it was the best tool to reach for (the glorious Swiss
| army knife).
|
| I guess there was an infection period - the brain drain to python
| and Ruby meant it was harder to find decent quality libs on CPAN
| anymore as folks would only do things in python. And Yea, while
| CPAN is still rich, it's not the first hit on Google anymore.
|
| Today, the map-sort-map Schwarzian transform is still the easiest
| to do in perl than any other language and it helps me whip up the
| throwaway scripts quick. Wouldn't change the language - I really
| love it!
| 7thaccount wrote:
| Instead of a Swiss army knife, I always heard it referred to as
| a "swiss army chainsaw" lol.
| waynecochran wrote:
| Been using Perl since the beginning... essentially every time I
| needed to write a shell script more than 10 lines long I used
| Perl ... eventually was also using it for web back end stuff too
| ... kind of like duct tape. I still use it today if I need to
| write more than 10 lines of a bash script.
| reddit_clone wrote:
| Same here. I use Raku instead.
| HelloNurse wrote:
| Personally, back when Perl 6 was harmless vaporware, I never
| found a place for Perl 5.
|
| For moderately advanced text processing with regular expressions,
| supposedly its strong point, it was far less elegant and concise
| than AWK at the low end and far less readable and less batteries-
| included than Python for more complex tasks involving some
| integration.
|
| For dynamic web pages, another of the main uses of Perl, PHP was
| purposefully designed and (while not really good) practical and
| user-friendly, with plenty of other obviously more robust and
| serious options (Ruby, Java, later Python, etc.) for more
| enterprise projects.
| runjake wrote:
| It sounds like Perl just wasn't your style and that's okay.
|
| But, Perl was _immensely_ popular, particularly in the 1990s in
| its 4.x /5.x days. We used it because it was precisely more
| elegant, ergonomic and performant than awk :-)
|
| Later on, Python gained more traction because it was more
| batteries-included, and PHP evolved from being a toy named
| "Personal Home Page".
| HelloNurse wrote:
| Perl was immensely popular, but it isn't necessarily enough
| to qualify for the personal "bubble" of languages one learns.
| It was a good choice of proven, general purpose interpreted
| scripting language for _you_ in a time when Perl competed
| with AWK and shell scripts, but in the 1990s I used mainly C
| and C++ before adopting Java quite early and almost
| exclusively; when I later decided to learn some proven,
| general purpose interpreted scripting language Python was
| _my_ obvious choice: more advanced than Perl 5 and more
| popular than Ruby.
| pizlonator wrote:
| Python and Ruby killed Perl.
|
| Before Perl, there was no scripting language that could do
| systems tasks except maybe shell and tcl, but that's shell is an
| extremely unpleasant programming experience and the performance
| is horrid, and tcl's string-based nature is just too weird.
|
| Perl gives you something more like a real programming language
| and can do shell-like tasks and systems tasks very nicely.
| Compared to what came before, it is amazing.
|
| But then Ruby and Python came along and checked the "real
| programming language" box even more firmly than Perl while
| retaining the shell/systems angle. Ruby and Python were better
| than Perl along exactly the same axis as the one on which Perl
| was better than Tcl and shell.
| daneel_w wrote:
| _> "Perl gives you something more like a real programming
| language ..."_
|
| It is a real general-purpose programming language, not a
| "scripting" language. Did you ever have a look at it?
| Kye wrote:
| Good luck getting any two people to agree on a sharp line
| between programming language and scripting language. Perl
| seems to swap sides depending on the year people are arguing
| about it.
| daneel_w wrote:
| In my experience those can't discern what's what are
| usually the ones who mainly did a bit of dabbling in
| either.
| spankalee wrote:
| Assuming you've done more than dabbling, what's
| specifically the difference to you then?
| spankalee wrote:
| That's a difference without a distinction
| pizlonator wrote:
| I've shipped Perl code so yeah, I have
| pengaru wrote:
| For many people especially old timer sysadmins, anything
| interpreted at runtime is a script.
|
| TBH, prior to perl6, perl was such a horrid inconsistent
| mess, it reeked of shell.
| rs186 wrote:
| BASIC and Pascal are real general-purpose programming
| languages as well, but I don't know anyone who uses them for
| anything serious.
| bitwize wrote:
| Entire enterprises ran/still run on Business BASIC and
| Delphi code. Billion-dollar fortunes have been made on such
| code. Those languages are used for serious things all the
| time.
| rs186 wrote:
| * for new code
| ianburrell wrote:
| In previous life, worked on large object-oriented Perl. There
| was a difference between good Perl and the Perl in messy
| scripts. Good Perl was nice to work in but required
| discipline to keep organized.
|
| I wonder if there was an earlier point of Perl's demise. Perl
| 5 came out with flexible object-oriented features, but it
| took years for packages like Moose to come out and make it
| nice and usable.
| SmirkingRevenge wrote:
| I always thought one of the best and worst things about
| Perl was the fact that you could build something like Moose
| with it.
|
| But the bad side was that by the time someone was clever
| enough to invent Moose, all sorts of other bespoke object
| systems had been invented and used in the meantime, and
| your CPAN dependencies used every single one of them.
| le-mark wrote:
| > and tcl's string-based nature is just too weird.
|
| TCL had the ability dynamically load and call into .so's which
| was really powerful. Those who knew, knew.
| pizlonator wrote:
| Yeah tcl is awesome.
|
| It's both awesome and weird.
|
| Some people use it effectively to this day. Most either have
| no idea about it, or know about it but can't get into the
| mindset (like me).
| fithisux wrote:
| Common Lisp for the masses
| citrin_ru wrote:
| IMHO Python killed both Perl and Ruby. While Ruby is more alive
| than Perl it's nowhere near as popular as Python.
|
| I like Perl and used it professionally for year and vaguely
| remember probably around 2010x relatively massive Python
| evangelism (lots of articles, conferences, lots of messages
| from Python adepts on forums e.t.c). One of talking points (no
| longer needed nowadays) was that Python is backed (sponsored)
| by Google so Python will be successful and you should not worry
| about it's future and also if you will choose Python you will
| be successful (as Google is).
| lizknope wrote:
| I still use Perl everyday. I know it isn't as popular as when I
| learned it in the 1990's but I process so many text logs that I
| find it very useful.
| reddit_clone wrote:
| I use Raku on a regular basis. I think it is the best language
| to write DevOps (for lack of a better term) scripts.
|
| Perfect for people who find Bash too sharp and fragile and
| Python too tedious.
| paulv wrote:
| I was a happy perl user for a long time, probably until sometime
| in the early 2010s. I am a sysadmin and perl was a great tool for
| what I needed to do.
|
| Jim Weirich was a heavy perl user for a long time, and we were
| both involved in the Cincinnati perl mongers group. He found ruby
| and fell in love. He thought Ruby would be a good fit for me and
| we had a long conversation about why he preferred it to perl. It
| took me a few years, but I eventually took his advice. As usual,
| Jim was right, and I haven't written any perl since then.
|
| tl;dr: for me, ruby killed perl.
| xnx wrote:
| Perl died because more shared web hosting installs supported PHP
| than Perl.
| the_biot wrote:
| Even before the Perl 6 insanity dropped, there was a serious
| underlying problem in the Perl ecosystem: CPAN. There was this
| module (I don't remember its name, or author) that was pretty
| important: you'd end up using it if you were serious about Perl.
|
| One day, around 2000 or so, the author/maintainer, a well-known
| guy in the Perl community, updated the package with an
| incompatible API. If you used that package, you had to update
| your code. There was no backward compatibility, nothing. To make
| things worse, the README stated that it would AGAIN change API in
| the future, but he didn't know yet what the change would be.
|
| I considered this disastrous maintainer behavior, as I'm sure
| anyone reasonable would. It was clear I had to stop using this
| package, and anything else this guy could get his claws on. But
| there really wasn't a massive outcry that I could see, nobody
| calling him out for this crap.
|
| That's when I knew I had to stop writing code in Perl. I tried
| Ruby but found it unstable at that time. Next project I used
| Python, and never looked back.
| satisfice wrote:
| After twenty years of Perl, I switched to Python because I was
| encountering too many useful frameworks and systems that had no
| corresponding Perl packages. The last straw was when I wanted to
| use Mongo and found that the Perl package was unsupported.
| juancn wrote:
| I haven't written perl in a long time but I cannot put a finger
| on why I stopped using it.
|
| It used to be my goto language for quick and dirty scripts that
| needed somewhat non-trivial text processing.
|
| Anyway, this made me think of the 2008 Damian Connway Perlcon
| keynote: "Temporally Quaquaversal Virtual
| Nanomachine Programming in Multiple Topologically Connected
| Quantum-Relativistic Parallel Timespaces... Made Easy"
|
| If you've never seen it it's worth a watch:
| https://www.youtube.com/watch?v=HzTjPx4NIiM
| giantrobot wrote:
| In all seriousness mod_php killed Perl, or at least struck the
| fatal blow. In the late 90s I wanted to make dynamic web content,
| just simple CRUD stuff. The most reliable way to do this was
| Perl. As long as your hash bang and permissions were correct you
| could drop a script in a cgi-bin directory and it would work. It
| didn't matter if the server was Solaris, Linux, or some other
| Unix. Most hosts that supported Perl also at least had the CGI
| module installed as well.
|
| It was worth fighting with Perl's syntax because it was the best
| option for web programming (for random amateurs like myself). Web
| hosts often didn't have C compilers available so C wasn't an
| option. TCL was workable but not as prevalent as Perl on web
| hosts. Same with PHP3. Keep in mind this was an era where you
| were deploying on machines you didn't on which you didn't have
| admin access. Most of the time you didn't have shell access on
| machines you'd deploy on.
|
| As Linux adoption on servers exploded so did the deployment of
| PHP. It was easy to deploy PHP web apps since they could be
| readily dropped in your htdocs or public_html directory and be
| handled by the server. Enabling other CGI outside cgi-bin
| directories was uncommon.
|
| So by 2000 or so there was no reason to learn Perl to do web
| stuff easily. You could do it in PHP which was already a
| templating language. The younger version of me that wanted to do
| web CRUD stuff bought a PHP book instead of a Perl book. With
| Python 2's release at that same time if you wanted to do portable
| non-web stuff you had a much nicer language than Perl available
| as well.
| ojosilva wrote:
| Perl was the internet in 1990s. People (me) who were doing unix
| systems work (C, shell, Perl and some DBs and FTPs) could now
| quickly throw a CGI script behind an Apache HTTP server, which
| tended to be up and running in many unixes :80 port back then
| (Digi, HP, Sun, etc). Suddenly I had a working app that would
| generate reports directly to people's browsers or full-blown apps
| on the internet! But Perl CGI did not scale at all (spawn 1
| short-lived process per request will choke a unix fast), and even
| after mod_perl [1], that got quickly superseded by PHP, which was
| really built for the web (of the 1990s). Web frameworks and
| fastcgi arrived too late to Perl, so internet Perl was
| practically dead at the turn of the century.
|
| The enterprise, who either did not have any webapps or had tried
| Perl CGI first and suffered it dearly, got pinged by their sales
| reps that Java and .NET (depending if you were a IBM, Sun or MS
| shop) were the way to go, and there they went with their patterns
| and anti-patterns for "scalable" million-dollar web stacks. That
| kicked-off the age of the famed application servers that resist
| up until today (Websphere, Weblogic, etc).
|
| So Perl went back to being a glue language for stitching up data,
| C/C++ and shell, and that's how the 2000s went by. But by then,
| Ruby and Python had more sane communities and Ruby was exciting
| and Python was simpler - Perl folks were just too peculiar, funny
| and nerdy to be taken seriously by a slick new generation that
| coded fast and had startup aspirations of the "only $1B is cool"
| types. Also the Perl6 delusion was too distracting to make anyone
| event care about giving Perl5 some good love (the real perl
| keeping servers running worldwide), so by the 2010s Perl was
| shooting down to collective ostracism, even though it still runs
| extremely well, fast and reliably in production. By the 2020s the
| release cycles were improved after Perl6 became a truly separate
| project (Raku, renamed in 2019), the core has gone through a
| relative cleanup and finally got a few popular features in demand
| [3]. The stack and ecosystem is holding up fine, although CPAN
| probably needs some good tidying up.
|
| The main issue with Perl at this point is that it has not been a
| target for any new stuff that comes out: any cool module,
| library, database, etc that is launched does not put out a Perl
| api or a simple example of any kind, so it's up to the Perl
| community to release and maintain apis and integrations to the
| popular stacks on its own, which is a losing game and ends up
| being the nail-in-the-coffin. By the way, nothing (OSS) that
| comes out today is even written in Perl. That reduces even
| further the appeal of learning Perl.
|
| Strangely enough, lately Perl has seen a sudden rise in the TIOBE
| index [4] back into a quite respectable 9th position. TIOBE ranks
| search queries for X language and is not much of a indicator,
| being quite noisy and unreliable. My guess is that those queries
| are issued by AI agents/chats desperately scraping information so
| that it can answer questions and help humans code in a language
| that is not well-represented in the training datasets.
|
| [1] mod_perl was released in 1996, and became popular around
| 1999: https://perl.apache.org/about/history.html
|
| [2] PHP was released 1994, took off ~1998 with PHP3:
| https://www.php.net/manual/en/history.php.php
|
| [3] Perl's version changes simplified:
| https://en.wikipedia.org/wiki/Perl_5_version_history
|
| [4] https://www.tiobe.com/tiobe-index/
| leejo wrote:
| I may blog about this next year, again[^1], as I'm working on a
| project that sort of covers it - not in a way that will answer
| the question but more observational.
|
| Anyway, I feel Perl's popularity was hugely exaggerated in the
| mid to late 90s and early 00s. The alternatives were either not
| there in terms of language and toolchain features, ease of use,
| "whipuptitude" or whatever, or library support (CPAN was a killer
| app), or they were too old school or enterprisey. Sysadmins were
| using it everywhere so it got into all sorts of systems that
| other languages couldn't without much more faff.
|
| Its back compatibility meant it stayed in those places for a long
| time. It's still in a lot of those places.
|
| The fall in popularity the last decade or two was more of a
| regression to the mean, or perhaps below the mean. Many other
| languages have come along, which have contributed even more to
| the fall in share.
|
| Yes, yes, Raku (ne Perl 6) but I'd argue that also contributed to
| a lot of really good stuff on CPAN. The Perl 5 core did get
| neglected for a number of years, as @autarch says, which may have
| been a factor.
|
| [^1] previously:
| https://leejo.github.io/2017/12/17/tpc_and_the_end_of_langua...
| orev wrote:
| 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 wrote:
| What we can learn is: evolution is a better choice over
| revolution given that there's no extreme internal or external
| pressure.
| cogman10 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| foobarian wrote:
| Can you imagine if the PSF had been working on Python 4 in
| parallel, with more backwards compat shifts or even a
| radically modified syntax?
|
| 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".
| foofoo12 wrote:
| > I really don't think Python was close to dying
|
| 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.
| mixmastamyk wrote:
| I was not affected by Py3 at all. First I completely
| ignored it for five years while it gestated. Then started
| kicking the tires when 3.4 dropped on a LTS. When 3.6 with
| better dicts and f-strings landed I moved over with barely
| a whimper, since I'd had a decade to get things upgraded to
| 2.7 first.
|
| None of my projects needed to worry much about char
| encoding, and I'd used logging extensively starting under
| 2.6 or so.
| dist-epoch wrote:
| You're contradicting yourself - if Python had no popular
| alternative, what would have new people used instead and
| what would existing code have migrated to?
| nine_k wrote:
| Python 2.7 was kept very much alive, with a number of small
| improvements from the 3.x branch backported to it.
|
| 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.
| tptacek wrote:
| Long before the AI/data science breakout, we were noticing
| in our consulting practice (2016-2020) a sharp dropoff in
| Ruby at startups, and Python as the modal language (by the
| time I left in 2020, it would have gone Python -> Node ->
| Ruby).
|
| So no, I don't think AI saved Python; it was fine before
| then.
| smohare wrote:
| 2016 already puts one far into the AI explosion. The
| current hype cycle, with LLMs as a service at the
| forefront, arguably makes python less relevant than in it
| was in the mid 2010's. The current crop of "AI Engineers"
| can use whatever languages they want for the most part.
| In 2016 most practitioners were leveraging a lot more of
| the standard scientific computing frameworks afforded by
| python.
| tptacek wrote:
| Python was the lingua franca of data science by 2016, but
| AI and data science was clearly not the reason startups
| were building in Django and Flask --- the data science
| teams were always a morass of Jupyter notebooks and
| pickle blobs.
| MoonWalk wrote:
| I don't know. Isn't Python still viewed as a mess now? I
| was thinking of taking the time to learn it as the best way
| to write cross-platform utilities, but encountered a lot of
| negative sentiment about its ecosystem. And all the
| environment managers you seem to need for it are a turn-
| off.
|
| 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.
| kstrauser wrote:
| It's vastly improved now. With uv, many times you can
| download a new utility off GitHub and run it with `uv run
| foo.py`, including fetching its dependencies.
| skylurk wrote:
| > No popular alternative
|
| 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.
| foofoo12 wrote:
| Before JS had promises, JS code was plagued with the
| callback pyramid of doom. You needed an advanced masters
| degree in masochism to endure that. I don't think Python
| devs would have liked that.
| matthewmc3 wrote:
| You forgot perhaps the most important one:
|
| 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.
| masklinn wrote:
| Six was one component but not the only one. Python 2.7
| also backported a number of early Python 3 features,
| Python 2 features were reintroduced in basically every P3
| version until at least 3.5 (although after 3.3 they were
| pretty minor), and a _lot_ of extensive migration guides
| were written (my main bible was eevee 's).
|
| 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.
| saurik wrote:
| > Python 2 features were reintroduced in basically every
| P3 version until at least 3.5
|
| 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).
| culi wrote:
| IMO javascript was a valid alternative. Easy to learn and
| easy to run. That's the main things needed for academic
| work
|
| Python had a history of tooling/libraries that made it well
| ingrained into academia
| maleldil wrote:
| Javascript didn't have the same FFI story with C/Fortran
| as Python. That's what allowed libraries such as numpy,
| scipy, pandas, etc. to flourish.
| dist-epoch wrote:
| Python continued growing fast during the 2 to 3 transition,
| it was nowhere near dying. It was one reason it took so long,
| people were starting new Python 2 projects 5 years after
| Python 3 was released. Only around 2017/2018 the default for
| new projects kind of became Python 3.
| orev wrote:
| Python 2 was used for such a long time because many modules
| only worked on 2, which was a direct result of the
| compatibility being broken. There was a catch-22 for a long
| time that nobody would upgrade to 3 because nobody else
| would.
| raverbashing wrote:
| I agree
|
| 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
| sleepybrett wrote:
| The delta between python 2 and 3 was much smaller than the
| delta between perl 5 and 6. Perl 6 might as well be a totally
| different langue which is probably why they renamed it to
| Raku, to stop people thinking that it was the same language.
| kvemkon wrote:
| > Python 2 to 3 took a really long time
|
| 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
| true2octave wrote:
| I know companies with a big Python 2 stack that rather
| preferred to rewrite in typescript than migrate to Python 3
|
| I turned down one of those companies because I didn't want to
| deal with that migration in 2021
| LexiMax wrote:
| I will never forget Mercurial's postmortem on their
| experience with the Python 3 transition. They had very few
| kind words to say about the process.
|
| https://gregoryszorc.com/blog/2020/01/13/mercurial's-journe
| y...
|
| 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.
| notepad0x90 wrote:
| If Golang was around, it might have killed python then I
| think. To many, the 2->3 jump made little sense. I honestly
| wish they just started a new language instead.
|
| 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?
| jcranmer wrote:
| Python 2.7 was EOL'd at the start of 2020, and serious
| effort to move from 2 to 3 didn't start until around 2018,
| by which time Go was a very major player.
| cogman10 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bloomca wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| chuckadams wrote:
| That variable in particular gets covered in the Llama book
| as well. Anyone serious about learning perl in the 90's had
| at least one of the Camel or Llama books.
| worik wrote:
| Golly
|
| 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...."
| broken-kebab wrote:
| man perldoc
|
| is too curt, and therefore may feel hostile especially
| for native English-speakers who are used for polite
| communication to be more wordy. But cultural things aside
| it's actually a good working solution.
| chuckadams wrote:
| > f*^&%k off
|
| 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.
| debtta wrote:
| This is exactly the point.
|
| 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.
| creer wrote:
| You did not need to google anything. The complete
| documentation was right there, next to the interpreter,
| on your machine. Ready for scanning and reading from top
| to bottom; and broken in sections that were actually
| relevant; and ready to search in bulk if you prefered
| with whichever local search tool you cared for.
|
| No need for google.
| idop wrote:
| I disagree, at least when it comes to the web (of those
| days). What's the point of rewriting what's already well-
| and accurately-written in the docs? What better job are
| the people on that message board going to do with regards
| to such a small, specific syntax feature? The point of
| those "communities" wasn't to answer questions like "what
| is this variable?" but rather to have actual discussions
| on the language, such as how to structure applications,
| design patterns, projects, etc. Imagine trying to build
| an online community for this purpose, only to spend your
| days answering the most basic questions possible that
| were already explained many times before.
|
| 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.
| creer wrote:
| A professional medium might have been gate-kept being
| paying coursework. Perl was not: the super-complete
| documentation was right there, in the distribution; the
| remarkably intelligently written course book was right
| there on everyone's shelves and in your local public
| library; the in-depth books same thing; And quickly
| enough even free on the net; the expert-built module
| library was all there to use and study; the experts were
| giving their time freely, writing deep dive articles at
| the simple prompt of worthy questions in addition to
| columns on topics which I guess were not getting enough
| questions.
|
| 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.
| broken-kebab wrote:
| Let me respectfully disagree. man perldoc
|
| would tell one needs to use -v key to learn about a var.
| And consequently perldoc -v '$|'
|
| would tell everything one needs to know about $|
|
| So it was actually reasonable advice.
| bawolff wrote:
| RTFM might be reasonable advice, but its not "welcoming"
| advice.
| broken-kebab wrote:
| I agree in general (and already commented on this). But
| some people believe it's like giving fish instead of
| fishing rod. And I think it was prevalent idea in tech
| circles during 90s-00s that people who don't read that fm
| waste other participants time, and needlessly multiply
| forum topics or extend conversation history. Which was
| seen as uncivil behavior in those times.
| maxlybbert wrote:
| I remember being very enthusiastic about helping people
| on, say, Stack Overflow. It didn't take much extra effort
| to be nice and made me happy.
|
| 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.
| creer wrote:
| > getting the same question repeatedly may suggest
| something should be redesigned
|
| Yes. And 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 (ADHD, dyslexia,
| whatever) and the man page is useless), or went to google
| first and '$|++' failed (because google was raised on
| python).
|
| Better marketing of the documentation would have helped.
| cestith wrote:
| If they specified 'perldoc -v $|' instead of just 'man
| perldoc' I'd have been thankful for that as the entire
| response. It's literally a pointer to where the answer is
| and to how to use the canonical tool to find it.
| kstrauser wrote:
| Yep, especially when so many instances of TFM were awful.
| Perl's docs were fantastic, or so at least I thought at
| the time, but they were the first large open source
| project docs I devoured. I can imagine someone coming
| from another language not even considering just looking
| at the man page because they were used to awful
| documentation.
| sltkr wrote:
| Fair enough, but I think the first part of the advice
| would be a lot more helpful if it included the second
| part too. It's the intermediate step that turns people
| off: why do I need to learn about `perldoc` when I asked
| about `$|`? (And that's assuming the question asker is
| familiar with man-pages to begin with, otherwise, you
| need to read `man man` first!) It feels like you're
| sending them off on a wild goose chase, even if that's
| not your intent.
|
| 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.
| knowitnone3 wrote:
| so they should have written that. Next you're going to
| tell me man man is reasonable advice
| chabska wrote:
| How would I know that $| is a var? It could be an
| operator, or a function, or a directive.
| throwaway173738 wrote:
| This comment kind of epitomizes the way the Perl community
| works, to be honest.
| gosub100 wrote:
| The problem is with man pages themselves. You shouldn't
| have to read 100% of something to find 0.1% of something.
| In fact, this concept is covered extensively in CS theory
| about sorting. Reading a manpage is less efficient than
| asking someone who already knows.
| thyristan wrote:
| Only locally, only for you, and only short term. You are
| wasting the time of the person you are asking, and you
| are learning absolutely nothing about the context of the
| answer. When the next question arises, you won't even
| know where to look, you will only continue wasting other
| peoples' time.
| broken-kebab wrote:
| There are some manpages which are too long, and
| cumbersome but it's not a widespread problem I believe.
| In particular man perldoc is laconic and on point.
|
| 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
| jwillp wrote:
| The trick is to already know how to use regexes to make
| searching the manpages easier! But you really have to
| nail down the rules for escaping when you want to search
| for perl's gnarliest sigil magic.
| creer wrote:
| The man pages were broken into competent sections over
| multiple man pages. About 260 of them on this machine
| (not really: there is a change-tracking man page per
| release recently.) The 1st man page is an very compact
| index to them.
|
| 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?"
| broken-kebab wrote:
| Sorry for the bad experience you had, I believe it's always
| better to be kind to strangers on those global nets. But TBH
| perldoc would really work very well for you.
| rcakebread wrote:
| > the only answer I got was 'man perldoc'
|
| 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.
| DonHopkins wrote:
| This is so spot on. You can't google line noise, and that
| mattered before LLMs. And everything else you said.
| creer wrote:
| Perl was not and still is not suitable for people who refuse
| to read the manual or tutorial.
|
| 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.
| chemotaxis wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| wk_end wrote:
| 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 wrote:
| 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 wrote:
| 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
| makr17 wrote:
| > 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 wrote:
| > _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.
| michaelcampbell wrote:
| > 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 wrote:
| 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.
| antonvs wrote:
| > 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.
| psim1 wrote:
| Around 2010 I ditched Perl for PHP because I had been using PHP
| for web and could write the same systems scripts in PHP as I used
| to write in Perl. Sticking with one go-to language is easier on
| the brain.
| nprateem wrote:
| It was too simple.
|
| (map { $~ =~ s/.*/$&/r } split /\s/, $^W x $/ ) ~~ tr/a-z/x/r x
| $!
| steveklabnik wrote:
| I have two programming language tattoos: A Perl camel, and a Ruby
| ruby.
|
| For me, that's the answer to this question: Ruby had all the
| stuff I liked from Perl, and didn't have the stuff I didn't like.
| It's just that simple.
| chuckadams wrote:
| What put perl out to pasture for me was lack of static types, nor
| any capability of adopting them. We were told to wait for Perl 6
| for that, and well, we saw how that went. I'm told that disabling
| indirect object syntax gives Perl a fighting chance at static
| analysis, but that in the end it's still the case that only Perl
| can parse Perl.
| cidd wrote:
| This reminds me of the april fools email from Richard Stallman to
| rewrite Emacs with Perl
| https://www.gnu.org/fun/jokes/gnuemacs.en.html
| bane wrote:
| Perl "died" through a 1,2,3 knockout of
|
| 1. failing to have a coherent path to Perl 6
|
| 2. Ruby (on Rails) taking over the workhorse task of serving up
| dynamic content that Perl had owned before then
|
| 3. Python completely dominating the utilitarian
| scripting/programming world in nearly every niche
|
| Why did this happen? I was a work-a-day developer working in Perl
| v5 when this transition occurred and from my perspective and
| recollection v6's meandering development cycle -- which didn't
| really address the issues of the broader Perl community was the
| primary choice. Perl 6 was developed in a way that didn't address
| the broad concerns of the Perl community, and expected people to
| make a wholesale switch to what was effectively an entirely new
| language anyways. It forced people to go out looking and what
| they found were either stronger solutions to specific domains
| (Ruby on Rails) or a nicer language than what was being proposed
| (Python).
|
| Where Python really excelled at the time was that it looked and
| worked very much like the pseudocode that was going around at the
| time, and had an opinion about how you should write your code.
| Perl is wonderful to write in, but in many ways is _too_
| expressive and permissive and it resulted in an ungodly mess that
| could be hard to maintain. Perl 6 simply leaned into that problem
| rather than encouraging a cleaner approach.
|
| I never liked Python much, but damn if I couldn't argue that I
| was much more productive with it than Perl in the end. Which was
| weird because when I was really hacking in Perl I could write
| code almost as fast as I could think giving a kind of illusion of
| productivity. But Python was easier to integrate into a coherent
| team development structure and _actual_ productivity is more
| important than feels.
|
| I miss working in Perl. But I knew it was really finally dead
| when I was giving tutorial classes to new bioinformaticists who
| were being given old Perl codebases to update and they were
| getting through school without learning the language.
| augusto-moura wrote:
| I would say PHP instead of Ruby was the big hit on Perl for
| web. It sat nicely in Apache and made replacing old cgi-bin
| much easier. It also had the philosophy and syntax heavily
| inspired by Perl
|
| Python was indeed the scripting replacement. I would say it won
| because of its philosophy on simplicity and explicitness. Perl
| v5 suffered heavily in complex projects because the language
| itself was too complex and often cryptic
| gwbas1c wrote:
| Perl died because the other languages are better. IMO, Perl was a
| quick solution to a need; but it has since been eclipsed by
| modern languages.
|
| I was in college 1999-2003, I did PHP in an internship, and then
| later did some Perl in one of my classes.
|
| Perl (in my college class) was so incomprehensible that I decided
| that I would avoid it. I've never applied to a job that uses
| Perl, and never responded to a recruiter that was looking for a
| Perl engineer. I've never had to use it at work, and fortunately
| I've never worked with anyone who wanted to use it.
|
| I think it's best to think of Perl as a transition technology.
| Kjeldahl wrote:
| My personal reason was observing the huge amount of investments
| into Javascript and its infrastructure (by Google and others).
| After Node.js was released it was a rational bet to make that
| Javascript would dominate, both server and client side. As
| someone who often does both front end and back end, it felt good
| to move to Javascript. It's got to be said that keeping a
| "common" directory around with shared code for both front- and
| backend is still a PITA, but still better than most other
| alternatives.
| _dan wrote:
| My experience of working with Perl as a primary language from
| late 90s to today: Perl was dead long before Perl 6/Raku was a
| real thing. By the time that happened it had already lost massive
| ground to PHP, Python, Java, etc.
|
| PHP had replaced CGI as the easiest way to get code on a
| webserver, Python and Java were easier to read and understand,
| easier to structure large systems with, and generally easier to
| use. Ruby came along and MVC frameworks became the thing for
| complex web platforms.
|
| Meanwhile Perl was _sorta_ keeping up, the "Modern Perl"
| movement helped dispel myths about "write only" code, things like
| Moose, DBIC, Catalyst, Mojolicious, etc meant you could write
| pretty modern stuff with it. But the community was smaller,
| fractured by Perl 6 and dominated by some _ahem_ divisive
| characters which made it intimidating for newcomers, and it just
| slowly died from there.
|
| By the time Stack Overflow came along it was easy to see that
| other languages had vibrant communities surrounding them and for
| me it never really recovered.
| glimshe wrote:
| It killed itself. I always remember the joke about any random
| sequence of characters and numbers being a valid Perl program.
|
| More importantly, there's hardly a problem that can't be solved
| in a much better way through other means.
| dana321 wrote:
| To get Perl to work with apache (the most used web server for a
| time), there were two options: the not-so-complicated cgi script
| which gets executed from scratch on every request, then there was
| mod_perl which required a lot of tinkering with apache
| configurations and writing your code in a different way.
|
| Even with those two options, you can't just write some code in a
| page and execute it without some sort of itermediate code.
|
| Thats why php became so popular, perl coders could pick it up in
| a day ($ and all) and all you have to do is write .php files to a
| server - with the bonus that you have a rudimentary templating
| system built-in to php.
|
| There really isn't much more to it than that.
| riordan wrote:
| This is why I preferred Mike Migurski's nickname for PHP:
| Apachescript; easy to integrate to the web server and next
| fastest thing to C for Apache.
| RajT88 wrote:
| I had to do a double take when I learned that modern cloud
| services still support PHP.
|
| Mentally, I put it in the same bucket as legacy ASP, which is
| looooong dead.
| dfltr wrote:
| I vividly remember the first time a friend showed me PHP in the
| late 90s. You're saying I can just write a script that
| generates HTML and throw it in /foo/index.php and that's the
| whole thing?
|
| It's wild that right up until Rails got popular, we were
| writing code that served billions of requests off of homebrewed
| MVC-ish PHP frankenframeworks.
| creer wrote:
| > mod_perl which required a lot of tinkering [...]
|
| Here we used mod_perl all over the place and it was glorious.
| It did take understanding how to use it - well, yes - same as
| the rest of perl (or apache for that matters). But it was so
| well integrated! I still miss it.
|
| "Picking it up in one day" is not a criteria for professional
| deployements.
| rdtsc wrote:
| Python killed Perl.
|
| By the time Perl 6 was around, Perl's lunch was already eaten by
| Python. Only a few table scraps left. Perl 6 would have had to be
| a better Perl 5 and a better Python 2 to win.
|
| Python came with better batteries and better syntax. It allowed
| producing code you could read and understand a week later. Perl I
| found was a write-only language for me. I went back looking at my
| old Perl code and I couldn't decipher it without some effort.
|
| And Python became popular not just because it was a better Perl,
| but it attracted folks who used Java and C++. CPU speeds were
| getting fast enough that you could actually do file and network
| IO at acceptable speeds without all the `public static void
| main(String[] args)` and `System.out.println(...)` boilerplate,
| but still had all the object oriented bits like inheritance and
| composition with which you could go crazy with if you wanted.
| icedchai wrote:
| PHP also contributed. Perl CGIs were a very popular way to
| build early web apps.
| rmunn wrote:
| Personal anecdote in support: my first job out of college was
| at a data-analysis company, where my task was usually to write
| one-off scripts to extract data from various data sources and
| massage it into the format the analysts wanted for their
| spreadsheets. I wrote most of those scripts in Perl at first,
| with the odd Bash script here and there. Then one of my
| coworkers said "Hey, if you like Perl, you'll love Python". I
| learned Python (2.1 was the most recent version at the time,
| which tells you how old this story is) and almost immediately
| switched over. All my new one-off data-extraction scripts from
| then on were written in Python (though still with the odd Bash
| script here and there).
| twoodfin wrote:
| I would bet against this hypothesis.
|
| Perl exploded because it was the easiest, richest ecosystem
| available to plug into CGI and the web.
|
| PHP & Ruby & Python then collectively covered the same
| waterfront whether you wanted "easy" or "fun" or "simple".
|
| And I would propose that PHP attracting the developer cohort
| who wanted "easy" and Ruby/Rails attracting the developer
| cohort who wanted "fun" were each individually more damaging to
| the Perl ecosystem than Python.
| scott_s wrote:
| Agreed. In grad school, I used Perl to script running my
| benchmarks, post-process my data and generate pretty graphs for
| papers. It was all Perl 5 and gnuplot. Once I saw someone do
| the same thing with Python and matplotlib, I never looked back.
| I later actually started using Python professionally, as I
| believe lots of other people had similar epiphanies. And not
| just from Perl, but from different languages and domains.
|
| I think the article's author is implicitly not considering that
| people who were around when Perl was popular, who were
| perfectly capable of "understanding" it, actively decided
| against it.
| michaelcampbell wrote:
| > By the time Perl 6 was around...
|
| Just my opinion, but this says more about perl 6's insane
| development schedule than python's advantages.
| jrm4 wrote:
| It would literally just be Python (and probably some php and
| maybe even ruby) plus "Bash is good enough and more ubiquitous
| for the things you don't need all of Python for," no?
| tyingq wrote:
| I love Perl. I think, though, that the crazy mix of sigils and
| braces/brackets to work with complex data structures was one of
| the main reasons.
|
| Especially for the type of users were Perl had gained some ground
| in the past...data science, DNA related stuff, etc. Non
| programmers.
|
| If you look at just about any other language and how you would
| pull data in and out of json yaml, manipulate individual
| elements, etc... the Perl is just hard to decipher if you don't
| have immediate recall of all the crazy syntax for dereferencing
| things.
| foofoo12 wrote:
| I learned Perl back in the day. It was fun and powerful.
|
| But I think the package management and culture killed it for me.
| People took pride is writing obnoxiously messy code. Package
| dependency hell. Gung ho borderline toxic RTFM culture.
| maximilianburke wrote:
| One thing I miss to this day is how ergonomic regular expressions
| are in Perl 5.
| cruffle_duffle wrote:
| Dude, a lot of the string handling stuff in Perl was great!
| eikenberry wrote:
| Perl 5.
|
| Perl 4 was a great upgrade to bash as a scripting language. Perl
| 5 added a bunch of complexity to remake Perl into a programming
| language. It failed.
|
| Perl 4 was a great scripting language whereas Perl 5 was a
| terrible programing language. Perl 5 lost to the better (dynamic)
| programming languages and bash reclaimed the scripting title as
| Perl 4 was dead.
| worik wrote:
| No.
|
| I came to Perl when Perl 4 was the latest.
|
| I was using it as a frame work for distributed computing,
| moving data between machines.
|
| I was on the point of throwing it all away for C++ when Perl5
| came out.
|
| I forget the details, but it made everything possible, and did
| not get in my way like Perl 4 did.
| ajb wrote:
| Interesting take! I wasn't around for perl 4. I didn't like
| perl 5, but I was quite interested in 6 at the start. For a
| moment it looked like Larry Wall had really reflected on the
| problems of perl 5, and was going to make a new language that
| was at once cleaner and more systematic, even though it had
| more features. Then he kept adding more shiny things and I lost
| interest.
| empw wrote:
| To me Perl was just Weird, to no particular end. Not the kind of
| mind expanding Haskell/Prolog/Lisp weirdness that opens up new
| possibilities. It just does roughly the same things as every
| other language, but everything is done slightly differently due
| to evolving out of the primordial soup of bourne shell and AWK
| filtered through Larry Wall's brain.
|
| Perl and Python were similarly powerful and useful languages, but
| I could learn and start producing useful code in Python after
| reading an hour long tutorial. Perl took an order of magnitude
| longer, and remained more awkward to use just due to the
| Weirdness. There was a momentum building in the early 2000s
| toward competitors like Python and Ruby that were seen as less
| crufty and more modern.
|
| Perl's developers seemed to agree, since they cooked up their own
| competitor to Perl, an entirely different language confusingly
| called Perl 6. The coexistence of Perl 5 and 6 made the Python 3
| transition look like a cakewalk -- at least it would have save
| for Perl 6's almost entire failure to exist for over a decade
| after its inception. It produced lots of constantly churning
| specs and blog posts about register based virtual machines with
| native support for continuations or whatever, but no
| implementation of a language that anyone felt comfortable using
| for any real development. Meanwhile people kept using the
| ossifying Perl 5 for existing applications, and gradually
| transitioning away as they were replaced.
|
| Also PHP overtook it for the "just FTP a script to $5 shared
| hosting and make a webapp" use case.
| fatbird wrote:
| I agree, and the blame for its weirdness can be laid directly
| at Larry Wall's feet, because Wall _wanted_ a language that
| allowed for cleverness, suprise, and ingenuity. He was never
| happier than when someone would come up with a completely new
| way to do something. For Wall, programming was less about
| coding an outcome, than it was about speaking a particular
| language (and ideally, writing poetry in it). And it was very
| successful in this way, and fit reasonably well with the high-
| knowledge users /environment of unix in the 90s.
|
| It's just that Wall's vision was incompatible with general
| purpose languages used widely by a wide range of knowledge and
| skill amongst its users, and as unix/linux opened up to that
| wider range, better general purpose alternatives were chosen.
| Having to learn to be a poet to be a good coder was too high a
| barrier.
| kubanczyk wrote:
| > Wall wanted a language that allowed for cleverness,
| suprise, and ingenuity. [...] Having to learn to be a poet to
| be a good coder was too high a barrier.
|
| To me this just sounds, umm, pathologically eclectic.
| fatbird wrote:
| Now extrapolate to "let's do a Perl 6 that allows us to do
| all the things I couldn't work into Perl 5" and a lot more
| history makes sense.
| jsight wrote:
| I sometimes wonder how different things might have been if Perl
| had been the dominant scripting language at the time that
| ChatGPT, Codex, Claude Code and other tools like that became
| available.
|
| Would Python have been able to compete, in a world where Perl
| could be readily comprehended by LLMs?
|
| So, maybe what killed Perl was lack of VS Code forks and lack of
| being agentic.
| hn_acc1 wrote:
| So then we'd have 100x as much "vibe coding" as now? <shudders>
|
| Even if I disagree with our AI code assistant's usefulness - it
| often just suggests code based on "someone else in a different
| file used this statement after that last API call" that is
| totally irrelevant to my current needs - I can usually assess
| AI-generated code (C++ / python) relatively quickly and
| determine if it's what I want or not. It generally nails the
| "you just created this variable and now want to print it to the
| log" part pretty well.
|
| Debugging AI-generated perl?? It would be like trying to follow
| "obfuscated C contest" entries all day, every day. No thanks!
| MikeNotThePope wrote:
| From a recruiter's perspective, I remember recruiting full stack
| Perl people for a San Jose based tech company in 2010. I was able
| to secure one really good Perl guy who had just been laid off
| from Yahoo, but there just wasn't anyone else who was relatively
| easy to find with the experience this company wanted. I was
| charging by the hour, and I distinctly remember suggesting that
| the company consider hiring non-Perl people and letting them
| learn on the job as I wasn't going to be able to find what they
| wanted. They kept looking for Perl people and I kept charging
| them. I wasn't shocked when an executive at the company
| eventually asked why the recruiting bill was so high given the
| lack of results.
| hn_acc1 wrote:
| I interviewed for Yahoo Mail in '05 - multiple rounds and they
| ghosted me. IIRC, it was all going to be perl stuff.. I'd done
| some out of necessity a few years earlier, and hated it.
|
| In hindsight, glad they didn't respond - got a much nicer EDA
| startup job a month later working with Tcl/Tk (which I had
| already used for ~10 years at the time).
| bawolff wrote:
| I use shell, vim, sed all the time (awk less but i have used it).
| I've never used perl. I don't even know if i've ever even
| encountered a perl program that i wanted to look inside.
|
| I think its just one of those things, they lost mindshare and
| people stopped making stuff in perl. Network effects made it
| snowball from there. How often do you see code examples written
| in perl? Almost never. I see people write blogs with code
| snippets in python, c, rust or even shell all the time. Never
| perl.
|
| Momentum matters and perl lost it. I think of perl the same way i
| think of cobol or fortran.
| pklausler wrote:
| You really think that Perl has billions of lines in active use
| in critical applications and libraries?
| nabbed wrote:
| Back in 1994, Perl was an amazing thing to me (as someone who was
| accustomed to mainframe scripting languages up to that point),
| and it helped make me very productive. But it sometimes would
| seem like the epitome of "Write once, read never". Tim Bray even
| remarked on its abstruseness back in 2003:
|
| https://www.tbray.org/ongoing/When/200x/2003/07/31/PerlAngst
| lc9er wrote:
| Expecting the Perl community, with it's TMTOWTDI (There's More
| than One Way to Do It) ethos, to come together and be the drivers
| of the next version.
| dgunay wrote:
| I have great love for Perl, but I'm not super eager to go back to
| using it.
|
| I used it in probably one of the more cursed contexts I've ever
| heard of. Understand[0] is a static analyzer for many languages,
| and one of its killer features is that it is programmable with a
| Perl API. I used this feature at a defense consulting job to help
| target audits of huge, multi-million LOC codebases.
|
| Perl's expressivity was very useful here. I cut my teeth on
| functional programming concepts to write some very nice
| traversals. The runtime environment of the host program was a
| nightmare to deal with though.
|
| [0]: https://scitools.com/
| Demiurge wrote:
| Perl is what killed Perl. I have never had as many "tear my hair
| out at 4AM" debugging sessions as I have had with Perl, because I
| missed some weird character somewhere.
| creer wrote:
| Simply python being pushed / sponsored by google? Was python all
| that popular before that? It had fans, of course - but was it an
| automatic go-to?
|
| Python claimed to be simple - which fit well with the "line
| noise", erm... propaganda.
| f055 wrote:
| What is dead may never die. Perl will live on in the few mostly
| weird places doing things other languages can only dream of. And
| that's fine. Perl doesn't need to win the race or update itself.
| It is good enough as it is. It's the magic wand in the world full
| of electronics. Sure you can light the room with an electric
| PHP/Python lightbulb script. But Perl can summon a levitating
| glowing orb out of thin air with a single line of code.
| worik wrote:
| Back in the day it was Perl or PHP on the web
|
| I was a Perl programmer, and I looked down my nose at PHP. Silly
| me, then and now
|
| Why did PHP, an objectively a worse language, win?
|
| Rasmus Lerdorf said in a quote I can no longer find, it was
| modperl vs. modphp for Apache.
|
| Modperl was, typically for Perl, very comprehensive and allowed
| access to all the Apache processing hooks
|
| Modphp was, typically for PHP, just enough to speed up rendering
| so only allowed access to the barest minimal set of hooks
|
| Modperl, so much better (I can hear myself say 30 years ago)
|
| But at the time most websites, by count not by traffic, ran on
| shared hosts where the system administrator gave you access to
| software. If they installed mosdperl you would be able to
| intercept, read, and change traffic for all websites hosted on
| that machine
|
| Modphp, not so.
|
| So PHP was widely available to the pioneers in the day, people
| scratching together a little web hosting business and growing .
| Perl was not
|
| Not enough on its own to kill Perl, but an important nail in its
| coffin
| rsync wrote:
| All of rsync.net and "Oh By"[1] are coded in perl.
|
| Which is to say, the customer facing web interface, ordering,
| management and our own management back ends.
|
| Obviously the _actual storage component_ employs no interpreters
| of any kind.
|
| Alive and well!
|
| [1] https://0x.co
| zzbn00 wrote:
| Moved out of TCL and into Python in 2001. Perl was big at the
| time. But Python had REPL and numeric/numarray which swung it in
| my case.
|
| (Worked out well I suppose? Almost 1/4 century and still using
| Python)
| ironman1478 wrote:
| Something I haven't seen mentioned is that python is very
| commonly taught at universities. I learned it in the 2010s at my
| school, whereas I never got exposed to Perl. The languages people
| learn in school definitely stick with you and I wonder if that
| plays a non-zero factor in this.
| David-Henrry wrote:
| Perl's decline is often attributed to competition from newer
| languages like Python and JavaScript, complexity, and shifting
| developer preferences toward simpler, modern alternatives.
| btilly wrote:
| Disclaimer. Perl was my first real language. I have several
| contributions to Perl, including a complete rewrite of Carp.pm.
| For a number of years I was also on the Perl 5 Grant Committee.
|
| I completely discount the basic syntax as an issue. Sure, it is
| an easy thing to complain about. But I've personally seen a
| number of people with no background master the basic syntax very
| quickly. In fact I was able to teach myself from the Camel book
| with absolutely zero background in the various languages that are
| supposed to help you. And during the dot com era, most of the
| people writing CGI scripts in Perl, similarly lacked a
| programming background.
|
| The first issue was the fact that a lot of bad Perl got written.
| It was remarkably easy to pick up a bit of Perl, then write a
| bunch of code. This code was generally bad, useful, and full of
| security holes. (Thanks, Matt Wright.) Most people's exposure to
| Perl was to this kind of code, and it left a permanent bad
| impression.
|
| The TIMTOWTDI (There Is More Than One Way To Do It) philosophy
| fed into a widespread cowboy philosophy. People took pride in
| their mastery of Perl, and demonstrated it by using obscure
| features. Like, say, C++, many subsets of Perl make for good
| languages. But if you try to use all of the features at once, the
| combination doesn't play well together.
|
| That said, there was a significant group of people who grew and
| improved together. They learned best practices, wrote good CPAN
| modules, and elevated their game. But this group fell into a
| different trap. They learned the immense productivity of small
| teams. But organizations filled with small teams of senior
| programmers, don't have a way to mentor junior programmers. This
| cut off the pipeline of future developers. Losing that pipeline
| is an organizational threat. How do you find maintenance
| programmers down the line? Many organizations that had a lot of
| Perl, then put a lot of work into trying to move away from Perl.
| A significant number of Perl programmers saw the writing on the
| wall, and took the opportunity to move away from Perl themselves.
| This resulted in very few new companies being built around Perl.
|
| (Incidentally the same "no pathway for junior programmers"
| problem is becoming a big issue for programming in general
| because of LLMs.)
|
| For the next problem, we have to go to perl5-porters. The group
| that maintained the core of the language.
|
| Let's start with a key individual. Tom Christensen. Brilliant,
| productive, and a technical genius. But also confrontational,
| unstable, and a toxic influence that shut down Perl development.
| This was a major reason why the Perl 5.6.1 release took over a
| year to get important bug fixes out. Tom also drove a number of
| people out of the Perl core.
|
| Then there was an underlying tension between two major groups.
| The first were people who wanted to take Perl, and run with it.
| Adding all sorts of new and interesting features. The opposing
| group was those who cared about production, and wanted to be
| reaaally careful about breaking anything.
|
| This lead in 2000 to a famous cup throwing incident by Jon
| Orwant. Larry's solution was to behind the scenes put a muzzle on
| Tom, and start the Perl 6 effort. That way people who wanted new
| features could go off and play in the new sandbox, while those
| who wanted to support existing Perl could stay in Perl 5.
|
| Over time a lot of the good ideas in the new sandbox got ported
| back to Perl. See, for example, Moose. The spread of these
| technologies meant that there was a lot of progress within the
| Perl ecosystem. Unfortunately this came as the Perl ecosystem
| itself was shrinking. The language itself improved a lot. But the
| programming world in general didn't notice, and didn't care.
| cestith wrote:
| Thanks for that perspective, Ben.
| btilly wrote:
| You're welcome.
|
| I should have also mentioned that I was tilly on Perlmonks.
| For a long time I was the top rated poster, on the dominant
| question and answer site for Perl questions.
| cestith wrote:
| I for one knew that. I'm mr_mischief on there, not that I
| visit regularly these days.
| btilly wrote:
| Oh wow! I remember you!
|
| I hope that life is treating you well. My life since
| COVID has been a nightmare.
| submeta wrote:
| In the early 2000s Perl was godsend. A dynamic language that
| helped solve a lot of problems very quickly. But as soon as
| projects got larger and/or others joined your codebase you
| realized it does not scale. For me that was the moment when I
| slowly migrated to Python. So for me Perl's syntax (&@!#%), the
| easter eggs in the language, and the thousands of ways to be able
| to write things, killed it. It was just not maintainable.
| psanford wrote:
| The thing that killed perl was python. The reason that python won
| is because it was Google's blessed scripting language.
| windowshopping wrote:
| I'll give you my two cents - I took a job in Perl in 2017 and set
| about learning it and found its community to be the most snobbish
| and unfriendly of any programming subcommunity I had ever
| encountered.
|
| The language had many strange quirks and every question I posted
| about its particularities was greeted with responses along the
| lines of "Are you even trying? How do you not get it? Did you
| even read the docs?"
|
| Well, yes, I did, and I still didn't understand, because I found
| them unclear.
|
| I left the job and dropped the language and moved on to greener
| pastures without much regret. And it seemed like many, many
| people I spoke to had similar experiences with it.
| reddit_clone wrote:
| Few years into Perl 6, they should have recognized the writing on
| the wall, forked off Raku and let Perl 5 grow on its own.
|
| One of the biggest fumbles in the history of computing. (With
| hindsight ofcourse..)
| fithisux wrote:
| Perl didn't die. It transformed to Raku.
|
| This is evolution. Not death. It found what are its strengths
| that would make it relevant today and it made the leap of faith.
| That is remarkable.
|
| No one need to switch to Perls 6 and Perl 5 can evolve
| incorporating incrementally stuff from Perl 6. Not every core
| team has the time, the $$$ or the devs to put forward long term
| plans of compatibility.
|
| People always expect "someone" to do it.
|
| What Perl 5 people could do, is improve its code base, clean it
| up and use sane software engineering practices to make code
| boring, modern and much more friendly for contributions.
|
| You know, the anthropic side of software.
| pbalau wrote:
| Perl was killed by mod_php.
|
| Not the language, but the easiest setup ever.
| warpspin wrote:
| I have been using Perl for almost 30 years now, privately and
| professionally. People here tend to say, Perl 6 or Python killed
| it, but that's not what I experienced in those 30 years. Not that
| simple.
|
| It was a combination of things, the Perl 6 announcement was one
| of the smaller parts actually.
|
| - TIMTOWDI lost against "batteries included", and it lost big:
| It's not so much that the simpleness of the Python language won
| over Perl, the real and absolutely major problem at that time was
| the success of CPAN, which "killed" Perl 5. Perl 5 would have
| needed ONE object system, ONE base exception class, ONE way to do
| function signatures. Instead at the time, it came bundled with a
| bunch of Perl 4 utilities which nobody dared unbundling, CGI and
| a handful math functions. Being able to pick is nice, but
| everybody else did pick, too, and so if you used any CPAN
| dependencies, you soon had 3 incompatible object systems, 4 type
| systems, 5 exception systems co-existing within your project. A
| problem Perl has to this day and the reason why my team tends to
| re-implement stuff instead of pulling in dependencies. Python's
| "batteries included" approach easily won out, because stuff
| worked with each other and you didn't burn then scarce RAM on
| having different implementations of the same thing.
|
| - Perl started to lose at the low-cost hosters against PHP
| already pretty early. It was easier during a certain time period
| to have a halfway performant PHP installation than a performant
| Perl installation. Hosters usually only offered CGI for Perl, not
| mod_perl, while PHP usually was offered as FastCGI module or
| mod_php which supposedly was easier to install. No low cost
| hoster wanted to mess with mod_perl, because it always was a
| hassle to setup.
|
| - Speaking of mod_perl, things in the web dev sector still stayed
| pretty stable as long as Apache 1 ruled. People had to use
| mod_perl, but then you had a pretty performant solution. Then
| Apache 2 came around but mod_perl 2 wasn't ready for a long time
| (honestly I don't know whether it ever became ready). The Perl
| community at that time appeared entirely unprepared for that.
| While Python users were accustomed to run standalone Python
| servers behind proxies, Perl always was relying mostly on
| mod_perl. But threading in Perl stagnated and ran against a wall,
| and Apache 2 preferred multi process multi threading modes versus
| the simpler prefork multiprocess model that Apache 1 and mod_perl
| 1 ran on. This was the time were you could basically feel the
| creaking and everything breaking apart: suddenly there was no
| clear path forward, with mod_perl2's stability issues and the
| general threading stability issues of Perl 5.
|
| It took years for the community to recover from that and focus on
| things like the Python-inspired PSGI/Plack as a way forward.
|
| So, how does Perl 6 fit into this? Yes, in the early 2000s we did
| think, it would be just around the corner and be a clear upgrade
| path and solve everything wrong with Perl 5. Nice fantasy at the
| time. But at the same time, people were busy with far more
| pressing immediate problems, like how to migrate away from
| mod_perl1. When Python's WSGI and soon after that, Ruby on Rails
| came, they pressed directly into the vacuum left open by the
| mod_perl 2/Apache 2 disaster and this is actually what sealed the
| deal, IMHO.
| downsplat wrote:
| There's more than one thing that "killed perl" (I still use it
| almost every day.)
|
| But I think the main thing that made it long term non competitive
| were a series of bad design choices all the way back to perl 4 or
| even 1.
|
| Namely:
|
| - the need for sigils
|
| - weird sigil rules where the 0 element of @x is $x[0] not @x[0]
|
| - auto flattening, ex. (@a, @b), and hence the need for manual
| reference management, as in (\@a, [1,2,3])
|
| - lack of a native object system, and widespread repurposing of
| hashrefs as objects, with awkward field syntax $x->{foo}
|
| - awkward function argument syntax: my ($x, $y) = @_;
|
| These things add up, and both JS and python showed that all those
| can be done much more smoothly.
|
| Another thing that counted at the time, is that PHP came out with
| a slightly worse language, but a super beginner-friendly approach
| to html templating and request lifecycle: you can just mix php
| and html in the same file, and the entire runtime environment is
| nuked at each request. The result was that php replaced perl for
| an entire generation of web devs in the early 2000s.
| wduquette wrote:
| What killed Perl for me was readability, long before Perl 6/Raku.
| I was an Awk programmer from way back, so took to Perl quickly
| once it was available. Then in the late 90's I wrote a utility
| program in Perl that generated some nice HTML documentation for
| me from some kind of input format I no longer recall.
|
| A year later I tried to use that script on another project, but
| had to make some changes; and couldn't make heads or tails of it.
| Shortly thereafter I had occasion to look at some Tcl/Tk I'd
| written at about the same time...and it made perfect sense to me.
|
| Had I used Perl on a daily basis, rather than occasionally, I
| might have stuck with it. Instead I switched to Tcl/Tk, and never
| regretted it.
| phendrenad2 wrote:
| Shhhh don't mention Perl. The fact that Perl is still installed
| by default on most Linux distros is the only ray of light in the
| horrible devops landscape. The fact that I can write a script in
| Perl and not have to deal with BASH's horrible syntax is a small
| joy in that world. If you mention Perl too much, the people who
| ruin everything might set their sights on it.
| Spooky23 wrote:
| I think Perl was very tied to Unix idioms. I love the language to
| this day and found it incredibly expressive for developing small
| order of magnitude programs.
|
| Python was more opinionated, and better able to integrate with
| external libraries. A lot of the heavy lift in python is really
| invoking external code from elsewhere. You can solve "real"
| problems with readable code without the learning curve of C or
| Java.
| superkuh wrote:
| Perl isn't dead. Perl is the only stable actively developed
| language. Code written in 2003 runs today and perl code written
| today runs on a perl interpreter from 2003. Because of this perl
| is by far the best language to do system administration. It is
| both ubiquitous and stable. Other scripting languages like python
| constantly have breaking changes and frankly, you have to have a
| special separate install for every python script you try to run.
| With perl the system perl is always enough. No containers needed.
|
| You can call it dead. That's fine. Keep it unpopular. Popularity
| kills. Popularity leads to a language becoming dozens of
| different incompatible things. Perl is quietly amazing. I write
| once and run anywhere, anytime. Other languages can only dream of
| this.
| a-dub wrote:
| python replaced it as a general purpose scripting language.
|
| a bunch of other things (java, ruby, js) replaced cgi scripts and
| mod_perl as a web backend environment.
|
| python became a "must know" to interview at google.
|
| old perl was neglected and became unreadable.
|
| perl itself became ugly to eyes used to modern languages.
|
| the perl 6 mess and associated sentiment made it look worse.
|
| it was time for it to go anyway.
___________________________________________________________________
(page generated 2025-11-19 23:00 UTC)