[HN Gopher] Perl's decline was cultural
___________________________________________________________________
Perl's decline was cultural
Author : todsacerdoti
Score : 181 points
Date : 2025-12-06 17:42 UTC (5 hours ago)
(HTM) web link (www.beatworm.co.uk)
(TXT) w3m dump (www.beatworm.co.uk)
| superkuh wrote:
| Perl's "decline" saved it from a fate worst than death:
| popularity and splitting into dozens of incompatible versions
| from added/removed features (like python). Instead Perl is just
| available everywhere in the same stable form. Scripts always can
| just use the system perl interpreter. And most of the time a
| script written in $currentyear can run just as well on a perl
| system interpreter from 2 decades ago (and vice versa). It is the
| perfect language for system adminstration and personal use. Even
| if it isn't for machine learning and those kinds of bleeding edge
| things that need constant major changes. There are trade-offs.
|
| This kind of ubiquitous availablility (from early popularity)
| combined with the huge drop-off in popularity due to raku/etc,
| lead to a unique and very valuable situation unmatched by any
| other comparable language. Perl just works everywhere. No
| containers, no dep hell, no specific versions of the language
| needed. Perl is Perl and it does what it always has reliably.
|
| I love it. The decline was a savior.
| keepamovin wrote:
| My language learning trajectory (from 10 years old) was 8086
| assembly, QBASIC, C, Perl, Java, MAGMA, JavaScript/HTML/CSS,
| Python, Haskell, C++, vibe coding
| pomatic wrote:
| How old are you now? Mid fifties here. And 'vibe coding' in
| what exactly - it is not of interest from a programming
| perspective, but from a 'what does the AI know best
| perspective'? I've followed a similar, but not identical
| trajectory and now vibe in python/htmx/flask without needing
| to review the code in depth (NB internal apps, not public
| facing ones), with claude code max. Vibe coding in the last
| 6-8 weeks now also seems to make a decent fist of embedded
| coding - esp32/arduino/esp-32, also claude code.
| amiga386 wrote:
| Perl's binary brings with it the ability to run every release
| of the language, from 5.8 onwards. You can mix and match Perl
| 5.30 code with 5.8 code with 5.20 code, whatever, just say "use
| v5.20.0;" at the start of each module or script.
|
| By comparison, Python can barely go one version without both
| introducing new things and removing old things from the
| language, so anything written in Python is only safe for a a
| fragile, narrow window of versions, and anything written for it
| needs to keep being updated just to stay where it is.
|
| Python interpreter: if you can tell "print" is being used as a
| keyword rather than a function call, in order to scold the
| programmer for doing that, you can equally just _perform the
| function call_.
| 0xDEAFBEAD wrote:
| The Python approach seems better for avoiding subtle bugs.
| TIMTOWTDI vs "there should be one obvious way to do it"
| again.
| zahlman wrote:
| > By comparison, Python can barely go one version without
| both introducing new things and removing old things from the
| language
|
| Overwhelmingly, what gets removed is from the standard
| library, and it's extremely old stuff. As recently as 3.11
| you could use `distutils` (the predecessor to Setuptools).
| And in 3.12 you could still use `pipes` (a predecessor to
| `subprocess` that _nobody ever talked about even when
| `subprocess` was new_ ; `subprocess` was viewed as directly
| replacing DIY with `os.system` and the `os.exec _` family).
| And `sunau`. And `telnetlib`.
|
| Can you show me a real-world package that was held back
| because the code needed a feature or semantics _from the
| interpreter* of a 3.x Python version that was going EOL?
|
| > Python interpreter: if you can tell "print" is being used
| as a keyword rather than a function call, in order to scold
| the programmer for doing that, you can equally just perform
| the function call.
|
| No, that doesn't work because the statement form has
| radically different semantics. You'd need to keep the entire
| grammar for it (and decide what to do if someone tries to
| embed a "print statement" in a larger expression). Plus the
| function calls can usually be parsed as the statement form
| with entirely permissible parentheses, so you have to decide
| whether a file that uses the statement should switch
| everything over to the legacy parsing. Plus the function call
| affords syntax that _doesn 't_ work with the original
| statement form, so you have to decide whether to accept those
| as well, or else how to report the error. Plus in 2.7,
| surrounding parentheses _are not redundant, and change the
| meaning_ : $ py2.7 Python 2.7.18
| (default, Feb 20 2025, 09:47:11) [GCC 13.3.0] on
| linux2 Type "help", "copyright", "credits" or "license"
| for more information. >>> print('foo', 'bar')
| ('foo', 'bar') >>> print 'foo', 'bar' foo bar
|
| The incompatible bytes/string handling is also a fundamental
| shift. You would at least need a pragma.
| never_inline wrote:
| asyncio.get_event_loop ?
| cedilla wrote:
| What incompatible versions of pythons do you mean? I'm entirely
| unaware of any forks, and the youngest version I have to supply
| at the moment is 3.9, which is over 5 years old and available
| in all supported platforms.
| superkuh wrote:
| Try to run any random python program of moderate dep use on
| your python 3.9 system interpreter without using containers.
| Most likely you'll have to use a venv or the like and setup a
| special version of python just for that application. It's the
| standard now because system Python can't do it. In practice,
| pragmatically, there is no Python. Only pythons. And that's
| not even getting in to the major breakages in point version
| upgrades or the whole python 2 to 3 language switch.
| zahlman wrote:
| > Most likely you'll have to use a venv or the like and
| setup a special version of python just for that
| application.
|
| _Using venvs is trivial_ (and orders of magnitude more
| lightweight than a container). And virtually every popular
| package has a policy of supporting _at least_ all currently
| supported Python versions with each new release.
|
| You need to set up a venv _because of how the language is
| designed_ , and how it has _always_ worked since the
| beginning. Python doesn 't accommodate multiple versions of
| a package in the same runtime environment, full stop. The
| syntax doesn't provide for version numbers on imports.
| Imports are cached by symbolic name and everyone is
| explicitly expected to rely on this for program correctness
| (i.e., your library can have global state and the client
| will get a singleton module object). People just didn't
| notice/care because the entire "ecosystem" concept didn't
| exist yet.
|
| I have at least one local from-source build of every Python
| from 3.3-3.14 inclusive (plus 2.7); it's easy to do. But I
| have them explicitly for testing, not because using someone
| else's project forces me to. The ecosystem is _just not
| like that_ unless perhaps you are specifically using some
| sort of PyTorch /CUDA/Tensorflow related stack.
|
| > It's the standard now because system Python can't do it.
|
| Your system Python absolutely can have packages installed
| into it. The restrictions are because _your Linux distro
| wants to be able to manage the system environment_. The
| system package manager shouldn 't have to grok files that
| it didn't put there, and system tools shouldn't have to
| risk picking up a dependency you put there. Please read
| https://peps.python.org/pep-0668/, especially the
| motivation and rationale sections.
|
| > major breakages in point version upgrades
|
| I can think of exactly one (`async` becoming a keyword,
| breaking Tensorflow that was using it as a parameter name).
| And they responded to that by introducing the concept of
| soft keywords. Beyond that, it's just not a thing for your
| code to become syntactically invalid or to change in
| semantics because of a 3.x point version change. It's just
| _the standard library_ that has changes or removals. You
| can trivially fix this by vendoring the old code.
| 999900000999 wrote:
| Python is mentioned and I think the key reason it's continued to
| grow while Perl declined, is a vastly more welcoming culture.
|
| Python says you know nothing, but want to automate a small task.
| The community will help you. More so than any other language.
|
| Then again, Python 2 and Python 3 are two different languages.
|
| Very few projects are willing to have such a massive migration.
| zahlman wrote:
| "Willing" is an interesting word choice. There was quite a bit
| of resistance in the Python world despite the clear benefits.
| (2.x really could not be fixed, because the semantics were
| fundamentally broken in many places.)
| 999900000999 wrote:
| It's open source.
|
| Any one ( and I'm sure a few have tried) can fork 2.x and
| keep using it.
|
| 3.x is remarkably easy , you can probably onboard a non
| programer to Python in a month.
| zahlman wrote:
| > Any one ( and I'm sure a few have tried) can fork 2.x and
| keep using it.
|
| They have tried and succeeded:
| https://docs.activestate.com/activepython/2.7/
|
| I still consider the result "broken".
| mmastrac wrote:
| In fairness, Perl died because it was just not a good language
| compared to others that popped up after its peak. Sometimes
| people just move to the better option.
| frankwiles wrote:
| Yeah I think I would have been considered part of the "in"
| crowd of Perl to some degree and it wasn't the culture that
| drove me away and to Python.
|
| It was Django and the people involved with it.
| liveoneggs wrote:
| > and the people involved with it.
|
| Culture?
| MangoToupe wrote:
| Perl was (and still is) a very expressive and concise language
| for working with text and a unix-style system. It exists in the
| odd space between a shell language and a general purpose
| language.
|
| But, shell scripting has already become somewhat of an arcane
| skill. I think the article nailed that Perl was just too hard
| to learn for the value it provided to survive. Python is not
| nearly as, erm, expressive as perl for working in that space,
| but it is much easier to learn, both in terms of reading and
| writing. In other words, it encourages broadly maintainable
| code. Ruby is quite similar (although I think people massively
| overstate how much the language itself generally encourages
| understandable semantics)
| jordanb wrote:
| Shell is a crappy scripting language because it has primitive
| data structures and data flow control making it hard to
| manage and manipulate data as you process it between
| applications. The fact that newlines are such a problem is a
| case in point.
|
| Python is a crappy shell scripting language because the
| syntax around pipe and subprocess is really clunky.
|
| Perl managed to have decent data structures and also have
| decent syntax around subprocess calls.
|
| But I feel like the Python invoke module gives me everything
| I need wrt subprocess calls. I basically write any nontrivial
| "shell script" these days as a Python invoke command.
| zahlman wrote:
| I assume you refer to https://www.pyinvoke.org/ which I
| just looked up. It looks quite promising, thanks for the
| heads-up.
| zahlman wrote:
| > Perl was (and still is) a very expressive and concise
| language for working with text and a unix-style system. It
| exists in the odd space between a shell language and a
| general purpose language.
|
| GvR explicitly describes the motivation behind Python in
| similar terms (I can probably find a timestamp in that recent
| documentary for this). But the goal there was to be fully
| "general purpose" (and readable and pragmatic, more than
| artistic) while trying to capture what he saw as the good
| things about shell languages.
|
| And it's changed quite a bit since then, and there are many
| things I would say with the benefit of hindsight were clear
| missteps.
|
| We all joke about the hard problems of computer science, but
| it seems to me that the hard problems of programming language
| design, specifically (and perhaps software engineering more
| generally?) include having good taste and figuring out what
| to do about reverse compatibility.
|
| > I think the article nailed that Perl was just too hard to
| learn for the value it provided to survive. Python is not
| nearly as, erm, expressive as perl for working in that space,
| but it is much easier to learn
|
| The use cases have also changed over time. Quite a lot of
| developers ended up on Windows (although that pendulum is
| perhaps shifting again) where the rules and expectations of
| "shell" are very different. To say nothing of e.g. web
| development; long gone are the days of "cgi-bin" everywhere.
| zihotki wrote:
| > Perl was (and still is) a very expressive and concise
| language
|
| And that could be one of major reasons why it lost in
| popularity. It was and still is easy to write but hard to
| read.
| atherton94027 wrote:
| There was so much complexity hidden behind "do what I mean".
| For example, scalar vs array context which was super subtle:
| my @var = @array # copy the array my $var = @array #
| return the count of elements in array
| js2 wrote:
| Or even worse: my($f) = `fortune`; # assigns
| first line of output to $f. my $f = `fortune`; # assign
| all output to $f.
|
| Which allegedly got a HS kid in hot water[^1].
|
| [^1]: "It's all about context" (2001):
| https://archive.ph/IB2kR
| (http://www.stonehenge.com/merlyn/UnixReview/col38.html)
| weare138 wrote:
| Then don't use the low level interfaces. In Perl, language
| features are plug and play. Everything's in a module. Use
| the core module List::Util instead.
| PunchyHamster wrote:
| I think what's most likely to happen here is that: * a
| developer that knew how it worked used it in code where he
| *wanted* to get the first line * someone just starting up
| copied it over and assumed that's the way to get the
| content of command into a variable
|
| It's essentially complaining about using feature wrong on
| purpose, because the person that made mistake never learned
| the language.
|
| my($var1, $var2...) is a way to multi-assign variables from
| an array.
|
| and that makes perfect sense when you look at it. Perl have
| no multiple returns, but if you need a function that
| returns 2 variables it is very easy to make it work with:
| my ($bandwidth, $latency) = speedtest($host)
|
| Perl's feature for returning different type depending on
| caller is definitely a confusing part but
| my @lines = `fortune`
|
| returning lines makes perfect sense for the use case (you
| call external commands to parse its output, and if you do
| that you generally want it in lines, because then you can
| just do foreach my $line (`fortune`) {}
|
| and it "just works".
|
| Now you might ask "why make such shortcuts?". Well, one of
| big mistakes when making Perl is that it was also aimed as
| replacement for sed/awk for the oneliners, so language is
| peppered with "clever short ways to do stuff", and it's a
| pleasure to use in quick ad-hoc oneliners for CLI.... but
| then people try to use same cleverness in the actual code
| and it ends up with the unreadable mess people know Perl
| for.
|
| the fact you can do my ($first_line,
| $second_line, ...) = `fortune`
|
| is just the feature being.... consistent in its use "when
| you give it array, it will fill it with lines from the
| executed command"
|
| you gave it array, and it just did what it does with
| arrays.
| creer wrote:
| What exactly is complex or "super subtle" about this? It's
| the textbook example from the 1st chapter in the tutorial or
| something?
| atherton94027 wrote:
| It's just very non-obvious what the code does when you're
| skimming it.
|
| Especially in a dynamic language like Perl, you wouldn't
| know that you're passing down an integer instead of a
| function until the code blows up in a completely unrelated
| function.
| weare138 wrote:
| Then use one of the type systems for Perl.
|
| https://metacpan.org/pod/Type::Tiny
| creer wrote:
| You can't do that if you gave up at the very first sigil
| puzzle.
|
| I'm fine with that: to program in Perl you need to be
| able to follow manuals, man pages, expert answers, - and
| even perl cookbooks, or CPAN or web searches. It's a
| technical tool. The swiss army chainsaw. It's worth it.
| atherton94027 wrote:
| Seems like you and a few other posters are making the
| article's point - that Perl's culture is hermetic and
| that new programmers would rather learn Python, Ruby or
| Javascript rather than figure out which sigil means what.
| creer wrote:
| I wouldn't call it hermetic in that the many forms of
| documentation are insanely thorough and accessible - if
| not well advertised. There is no gate-keeping (from my
| point of view). New users are welcome. It's easy to learn
| (for the people for whom reading is not an obstacle).
|
| But yes, no contest that the world has been on a
| simplicity binge. Python won by pushing simplicity and by
| having giant software corporations choosing it (and not
| complaining about the line noise nonsense). If you want
| to go into programming professionally, for now many
| years, you need python.
|
| I don't know that I would put Javascript in the same bag.
| I mean, it's the other way: it looks simple and it isn't.
|
| But python, yes, python won because it looks simple and
| google pushed it.
|
| Many other languages now have to reckon with the python
| supremacy. This is not specific to perl / raku. It will
| take work for anything to replace python.
| totallykvothe wrote:
| That's not super subtle any more than it's super subtle that
| "*" performs multiplication and "+" performs addition.
| Sometimes you just need to learn the language.
|
| This is not a general defense of Perl, which _is_ many times
| absolutely unreadable, but this example is perfectly
| comprehensible if you actually are trying to write Perl and
| not superimpose some other language on it.*
| Sammi wrote:
| There's is no fair comparison to be made here with how +
| and * work is most languages, precisely because + and *
| work the same in most languages, while whatever perl is
| doing here is just idiosyncratic.
|
| Even C gets it's fair share of flack for how it overloads *
| to mean three different things! (multiplication, pointer
| declaration, and dereference)
| agumonkey wrote:
| I always found contextual eval interesting. It's a
| generalized version of toString in a way
| petre wrote:
| It's not complexity, it's _magic_. Useful when one cannot be
| bothered to write array.length. So is if (@a) when the array
| is empty.
| eduction wrote:
| I agree and Steve Yegge covered the reasons well here:
| https://sites.google.com/site/steveyegge2/ancient-languages-...
|
| His point about references is no small thing. Other dynamic
| languages don't make users think much about the distinction
| between references and values at the syntax level. With Perl
| you needed to use "->" arrow operator frequently if and only if
| you were using references. So getting at a map inside an array
| or vice versa had its own syntax vs reading a string in a map
| or array.
|
| Also it had bolted on, awkward OO on top of the bolted on,
| awkward params passing. You literally had to shift "self" (or
| "this") off a magical array variable (@_).
|
| By default it wouldn't warn if you tried to read from an
| undeclared variable or tried to use one in a conditional or
| assign from one. You had to declare "use strict;" for that.
| Which wasn't hard! But these awkward things piled up, a bunch
| of small cuts. Don't forget "use warnings;" also, another thing
| to put at the top of every Perl file.
|
| To the extent its awkward syntax came out of aping of shell and
| common Unix cli tools, you could maybe see it as cultural issue
| if you squint.
|
| But any language in the mid 90s was infected with the "rtfm"
| priesthood vibe the author writes about, because the internet
| then was disproportionately populated by those sysop types,
| especially the part that can answer programming language
| questions on usenet, which is basically where you had to ask
| back then.
|
| So for example Rails won for technical reasons, it is much more
| concise with fewer footguns than its Perl equivalents. I was
| actively coding web stuff in Perl when it came along and early
| switched. It wasn't a cultural thing, having choice in Perl was
| fine (and ruby has sadly never grown much culture outside Rails
| - it could really use some). It probably did help that it came
| along in the mid aughts by which time you could ask questions
| on the web instead of Usenet. And it used YouTube for that
| first rails demo. So ruby did end up with a less sysopy culture
| but that had more to do with the timing of its success than the
| success itself.
| dehrmann wrote:
| > bolted on, awkward params passing
|
| Shell had to do this because of shell reasons, like how you
| need spaces where you shouldn't. Perl post-dated C by over a
| decade, so there was no reason for goofy argument unpacking.
| ojosilva wrote:
| Yes there was a reason as Perl took inspiration from Lisp -
| everything is a list- and everyone knows how quick C's
| variadic arguments get nasty.
|
| So @_ was a response to that issue, given Perl was about
| being dynamic and not typed and there were no IDEs or
| linters that would type-check and refactor code based on
| function signatures.
|
| JS had the same issue forever and finally implemented a
| rest/spread operator in ES6. Python had variadic from the
| start but no rest operator until Python3. Perl had
| spread/rest for vargs in the late 80s already. For
| familiarity, Perl chose the @ operator that meant vargs in
| bourne shell in the 70s.
| nine_k wrote:
| Perl is a _great_ language, the way Scala and Haskell are
| great: as openly experimental languages, they tried
| interesting, unorthodox approaches, with varied success. "More
| than one way to do it" is Perl's motto, because of its
| audacious experimentation ethos, I'd say.
|
| Perl is not that _good_ a language though for practical
| purposes. The same way, a breadboard contraption is not what
| you want to ship as your hardware product, but without it, and
| the mistakes made and addressed while tinkering with it, the
| sleek consumer-grade PCB won 't be possible to design.
| pavel_lishin wrote:
| > _" More than one way to do it" is Perl's motto, because of
| its audacious experimentation ethos, I'd say._
|
| Perl lets every developer write Perl in their own
| idiosyncratic way.
|
| And every developer does.
|
| It makes for very un-fun times when I'm having to read a file
| that's been authored by ten developers over ten years, each
| of whom with varying opinions and skill levels.
|
| I guess in 2026, it'll be 11 developers writing it over 11
| years. My sincere apologies to those who come after me, and
| my sincere fuck-you to those who came before me. :)
| creer wrote:
| > in 2026, it'll be 11 developers writing it over 11 years.
|
| Perhaps too, a tool that's been around and in active
| maintenance for 11 years has been wildly successful.
| pavel_lishin wrote:
| I wouldn't say "wildly". I would say that it's critical
| enough to the company's workings that they devote enough
| resources to it to keep it going, but not enough
| resources to consider re-writing it or re-factoring it to
| be easier to work on.
| hinkley wrote:
| Something I only figured out in the '10s is that the main
| tax of code smells is during debugging. Debugging when
| taken to the level of art is less about sorting all of the
| possible causes for a problem by likelihood but by ease of
| validation.
|
| Things that are cheap to check should be checked first
| unless they are really unlikely. You change the numbers
| game from trying to make the biggest cleaving lines
| possible, to smaller bites that can be done rapidly (and
| perhaps more importantly, mentally cheaply).
|
| Code smells chum the waters. Because where there is smoke
| sometimes there is fire, and code smells often hide bugs.
| You get into Tony Hoare's Turing award speech; either no
| bugs are obvious, or there are no obvious bugs.
|
| So I end up making the change easy and then making the easy
| change because we have more code each week so the existing
| code needs to be simpler if someone is going to continue to
| understand the entire thing.
|
| Perl doesn't seem to have figured this out at all.
| nine_k wrote:
| Exactly. Perl is about experimenting, trying things your
| way, and discovering new and good ways to write programs.
| Which is a wonderful capability for research and discovery,
| and for art or recreation, but not that great for
| industrial production.
|
| This is why Perl was quite fit for the job at the dawn, or,
| rather, the detonation phase of the Internet explosion in
| late 1980s and early 1990s, along with Lisp and Smalltalk
| that promote similar DIY wizardry values. But once the
| industry actually appeared and started to mature, more
| teamwork-friendly languages like Java, PHP, and Python
| started to take over.
| hinkley wrote:
| The big pearl of wisdom I took from Larry Wall seemed to be
| counter to the culture I experienced looking in from the
| outside. That always confused me a bit about Perl.
|
| And that was, paraphrased: make the way you want something to
| be used be the most concise way to use it and make the more
| obscure features be wordy.
|
| This could have been the backbone of an entire community but
| they diminished it to code golf.
| athenot wrote:
| In a similar vein, as the industry matured, we went from
| having teams of wizards building products, to teams of "good-
| enough" developers, interchangeable, easy to onboard. Perl
| culture was too much about craft-mastery which ended up being
| at odds with most corporate cultures.
|
| Unfortunately, as a former Perl dev, it makes a lot of other
| environments feel bland. Often more productive yes, but bland
| nonetheless. Of the newer languages, Nim does have that non-
| bland feel. Whether it ends up with significant adoption when
| Rust and Golang are well established is a different story.
| morshu9001 wrote:
| Couldn't they have figured out one decent way to do things
| before releasing features to all users? I tried Scala for a
| bit then decided it was complicated for no good reason.
|
| Idk about Haskell, but I used Erlang which is also purely
| functional. No matter how long I used it and tried to
| appreciate its elegance, it became clear this isn't a
| convenient way to do things generally. But it was designed
| well, unlike Scala.
| jerf wrote:
| Erlang is, by my accounting, not even a functional langauge
| at all. It takes more than just having immutable values to
| be functional, and forcing users to leave varibles as
| immutable was a mistake, which Elixir fixes. Erlang code in
| practice is just imperative code written with immutable
| values, and like a lot of other modern languages,
| occasional callouts to things borrowed from functional
| programming like "map", but it is not a functional language
| in the modern sense.
|
| If you go to learn Haskell, you will find that it has a lot
| to say about functional programming that Erlang did not
| teach you. You will also find that you've already gotten
| over one of the major hurdles to writing Haskell, which is
| writing with immutable values, which significantly reduces
| the difficult of swallowing the entire language at once and
| makes it relatively easier. I know it's a relatively easy
| path because it's the one I took.
| asa400 wrote:
| > Erlang is, by my accounting, not even a functional
| langauge at all.
|
| How do you figure?
|
| The essence of FP is functions of the shape `data ->
| data` rather than `data -> void`, deemphasizing object-
| based identity, and treating functions as first-class
| tools for abstraction. There's enough dynamic FP
| languages at this point to establish that these traits
| are held in common with the static FP languages. Is
| Clojure not an FP language?
|
| > It takes more than just having immutable values to be
| functional, and forcing users to leave varibles as
| immutable was a mistake, which Elixir fixes.
|
| All data in Elixir is immutable. Bindings can be rebound
| but the data the bindings point to remains immutable,
| identical to Erlang.
|
| Elixir just rewrites `x = 1; x = x + 1` to `x1 = 1; x2 =
| x1 + 1`. The immutable value semantics remain, and
| anything that sees `x` in between expressions never has
| its `x` mutated.
|
| > Erlang code in practice is just imperative code written
| with immutable values, and like a lot of other modern
| languages, occasional callouts to things borrowed from
| functional programming like "map", but it is not a
| functional language in the modern sense.
|
| I did a large amount of Scala prior to doing
| Erlang/Elixir and while I had a lot of fun with
| Applicative and Monoid I'm not sure they're the essence
| of FP. Certainly an important piece of the puzzle but not
| the totality.
| dtauzell wrote:
| If you wanted to write a quick on off script then using
| magic variables,etc made sense. Writing something you'll
| keep? Don't use those. When Perl 5 introduced references
| they could have simplified the syntax though.
| eduction wrote:
| Not really. It wasn't audacious in service of anything
| innovative. Haskell takes functional programming to the nth
| degree, scala tried to be an advanced Java for example better
| at concurrency.
|
| Perl was an early dynamic (garbage collected) "scripting
| language" but no more advanced than its contemporary python
| in this regard.
|
| It had the weird sigils due to a poor design choice.
|
| It had the many global cryptic variables and implicit
| variables due to a poor design choice.
|
| It has the weird use of explicit references because of the
| bad design choice to flatten lists within lists to one giant
| list.
|
| It actually was the one thing you said it wasn't - a good
| practical general language at least within web and sysadmin
| worlds. At least until better competitors came along and
| built up library ecosystems.
| Scarblac wrote:
| It could have used a good "Perl: the Good Parts" book.
|
| With a team where everybody wrote it in a similar style, Perl
| did perfectly well. Mod_perl was fast. I liked Perl.
|
| Then Django came out, and then Numpy, and Perl lost. But
| Python is still so incredibly slow....
| creer wrote:
| Mostly - from here - python is so incredibly slow to write.
| Who has this kind of time?
| ipaddr wrote:
| Slow to write, slow to run and throws whitespace errors.
| Surprised it made it so far.
| altairprime wrote:
| Sounds exactly like academia itself, and is probably a
| selling point if you're a business.
| tasty_freeze wrote:
| Check out "Perl Best Practices" by Damien Conway, and the
| more recent "Modern Perl" by Chromatic. Both can be had as
| paperbacks, and I think both are also available free on
| online.
| Klonoar wrote:
| It is not a _great_ language.
|
| It is, however, a _significant_ language. It has left a mark
| and influence on the culture and industry of programming.
| Nothing to sneeze at.
| 0xbadcafebee wrote:
| > it was just not a good language compared to others
|
| I think this was one of those things people just repeated,
| rather than having concrete examples from experience. It's like
| people saying a Toyota Corolla is better than a Honda Civic. Is
| it really? Or are they really just two different forms of the
| same thing? They both get you to the grocery store, they're
| both very reliable, small cheap. Having a preference is not the
| same thing as one actually being superior to the other.
| deafpolygon wrote:
| Perl6/Raku killed Perl.
|
| Python 3 _almost_ killed Python.
|
| It's normal. Once a community loses faith, it's hard to stop them
| from leaving.
| MangoToupe wrote:
| > Python 3 almost killed Python.
|
| People were being crybabies; the critics were extremely vocal
| and few. Python 3 improved the language in every way and the
| tooling to upgrade remains unmatched.
| symbogra wrote:
| Python 3 was a disaster and enterprises were still
| undertaking pointless 2->3 upgrade projects 10 years later
| jordanb wrote:
| It was annoying but if it hadn't happened Python would
| still be struggling with basic things like Unicode.
|
| Organizations struggled with it but they struggle with
| basically every breaking change. I was on the tooling team
| that helped an organization handle the transition of about
| 5 million lines of data science code from python 2.7 to
| 3.2. We also had to handle other breaking changes like
| airflow upgrades, spark 2->3, intel->amd->graviton.
|
| At that scale all those changes are a big deal. Heck even
| the pickle protocol change in Python 3.8 was a big deal for
| us. I wouldn't characterize the python 2->3 transition as a
| significantly bigger deal than some of the others. In many
| ways it was easier because so much hay was made about it
| there was a lot of knowledge and tooling.
| xscott wrote:
| > It was annoying but if it hadn't happened Python would
| still be struggling with basic things like Unicode.
|
| They should've just used Python 2's strings as UTF-8. No
| need to break every existing program, just deprecate and
| discourage the old Python Unicode type. The new Unicode
| type (Python 3's string) is a complicated mess, and
| anyone who thinks it is simple and clean isn't aware of
| what's going on under the hood.
|
| Having your strings be a simple array of bytes, which
| _might_ be UTF-8 or WTF-8, seems to be working out pretty
| well for Go.
| MangoToupe wrote:
| I can't say i've ever thought "wow I wish I had to use
| go's unicode approach". The bytes/str split is the
| cleanest approach of any runtime I've seen.
| JoshTriplett wrote:
| With the benefit of hindsight, though, Python 3 _could_
| have been done as a non-breaking upgrade.
|
| Imagine if the same interpreter supported both Python 3
| and Python 2. Python 3 code could import a Python 2
| module, or vice versa. Codebases could migrate somewhat
| more incrementally. Python 2 code's idea of a "string"
| would be bytes, and python 3's idea of a "string" would
| be unicode, but both _can_ speak the other 's language,
| they just have different names for things, so you can
| migrate.
| MangoToupe wrote:
| > With the benefit of hindsight, though, Python 3 could
| have been done as a non-breaking upgrade.
|
| Not without enormous and unnecessary pain.
| JoshTriplett wrote:
| It would _absolutely_ have been harder. But the pain of
| going that path might potentially have been less than the
| pain of the Python 2 to Python 3 transition. Or,
| possibly, it wouldn 't have been; I'm not claiming the
| tradeoff is _obvious_ even in hindsight here.
| kstrauser wrote:
| That split between bytes and unicode made better code.
| Bytes are what you get from the network. Is it a PNG? A
| paragraph of text? Who knows! But in Python 2, you
| treated them both as the same thing: a series of bytes.
|
| Being more or less forced to decode that series into a
| string of text where appropriate made a huge number of
| bugs vanish. Oops, forget to run
| `value=incoming_data.decode()` before passing incoming
| data to a function that expects a string, not a series of
| bytes? Boom! Thing is, it was _always_ broken, but now it
| 's _visibly_ broken. And there was no more having to
| remember if you 'd already .decode()d a value or whether
| you still needed to, because the end result isn't the
| same datatype anymore. It was so annoying to have an
| internal function in a webserver, and the old sloppiness
| meant that sometimes you were calling it with decoded
| strings and sometimes the raw bytes coming in over the
| wire, so sometimes it processed non-ASCII characters
| incorrectly, and if you tried to fix it by making it
| decode passed-in values, it start started breaking
| previously-working callers. Ugh, what a mess!
|
| I hated the schism for about the first month because it
| broke a lot of my old, crappy code. Well, it didn't
| actually. It just forced me to be aware of my old, crappy
| code, and do the hard, non-automatable work of actually
| fixing it. The end result was far better than what I'd
| started with.
| JoshTriplett wrote:
| That distinction is indeed critical, and I'm not
| suggesting removing that distinction. My point is that
| you could give all those types names, and manage the
| transition by having Python 3 change the defaults (e.g.
| that a string is unicode).
| kstrauser wrote:
| I'm a little confused. That's basically with Python 3
| did, right? In py2, "foo" is a string of bytes, and
| u"foo" is Unicode. In py3, both are Unicode, and bytes()
| is a string of bytes.
| zihotki wrote:
| A month ago I had to fix a small bug in Python 2.6 code in
| one of internal systems. It won't be ever migrated, no
| capacity and no value
| MangoToupe wrote:
| It was not a disaster in any way. People just complained
| about having to do something to upgrade their codebases.
| raverbashing wrote:
| The real problem here was releasing 3.0 as if it was stable,
| when the real usable version was 3.3/3.4
| symbogra wrote:
| Agree 100%. We were told to wait for any improvements or new
| features we wanted and just to wait for Perl 6, which never
| came
| ajross wrote:
| Python 3 couldn't even kill Python 2!
| o11c wrote:
| I'd take this a step further and say that the design flaws that
| _motivated_ Perl6 were what really killed Perl. Perl6 just
| accelerated the timeline.
|
| I do imagine a saner migration could've been done - for
| example, declaring that regexes must not start with a non-
| escaped space and division must be surrounded by space, to fix
| one of the parsing problems - with the usual `use` incremental
| migration.
| Todd wrote:
| Yep. Perl 6 was a wall that Perl 5 would never move beyond.
| It's still Perl 5 25 years later.
| daedrdev wrote:
| I think a big part is does someone starting to program even hear
| that Perl exists? No, and they start learning python and so have
| little need to learn Perl after that
| zahlman wrote:
| That's why it has _stayed_ dead. But that can 't explain how it
| died. People don't just spontaneously stop hearing about the
| existence of a programming language in common use.
| creer wrote:
| Which is (sadly) hilarious because that was the reason most
| people seem to have gone with python: they were told "this is
| what we use here" or they bought the "line noise" nonsense.
| They never put much effort into this.
|
| But I also think that people who are truly interested in
| programming immediately learn that there are many different
| paradigms. And the net makes it dead easy for them to explore
| different directions and, I don't know, fall in love with
| haskell or something. Perl is plenty visible enough for THAT. I
| don't know about perl 6 / raku though.
| jordanb wrote:
| I always found the Perl "community" to be really off-putting with
| all the monk and wizard nonsense. Then there was the whole one-
| liner thing that was all about being clever and obscure.
| Everything about Python came off as being much more serious and
| _normal_ for a young nerd who wasn 't a theater kid.
| simonw wrote:
| This made me smile given Python's love of Monty Python
| references - the cheese shop etc.
| tmp10423288442 wrote:
| I appreciated them at the time I encountered them
| (mid-2000s), but they were definitely a bit cringe in their
| frequency and shamelessness. I wonder if younger people even
| know Monty Python anymore - by my time, I think people had
| mostly forgotten about Hitchhiker's Guide to the Galaxy, even
| if 42 survived.
| edoceo wrote:
| The kids these days have factored 42 to 6,7 (said with some
| inflection and hand waving)
| GPerson wrote:
| Did you come up with that? If so, bravo!
| edoceo wrote:
| 6-7? No, my kid says it about a thousand time a day.
| Then, for some unknown reason they follow it with 41!
| WTF! I've shouted 42! many times and have tried to inform
| the child of the significant cultural and scientific
| importance of 42. Which, IIRC, factors to 2,3,7.
| rightbyte wrote:
| Dude it is not cringe. It is silly.
|
| Pretending to be a all serius grown ups language is cringe.
| sph wrote:
| I agree but don't forget that the average programmer
| nowadays is a strait-laced corporate entity, whose
| personality is Node.js stickers on a macbook, like
| everybody else in their team.
|
| They forget that Perl and co. were written by people that
| had one too many tabs of LSD in the 70s, sporting long
| hair and a ponytail.
| aaronbrethorst wrote:
| I'm going to go out on a limb and guess that Larry Wall,
| a devout evangelical Christian and the child of a pastor,
| was not turning on, tuning in, or dropping out in the
| 1970s.
| culebron21 wrote:
| As a foreigner I hadn't known Monty Python when I started
| learning the language and reading the docs, and I haven't
| noticed any of those. I guess they came across as just
| noise.
| lysace wrote:
| Perl is a sysadmin language. There's "always" been this tension
| between sysadmins and developers.
|
| In my mind (developer back then) I'd amateur-psychoanalyze all
| of that nonsense as some kind of inferiority complex meant to
| preserve the self image. Needless complexity can be a feature!
|
| And now we are all developers!
| MrDarcy wrote:
| In the 2000's Python was also a sysadmin language.
|
| Edit: But I see your point, Google SRE's around the late
| 2000's reached for Python more than Perl.
| lysace wrote:
| (90s) Yes, but it developed.
| calmbonsai wrote:
| As someone who lived through that transition, we used
| Perl extensively to sysadmin ~30 Solaris and Irix
| workstations and it was superlative at that.
|
| At that time, Guido was still working at CNRI locally to
| us in Reston, VA and we had several discussions at the
| local Pyggies (Python User Group) on transitioning over
| to Python for that work. We were a (mostly) C++/Java
| shop, but Perl fit into all the other "crevices"
| beautifully.
|
| Python just didn't have enough library support for all of
| our "swiss-army chainsaw" demands. Still, it was very
| apparent at the time it would eventually get there and I
| was enamored with its "one right way" of doing things--
| even at the bytecode level.
| oncallthrow wrote:
| I think Perl is still more popular even today than Python
| as a sysadmin language. Late 2000s it certainly was. Maybe
| Google was different, but across the industry more widely
| Python was barely used, Perl was used everywhere.
| lysace wrote:
| My experience:
|
| Sysadmin-driven companies (typically Sun-based) often
| used Perl.
|
| Developer-driven companies used other languages running
| on cheaper X86 Linux.
| lo_zamoyski wrote:
| > some kind of inferiority complex meant to preserve the self
| image
|
| Or, as the kids say, a flex, but without the sexy
| connotations.
|
| (Incidentally, I am also reminded of a great quote attributed
| to Morphy:
|
| "The ability to play chess is the sign of a gentleman. The
| ability to play chess well is the sign of a wasted life.")
| chihuahua wrote:
| That quote is not very convincing to me. Both parts of it
| are questionable.
|
| Just being able to play chess is not a very high bar at
| all. Most 6-year-olds can learn it in an hour. Are the
| Chess hustlers at Washington Square Park all Gentlemen?
|
| I don't see being able to play Chess well as any kind of
| deficiency. It could be that it's just someone's hobby. It
| doesn't have to mean they spiraled into madness, Bobby
| Fisher style.
|
| (I can play chess, but not well, so I personally don't care
| about either half of that quote as it applies to me)
| pavel_lishin wrote:
| I'm having to pick up some perl now, and while I don't interact
| with the community, it surely _feels_ like it was written by
| wizards, for wizards. Obscure, non-intuitive oneliners, syntax
| that feels like it was intentionally written to be complicated,
| and a few other things that feel impossible to understand
| without reading the docs. (Before everyone jumps on me - yes,
| as a developer, I should be able to read documentation. And I
| did. But until I did so, what the code was doing was completely
| opaque to me. That feels like bad language design.)
|
| Some of it I recognize as being an artefact of the time, when
| conciseness really mattered. But it's still obnoxious in 2025.
|
| The whole thing reminds me of D&D, which is full of classes &
| spells that only exist in modern D&D because of One Guy who
| happened to be at the table with Gygax, who really wanted to be
| a wuxia guy he saw in a movie, or because he really wanted a
| spell to be applicable for that one night at the table, and now
| it's hard-coded into the game.
| phil21 wrote:
| It's interesting to me how brains work.
|
| Perl has always "flowed" for me and made mostly intuitive
| sense. Every other language I've had to hack on to get
| something done is a struggle for me to fit into some rigid-
| feeling mental box.
|
| I understand I'm the weird one, but man I miss Perl being an
| acceptable language to pound out a quick program in between
| "bash script" and "real developer".
| pavel_lishin wrote:
| Was Perl one of your first languages by any chance? I
| freely admit that I've only been poking at it for a few
| months; maybe by this time next year, I'll be boggled at
| the comment I left, like it was written by a different
| person.
|
| > _in between "bash script" and "real developer"._
|
| One of my coworkers gave me some great perspective by
| saying, "at least it's not written in Bash!"
| phil21 wrote:
| Yep, first language I learned. And since I was somewhat
| early to the Internet thing, I found IRC when I was about
| 14 years old and actually learned from a lot of the folks
| who have authored books on Perl or are at least (were)
| well known in the community.
|
| It certainly was the major factor in how I connected the
| dots!
|
| Haven't really thought about it until now, but I suppose
| having Larry Wall and Randal Schwartz telling you to RTFM
| guides your early development in a certain manner.
|
| I certainly have never considered myself a developer or
| programmer though. I can pick up enough syntax to get a
| quick hack done or start a MVP to demo my ideas, but I
| leave the "big boy" dev stuff to the professionals who
| can run circles around me.
| alsetmusic wrote:
| Not the person you replied to, but I thought the same
| thing. Perl was my first as well, and it certainly shaped
| the way I think about coding. It made Python feel too
| rigid and Ruby feel familiar. There's something to be
| said for the restrictions of an environment when you're
| learning how to operate in a domain that seems to shape
| future thinking.
|
| I'm sure there are people who started in a language and
| later found something that made more sense. I'm just
| reflecting on what I've found in my experience.
| asa400 wrote:
| > One of my coworkers gave me some great perspective by
| saying, "at least it's not written in Bash!"
|
| I wish bash was the thing that was dying. As an industry,
| we need to make better choices.
| skywhopper wrote:
| There's nothing that can replace bash for what it does.
| People have been trying for decades. You'll be happier if
| you accept that bash can and will happily coexist with
| anything and everything else, which is exactly why it
| will never go away.
| skydhash wrote:
| CLI usage revolves around text and bash is a meta layer
| above that. Given curl, jq, and awk, you can create a
| quick MVP client for almost any api. Doing the same in
| Python and Go is much more involved.
| altairprime wrote:
| > _Some of it I recognize as being an artefact of the time,
| when conciseness really mattered_
|
| It was an artefact of bursting out of those constraints, but
| honoring them still. The roots of perl as a "more capable,
| less restrictive" sed/awk means that it _must_ support `perl
| -pi.bak -e oneliner file`, just like sed did -- and so from
| that core requirement forward, everything it did, _does_. By
| the heyday of Perl5 era, conciseness was not a requirement,
| but the sed-compat roots remained a focus of the language's
| creator.
| petre wrote:
| Yup, Perl is something clearly out of Unseen University, err
| I mean Berkeley linguistics dept.
|
| I liked it, thought the sigils were a cute way to singal that
| something is a variable. When you work with deeply nested
| data structures, dereferencing arrays and hashes that sort of
| changes and becomes kind of annoying. Nowadays I like Ruby.
| Compared to it, Perl does feel like spells mixed with C and
| Posix stuff. But if I want to feel smart, I'll write some
| code in Scheme, thank you.
| tasty_freeze wrote:
| It isn't bad language design that you need to study the
| language before you can use it. I look at haskell programs
| and it looks mysterious to me because I haven't spent any
| time studying it, but I'd not thing to say it is bad language
| design.
|
| Yes, one can write obscure perl code and some love perl
| golfing. In the same way there is an IOCCC which delights in
| unreadable code, it doesn't mean that the C language should
| be relegated to the dustbin. The answer is to write readable
| code, no matter which language is in use.
| harpiaharpyja wrote:
| Seems like the essential criteria is not whether you can
| write opaque code in it, but rather whether the language
| enables you to accomplish most tasks using clear, readable
| code. They aren't mutually exclusive.
|
| Hopefully I am paraphrasing you correctly.
| pavel_lishin wrote:
| But I can look at most Python code and be able to
| understand what it does. With perl, I have to look up so
| much.
|
| - Why is there a `1;` on a single line in the middle of
| this file?
|
| - What is `$_`?
|
| - This parallel execution manager doesn't actually seem to
| define what code needs to run in parallel in any specific
| way, how does this work?
|
| - What is this BEGIN block at the start of this Perl file?
| Why is that necessary?
|
| - What's going on with qx, qw, qq?
|
| - What does chomp do when it's just on its own line, with
| no arguments given to it?
| tasty_freeze wrote:
| Again: python syntax is more akin to what you are used
| to, and so it feels more comfortable to you.
|
| $_ is inscrutable if you haven't studied perl, but the
| same thing would happen to anyone who sees a python
| decorator for the first time. what does "else: do after a
| while loop in python? Only people who know python know
| what it does (and I suspect most don't). The different
| quoting operators are also trivial to learn. In
| comparison, yield from python is also simple syntax but
| the semantics are much more involved.
|
| BEGIN? Take 60 seconds to read what it means. And if you
| knew awk, you'd not have to do that, as it was directly
| lifted from awk.
| skywhopper wrote:
| Given python's love for string-leading sigils, the
| previous commenter should be quite comfortable with the
| idea of obscure single-letter operators that dictate the
| interpretation of the following tokens.
| montroser wrote:
| Yeah, it's true that Perl did not have as a design goal
| that a complete newcomer should be able to intuitively
| understand the code without having any prior exposure to
| the language. There _is_ a little bit of a learning
| curve, and that was completely expected by Perl 's
| creators. Yes, you have to learn about the idioms above,
| but they became second-nature. For many of us, the model
| clicked in our heads and the terseness was worth it. You
| could express a lot of functionality in very few
| characters, and if you had invested in learning, it was
| very quick to grok because common patterns were reduced
| to familiar abstractions in the language.
|
| And yet, as the industry grew and all sorts of people
| from all sorts of backgrounds converged in this space,
| the tolerance and appetite for funky/terse waned in favor
| of explicit/verbose/accessible. It's probably for the
| better in the end, but it did feel a little bit like the
| mom-and-pop store on the corner that had weird pickled
| things at the register and a meemaw in the back got
| replaced by a generic Circle K with a lesser soul.
| asa400 wrote:
| > And yet, as the industry grew and all sorts of people
| from all sorts of backgrounds converged in this space,
| the tolerance and appetite for funky/terse waned in favor
| of explicit/verbose/accessible. It's probably for the
| better in the end, but it did feel a little bit like the
| mom-and-pop store on the corner that had weird pickled
| things at the register and a meemaw in the back got
| replaced by a generic Circle K with a lesser soul.
|
| This is an amazing point that I haven't seen anyone else
| make about languages in this way.
|
| As someone who got into the industry right after Perl's
| heyday and never learned or used it but learned
| programming from some former Perl power users, Perl has a
| pre-corporate/anarchic/punk feel about it that is
| completely opposite to something like Golang that feels
| like it was developed by a corporation, for a
| corporation. Perl is wacky, but it feels alive (the
| language itself, if not the community). By contrast,
| Golang feels dead, soulless.
| EgregiousCube wrote:
| Honestly, $_ and "what does a function do when I don't
| supply any arguments?" are really nice in Perl, and not
| that difficult to understand. I think a lot of languages
| could use a 'default variable'.
| skywhopper wrote:
| You're mad that you have to look up what keywords do in a
| programming language you aren't familiar with? If you
| think Python is always clear, I can guarantee you (as
| someone with relatively expert grasp of Bash, Ruby, Go,
| and once long ago, Perl) that no, it isn't always
| obvious.
| lo_zamoyski wrote:
| The term "surrogate activity" comes to mind, specifically,
| activities of no real value that some people like to waste
| time on to feel better about themselves.
| Insanity wrote:
| I don't know about the wider Perl community, but I listened to
| some interviews from Larry Wall and he just came across as a
| nerdy guy having fun with what he's doing. I quite liked
| listening to him.
| c0brac0bra wrote:
| My anecdotal experience was with perl guys who were ex-
| military, irreverent, and fly-by-the-seat-of-your-pants. The
| Java and .NET guys were straight laced and nerdy.
| riffraff wrote:
| I was never a perl programmer, but this was my impression of
| basically every perl programmer I have interacted with.
|
| Also, I think Larry Wall's "Diligence, Patience, Humility"[0]
| is among my favourite articles about programming.
|
| [0]
| https://www.oreilly.com/openbook/opensources/book/larry.html
| ascendantlogic wrote:
| Individuals are rarely (not never, but rarely) the full
| problem. Groups of people are what cause feedback loops and
| cultural reinforcement like the author describes. Sometimes
| this is a virtuous reinforcement cycle but more often than
| not the well gets poisoned over time.
| ErikCorry wrote:
| Larry should be remembered for the development of "patch"
| more than perl. Without the concept of fuzzily applying
| patches to modified source files you can't have "git rebase"
| or "git merge".
| PunchyHamster wrote:
| Perl made a mistake, the language was invested in depth of
| expression and that, in a programming language, just leads to a
| 1000 ways to write same thing where like... 2 of them are
| actually nice to read.
|
| Pyton was ("was" was used here on purpose) the opposite, the
| whole "one way to do a thing" and insisting on more clean code
| even if more verbose.
|
| You could write nice looking Perl code but you had to _choose_
| to do it, while Python pushed you in that direction from the
| start.
|
| As much as I dislike using whitespace as flow control it also
| does make sure the code is always indented reasonably even if
| it is a newbie just starting in the language.
|
| It didn't help that Perl, just like other languages after (PHP,
| JS, Python too), had a "curse of the newbie language", with
| many people starting with it (as at the time it was kinda only
| sensible choice for webpages before mod_php did a revolution in
| how most webpages are hosted), with no training and just
| winging it, which in language that puts no limits on what user
| can do and no guidance on what they _should do_... leads to
| that ugly one liners and line noise as a code scripts.
| skywhopper wrote:
| That is the story that Python tells about itself. Meanwhile,
| folks who don't use it every day are constantly learning that
| it's only true within a single version of Python, but that
| over the years there will be multiple, incompatible ways to
| do niche wild rare stuff like ... iterating over a map.
| OptionOfT wrote:
| I actually think it works when you are in the ecosystem
| fulltime for a good while.
|
| But having to interact with it once in a while is always a
| hurdle. The same with bash. Do I use [ or [[? Where does the
| semi-colon go? if then fi, but while do done (and not elihw).
| -eq or =? Functions have () but no parameters.
|
| I'm sure those things make sense when all you write is Bash /
| Perl, but it's daunting.
|
| Now, Python can get pretty far out there too with Meta-
| programming, and JavaScript can get confusing with prototyping.
| And Ruby (especially RoR) takes the crown, where they resolve
| variables at the moment the line executes. Makes debugging
| blocks really hard.
|
| The less magic in code the better.
| skywhopper wrote:
| You realize you can learn all of this easily online, I hope?
| Sure it turns out that a scripting language maintaining
| compatibility with scripts from 40+ years ago has some
| confusing aspects. That's the price of such incredible
| staying power.
| ErikCorry wrote:
| The syntax problems are just surface. There are some real
| problems underneath:
|
| Poor performance of the single implementation.
|
| A single implementation.
|
| Leaky ref counted GC, but 'luckily' the syntax for references
| is so clunky that nobody does anything complicated enough that
| it really matters.
|
| Bolted on object oriented features that never got the love they
| needed at a time when oo languages were sweeping the world.
|
| Most of the wizards decamping to a new language (Perl6) that
| was 'developed' for years without an actual implementation to
| keep them grounded.
| mr_toad wrote:
| > 'luckily' the syntax for references is so clunky that
| nobody does anything complicated enough that it really
| matters.
|
| That made me laugh. Unlike actually working with Perl
| references, which made me want to cry.
| Asooka wrote:
| I never interacted with any of that, to me Perl was always
| "Bash with text processing built-in and no string interpolation
| pitfalls". I reach for it when I need to write one to two page
| long utility scripts. Python is too willing to deprecate
| features (plus the whole 2 to 3 fiasco burned me badly), so I
| only use it for things I know I will maintain. Perl is for
| writing a shell script that will run unchanged in perpetuity.
| baxtr wrote:
| I loved Perl and all the obscurity. It felt like black magic
| back then. It should have become what python is today.
| librasteve wrote:
| actually Perl was what Python is today - the go to scripting
| language
| ahartmetz wrote:
| I've always found Perl just plain ugly, too clever about some
| things (like iterating over regex matches on stdin or
| something) and really dumb about other things (variable syntax,
| the god-awful OOP system). Python is clean and pretty in
| comparison and usually well thought out. If the communities
| were reversed, I'd still prefer Python: I just read the
| documentation in 99% of cases, I very rarely need to interact
| with the community. Python, as the article says, is mostly not
| a language for fans - it's mostly for auxiliary tasks.
| librasteve wrote:
| > Perl has always "flowed" for me and made mostly intuitive
| sense. Every other language I've had to hack on to get
| something done is a struggle for me to fit into some rigid-
| feeling mental box
|
| That is just how I felt about Perl (4 years full time dev in
| the 2000s) and how I now feel about https://raku.org (aka
| Perl6). Anyway, I tried to gather some fellow feelings here
| about 18 months ago:
|
| https://rakujourney.wordpress.com/2024/05/22/perl-love-notes...
|
| It is sad that Perl became so despised after the error of
| preannouncing a non-compatible upgrade. I understand that
| people couldn't wait. But Raku is here now and it is worth a
| second look imo.
| lamontcg wrote:
| > I always found the Perl "community" to be really off-putting
| with all the monk and wizard nonsense.
|
| Rubyists vs. Pythonistas isn't any better.
|
| Programming languages as counter-cultural lifestyle choices is
| pretty "cringe" as the kids say.
| overfeed wrote:
| > I always found the Perl "community" to be really off-putting
| with all the monk and wizard nonsense
|
| The Perl community introduced the world to the first language
| module repositories via CPAN. No more manually hunting down
| tarballs off FTP servers
|
| As a language, Perl is extremely expressive, which is amazing
| for one-off scripts, and awful for code that's meant to be
| shared and/or reread. For pure text-munging, Perl is still
| unbeaten, when using Perl-Compatible regexes in other
| languages, I feel the language getting in my way.
|
| You can write easy-to-read Perl (TIMTOWTDI, and all that), but
| it doesn't force you like Go (small language size) or Python
| (by convention and culture, on what counts as 'Pythonic')
| RayFrankenstein wrote:
| There was a lot of pressure in the Perl community to write things
| as succinctly as possible instead of as maintainably and
| understandably. That's not realistic for use in a field with a
| lot of turnover and job hopping.
| chrisweekly wrote:
| Yeah the joke was, Perl is write-only.
| superkuh wrote:
| Write-only perhaps, but with perl you only have to write it
| once and it'll run forever, _anywhere_. No breaking on
| updates, no containers, no special version of Perl just for
| $application, just the system perl.
|
| Because of this, in practice, the amount of system
| administration mantainence and care needed for perl programs
| is far, far less than other languages like python where you
| actually do have to go in and re-write it all the time due to
| dep hell and rapid changes/improvements to the language. For
| corporate application use cases these re-writes are happening
| anyway all the time so it doesn't matter. But for system
| administration it's a significant difference.
| pjc50 wrote:
| There was really only one big forced rewrite, 2->3, and
| ironically Perl was killed by failure to do the same with
| 5->6.
|
| I agree that python versioning and especially library
| packaging is the worst part of the language, though.
| chrisweekly wrote:
| Agreed! My father (RIP) absolutely loved Perl and could do
| amazing things with it in seemingly impossibly-few
| characters. I got reasonably proficient w/ regex but never
| came close to his wizardry. Much respect for those in his
| rarified company.
| JackSlateur wrote:
| Aren't perl modules locked to the exact version they were
| compiled in ?
|
| I've met many time some error "haha nope, wrong version,
| perl 5.31.7 required"
| creer wrote:
| There was no such pressure. That's ridiculous. There were a lot
| of things people could grab as reasons to form an opinion
| without even reading articles, never mind the tutorial. They
| then ended up with php or python, even java for crying out
| loud, and years later THAT was a problem.
| Supermancho wrote:
| > There was no such pressure. That's ridiculous.
|
| I lived it. I'm sure there's still some Mailing List archives
| and IRC snippets that still endure, demonstrating the utter
| vicious 1-upmanship of how to do something in Perl as
| succinctly as possible. Why do X and Y when you can just do
| Z? What are you really trying to do? etc.
| creer wrote:
| You COULD, if you wanted, and spent quite a bit of effort
| in the pursuit of that hobby, participate in one-liner, or
| obfuscation, or golfing friendly contests. Which were
| enabled by perl's expressiveness constructs. Nobody pushed
| anyone into that. On the contrary "there is more than one
| way to do it" was there to legitimize that getting the
| problem solved was the goal - instead of trying to force a
| one true way (like python).
|
| After that, experts would often propose multiple ways to do
| something when they answered questions. THEY found that
| intellectually playful and exciting. They still do. And for
| the rest of us, that was an amazing way to learn more and
| understand more of that tool we were using daily. Still is.
|
| You apparently saw viciousness in this and that certainly
| sucks.
| altairprime wrote:
| Those experts were horrendously vicious. I can name them
| and can still describe their dismissive cruelty, since I
| spent ten years socializing nonstop in the Perl5 core
| communities (and have a CPAN id, and have an Authors
| entry in Perl5 core). Think "Linus before he learned to
| stop insulting people's worth and focus on critiquing
| their work instead". It was absolutely intended as a form
| of cultural propagation: I can do this more succinctly,
| so You Should Be Ashamed Before Me. If somehow you
| weren't exposed to that aspect of it, I envy you.
|
| Interestingly, that same prideful "my way is so obviously
| better that it's a ridiculous waste of my time
| considering yours" ended up carrying forward to Mozilla,
| which was launched in part by cultural exports of the
| Perl5 conservative-libertarian community, and for a
| decade developer hiring was filtered for cultural
| sameness, leaving a forest of TMTOWTDI trees that viewed
| meadows as an aberration to be reforested back to their
| sameness.
| creer wrote:
| You indeed ran into toxic environments. I don't feel that
| the common, new perl programmer intake path was anything
| like that. Not what I ever ran into.
|
| Support in forums and such was needlessly short in using
| RTFM as an answer. People could have pasted a one
| paragraph pointer to the documentation intake path and
| that would have helped.
| altairprime wrote:
| It was EFnet/#perl which included most of the core
| development team. I don't really have experience with the
| non-core social environment, sorry.
| autoexec wrote:
| There wasn't pressure to write concise code exactly, but if
| you posted your code somewhere the odds were good that
| somebody would reply with a way to do the same thing with
| less code, followed by someone else who managed to shave
| several lines/characters off of that, etc.
|
| While almost all of the time it was all just people having
| fun (perl is fun and play was encouraged) and not an
| admonishment of the code you'd posted or an example of how it
| should have been written I can see how some folks might have
| gotten that impression. Especially if they were new to perl
| and were more used to languages where TIMTOWTDI wasn't thing
| syncsynchalt wrote:
| Code golfing originated in perl.
|
| There was strong cultural pressure to be able to write perl
| in as few bytes as possible, ideally as a CLI one-liner.
| Books[1] were written on the topic.
|
| https://www.thriftbooks.com/w/perl-one-
| liners-130-programs-t...
| IshKebab wrote:
| Nah Perl just wasn't a very good language. Not every language is
| equally good.
| lysace wrote:
| Careful, we are not allowed to say such things.
| DonHopkins wrote:
| We don't have to say such things, because the syntactic sirup
| of ipecac and sputtering line noise of perl code speaks for
| itself.
| IshKebab wrote:
| Clearly not loudly enough - look at all the people here
| searching for some mysterious cultural reason it failed.
| zahlman wrote:
| Ironically alluding to the possibility of others who would
| castigate you for saying something reasonable things, is not
| any less obnoxious than the castigation.
| tguvot wrote:
| I spent year developing CMS in Perl in 1999 (HTA application with
| ActivePerl. wonder if anybody else did something like this). It
| traumatized me, and first thing that I did in my next job is to
| learn python and develop some core systems in it. Few of my
| friends moved from perl to python as well.
|
| I still remember spending time with my coworkers on bench outside
| of building trying to figure out #@$%$^&$%@something =
| []sd[dsd]@$#!&lala lines written by previous developers
| tsak wrote:
| Before I eventually switched to PHP, I ended up writing
| multiple CMS-like solutions that would run via `cgi-bin` but
| write contents to the webroot (what we would now call a static
| site generator). As I was quite limited with the standard
| shared hosting at the time, I ended up inventing my own single
| file database format (it was a simple text file) to keep state.
| It worked quite beautifully and kept me afloat for the first
| few years of my life as a web developer around the early 2000s.
|
| I was aware of ActivePerl and quite liked Komodo. Thankfully I
| could keep myself from doing things on Windows/IIS apart from a
| brief stint writing a single file CMS in ASP.
| tguvot wrote:
| I wrote php2 + msql before starting in that company (and a
| bit of php3). Like in your case it was essentially static
| site generator but the management part was HTA (application
| hosted in internet explorer. you could write one using
| whatever activex/language: vbscript, python, perl).
|
| as backend we had oracle. at first we tried oracle/linux
| (just released). but we never managed make it work (oracle
| engineers that came to us failed as well). So we got
| dedicated sun server for it.
|
| One day I was bored, installed mysql on my workstation, made
| a changes in couple of queries and all of sudden i got x20
| performance of sun box with oracle. Lead developer said that
| it's bad solution as mysql doesn't properly supports
| referential integrity (we didn't actually used it in oracle
| iirc)
| eduction wrote:
| Perl heads are downvoting you but I agree as a longtime ex Perl
| user that the sigils were noisy nonsense.
|
| The original intent was you could see var types with them -
| $scalar, @array, %hash.
|
| They immediately broke this by deciding the sigil would apply
| to the value /extracted/ from the data structure. So you
| declared array @foo but accessed an element as $foo[1]. What?
| There's a logic there but already you're violating many
| people's expectations so why even have them. The sigils are now
| confusing many people instead of clarifying anything.
|
| The sigil idea then /completely/ failed when they introduced
| references and "complex data structures" (nesting arrays within
| arrays like every other language - in Perl this was a special
| thing because they had been flattening lists by default so no
| way to put one inside another).
|
| So now to get at a hash in a hash you used not % but $ since a
| reference is a scalar. $hash1->$hash2->{"key"}. Versus
| $hash3{"key"} for a simple hash. Just awful noisy syntax. Due
| to poor language design up front.
| eduction wrote:
| Oops last example should be $hash1->{"hash2"} - this is a
| whole hash referenced with $ because of the implementation
| detail that it is in hash1 as a reference, which is
| considered a scalar.
|
| Technically you are allowed to use % like so:
| %{$hash1->{"hash2"}}. Which, just - lol.
| tguvot wrote:
| Before that job in perl i wrote asm/tcl/delphi/c/php (and
| bunch of other languages after).
|
| This perl syntax caused some kind of rejection on almost
| physical level. It was same for many of my friends. "Zen of
| python" was a breath of fresh air.
| nagaiaida wrote:
| and people wonder why raku had so many things it needed to
| change to free the excellent core of the language and its
| ideas
| kstrauser wrote:
| That last paragraph got me off Perl to Python. The first time
| I wrote Python like hash1[hash2]["key"] and it worked, then
| tried hash1[hash2]["array_name"][3] and it worked because
| that's the obvious way to write something, I fell in love and
| never looked back.
|
| I never wanted to have to reason my way through chasing
| pointers through nested hashrefs again.
| kstrauser wrote:
| Yesterday I used `pwgen` to role a random password, and at
| first glance I legit thought it might've been working Perl
| code. I'm not even slightly kidding.
| calmbonsai wrote:
| No. Perl died because other languages starting having an
| equivalent to CPAN and its extremely flexible syntax does not
| scale for medium to large team coordination.
| altairprime wrote:
| It does if you restrict flexibility, but one of the critical
| flaws in Perl culture was the belief in letting everyone evolve
| in different directions while cooperating. It's a genuinely
| charming belief, but it's also explicitly incompatible with
| 'interchangeable parts' employment, and tends to only work in
| an environment where every individual is the 'wizard' lord of
| their personal domain over code. Even if you managed to train
| everyone to parse Perl, the cognitive overhead of having to
| train everyone in each other's syntactic decisions was O(2^n)
| expensive, which contrasted quite sharply with Python moving
| that expensive cognitive overhead to the Proposals system while
| the produced language had slow version updates and "What we
| argued about so you don't have to retread the same ground at
| work every quarter" mission briefs.
| dc396 wrote:
| I was a fairly heavy user of Perl, but eventually migrated to
| Python. The primary reason was the generally abysmal quality of
| what was in CPAN compared to what was available as third-party
| packages for Python. I found myself having to spend way too much
| time fixing stuff I pulled down from CPAN far more than I'd need
| to for Python for the same functionality. Undoubtedly Perl stuff
| got better, but I didn't have time to wait.
| dunham wrote:
| I mainly moved on to Python because the startup time for
| scripts seemed to be a lot worse for Perl. I was a heavy Perl
| user in the 90's and early 2000's.
| webdevver wrote:
| i disagree, python is Just Better. ive never used perl but ive
| had to install it due to some antique tools requiring it, and
| every time its been an incomprehensible mess. i still have no
| idea how packages work in perl. also, it seems like everything in
| perl is a string? and the syntax looks like a mess.
|
| maybe its painful for guys to admit that languages could be a lot
| better designed, and when such langauges appeared, everyone
| flocked to them.
| oncallthrow wrote:
| > also, it seems like everything in perl is a string?
|
| It's actually somehow even worse than this. The Perl type
| system is honestly ridiculous. Most veteran Perl developers
| don't fully understand it.
|
| https://blogs.perl.org/users/leon_timmermans/2025/02/a-deep-...
| is a good introduction.
| streptomycin wrote:
| For me it wasn't cultural.
|
| Perl was my first language because I wanted to make interactive
| websites and that was the most common way to do it in the late
| 90s. Shortly after, everyone switched to PHP because mod_php was
| much faster than Perl CGI scripts.
| bufordtwain wrote:
| I thought its decline was due to Perl's confusing syntax. That's
| what caused me to move away from it anyway.
| buescher wrote:
| I never really warmed to perl in its era but perl dbi was kind of
| perfect in its way. If you needed what it could do, it got very
| intuitive very fast, and was pretty terse. Both of which were
| supposedly the appeal of perl.
| js2 wrote:
| Perl died for many reasons. For me, it was a language that was
| always too tempting to be too clever by half. I'd been using Perl
| pretty significantly from 1995-2000 (perl4 to perl5) when I was
| introduced to Python (1.5.2)[^1]. I greatly appreciated its
| simplicity, zen, batteries included standard lib, and REPL. I
| found add on packages easier to install than dealing with CPAN. I
| switched to Python and basically never looked back.
|
| [^1]: https://news.ycombinator.com/item?id=44790671
| notepad0x90 wrote:
| I didn't like cpan and python was just easier and available, if
| python didn't exist I'd like to think I'd have invested heavily
| in perl because it was everywhere at some point.
| mschuster91 wrote:
| I don't get why Ruby is mentioned before PHP. The _only_ Ruby
| thing I 've ever come across is GitLab, and not with positive
| associations either - up until maybe 3, 4 years ago particularly
| Sidekiq was a constant point of utter pain.
| cwyers wrote:
| I was surprised by that, too, and assumed it was a decade-old
| article until I saw the date at the bottom. Both being
| mentioned before Python is wilder, as is the total exclusion of
| JavaScript.
| mschuster91 wrote:
| JavaScript on the backend is a rare thing to see, even in
| "resume driven development" scenarios it's usually some sort
| of static build that gets pushed to S3 or whatever.
| DonHopkins wrote:
| Are you time traveling from 1998, when AOL acquired
| Netscape and sidelined Livewire?
| cwyers wrote:
| Node.js is the most popular web framework/technology in the
| StackOverflow developer survey. Express is more popular
| than FastAPI, Django, Flask and Rails in the same survey.
| Just... what are you talking about?
| sammy2255 wrote:
| I don't understand how Perl fell off and PHP didn't
| dbalatero wrote:
| I think PHP is way more accessible syntactically, even with all
| the standard complaints about the language. In the early 2000s
| it felt like "simple C style function calls embedded in HTML
| templates" more or less. Not much to have to teach there.
|
| And serving it tends to be "copy the files to your web server's
| public dir".
| inglor_cz wrote:
| PHP is, at least for me, way, way more readable. Similar enough
| to Java that you don't have to re-learn syntax too much.
| wvenable wrote:
| Perl is a very difficult language. PHP was a comparatively
| simple language. PHP was just a scripting language for C and
| incorporated as many open source C libraries as possible back
| when open source libraries were a bit of disjointed mess.
|
| PHP's success and Perl's decline was obvious at the time.
| getnormality wrote:
| The lede says Perl died because it was "reactionary" and
| "culturally conservative", but the content says Perl died because
| it had _bad_ culture, the culture of angry, socially corrosive
| anonymous internet commenters.
|
| If Perl had had a _good_ culture, then conserving it would have
| been good!
| Juliate wrote:
| A good culture, as time goes, is not reactionary and
| conservative, if only because it opens itself to the
| contribution of the younger generations.
| lemonwaterlime wrote:
| Rather than its "decline was", Perl's _existence is_ cultural.
| All programming languages (or any thought tools) are reflections
| and projections of the cognitive values of the community who
| creates and maintains them. In short, the Perl language shares
| the structure of the typical Perl dev 's mind.
|
| A shift to Python or Ruby is fundamentally a shift to a different
| set of core cognitive patterns. This influences how problems are
| solved and how sense is made of the world, with the programming
| languages being tools to facilitate and, more often than not,
| shepherd thought processes.
|
| The culture shift we have seen with corporations and socialized
| practices for collaboration, coding conventions, and more
| coincides with the decline of a language that does in fact have a
| culture that demands you RTFM. Now, the dominant culture in tech
| is one that either centralizes solutions to extract and rent seek
| or that pretends that complexity and nuance does not exist so as
| to move as quickly as possible, externalizing the consequences
| until later.
|
| If you've been on this forum for a while, what I am saying should
| seem familiar, because the foundations have already been laid out
| in "The Pervert's Guide to Computer Programming", which applies
| Lacanian psychoanalysis to cognitive patterns present in various
| languages[1][2]. This explains the so-called decline of Perl--
| many people still quietly use it in the background. It also
| explains the conflict between Rust and C culture.
|
| As an aside, I created a tool that can use this analysis to help
| companies hire devs even if they use unorthodox languages like
| Zig or Nim. I also briefly explored exposing it as a SaaS to help
| HR make sense of this (since most HR generalists don't code and
| so have to go with their gut on interviews, which requires them
| to repeat what they have already seen). With that stated, I don't
| believe there is a large enough market for such a tool in this
| hiring economy. I could be wrong.
|
| [1] [PDF] -- "The Pervert's Guide to Computer Programming"
| https://s3-us-west-2.amazonaws.com/vulk-blog/ThePervertsGuid...
|
| [2] [YouTube Vulc Coop]--
| https://www.youtube.com/watch?v=mZyvIHYn2zk
| diegof79 wrote:
| There is no doubt that a product's community culture and the
| maintainer's attitude have a significant influence.
|
| However, I used Perl and stopped using it without knowing
| anything about its internal politics or community. PHP, ASP, Java
| JSP and later Rails were much better than Perl for web
| development.
|
| * I know that for some the mention of JSP will be rare, as it was
| ugly... However in the 2000s it was the state of the art
| hinkley wrote:
| > if difficulty itself becomes a badge of honour, you've created
| a trap: anything that makes the system more approachable starts
| to feel like it's cheapening what you achieved. You become
| invested in preserving the barriers you overcame.
|
| The mentality described here has always galled me. Half the
| reason I'm willing to scramble up these hills is to gain the
| perspective to look for an easier way up the next time. It's my
| reward for slogging through, not for the gathering of sycophants.
|
| I'm not sure you've mastered a thing until you've changed the
| recipe to make it a little bit better anyway. My favorite pumpkin
| pie recipe, isn't. As written the order of operation creates
| clumps, which can only be cured with an electric mixer. You
| shouldn't need an electric mixer to mix pumpkin pie filling. If
| you mix all the dry ingredients first, you get no clumps. And
| it's too soupy. Needs jumbo eggs, not large. So _that_ is my
| favorite recipe.
|
| But maybe this is why I end up writing so many tools and so much
| documentation, instead of hoarding.
| Emen15 wrote:
| Perl 5's non-breaking conservatism kept old scripts running
| forever, but it also meant there was never a clear migration path
| the way Python 3 eventually provided, and that made long term
| planning a lot harder.
| twoodfin wrote:
| Perl did have `use strict`, so there was at least some
| plausible path to making non-breaking changes under a new
| pragma.
|
| The OP's theory that Perl 6's radicalism allowed Perl 5 to be
| conservative sounds right to me.
| syklemil wrote:
| Though at the same time the bit where `use strict` was
| optional wound up being off-putting to a lot of us, at least
| in part because we'd always wind up with _something_ that
| wasn't designed for `use strict` and had, uh, interesting
| failure modes.
|
| It's the same drive that we see from JS to TS these days, or
| adding type hints to Python, and even to some extent why
| people pick up Rust: because you get a refusal to act and an
| explanation rather than wonky results when you goof.
|
| IME there's been a wider shift away from worse-is-better, and
| Perl was kind of one of the early casualties of that. Part of
| that is also how science has marched on: When Python and Perl
| were new, the most popular typed languages were kind of
| tedious but not what people would consider _good_ at types
| these days. Perl was the first language I learned, and if I
| was transported back to the 1990s, I'd probably still pick
| it, even if I don't use it in 2025.
|
| (OK, maybe I'd go all in on OCaml. Any way the camel wins.)
| neuroelectron wrote:
| Perl being so old means it's extremely fast for what it's
| designed to do, process streams or pipes. In a few tasks, it's
| faster than C, but being much faster to create a script or
| program that is useful, and with the implicit syntactic sugar,
| and since it's so flexible, you can just do things in the one way
| you know how and that's usually good enough.
|
| Python is pretty good too for this and because modern computers
| are so fast it doesn't matter that it's much slower than perl,
| but if you're doing something like processing terabytes of files,
| it's probably worth your time to find or vibe code a one-liner in
| perl and torture it into working for your task.
| autoexec wrote:
| Perl is amazing when it comes to regular expressions too. It's
| one of the reasons why perl is way more fun to write than
| Python. I still use perl for regex heavy tasks. I wish that
| python had integrated regex into the language the same way.
| ChrisArchitect wrote:
| Related:
|
| _What Killed Perl?_
|
| https://news.ycombinator.com/item?id=45977900
| morshu9001 wrote:
| I looked at Perl once and decided to just not use it, and hoped
| it'd go away so I never have to use it. Sorry, the decline was
| probably due to it being bad.
| d_sem wrote:
| I worked for a few years in an large org which utilized perl for
| build scripts, testing automation, and a few other things. I
| would summarize the half decade Perl learning curve as initial
| bewilderment, intermediate cult like praise, to advance level
| disillusionment.
|
| There was something about scaling usage in large teams that felt
| awkward and high friction.
| oncallthrow wrote:
| > Perl always had a significant amount of what you might call
| "BOFH" culture, which came from its old UNIX sysadmin roots. All
| of those passive aggressive idioms and in jokes like "RTFM",
| "lusers", "wizards", "asking for help the wrong way" etc.
|
| > [...]
|
| > Cultural conservatism as a first principle.
|
| Counterpoint to this: Rust. Rust has a similar RTFM/"wizards"
| culture, but is not culturally conservative (in any sense of the
| word).
|
| My two cents: Perl's "culture" had little to do with its fall. I
| think Perl's problems run much deeper. Perl is built on rotten
| foundations. It's fundamentally a scripting language (albeit with
| bolted on additions to make it kinda-OOP), and it therefore has
| all the problems that scripting languages have for building large
| software projects.
|
| Those problems have no quick fix, and indeed fixing them would
| require throwing the language out entirely -- at which point, why
| not simply switch to another language entirely (which is exactly
| what happened...).
| twoodfin wrote:
| Probably stretching the cultural metaphor too far here, but
| Rust has much more of a "vanguard of the proletariat" vibe &
| appears susceptible to some of the problems inherent in that
| political mission.
| tbrownaw wrote:
| The reason I mostly use Python is `python3 -mvenv env`. If I know
| that everything I might want is part of Perl's built-in modules,
| I prefer Perl.
| 1vuio0pswjnm7 wrote:
| Perl is still required for compiling autotools, openssl, nasm,
| etc.
|
| As such, is likely to be around for a long, long time
|
| Python is sometimes required for compiling software, too, but
| projects like the ones mentioned above requiring Perl have not
| switched to Python
| anarticle wrote:
| Perl was of a time, so it's important to remember when it was
| around. CPAN was legitimately one of the first package managers
| for a programming language that WORKED. Contextually, its
| references are bash, sed, awk, and other cli tools. There are too
| many ways to do things in perl because of the various flavors /
| takes on how to do things. It was also a fun way to write cgi
| apps in the era of C/C++. Is that the best way to do things
| today? No! It was one way to do something complex in few lines of
| code. It was the python of its day in many ways.
|
| There are tons of quirks that are interesting that influenced
| language development today, for me the spaceship operator "<=>"
| was a fun one. You can have a flip through the camel book to see
| what kind of stunts were common in its era.
|
| It is an auteur language that was not really done the way
| languages are today.
|
| Perl 6 did massive damage to the community mainly because it was
| so different that it looked like a fantasy language. That along
| with Parrot really lost the plot for me, I had mostly stopped
| doing that kind of work and moved on to R for my bioinformatics
| things. Bioconductor was the bees knees.
|
| I'm surprised at all the haterade, probably you're either <30,
| and/or being overly critical of a very nascent tech era. Perl was
| pre and post .bomb, and had one of the first online communities
| that I remember that shared tips and tricks at scale at
| perlmonks.org. It predated stackoverflow! It was a very different
| time to now.
|
| This was also from a time when people still paid for compilers(!)
|
| I am deeply biased, as I wrote a 3d distance calculator in Perl
| for small molecule drugs. We were looking for disulfiram analogs
| doing biopanning and then simulations. There was a great PDB
| library for structures at that time that saved me tons of time.
| This was circa 2005~, ages from now.
| darrenf wrote:
| > _[TIMTOWTDI] literally means 'there is more than one way to do
| it in Perl' - and you can perhaps infer from that that there's
| little to no reason to do it using anything else_
|
| Not my experience at all, FWIW. For me, and the vast majority of
| Perl devs I've worked with over the past 30 years, TIMTOWTDI
| absolutely means some of the "ways to do it" don't involve Perl,
| and that's not only OK but expected. _Of course_ Perl isn't the
| be all /end all. It's a lot of fun though!
|
| (I'm a majority Perl coder to this day, it's my favourite
| language by far. Hell, I even find it readable and easy/fun to
| debug)
| nucleogenesis wrote:
| The number of blogs posted on here by people who can't be arsed
| to make their writing legible on mobile blows my mind. Did
| everybody just skip the section of their CSS journey that covered
| media queries or what?
|
| I enjoyed the article but it was a nightmare to read on my
| phone's browser
| outside1234 wrote:
| C'mon. The language was like something born in Hogwart's. Magic
| spells, incantations. It lost because it was not an easy language
| to learn - and others were (in particular Python) - while being
| just as powerful.
| jancsika wrote:
| > None of this is literally serious,
|
| Exactly.
|
| I remember someone telling me to RTFM when I posted a question on
| IRC back in the 90s. Luckily, I explicitly asked if they were
| serious. They responded of course not-- they were kidding!
|
| Then they PM'd me with hidden link that had an image map of Perl
| wizards with whom I could schedule a free meeting and coffee to
| get started as a newbie. I was skeptical-- who cares about some
| random noob from the interwebs?!? Well, Perl, apparently. That
| face-to-face meeting left me with goosebumps that I feel to this
| day when I think back on it. It turned out to be an important
| confidence booster and my chief way into programming.
|
| I don't think it's an exaggeration to say that without Perl's
| focus on outreach I would never have served as president of
| Software Local 2142.
|
| Like my wizard mentor told me when I tried to pay for the coffee
| that afternoon: _Perl it forward!_
| kstrauser wrote:
| I need to hear more about this Software Local 2142.
| ____tom____ wrote:
| perl died because "Perl is write once, read never"
| fenazego wrote:
| My first and only experience with Perl was like this: in 1997,
| just for fun, I tried to write a program in Perl to turn my
| Mozilla bookmarks into a website. After a week of not succeeding,
| in frustration I decided to try Python. In two days I had what I
| wanted, and programming it was a joy. That sealed my judgement
| that Perl (and all of its culture) was not for me, so I'm not
| surprised at all that others might feel the same. (To be fair,
| there's a single oneliner that does make life a lot easier: ... |
| perl -pe 's{...}{...}')
| chihuahua wrote:
| I had an interesting experience starting a job at ZipRecruiter,
| and finding that up to that point (2022), most of their code had
| been written in Perl. Their CTO had just gotten fed up with Perl
| and decreed that from now on, all new projects should be written
| in Go. I was the first one on my team to write code in Go.
|
| There were various greybeards who kept telling me that Perl was a
| perfectly fine language and was fast enough for most purposes. I
| didn't argue with them and just backed away slowly.
|
| Regarding Perl as a language, it seemed fine in the 1990s as a
| slightly more advanced alternative to Unix shells. But for me,
| what made it a failure as a language is that in order to have an
| array of hashes, or a hash of arrays, you needed to use
| references. That may have been a nice hack to enable some things
| in the 1990s, but even in 2005 that sounds pretty primitive and
| outdated to me. Plus the reliance on using magical variables
| consisting of $ and every non-letter ASCII character for all
| kinds of random stuff, like $_ and $# and so on. That may have
| been cool in 1992, but it's not 1992 any more.
|
| Overall, Perl was pretty neat for little scripts up to 20 lines,
| but a bad idea for building an entire company on (like
| ZipRecruiter.) That's more of an indictment of ZipRecruiter than
| Perl.
| fredsmith219 wrote:
| My client uses IBM servers with it's hobbled version of Unix
| (AIX). Perl and access to copilot have really helped me out. I
| don't love Perl but I'm damn glad I have acres to it.
| twentyfiveoh1 wrote:
| early pearl was just about having an awesome tool at your
| disposal. There was minimal code written in a team environment.
|
| People were still amazed that you could do X in 1 line rather
| than 100 lines. Some people couldn't have done those 100 lines.
|
| So the idea of recipes/spells/hacks was an intentional parallel.
|
| It became a cultural thing. New people wanted to be respected for
| compact code that impressed people the same way they were
| impressed.
| PLenz wrote:
| I'm really, really confused by the typescript overtaking python
| comment, they're not really tackling the same domain of problems,
| right?
| stack_framer wrote:
| Should the Rust community take a lesson here, and maybe the Zig
| community to an extent?
|
| To me it seems that some in the Rust community in particular,
| perhaps because they're just the most vocal, are tightly coupled
| to progressive, social activism.
|
| I guess in general I just find myself wishing that political and
| social issues could be entirely left out of technical
| communities.
| valiant55 wrote:
| I'd love for politics to not infiltrate most aspects of life.
| Until everyone is able to, at least in part, persue life
| without being oppressed because of their immutable attributes,
| their belief or lack of belief system, who they choose to love
| and/or how they view themselves I think it's our civic duty to
| crusade for those causes.
| stack_framer wrote:
| > I think it's our civic duty to crusade for those causes
|
| Why crusade using the resources of a technical community
| though? Surely it alienates the people who don't happen to
| align with the causes important to you.
|
| There are myriad ways to perform your civic duty in your
| city. You could knock doors and encourage people to vote, for
| example. Why do it through a technical community?
| rcarmo wrote:
| This tracks. My own experience was that I moved from Perl to
| Python (for system and API stuff) and PHP (for templating and
| HTML).
|
| The only thing I kept using Perl for over a decade was RADIUS (we
| ran Radiator, which was arguably the most insanely flexible AAA
| server for ISPs)
| heikkilevanto wrote:
| I don't know, but for me Perl has not died at all. I still use it
| for smallish scripts and some CGI. Maybe I am an old retired
| fart, but it is the tool I reach for, when the problem looks like
| Perl-ish. Like I reach for C or other languages when I need that
| kind of things.
| grim_io wrote:
| At first glance it looks like shit. That's all the reason I need
| to never touch it.
|
| It doesn't feel like I've missed out.
| dana321 wrote:
| I remember the first time a saw Perl, it looked like some kind of
| alien language from outer space, all the symbols it used looked
| insane.
|
| But once you get it, its pretty intuitive to use.
|
| The worst part about it was the syntax for object oriented
| programming, which in raku (perl 6) is a lot better and
| intuitive.
|
| Raku has some great ideas like grammars, but has a lot of new
| magic symbology and lost what i thought was an intuitive way of
| regular expressions in Perl 5.
|
| =~ vs ~~
| 0xbadcafebee wrote:
| I think it's worth pointing out that Python only became popular
| after Google started using it. Remember when every nerd on the
| web was an ardent defender of Google? When people wanted to reach
| for a new language (say, for data science, also a new thing at
| the time) they reached for that slightly obscure yet easy to
| learn language that the cool tech company used. Schools adopting
| it exposed it to more people, but they picked it up, again, cuz
| Google used it and it was easy to learn.
|
| Nowhere in that decision-making process is there the
| consideration of if it's actually a good language, more
| efficient, more flexible, more powerful, faster, etc. It was ease
| of use and "the cool kids are using it".
___________________________________________________________________
(page generated 2025-12-06 23:01 UTC)