[HN Gopher] Perl's decline was cultural
___________________________________________________________________
Perl's decline was cultural
Author : todsacerdoti
Score : 367 points
Date : 2025-12-06 17:42 UTC (1 days 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.
| keepamovin wrote:
| 35-44. Same thing, sometimes it makes planning errors, or
| misses context that should be obvious based on the files,
| but overall a huge booster. No need to review in depth,
| just set it against tests and let it iterate. So much
| potential, so exciting.
|
| My feeling is the current suite of LLMs are "not smarter
| than US" they simply have far greater knowledge, unlimited
| focus, and unconstrained energy (modulo plan/credits/quotas
| of course!). I can't wait for the AIs that are actually
| smarter than us. Exciting to see what they'll do.
| 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 ?
| zahlman wrote:
| I seem to have messed up my italics. The emphasis was
| supposed to be on "from the interpreter".
| asyncio.get_event_loop is a standard library function.
| amiga386 wrote:
| > Can you show me a real-world package that was held back
| because the code needed a feature or semantics from the
| interpreter
|
| That is not what I was getting at. What I was saying is
| that, if you write code for perl 5.20 and mark it "use
| 5.20.0;", then that's it, you're done, code never needs to
| change again. You can bring in newer perl interpreters, you
| can upgrade, it's almost certainly not going to break.
|
| You can even write new code down the line in Perl 5.32
| which wouldn't be possible in 5.20, and the 5.20 code
| wouldn't be valid in 5.32, but as they're both declaring
| which version of the language they're written in, they just
| seamlessly work together in the same interpreter.
|
| Compared to Python's deliberate policy, which is they won't
| guarantee your code will still run after two minor
| releases, and they have a habit of actively removing
| things, and there's only one version the interpreter
| implements and all code in the same interpreter has to be
| be compatible with that version... it means a continual
| stream of having to update code just so it still runs. And
| you don't know what they're going to deprecate or remove
| until they do it, so it's not possible to write anything
| futureproof.
|
| > in 2.7, surrounding parentheses are not redundant,
|
| That is interesting, I wasn't aware of that. And indeed
| that would be a thorny problem, moreso than keeping a print
| statement in the grammar.
|
| Fun fact: the parentheses for _all_ function calls are
| redundant in perl. It also flattens plain arrays and does
| not have some mad tuple-list distinction. These are all the
| same call to the foo subroutine: foo
| "bar", "baz" foo ("bar", "baz") foo
| (("bar", "baz")) foo (("bar"), "baz") foo
| (((("bar")), "baz"))
| zahlman wrote:
| > Compared to Python's deliberate policy, which is they
| won't guarantee your code will still run after two minor
| releases
|
| They don't guarantee that _the entire standard library
| will be available to you_ two minor releases hence. Your
| code will still run if you just vendor those pieces (and
| thanks to how `sys.path` works, and the fact that the
| standard library was never namespaced, shadowing the
| standard library is trivial). And they tell you up front
| what will be removed. It is _not_ because of a runtime
| change that anything breaks here.
|
| Python 3 has essentially prevented any risk of semantic
| changes or syntax errors in older but 3.x-compatible
| code. That's what the `__future__` system is about. The
| only future feature that has become mandatory is
| `generator_stop` since 3.7 (see
| https://peps.python.org/pep-0479/), which is very much a
| corner case anyway. In particular, the 3.7-onward
| annotations system _will not_ become mandatory, because
| it 's being replaced by the 3.14-onward system
| (https://peps.python.org/pep-0649/). And aside from that
| again the only issue I'm aware of (or at least can think
| of at the moment) is the async-keyword one.
|
| > And you don't know what they're going to deprecate or
| remove until they do it
|
| This is simply untrue. Deprecation plans are discussed in
| public and now that they've been burned a few times,
| removal is scheduled up front (although it can happen
| that someone gives a compelling reason to undo the
| deprecation).
|
| It's true that you can't make your own code, using the
| standard library (which is practically impossible to
| avoid), forwards-compatible to future standard libraries
| indefinitely. But that's just a matter of what other code
| you're pulling in, when you didn't write it in the first
| place. Vendoring is always an option. So are
| compatibility "forward-ports" like
| https://github.com/youknowone/python-deadlib. And _in
| practice your users are expecting you to put out updates
| anyway_.
|
| And most of them are expecting to update their local
| Python installations eventually, because the core Python
| team won't support those forever, either. If you want to
| use old FOSS you'll have to accept that support resources
| are limited. (Not to mention all the other bitrot
| issues.)
| asus386 wrote:
| Well isn't that nice. The boxes I care most about are 32 bit.
| The perl I use is 5.0 circa 2008. May you amiga386, or anyone
| else, thank you in advance, may be able to tell me what do I
| need to upgrade to perl 5.8? Is it only perl 5.8 and whatever
| is the contemporaneous gcc? Will the rest of my Suse 11.1
| circa 2008, crunch? May I have two gcc's on the same
| box/distro version, and give the path to the later one when I
| need it? The reason I am still with Suse 11.1, is later
| releases broke other earlier things I care about, and I could
| not fix.
| amiga386 wrote:
| suse 11.1 includes perl 5.10: https://ftp5.gwdg.de/pub/open
| suse/discontinued/distribution/...
|
| perl 5.8 was released in 2002. perl 5.000 (there is no perl
| 5.0) was released in 1994. I have difficulty accepting you
| have perl "5.0" installed.
| ab5tract wrote:
| I assumed 5.0 was referring to using any of the 5.00x
| series.
| 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.
| jkrejcha wrote:
| > And that's not even getting in to the major breakages in
| point version upgrades or the whole python 2 to 3 language
| switch.
|
| Python doesn't use semver and never claimed to do so, but
| it's probably worth treating "x.y" releases as major
| versions in their own right (so like 2.7 -> 3.0 is a major
| version and so 3.10 -> 3.11). If you do that, the
| versioning makes a bit more sense
| 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.
| wlonkly wrote:
| It's funny, because something like array
| var = array # copied int var = array # length
|
| or var = array # copied var =
| array.to_i # length
|
| is less subtle to me but I can't put my finger on why.
| 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.
| colinstrickland wrote:
| Although Perl auto flattens lists by default, which isn't
| particularly lisp like.
| tmtvl wrote:
| Perl was developed in 1987, the first Common Lisp
| standard was released in 1984, 3 years earlier. Common
| Lisp allows arguments like so: (defun
| frobnicate (foo &key (bar (Vector 1 2 3)) (baz 'quux))
| (declare (type Foo foo) (type (Vector
| Integer) bar) (type Symbol baz))
| ...)
|
| Not only normal arguments like we get in C or Pascal, but
| there's keyword arguments, you can have optional
| arguments, and a rest argument, which is most like Perl's
| @_. And that's not even getting into destructuring lambda
| lists which are available for macros or typed lambda
| lists for methods.
| 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.
| morshu9001 wrote:
| Pretty sure FP is exactly what you said. If it's not, I'm
| ok calling it a "no variables" language.
| 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.
| programd wrote:
| I'll go further. Ignore the Perl specific bits and
| Conway's "Perl Best Practices" is one of the best general
| programming books ever written.
|
| It has so many great pieces of advice that apply to any
| programming task, everything from naming variables, to
| testing, error handling, code organization,
| documentation, etc, etc. Ultimately, for timeless advice
| on programming as a profession the language is
| immaterial.
| 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.
| writtiewrat wrote:
| Reasoning through analogies?
| 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.
| bsder wrote:
| Exactly. Perl did regexes _very_ well. It did basic hash tables
| okay. It did everything else poorly.
|
| Once languages came along that did okay regexes and good hash
| tables along with getting other stuff decent, Perl just got
| pushed aside.
| 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.
| MangoToupe wrote:
| I think you have causation reversed: it would have been
| at least two orders of magnitude greater to act like
| moving to python 3 was harder than staying. But you do
| you boo :emoji-kissey-face:
| SoftTalker wrote:
| Pain on whose part? There was certainly pain porting all
| the code that had to be ported to Python 3 so that the
| Python developers could have an easier time.
| MangoToupe wrote:
| Yes, exactly. customers need to stop acting like a bitch
| if they wanna be taken seriously
| 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.
| JoshTriplett wrote:
| The difference is that the two don't interoperate. You
| can't import a Python 3 module from Python 2 or vice
| versa; you have to use completely separate interpreters
| to run them.
|
| I'm suggesting a model in which one interpreter runs both
| Python 2 and Python 3, and the underlying types are the
| same, so you can pass them between the two. You'd have to
| know that "foo" created in Python 2 is the equivalent of
| b"foo" created in Python 3, but that's easy enough to
| deal with.
| MangoToupe wrote:
| Ok who would suggest this when the community could take a
| modicum of responsibility
| 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.
| bsder wrote:
| Except that Python took the _other_ path when migrating
| from Python 1 to Python 2 and ... guess what? That was a
| "disaster" too.
|
| The only difference was that by the time of Python 3,
| Python programs were _orders of magnitude_ bigger so the
| pain was that much worse.
| symbogra wrote:
| Differences of scale do make a qualitative difference and
| must be considered when doing a migration.
| 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.
| topspin wrote:
| "Perl6/Raku killed Perl."
|
| Perl was effectively "dead" before Perl 6 existed. I was there.
| I bought the books, wrote the code, hung out in #perl and
| followed the progress. I remember when Perl 6 was announced. I
| remember barely caring by that time, and I perceived that I was
| hardly alone. Everyone had moved on by then. At best, Perl 6
| was seen as maybe Perl making a "come back."
|
| Java, and (by extension) Windows, killed Perl.
|
| Java promised portability. Java had a workable cross-platform
| GUI story (Swing). Java had a web story with JSP, Tomcat, Java
| applets, etc. Java had a plausible embedded and mobile story.
| Java wasn't wedded to the UNIX model, and at the time, Java's
| Windows implementation was as least as good as its non-Windows
| implementations, if not better. Java also had a development
| budget, a marketing budget, and the explicit blessing of
| several big tech giants of the time.
|
| In the late 90's and early 2000's, Java just sucked the life
| out of almost everything else that wasn't a "systems" or legacy
| big-iron language. Perl was just another casualty of Java. Many
| of the things that mattered back then either seem silly today
| or have been solved with things other than Java, but at the
| time they were very compelling.
|
| Could Perl have been saved? Maybe. The claims that Perl is
| difficult to learn or "write only" aren't true: Perl isn't the
| least bit difficult. Nearly every Perl programmer on Earth is
| self-taught, the documentation is excellent and Google has been
| able to answer any basic Perl question one might have for
| decades now. If Perl had somehow bent itself enough to make
| Windows a first-class platform, it would have helped a lot. If
| Perl had provided a low friction, batteries-included de facto
| standard web template and server integration solution, it would
| have helped a lot as well. If Perl had a serious cross-platform
| GUI story, that would helped a lot.
|
| To the extent that the Perl "community" was somehow incapable
| of these things, we can call the death of Perl a phenomena of
| "culture." I, however, attribute the fall of Perl to the more
| mundane reason that Perl had no business model and no business
| advocates.
| chromatic wrote:
| Excellent point in the last paragraph. Python, JavaScript,
| Rust, Swift, and C# all have/had business models and business
| advocates in a way that Perl never did.
| 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.
| SoftTalker wrote:
| How did vbscript die? How did php die? Better alternatives
| came along and sucked up the oxygen.
| 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.
| antonvs wrote:
| > 41!
|
| That's a very big number!
| inkyoto wrote:
| 67 and 41 are the TikTok / Gen Z speech.
|
| 67 stands for <<whatever>>, <<I don't care>>, or,
| cyclically, 67!
|
| 41 is an expression of shock or disbelief - <<that's
| wild>>, <<no way>> and stuff like that.
| 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)
| hylaride wrote:
| The quote, if originally from Morphy, is from the 1800s,
| though. So it's the context of the quote that matters.
|
| Either way, it's not meant to be taken so literally!
| astrange wrote:
| Morphy, who is probably the greatest chess player to ever
| live, would probably know.
| 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.
| AndrewDavis wrote:
| > 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.
|
| When at University the academic running the programming
| language course was adamant the Sapir-Whorf hypothesis
| applied to programming language. ie language influences
| the way you think.
| alsetmusic wrote:
| I only recently learned about this, maybe a month ago. It
| made a lot of sense to me.
| algernonramone wrote:
| Seems somewhat related to Iverson's 1979 Turing Award
| lecture, "Notation as a Tool of Thought" (https://www.eec
| g.utoronto.ca/~jzhu/csc326/readings/iverson.p...)(https:/
| /news.ycombinator.com/item?id=25249563)
| jodrellblank wrote:
| Reading the YCombinator link there's a mention of APL and
| a comment by dTal[1] which includes saying:
|
| > " _A lot of the mystique of APL is because it 's
| illegible ... nothing more than a DSL for 'numpy-like'
| code. .. same demo, using Julia and the result is (in my
| opinion) much more legible: ... let n=sum(map(_
|
| sum() in Julia is more clear and more readable at a
| glance than +/ in APL, but the APL version is a
| combination of two things. + which is a binary addition
| function, and / which is reduce, a higher-order operator
| or meta-function. sum() in Julia doesn't lead you to
| think about anything else except what other builtins
| exist. The APL notation leads you to wonder about
| combining other commands in that pattern, like times-
| reduce is x/ and calculates the product of an array of
| numbers. From the notation you can see that sum and
| product are structurally related operations, which you
| can't see from names sum() and product(). Then you change
| the other part by wondering what plus does if used with
| other higher functions, like +\ (scan) and it's a
| running-sum across an array. (i.e. "+\ 1 1 1 1" gives "1
| 2 3 4", the sum so far at each point).
|
| So the notation isn't just about readability, it's a tool
| for thinking about the operations. Different notations
| enable you to think about different things. If we imagine
| there was no sum() then you might write:
| sum = 0 foreach (n in numbers) { sum += n }
| product = 0 foreach (n in numbers) { product *= n
| }
|
| and whoops that doesn't work; this notation brings to the
| focus that sum has to start with 0 and product has to
| start with 1 to get the right answer and you can wonder
| mathematically why that is; APL notation hides that just
| like it hides the looping. Different notation is a tool
| for changing the what people think about - what things we
| must attend to, cannot attend to, and what new things a
| notation enables us to see. dTal's next reply:
|
| > " _the power of abstraction of APL is available to any
| other language, with the right functions. ... there 's
| nothing to stop anyone from aliasing array-functions to
| their APL equivalents in any Unicode-aware language, like
| Julia (oddly, nobody does)._"
|
| Maybe nobody does it because if you can't take the
| patterns apart and put them back together differently
| without an APL engine behind it, is there any benefit?
| Take an example from APLCart[2]:
| {[?]/[?][?]\[?][?]' '} Dv # Remove leading blanks
| [from a character vector]
|
| In C# that task is str.TrimStart() and I assume it's a
| loop from the start of the string counting the spaces
| then stopping. Calculating length - num_of_spaces,
| allocating that much memory for the new string, copying
| the rest of the string into the new memory. I wouldn't
| think it was do-able using the same higher order function
| (\ scan) from a running sum. What this is doing to
| achieve the answer is different:
| {[?][?]' '} ' abc def' # make a boolean array
| mask +-----------------------+ # 0 for
| spaces, 1 for nonspaces |0 0 0 1 1 1 0 0 0 1 1 1|
| +~----------------------+ {[?]\[?][?]' '} '
| abc def' # logical OR scan
| +-----------------------+ # once a 1 starts,
| |0 0 0 1 1 1 1 1 1 1 1 1| # carry it on to end
| of string +~----------------------+
| {[?]/[?][?]\[?][?]' '} ' abc def' +---------+
| # 'compress' using the boolean |abc def|
| # array as a mask to select what to keep
| +---------+
|
| Now how do I remove the leading 0s from a numeric array?
| In C# I can't reach for TrimStart() because it's a string
| only method. I also can't assume that there's a named
| method for every task I might possibly want to do. So I
| have to come up with something, and I have no hints how
| to do that. So I have to memorise the TrimStart() name on
| top of separately learning how TrimStart() works. That
| notation gives me a clear readable name that isn't
| transferable to anything else. In APL it's:
| {[?]/[?][?]\[?][?]0} Dv # Remove leading zeroes
| [from a numeric vector]
|
| That's the same pattern. Not clear and readable, but is
| transferable to other similar problems - and reveals that
| they can be considered similar problems. In C where
| strings are arrays of characters, you aren't doing whole
| array transforms. In C# strings are opaque. In APL
| strings are character arrays and you can do the same
| transforms as with numeric arrays.
|
| Which part of that would you alias in Julia? I suspect
| you just wouldn't write a trimstart in this style in
| Julia like you wouldn't in C#. You wouldn't think of
| using an intermediate boolean array.
|
| It's not just about "readability", the APL notation being
| concise and self-similar reveals some
| computy/mathematical patterns in data transforms which
| "giving everything a unique English name" obscure. And
| APL notation hides other patterns which other notations
| reveal. i.e. Different notations are being tools for
| thinking differently about problems, Notation as a Tool
| for Thought.
|
| [1] https://news.ycombinator.com/item?id=25258819
|
| [2] https://aplcart.info/
| em-bee wrote:
| this is why i like how operators work in pike:
|
| + - * / and other operators work not only on numbers but
| on strings, arrays and other types and all have an
| intuitive application.
|
| on strings and arrays for example, + is concatenate, / is
| split, * is join, - is filter (with static values).
| pavel_lishin wrote:
| > _It made Python feel too rigid and Ruby feel familiar._
|
| That's so funny to me; I like Python, and dislike Perl &
| Ruby. Something about Ruby rubs me the wrong way - I
| could name a few things that I think are _objectively_
| bad decisions in the language's design, but it's mostly
| about an aesthetic preference that's just a matter of
| taste.
| 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.
| QuadmasterXLII wrote:
| Throw in nc and a while loop, and you can have a server
| too!
| keernan wrote:
| >it will never go away
|
| Chet Ramey became the primary maintainer of Bash in the
| early 1990s and is the sole author of every bash update
| (and Readline) since then. That would be an enormous task
| for a team of 100, no less a team of one.
|
| I've become quite a fan (after struggling mightily with
| its seemingly millions of quirks.
| BobbyTables2 wrote:
| Indeed. If I had to download and install bash ... I
| wouldn't!
|
| I write bash scripts only because I can rely on it being
| there.
| em-bee wrote:
| i think this is changing. in recent years, alternative
| shells that break with bash syntax like fish or elvish
| and others are gaining in popularity. oils is of
| particular interest because it has an sh/bash compatible
| mode and thus provides an upgrade path away from bash.
| MayeulC wrote:
| At least you have bash scripts. Most of my coworkers
| write tcsh scripts :|
|
| (And yes, I have been pushing for bash or posix sh).
| SoftTalker wrote:
| I think if you were a sysadmin and used to shell scripts,
| sed, awk, grep and xargs then perl probably made more sense
| than if you were a programmer from a more traditional
| language coming into the perl world.
| aorloff wrote:
| If I am familiar with sed, awk, grep and xargs, was I a
| sysadmin ?
| tsimionescu wrote:
| If you are familiar with all of these but _not_ C or Java
| or some other "traditional" programming language, then
| yes, I think anyone would guess you were a sysadmin. This
| was the type of background GP was talking about - people
| familiar with shell scripting but not any other
| programming language, who come by Perl for the first
| time.
| Suppafly wrote:
| >I think if you were a sysadmin and used to shell
| scripts, sed, awk, grep and xargs then perl probably made
| more sense than if you were a programmer from a more
| traditional language coming into the perl world.
|
| This, it was very unixy and felt like a natural
| progression from shell scripting. I think that's why a
| lot of early linux adopters were so enamored.
| npsomaratna wrote:
| That makes a lot of sense. After 30+ years of
| programming, I still have to do a search (or use an LLM)
| to do anything useful with sed, xargs, etc. Perl never
| really clicked with me either.
|
| On the other hand, I was able to easily pick up just
| about any "tradional" language I tried--from Basic and C
| in the 80s all the way to Dart and Go more recently.
| pjmlp wrote:
| As somone that switches between both roles, when doing
| DevOps (aka sysadmin in 21st century) even though there
| is more stress regarding dealing with infrastructure,
| there is a certain peace of mind being away from Scrum,
| Jira, milestones, and other stuff, versus plain shell
| scripts, sed, awk, grep and xargs, VMs up and down.
|
| Or doing a plain set of scripts into a repo, instead of
| endless arguments how fit a module implemenents the onion
| and hexagonal architectures, clean code, or whatever is
| the trend in this year's architecture conferences.
| znpy wrote:
| As another "devops-y" guy (I'm essentially a sysadmin,
| but i accept whatever job title is trending right now) i
| agree on everything. It's nice to see (from a distance)
| all the bs developers have to endure on a daily basis
| knowing it doesn't affect me much.
|
| Also... a lot of that complexity is essentially self-
| inflicted.
|
| I must say however: "devops" is completely different from
| what old-school system administration used to be.
| chamomeal wrote:
| If you're in the market for fun hackable tool that sits
| between "bash script" and "real developer" I highly
| recommend checking out babashka.
|
| It lets you write shell scripts with clojure. Babashka
| itself is a single executable, so no JVM bulk or startup
| time. And the built-in libs include all sorts of nifty
| utilities. Parsers, servers, _excellent_ async stuff (but
| IMO clojure might have the best async story of any language
| out there so I'm biased), http stuff. All macro-able and
| REPL-able and everything. It's a scripting dream, and when
| it's time to be an adult, you can throw it on the JVM too!
| erpellan wrote:
| You might also enjoy Janet https://janet-lang.org/
| em-bee wrote:
| a different approach is to replace bash altogether and
| switch to modern shells like fish, elvish, murex, nushell
| (not stable yet afaik) or oils (very interesting
| approach, it has a bash or sh compatible mode and another
| one with a more modern and cleaner syntax).
| signal11 wrote:
| I agree. Perl made sense as a "step up" in the world of *sh
| and awk.
|
| Also the culture wasn't hostile to me as a newcomer. The
| Perl books I read encouraged not writing overly terse,
| cryptic code, and I got helpful answers via mailing lists.
|
| I still use Perl sometimes if my command pipeline gets too
| complicated.
| dxdm wrote:
| It's been a while, but I found for me personally, that Perl
| flows while writing it, but stops flowing when reading the
| same code after some time has passed. It was good for
| getting things done once, but no fun to maintain and adapt
| - at least the way I was using it decades ago. I moved from
| Perl to Python and never looked back.
| klipt wrote:
| LUKE: Is Perl better than Python?
|
| YODA: No... no... no. Quicker, easier, more seductive.
|
| LUKE: But how will I know why Python is better than Perl?
|
| YODA: You will know. When your code you try to read six
| months from now.
|
| https://wiki.python.org/moin/PythonCdFun
| tootie wrote:
| I wrote a ton of Perl 5 and also found it very intuitive
| and powerful. I think the notion that Python is "more
| readable" is true, but also less useful of a metric than it
| would seem. Python is still gibberish to a new coder and
| requires training and experience to master. Perl requires
| somewhat more effort to acclimate to, but ultimately is
| much more expressive and much closer to real-world software
| engineering problems. Once the incremental effort is made,
| Perl is (or at least was) a better Python.
| jgalt212 wrote:
| For me it's not so much that Python was more "readable"
| than Perl. I've found pretty much any language other than
| XSLT more readable than Perl.
| 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.
| BrenBarn wrote:
| It's not just a matter of "read the docs", though,
| because languages can differ in how many distinct
| concepts/constructs they employ. Python has gradually
| added more over the years but still I think is well short
| of Perl in this regard.
| somat wrote:
| With regards to BEGIN
|
| The only reason AWK needs a BEGIN is due to it's implied
| data loop. As far as I know perl has an explicit data
| loop and as such needs no BEGIN.
|
| Oh god, perl has an implied data loop mode doesn't it.
| Sigh, now I am reading perl manpages to find out.
|
| Update: of course it does, -n or -p
| thaumasiotes wrote:
| > 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).
|
| OK, I had never heard of the syntax, but in its own
| defense it does exactly what you'd guess, the same thing
| it does after an "if".
|
| These are equivalent statements:
| preloop: if condition:
| do_more_stuff() goto preloop
| while condition: do_more_stuff()
|
| and these are also equivalent: preloop:
| if condition: do_more_stuff()
| goto preloop else: wrap_it_ip()
| while condition: do_more_stuff() else:
| wrap_it_up()
| martinflack wrote:
| It could've easily been defined that the else branch runs
| if the while condition never had a true value at all. In
| fact, I think that's more intuitive.
| thaumasiotes wrote:
| What are you trying to say? It _is_ defined that way. And
| the example I provided above makes that completely
| explicit.
|
| But here, from the official documentation:
|
| > if the expression is false (which may be the first time
| it is tested) the suite of the else clause, if present,
| is executed and the loop terminates.
|
| https://docs.python.org/3/reference/compound_stmts.html#t
| he-...
| crote wrote:
| > BEGIN? Take 60 seconds to read what it means.
|
| Yes, that's exactly the problem: it's additional mental
| load you have to read up on.
|
| Have 60 of those small oddities in a file, and suddenly
| you're spending an hour dealing with Perl quirks rather
| than _actually debugging_ that obscure script a retired
| coworker wrote a decade ago. A 5-minute fix turned into a
| 65-minute fix, solely because of Perl.
|
| Most programming languages use more-or-less the same
| constructs, and the few per-language oddities are usually
| fairly obvious from context. In practice this means
| someone familiar with _any_ programming language will to
| a certain extent be able to read, debug, and patch small
| issues in code written in _any other_ programming
| language. Perl 's obscure and dense syntax makes this
| virtually impossible. Give a buggy Python script to a
| developer who daily-drives Javascript and they can
| probably fix it. Give a buggy Perl script to that same
| Javascript developer, and they probably have absolutely
| no clue what's going on.
|
| In practice this turns Perl into technical debt. It has
| very few natural niches where it is genuinely the best,
| so experienced Perl developers are quite rare to have
| around. Any script _written_ in Perl will most likely
| have to be read by someone who isn 't an experienced Perl
| developer - which is significantly harder than a script
| written in just about any other language. The result is
| that any Perl scripts you have lying around are basically
| a grenade waiting to go off: they can't be maintained, so
| they should probably be replaced.
| 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'.
| partomniscient wrote:
| $_ was one of the things that put me off perl, because
| the same syntax meant different things depending on
| context.
|
| The Pragmatic Programmers had just started praising Ruby,
| so I opted for the that over Perl, and just went with it
| ever since. Hated PHP and didn't like Python's whitespace
| thing. I never Ruby on Rails'd either. That said my first
| interactive website was effectively a hello world button
| with cgi/perl.
|
| But trying to learn to code from reading other peoples
| perl scripts was way harder than the (then) newer
| language alternatives.
|
| Now I'm over 50 none of that is nearly as important. I
| remember being young and strongly opininated, this vs.
| that - its just part of the journey, and the culture. It
| also explains the current FizzBuzz in CSS minimisation
| post. We do because we can, not necessarily because we
| should.
| 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.
| inkyoto wrote:
| To be able to fully comprehend Perl (even without having
| to embrace it), one needs a fiddle.
|
| Perl and some of Perl's quirks will make more sense once
| you realise that it is deeply rooted in UNIX command line
| utilities, UNIX conventions and some UNIX shell defaults,
| except when it is not, i.e. - What is
| `$_`?
|
| $_ follows the spirit of shell variables (such as $*, $@,
| $! etc., heavily used in Korn, Bourne flavours but not
| the C flavours), but was repurposed or - more likely -
| picked from a pool of vacant characters with the help of
| a dice roll. Kind of like how ancient Egyptians built the
| pyramids with the help of sophisticated cranes and
| machinery and then vapourised their tools with high-
| particle beams to leave future generations guessing <<how
| on Earth did they manage to do that>>. This is one of the
| main criticisms of Perl. - What is this
| BEGIN block at the start of this Perl file? Why is that
| necessary?
|
| Perl started out as an improvement over <<awk>>, and
| BEGIN is an awk construct where it is used frequently,
| e.g. awk 'BEGIN { IFS=":" } { ... do something ... }'
| - What does chomp do when it's just on its own line, with
| no arguments given to it?
|
| It follows the standard convention of UNIX utilities that
| expect the input to come from the standard input stream
| (file descriptor 0 or <file-in in the shell) when no
| input file name has been specified. So, when no <FILE1>
| given to chomp, it chomps on the standard input.
| nmz wrote:
| If you think that's bad, try learning python or a verbose
| language while not speaking english, all of these words
| like while, for, if, else, break are just gibberish and
| your code just reeks of some weird mish mash of broken
| english and broken <mother tongue>, I have a hypothesis
| that terseness favors universality, if you don't speak
| english, something like $_ is equal or easier to grasp,
| it honestly just looks like terse and weird math.
| jhbadger wrote:
| That was the idea of APL (and its successors like J and
| K) -- make programming a math notation rather than
| pretend to be a human language (generally English, but
| there have been programming languages with keywords in
| Chinese and Russian, among others).
| AlexCoventry wrote:
| When I was choosing between learning python and perl in the
| late 90's, it was the context sensitivity of perl
| expressions which really squicked me. To me, that was the
| critically bad language decision in perl. You can make
| context-sensitive expressions in python (using operator
| overloading, for instance), but you have to go out of your
| way to do it in one way or another. In perl you can easily
| do it by accident, and it can result in serious bugs. It
| seemed masochistic, to me.
| 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.
| __patchbit__ wrote:
| People summit Qomolangma. (with logistics)
| kamaal 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.
|
| Those days were different. You could say what people are
| doing in months to years today, in many ways people back then
| were doing in days to weeks.
|
| Pace and ambition of shipping has not only faded, that very
| culture is non existent. You don't see people building the
| next Facebook or Amazon these days, do you?
|
| I remember managers asking Java programmers how much time it
| would take to get something done, and get timelines on months
| and years. They would come to us Perl programmers and get it
| done in a week.
|
| The era didn't last long. I would joke around our team
| saying, ideally a Java programmer with 10 years experience
| was somewhat like like a Perl programmer with 1 year
| experience. This was one of the big reasons, most of these
| enterprise coders wanted Perl gone.
| colinstrickland wrote:
| > Pace and ambition of shipping has not only faded, that
| very culture is non existent. You don't see people building
| the next Facebook or Amazon these days, do you?
|
| Do you not? The pace of anthropic/Claude tool development
| is pretty bonkers, AI hype reminds me of the 90s a lot.
| petit_robert wrote:
| >This was one of the big reasons, most of these enterprise
| coders wanted Perl gone
|
| I see some people disagree with you, but reading this
| reminds me of this anecdote :
|
| My brother has a very high IQ score, but poor social
| skills. He once found employment in one of the very early
| companies developing websites in our area.
|
| There was a process requiring to manually check hundreds of
| links for validity, which took large amounts of time to do
| (as in several developper hours weekly), and was error
| prone at that. The details are fuzzy as this happened some
| 30 years ago or so, but essentially he found a logical way
| to do the thing without error in 15 minutes.
|
| The other developers went on a rampage to dismiss the
| solution, for fear of looking like idiots, and even though
| the solution was provable, my bro go fired, and went on to
| become a mechanic. What a shame though.
|
| So, your comment rang a bell.
|
| Also : I make a living developing and maintaining a handful
| of custom made SaaS for small clients on a LAMP stack
| (Linux Apache Mod_perl Postgresql). Very thrifty.
|
| Little money, but loads of fun as far as I'm concerned
| pasc1878 wrote:
| This is it. I wrote largish systems in perl using its OO
| things and that was good.
|
| The one thing I could never ever get was using a regex - not
| the regex itself but the line to actually use it.
|
| Python was so much easier as it was simple define the regex
| and then use a function on it. I suppose I should hjave spent
| a few days to write some wrapper in perl - doing those few
| days would have saved me time overall.
|
| As for one liners I was originally an APL programmer so not a
| problem. But it is just bad style to write a one liner much
| better to write it in a maintainable form and split up the
| operations so they can be seen.
|
| Nowadays I ddon't use lambdas if possible - much better to
| have a named function you can refer to.
| finaard wrote:
| > Python was so much easier as it was simple define the
| regex and then use a function on it. I suppose I should
| hjave spent a few days to write some wrapper in perl -
| doing those few days would have saved me time overall.
|
| That's funny. I avoid python whenever possible, but one of
| the things I hate the most is how it is doing regex. I find
| the way it works in perl (both for search/replace and in
| conditionals) just intuitive.
| 59nadir 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.
|
| Perl 5 is to me a classic scripting language (as opposed to
| an actual programming language), for both good and bad. I've
| always viewed Perl scripts with exactly that perspective and
| I find them fine/good. In contrast, I find Python to be a
| mediocre scripting language, an okay-ish programming language
| from a syntax perspective and a bottom-5 programming language
| in pretty much every other regard.
| 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".
| wlonkly wrote:
| Larry was (and presumably is, but I'm out of that loop) a
| gem. The Weird Al of programming languages. Hilarious and
| kind.
|
| But those who remember the regulars of, say, efnet #perl
| (THIS ISN'T A HELP CHANNEL), there was a dearth of kindness
| for sure. I was probably part of it too, because that was the
| culture! This is where the wizards live, why are you here
| asking us questions?
|
| Like cms, I'm also hesitant to name names, but the folks I'm
| thinking of were definitely perl-famous in their day.
|
| There were also a bunch of great people in the community, and
| they helped me launch my career in tech in the 90s, and I
| have close internet friends from that community to this day
| (and great memories of some who have passed on). But there
| were definitely also jerks.
| 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.
| PunchyHamster wrote:
| ...that's why I used "was". Current direction of the
| language mostly goes against the "Zen of Python".
| bigstrat2003 wrote:
| Python has never actually followed the Zen of Python,
| which is one of my gripes with it. For example, "explicit
| is better than implicit" is a bad joke given how Python
| implicitly treats non-boolean types as booleans.
| dragonwriter wrote:
| > the whole "one way to do a thing"
|
| There's a whole lot of words popularly excised (as you just
| did) from that line of the Zen to create a false polar
| opposite to Perl's TMTOWTDI that was never actually part of
| Python's philosophy.
|
| The _actual_ line from the Zen of Python is: " _There should
| be_ one-- _and preferably only one_ -- _obvious_ way to do
| it." (omissions in italics).
| 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.
| bigstrat2003 wrote:
| The point is not that such quirks are impossible to learn;
| the point is that they make the language extremely
| unpleasant to use.
| forgotpwd16 wrote:
| >I'm sure those things make sense when all you write is Bash
|
| Not really. Bash is known to be incoherent (due to legacy).
| You eventually getting accustomed to its quirks but they
| still remain absurd and may unexpectedly bite you someday.
| Perl code can, and perhaps will (it's humorously referred to
| as a _write-only language_ afterall), get hard to read but at
| least is more robust.
| 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.
| petit_robert wrote:
| Strange, for me it's the opposite.
|
| Just yesterday, I moved some 100 lines of code using a hash
| quite a few times from the main module to a function using
| a reference to the hash.
|
| if %args is the hash holding the data, '$args{key}' tells
| me the value of 'key' in the main module.
|
| a reference to the hash passed to the function is noted
| like so : '$args = \%args';$args->{key} tells me value of
| 'key'
|
| All I had to do to adapt the code was to replace '$args{'
| with '$args->{', done by the time I typed the replace
| command in my editor.
|
| Funny that it just makes sense to me, must be something
| with the brain's wiring.
| 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.
| zbentley wrote:
| > Rubyists vs. Pythonistas isn't any better.
|
| Eh, in different ways. Ruby people often felt a little
| smug/over-emotive about how much joy using their tool could
| bring programmers. TFA is spot on about Perl: Perl folks
| often felt cliquish, arrogant, defensive. Python people are
| at times patronizing or overly dismissive.
|
| And in all of those communities the biggest difference was
| how _many_ people in the community had those dysfunctions,
| versus the rest--the vast majority of each language's users
| who were using it, sharing techniques or code, answering
| questions about it without being jerks.
|
| Where Perl fell down for me was that its community and people
| I knew who used it had a much higher chance of evidencing
| those crappy behaviors. More bad apples--not many in the
| grander scheme, but enough more to be noticed.
| Ferret7446 wrote:
| I don't think "Pythonista" was a thing in the 2000s. Python
| is very old and only became more of a "fad" relatively
| recently.
| AlexCoventry wrote:
| It was definitely a thing.
| zweifuss wrote:
| I can remember perl vs python flame wars ca. 2002.
|
| Also, the early 2010s are not that recent: https://books.go
| ogle.com/ngrams/graph?content=Pythonista%2Cp...
| pjmlp wrote:
| This will keep happening until we start programming computers
| with some kind of AI style driven interfaces, and even then
| maybe not.
|
| Humans are tribal, and HR only hires for specific bullet
| points, thus everyone wants to assert they are on the right
| tribe when they need to go job hunting.
| 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')
| cjs_ac wrote:
| CPAN was inspired by CTAN, the Comprehensive TeX Archive
| Network.
| jamal-kumar wrote:
| oh yeah you're right and this is coming from someone who still
| likes/uses perl once in a while for text manipulation stuff
| that awk/sed won't cut it for. try going into your terminal and
| typing in man 3pm Errno
|
| And you get this code snippet: my $fh;
| unless (open($fh, "<", "/fangorn/spouse")) {
| if ($!{ENOENT}) { warn "Get a wife!\n";
| } else { warn "This path is barred: $!";
| } }
|
| man is that ever from a different time... but let me tell you
| if you can pull off some of those awk/sed or perl one liners
| you can do some pretty useful things with less resource
| allocation than you would be spending if you had written that
| in python, which becomes important if you're running it over
| and over on terabytes of data or on limited hardware
| chrisandchris wrote:
| I have never worked (in Prod) with Perl, but my introduction to
| programming was with PHP and all I know IMHO is that PHP was/is
| so easy to start with. One of the reasons I picked PHP over
| other languages.
| pjmlp wrote:
| Strange, maybe because of being a 70's kid and a D&D nerd, that
| kind of stuff is exactly why I liked Perl in first place.
|
| That and Perl giving me a reason to do safe programming in UNIX
| with a managed language that exposed all the UNIX API surface,
| and only switching back into C when I actually needed some
| additional perf, or low level stuff not fully exposed in Perl.
|
| Then again, I am also a fanboi of Haskell, C++, Scala, Idris
| and similar "wizard" languages.
| zaphirplane wrote:
| First time I read something like that about Perl. Is this
| personal experience during the Perl peak period or
| extrapolation from phrases
| tails4e wrote:
| I liked perl, it was the first language I used daily as a HW
| engineer. When I moved to python more recently what I missed
| the most was how easy it was to do a one liner if with regex
| capturing. That couldn't be done in python for a long time. I
| think the walrus operator helps, but it's still not quite as
| concise, but it's closer
| rs186 wrote:
| Good for you, not for anyone else reading the code or
| yourself 6 months later. Seen too much of that.
| tails4e wrote:
| My code wasn't written to be hard to decipher, and it
| wasn't a goal to get everything on one line by any stretch,
| I just didn't like an if with regext was 2 lines minimum in
| python, it felt inelegant for a language that is pretty
| elegant in general
| derbOac wrote:
| Python for awhile had its own cultural issues. I guess, coming
| from more of a C and lisp background, the stuff you're
| mentioning seemed playful and fun to me and I didn't get the
| sense anyone expected to write performance critical code in it
| anyway.
|
| Python forums in contrast to me included neverending
| justifications for why whitespace and indent formatting was
| critical and this kind of odd (to me) imperfect type system
| implementation, like the whole thing was some toy language
| pretending to be more than it was (in the sense that if you
| wanted something more complete in language or performance you'd
| go elsewhere).
|
| Perl just seemed to know its place and not take itself too
| seriously.
|
| Things changed though. I haven't touched Perl in years but use
| Python all the time. I never understood why Python got the
| traction it did given its performance limitations compared to
| some other languages (except as part of a broader trend for
| people to use whatever language they leaned in introductory
| comp sci) but I do think I understand why people stopped
| learning Perl.
| 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"
| WesolyKubeczek wrote:
| Pure perl modules are not, unless they use syntactic
| features that first appear in the newer versions.
|
| Modules with C extensions have to be recompiled with
| libperl they run against, as much as CPython extensions
| link to a particular libpython, and guess Ruby is the
| same. But they, with very few exceptions, will recompile
| and run fine. XS is cryptic but its backwards
| compatibility story is good.
| 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.
| SoftTalker wrote:
| Don't forget many people were still on dial-up and long
| forum posts were probably discouraged in favor of RTFM or
| other terse reply.
| altairprime wrote:
| It was primarily the exhaustion of experts at tireless
| waves of newbies who hadn't studied the available
| materials.
|
| IRC being async if the client is run locally, modem
| delays made no difference (just as with QWKmail and forum
| posts). And for remote host IRC, I don't remember what
| the IRC line length limit was but at 300bps you could get
| an entire message and the buffer scroll updates
| accompanying it in 1 second, which was well-sufficient
| enough to support peak volume with no relevant latency.
| And, I can still type a paragraph at clock seconds of
| input latency and remember where I'm at when backspacing.
| So, I would definitely _not_ ascribe a desire for brevity
| as an outcome of modems.
| 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...
| creer wrote:
| One-liners is one of the ways you can use perl. You can
| also use it as the embedded language in some larger
| project. As perl CGI. As mod_perl. etc. There is no
| "cultural pressure" to use any of these. You can choose to
| mess around with one-liners and you can choose to spend
| time shaving a few characters off your code. Or not. None
| of this is the one true way. This is not python.
| nocman wrote:
| > There was strong cultural pressure to be able to write
| perl in as few bytes as possible
|
| Hard disagree. Many Perl programmers _enjoyed_ engaging in
| code golf (always just for fun, in my experience), but in
| my nearly 30 years of programming Perl, I never encountered
| anything that I would call _pressure_ to do so -- not from
| anyone.
| IshKebab wrote:
| Nah Perl just wasn't a very good language. Not every language is
| equally good.
| forgotpwd16 wrote:
| Neither is Ruby that has also similarly disappeared and article
| praised it? Or Lisp? On the opposite end, C, PHP, JS that are
| omni-present are good languages? Sometimes meritocracy and
| success don't align.
| 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.
| writtiewrat wrote:
| Some of the reasons why I never bothered with Perl was that I
| had the perception that it, like Ruby, encouraged mutating
| and modifying classes on the fly, willy-nilly. And the lack
| of static typing. Python also did not have static typing (it
| has some optional typing now or something like it), but my
| perception was that monkeypatching was not abused as much in
| Python as it might be in Perl and Ruby. Not that I used
| Python a lot.
| altairprime wrote:
| Perk was never much interested in fiat-enforced
| restrictions. That was considered to be the domain of local
| policy in a given project or team and not something to
| declare upon its users. We've since determined in
| programming that restrictions can exceed the value of
| perfect freedom (cf. Rust, TypeScript vs. C, Perl). But for
| scenarios where rapid flexibility is key (eg. ops eng, sans
| sre/k8s/etc) the flexibility is more important than the
| restrictions. Always have an adjustable wrench alongside
| your fixed-jaws, just in case.
| writtiewrat wrote:
| Regarding restrictions vs. perfect freedom, I think it's
| also about trade-offs, implementation quality, etc.
| Typescript has very easy and well-defined escape hatches.
| Conversely, Rust's escape hatches are an active research
| field, not well-defined, considered significantly
| difficult by prominent Rust figures, the safety is leaky
| (for instance no_std), etc.
|
| C is also a significantly stricter language in some ways
| than Perl, due to its static type system, despite that
| type system being primitive. C, ironically, is in some
| ways way stricter than Rust, since it has a goal of
| simplicity in its language, and thus writing compilers
| for it (despite its ancient syntax) and standardizing it
| is much easier than for Rust. And those properties are
| rather good for a systems language. Simplicity in the
| language does of course not generally necessarily
| translate to simplicity in the code, the ability to
| create good abstractions is worth a lot.
|
| Rust has also experimented with editions. And there is
| the issue of Rust allowing backwards compatibility to be
| broken regarding type inference AFAI recall, in part
| leading to the 1.80 time crate debacle.
| themafia wrote:
| I switched to ruby because of the quality of the MRI for
| writing extensions. It was literally a revolution. No more
| SWIG, no more complex type magic, no more struggles to compile
| my module on end users systems. This was all wrapped by up gem
| as well so the switch was genuinely impossible to avoid.
|
| This was all also at a time when Perl 6 was first starting to
| emerge from the vapor. The extremely wishy washy and decade
| long development track they put themselves on finally destroyed
| any notion of ever even returning to Perl. It served as the
| motivation to hoist all my old Perl code into ruby code.
| kamaal wrote:
| >>Perl died because other languages starting having an
| equivalent to CPAN
|
| Last time I checked apart from npm, no other language has
| anything similar to CPAN.
| webstrand wrote:
| PyPI doesn't count? (or rust's cargo)
| lamontcg wrote:
| or rubygems
| 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.
| maxbond wrote:
| Surely the people who had purely performance problems with Perl
| CGI scripts moved to mod_perl? I didn't figure out when mod_php
| was introduced from casual searching, but given that mod_perl
| is only a year younger than PHP it must've been available to
| almost anyone who was considering rewriting their app in PHP.
| So I have to imagine there were additional reasons.
|
| Wikipedia says that this source [1] claims early versions of
| PHP were built on top of mod_perl, but I can't access the
| archive right now for some reason so I can't confirm.
|
| [1]
| https://web.archive.org/web/20130625070202/http://www.theper...
| jeberle wrote:
| mod_php was distributed w/ Apache httpd, so it was "already
| installed". mod_perl needed to be installed manually, so it
| posed immediate friction, if not a complete freeze-out,
| depending on the situ. I believe that was why PHP became
| popular.
| giantrobot wrote:
| Systems with mod_perl (or just Perl allowing normal CGI)
| installed, especially shared hosting was so common as to be
| the norm in the late 90s and early 00s.
|
| I think instead the biggest reason PHP took off was it had
| far less deployment friction and better aesthetics than Perl
| did on machines where you _didn 't_ have admin access,
| basically ever shared web hosting ever.
|
| Typically CGI scripts on shared hosting were limited to
| explicit cgi-bin directories that had +ExecCGI. At the same
| time hosts would often not enable mod_rewrite because it
| could get computationally expensive on hardware of the era.
|
| This all meant that all your dynamic content had to live at
| some "/cgi-bin/" path. It could be difficult to have a main
| landing page be dynamic without an empty index HTML just
| having an HTTP-Refresh meta tag to your "/cgi-bin/" path.
|
| Contrast with PHP which would be processed from any directory
| path and was its own built-in templating language. It was
| also usually included in the DirectoryIndex list so an
| index.php would act as a directory index leading to cleaner
| URLs.
|
| In the era when deployment mean MPUT in an FTP client those
| small differences made a difference for people trying to make
| their first dynamic website and look "professional".
| 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?
| petepete wrote:
| I suspect it's because Ruby's ability to deal with strings is
| so heavily influenced by Perl.
|
| When I first started using Ruby after years of Perl, it felt
| familiar but everything was just more... sensible.
| 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.
| writtiewrat wrote:
| As someone who doesn't really know neither Perl nor PHP, PHP is
| more of a domain-specific EDSL than a mainstream programming
| language.
|
| One of the few insights in the blog post that aren't stupid,
| fake, inconsistent and schizophrenic, is the one about PHP's
| common approach regarding spinning up new processes.
| SoftTalker wrote:
| PHP has fallen off. Who is doing anything new in PHP?
|
| PHP has a much bigger legacy of web stuff than Perl, because it
| was so much easier to use. But there's no future in it.
| Wordpress, Drupal, Joomla... all had their time but it's all in
| the past.
| petesergeant wrote:
| mod_php was dramatically simpler to use than mod_perl. If the
| sysadmin set it up, you didn't need to know it was there, and
| your regular PHP just ran really fast. That and nothing else
| really copied the "scriptable HTML file" paradigm which some
| people really really liked and made a very low barrier to entry
| compared to Perl. That's really what kicked off the demise of
| Perl -- it stopped being the most accessible way onto the
| internet. PHP also didn't screw up their major language
| upgrades like Perl did.
|
| RoR helped Ruby push off its inevitable demise for a while, but
| it's going the same way as Perl. Python got lucky that it's
| become the defacto choice for everything ML.
| 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.
| writtiewrat wrote:
| The blog post is, quite frankly, dishonest, inconsistent and
| schizophrenic.
| themafia wrote:
| That was effectively the culture of the Internet in general at
| that time. It was the "wild west" for years, because, well, it
| _was_ a modern incarnation of the same phenomenon.
| 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
| writtiewrat wrote:
| Sorry for this repetition, but how popular was/is
| monkeypatching in Perl?
| coopierez wrote:
| This is interesting to me, as someone moving from a company
| that uses C++ to one that uses Rust. It feels like the whole
| culture of the former company is built similarly - no
| guardrails, no required testing, or code review, minimal "red-
| tape".
|
| In effect, the core principles of the company (or at least, the
| development team of the company) end up informing which
| programming language to use.
| balamatom wrote:
| >The Pervert's Guide to Computer Programming
|
| That's a rather glamorous piece of discourse, yall aint sleepin
| 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.
| zippyman55 wrote:
| My fingers have long forgotten all the PERL they once knew.
| But it was always pleasant.
| 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)
| writtiewrat wrote:
| How popular was/is monkeypatching in Perl?
| darrenf wrote:
| Very. I use `Test::MockModule` (not just in tests) or
| `Sub::Override` or `Class::Method::Modifiers` a lot,
| according to convention/style or as I see appropriate -- but
| there are, of course, tons more ways to do it.
| sivoais wrote:
| It is possible to do so, but it stands out in a way such that
| most people aren't doing it using direct language features
| unless necessary. If you have `strict` and `warnings`
| enabled, which is recommended, then the interpreter can give
| runtime warnings or compile-time errors if you try to
| manipulate the symbol table or redefine a function. If you
| still want to use those on a case-by-case basis, you have to
| turn off those pragmas within a scope. So there are built-in
| ways the language discourages using them arbitrarily.
|
| In tests, you can use monkeypatching as a quick way to mock,
| but typically, you use modules that wrap up the functionality
| and make it cleaner. The mocks get cleaned up on scope exit.
|
| There are also more principled ways of having composable
| behavior, such as
| <https://metacpan.org/pod/Class::Method::Modifiers>
| (advice/method combination).
|
| There is another approach that takes advantage of the variety
| of scoping approaches Perl has. If one uses `local`, it
| indicates the use of dynamic scope rather than the standard
| `my` lexical scope. This can be used for things like setting
| an environment variable temporarily and automatically
| reverting it when leaving the scope. But this is not common.
| 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
| colinstrickland wrote:
| (Author) Sorry you had a poor experience, yes my blog "engine"
| is a hacked together POS that barely works, with hand written
| CSS, that was mostly built before the mobile first era, I have
| just tweaked it to work somewhat on portrait phone screens, but
| it's really not a very good website. I do try to generate
| fairly plain semantic HTML so the pages should work pretty well
| with "reader mode" or user stylesheets if you have access to
| that. That's probably the optimal experience.
| intalentive wrote:
| Fine for me on iPhone Safari.
| 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.
| Suppafly wrote:
| I can't tell if this is real or real funny.
| kbelder wrote:
| Neither?
| chuckadams wrote:
| Looks like slashdot-era copypasta.
| ____tom____ wrote:
| perl died because "Perl is write once, read never"
| Nextgrid wrote:
| Executable line noise.
| 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{...}{...}')
| kwoff wrote:
| I hope this doesn't come off as argumentative. You said that
| with Python "In two days I had what I wanted", but another way
| of looking at it: in a week of not succeeding in Perl plus
| those two days in Python, you had what you wanted.
| 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?
| troad wrote:
| I thought it was really perceptive. Look at what JS was
| designed to do cf. what it's actually doing these days.
|
| Turns out it doesn't really matter what domain you were
| originally trying to tackle. If you've stumbled upon a low
| friction way of achieving other things, people are going to use
| your tool for those things, even if it's not the optimal tool
| for those domains.
|
| I dread the JS/TS future, but it's obviously coming.
| 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?
| array_key_first wrote:
| There is zero way you don't alienate anyone. Ask women
| software engineers if they ever feel alienated. That's the
| reason why some communities like the python community do
| outreach for minorities in tech.
|
| I'm a white man, and I have never felt "alienated" in so-
| called progressive spaces.
| stack_framer wrote:
| > outreach for minorities in tech
|
| Why is there no outreach to other minorities in tech,
| like the Amish, for example? They are certainly more
| underrepresented than women in the python community.
|
| Or how about male ballet dancers? Why isn't the python
| community allocating some of its resources to helping
| them feel seen and included?
|
| I'm giving ridiculous examples because the whole premise
| is ridiculous. And my general question remains: Why
| devote the resources of a tech community toward one
| social issue/group or another? There are plenty of other
| outlets more suitable for doing our civic duty.
| array_key_first wrote:
| > Why is there no outreach to other minorities in tech,
| like the Amish, for example? They are certainly more
| underrepresented than women in the python community.
|
| Well the amish wouldn't want the outreach, because
| they're amish.
|
| > There are plenty of other outlets more suitable for
| doing our civic duty.
|
| I kind of hate this mentality, because there's no logic
| or reasonableness behind it.
|
| There's ALWAYS another place you can do something.
| Always. Where you draw the line is arbitrary. There's no
| rulebook anywhere saying we _can 't_ do this in tech.
| That's just your opinion, that you made up. We don't have
| to do that and, evidently, we don't.
| bigstrat2003 wrote:
| Agreed. The Rust community is an incredibly toxic place because
| they are so determined to involve politics in tech. I love the
| language, but I stay as far away from the community as I
| possibly can.
| 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.
| michaeld123 wrote:
| agreed. it's often in my toolbox -- mostly since I already know
| it, and I prefer semi-colon-driven syntax -- but it's just one
| of a few languages I use.
| 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 ~~
| xyzwave wrote:
| "Warning: Smartmatch is experimental at foobar.pl line 42."
|
| If only I had a dollar for every time I've seen this message.
| 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".
| laughing_man wrote:
| My problem with PERL was always that there's just too many things
| to remember, particularly if the code I'm debugging was written
| by someone who knows the language well. I'd be on a PERL project
| for awhile, then get pulled off to do Java or Ruby or whatever.
| By the time I needed to do PERL again, I had to go back and
| relearn everything. I never had that problem with Java, Ruby,
| Python, or Javascript.
|
| Also, PERL allows you to write the most unmaintainable code I've
| ever seen. I ran across a single line of PERL that would read a
| buffer, do some simple data transformations, add framing
| information (some of it derived from the data like length, data
| type, and checksum), and then write out the completed buffer.
|
| It was beautiful. And also completely unmaintainable. Even the
| guy who wrote it didn't remember how it worked and had to fiddle
| with it for twenty minutes before he remembered a variable he
| used was getting set as a side effect of something else later in
| the line. That's great for a programming contest, but not so much
| for production code you may be tasking a newly minted software
| developer with maintaining.
|
| Granted, you _can_ write maintainable PERL code. But over the
| years the PERL has been hands down the least maintainable in
| different jobs and projects.
| kwoff wrote:
| Perl's "decline" means there is some metric to measure how high
| Perl is. It was higher, but now it is lower. I don't think the
| metric is well-defined, though.
| JSR_FDED wrote:
| Perl was the duct tape of the Internet.
|
| Regardless of the culture issues, it was _effective_!
| smithkl42 wrote:
| Perl failed because it's a write-only language. The only time you
| really understand a Perl program is when you're writing it. Check
| back in six months and good luck. It's like trying to read
| someone else's regular expression - and the connection between
| Perl and Regular Expressions is not accidental.
| majormajor wrote:
| I never interacted with the "Perl community" described here. When
| I used Perl in a past job it was in the "just google for how to
| do things" era.
|
| The syntax, full of @ and %, was convoluted and made you have to
| think about more things compared to Ruby or Python without giving
| you that much apparent power or benefit (as opposed to when you'd
| need to think about types more in Java or a C-family language).
|
| Neither Ruby, Python, nor Perl were in my first three languages
| (Pascal, C/C++, Java were those). Ruby, Python, Matlab, R, and
| Perl all came later for me, within a few years of each other.
| Perl did not have anything like the approachability of Ruby and
| Python coming from that Pascal/C/Java background.
|
| (IMO Python is losing some of that now, especially like in the
| last project I encountered in a professional capacity in Python
| where optional type hinting was used _but wasn 't always
| accurate_ which was a special sort of hell.)
|
| EDIT: the article even touches on this some in its description of
| Ruby: "Ruby is a language for programmers, and is at this point
| an sensible candidate for building something like Rails with - a
| relatively blank canvas for dynamic programming, with many of the
| same qualities as Perl, with less legacy cruft, and more modern
| niceties, like an integrated object system, exceptions,
| straightforward data structures." Ruby was newer, and wasn't
| something that grew out of sysadmin tools, but was always a full
| fledged OO application programming language first. So my
| disagreement with the article is that the culture then doesn't
| matter because no perl culture changes would've been able to
| reinvent the language as a nicer, newer language like Ruby
| because it never would've been perl anymore at that point.
| thaumasiotes wrote:
| > the last project I encountered in a professional capacity in
| Python where optional type hinting was used but wasn't always
| accurate which was a special sort of hell.
|
| But that's the _entire purpose_ of optional type hinting. If
| the hints had to be accurate, you 'd have mandatory typing, not
| optional hinting.
| majormajor wrote:
| I think the purpose of _optional_ type hinting is _that you
| don 't have to add it everywhere all at once_, not that it
| doesn't have to be accurate. I guess you could split hairs
| and say "hint" doesn't imply perfect accuracy, but... adding
| a language feature _that can lie_ really seems to have a lot
| of downsides vs upsides; whereas at least _optional_ has
| obvious migration benefits.
|
| You could have optional type hints where the runtime would
| still yell at you - maybe even from just an optional flag -
| if you returned a string out of a function that should return
| an int.
|
| Because as-is, once you have those function that says it
| returns an int but returns a string instead, etc, in a big
| codebase, your editor tooling gets really confused and it's
| way worse to work through than if the hints weren't there at
| all.
|
| (And there are tools in Python that you can use to inspect
| and verify the accuracy. But those tools are also...
| optional... And if you start to apply them to a codebase
| where they weren't used, it can be very time-consuming to fix
| everything...)
| thaumasiotes wrote:
| > And there are tools in Python that you can use to inspect
| and verify the accuracy. But those tools are also...
| optional... And if you start to apply them to a codebase
| where they weren't used, it can be very time-consuming to
| fix everything...
|
| How is that "bad" solution different from this "good" one?
|
| > You could have optional type hints where the runtime
| would still yell at you - maybe even from just an optional
| flag - if you returned a string out of a function that
| should return an int.
| majormajor wrote:
| If it's built in to the runtime you get a lot of
| potential benefits:
|
| - you don't need to install additional packages
|
| - you could have (because you don't want to hurt prod
| perf by checking all the time) dev-mode with warnings by
| default on execution and a prod-mode where they're
| ignored
|
| - you can then have people in the dev environment
| catching things as they write/run/test their code vs only
| whenever they run the third party tool (which it seems a
| lot of people don't set up for even run-on-every-commit)
|
| Let's flip the question around! What do you think are the
| _benefits_ to making it easy to add misleading incorrect
| type hints?
| Arainach wrote:
| No, optional type hinting means there's sometimes not a hint.
| Having a hint and then passing some type that's not that is
| wrong and hell.
| echelon wrote:
| Python's type hinting is horrible.
|
| It's not checked, it's not required, and the bolted on
| syntax is ugly.
|
| Even if the types were checked, they'd still fail at
| runtime and some code paths wouldn't get exercised.
|
| We need a family of "near-scripting" languages like Go that
| check everything AOT, but that can be interpreted.
| dragonwriter wrote:
| > It's not checked, it's not required,
|
| It is both of those if you use a typechecker, which is
| the whole reason it exists (in fact, the first popular
| typechecker existed _before_ the annotation syntax using
| type comments; type annotations were developed
| specifically so that it could be accommodated in the
| language rather than becoming its own separate language.)
| echelon wrote:
| That's the problem! The code should not run if the types
| are wrong. Having an external tool is an antipattern.
|
| Having to rely on process for validity is a recipe for
| bad. We already know how the greater python community has
| been with requirements.txt and dependencies. I've spent
| days fixing this garbage.
|
| It's a tooling problem. Good tools make good habits part
| of the automation and stop you from having to think about
| it.
| adamors wrote:
| You are talking about misleading type hints, not optional
| ones. Optional means they don't have to be added. Wrong
| typehints are so much worse than missing ones.
| bpbp-mango wrote:
| I tried to learn perl a few times early in my career, we still
| had some old perl internal sites and a bit of tooling written in
| it. I really struggled to find good resources on the web at the
| time, and most of the perl I was exposed to was so badly written
| as to be incomprehensible to me. I knew C and Python at the time.
|
| I wonder how common my experience was and why the next gen (at
| the time) I was part of never learned it
| padjo wrote:
| I had the exact same experience. The Perl I encountered early
| in my career seemed hard to understand in way other languages
| weren't. I also didn't feel I made progress quickly trying to
| learn it, every time I thought I had my feet under me I'd
| encounter a new sigil or a new pattern and be back to having no
| idea what the code was doing.
| david_shaw wrote:
| Yes: in retrospect, the Perl community (and maybe even the
| language in general) was cringe-worthy and perhaps even toxic.
|
| But at the time, that elite and esoteric language drew me and
| many others to it in much the same way that *BSD and arguably
| even Linux did. The way that programming computers in general
| did.
|
| It wasn't a pleasant vibe that anyone should strive to recreate,
| but Perl was something that felt cool to many nerds back then.
| Perl's decline being cultural is a good thing: it's because the
| industry grew and matured.
| Simplita wrote:
| Perl shaped so much of early web culture. It's interesting how a
| language can fade not because of capability, but because the
| community's momentum shifted elsewhere.
| INTPenis wrote:
| Perl was my first favourite programming language, used it for
| most things, from 1999 until switching to Python in 2012.
|
| I still find the occasional Perl script in my current job,
| usually going through someone's legacy infrastructure, and I
| always have the same reaction, "phew I'm glad I switched to
| Python".
|
| That reaction has nothing to do with the culture, it's 100%
| technical.
|
| Just a few of the main points, I don't know why Perl coders were
| so adverse to comments, it's almost like some of us took a
| perverse pleasure in producing the most illegible piece of code.
|
| It's like a stream of someone's consciousness.
|
| I used to take pride in being fluent in PCRE, as well as some
| other dialects, and looking through an old Perl script you easily
| see why, it's used on every 10th line. And it always strikes me
| with a sense of relief when I realize all those instances of
| Regex are solved in a more OOP/Pythonic way today. Regex is
| something I reserve for edge cases.
| psadri wrote:
| 25 years ago Perl allowed you to express what was in your head
| 10x more concisely as in other mainstream language (which have
| since caught up with some of the features).
|
| This was not the best when it came to others (or even yourself 6
| months later) reading the code. But it was great for cranking
| stuff out that was simply too tedious in other languages.
| procaryote wrote:
| By a lot of metrics it was a pretty awful language; hard to read,
| implicit, inconsistent, uncomfortable to write due to all the
| special characters etc. The idea of default arguments alone
| should have killed it by being a monumentally bad idea.
|
| In my recollection perl6 helped kill it by making perl5 stagnate,
| but hopefully it would have died regardless.
| hexo wrote:
| Oh Perl, the programming language entirely made of footguns. Is
| it dead already?
| relistan wrote:
| Way back, Perl got off the ground really because, in contrast to
| the C compilers of the era, code written on one Unix ran on the
| others, usually unmodified. In my first jobs, where we had
| heterogeneous mixes of commercial Unixes, this was unbeatable. It
| also wrote like higher level shell, which made it easy to learn
| for systems people, who really were the only ones that cared
| about running things on multiple platforms most of the time
| anyway.
|
| As things became more homogeneous, and furthermore as other
| languages also could do that "one weird trick" of cross platform
| support, the shortcomings of both Perl and its community came to
| the fore.
| Deeg9rie9usi wrote:
| While I don't code in perl myself, one modern tool I use a lot is
| written in perl: https://github.com/digint/btrbk
| dash2 wrote:
| I dunno, I interacted with perl about 2000-2003 in a small way,
| it always seemed pretty friendly and welcoming, I loved perlmonks
| and remember it happily.
|
| I'm a bit sceptical about this:
|
| > (Pause a second and ask yourself about the sort of social
| culture that both allows this kind of behaviour at public events,
| and then chooses to embrace it as a key piece of cultural lore)
|
| Is it really so terrible that someone throws a coffee cup or two
| at a wall to make a point? Sounds a bit pearl-clutching.
| artyom wrote:
| Perl was aimed at intelligent people that considered obfuscated
| code challenges a sport and had a tendency for masochism.
|
| Its main achievement is being there first, before everyone else,
| to run server-side code in a scripting/interpreted language.
|
| The rest wasn't neither cultural nor technical. From a purely
| business perspective, having to fight against an idiosyncratic
| tool half the time doesn't really make much sense.
| leoc wrote:
| I'm not sure about the Perl-specific claims here, but it _is_
| amusing how pervasive "on one or more occasions, I got a
| dopamine release after managing to struggle through the horror
| and misery of X: now I'm convinced that X is Good, Actually"
| seems to be in computing.
| nmz wrote:
| But isn't this everything? All of computing is a struggle for
| me at least, all followed with confusion and "Why did they make
| this, this way?"
| IshKebab wrote:
| But is it all _equally_ a struggle? Some things are
| definitely more of a struggle than others. Remember
| xfree86config? We used to have to _manually configure_ our
| screen resolution in a shitty text file. I even remembered
| that you had to specifically add a line to tell it you had a
| 3 button mouse. This was in the late 90s, maybe early 00s.
| Way after it was sane to have to do that.
|
| And I specifically remember when they fixed it there really
| were some people who pushed back against the change. Kind of
| unbelievable but it's true. I guess psychologically they felt
| that it was unfair that they had to struggle and future
| people wouldn't have to. But they couldn't just _say_ that so
| they came up with nonsense technical objections.
| leoc wrote:
| One of those many cases where X = X.
| smt88 wrote:
| I didn't have this experience when I first learned C#.
| Everything just kind of worked the way I expected it to.
| There are sharp edges, but far fewer than expected and always
| for an actual reason.
| zzzeek wrote:
| > I wrote a lot of Perl in the mid 90s and subsequently worked on
| some of the most trafficked sites on the web in mod_perl in the
| early 2000s, so I have some thoughts.
|
| Hey me too exactly! I wrote the CMS for mlb.com in 2003 entirely
| in mod_perl.
|
| This post is indeed a little walk down memory lane of the
| Perliness of the 1990s. I spent most of the 1990s enforcing
| everyone in my team (yes, by 1998 they made me in charge, totally
| inappropriately) use Perl on awkward environments like Windows NT
| because giving in to horrendous systems like Active Server Pages
| or...shudder...Cold Fusion represented the heat death of the
| profession. Microsoft was determined to to murder the whole "RTFM
| / TMTOWTDI" culture and replace it with their own brand of
| corporate mediocrity (remember, there was no XBox at this time.
| Github? no, source control was in Visual Source Safe [narrator:
| your source code was, in fact, not very safe!]. MSFT was 1000%
| uncool and evil).
|
| But ultimately mod_perl's decline was technical! It's syntax,
| organization and operation were enough to get us through the 90's
| but were at the same time doing violence to one's cognitive
| facilities. Python came along and fixed everything that was wrong
| with Perl. I started in Python porting things from Perl, like
| HTML::Mason, because I was not yet enlightened enough. But I got
| there eventually.
| nottorp wrote:
| I always thought Perl faded because it's write only and more
| readable alternatives showed up.
|
| Why did it have to take over the world anyway?
| hylaride wrote:
| > Why did it have to take over the world anyway?
|
| Because it was there, mostly. In a UNIX world where text was
| everything, it was well suited to quick and dirty solutions
| (that then morphed into long-term technical debt). Most
| alternatives at the time were not there by default as they
| either were commercial or otherwise didn't have any ecosystem
| to expand it's utility (like CPAN - without it Perl would
| likely be like awk - a fully capable language, but only used
| for one-liners 99.999% of the time).
| nottorp wrote:
| Well that's not what I meant. Does everything has to have
| taking over the world as a goal? Perl still exists, I guess
| it's updated, why isn't that enough?
| hylaride wrote:
| > Does everything has to have taking over the world as a
| goal? Perl still exists, I guess it's updated, why isn't
| that enough?
|
| I never got the impression that perl's goal was to take
| over the world, but it was good at dealing with certain
| kinds of problems at a time in computing where it mattered,
| especially for one-offs.
|
| The 1980s/1990s was full of many, many different data
| formats in a time before XML/JSON, often by long dead
| companies. Many a tech person was in a situation where "Oh
| fuck, how do I get this data out of some obscure database
| or other data format from some dead company that only ran
| on SCO UNIX or whatever into SAP/Oracle/etc" only to see
| somebody else already done it and made a CPAN module.
|
| It also became an early CGI workhorse because, quite
| frankly, it was just there until much cleaner web-native
| languages started to show up.
|
| Anecdotally, as part of some corporate lawsuits that
| involved stuff going back decades, a former colleague of
| mine recently had to grab ancient data for an insurance
| company from backup tapes that were last accessed in the
| 1980s (apparently getting readers for them was its own
| story). The only google results he could get for the data
| formats stored on them were literally usenet posts from the
| 1990s of people discussing working with it and...some CPAN
| modules somebody wrote to export it. He did chuckle when
| for the first time in his life he used tar without the -f
| switch, though.
| nottorp wrote:
| > I never got the impression that perl's goal was to take
| over the world
|
| Yeah, it's more like the article is implying that should
| be the goal.
| tracker1 wrote:
| I always thought of Perl as write friendly... And Ruby as Perl++.
|
| I feel it only gained any web traction in the sense that it was
| widely available and already there in the early cgi-bin approach.
|
| On the last comment, I've taken to using Deno/TS for most of my
| shell scripting type tasks these days. In general it's worked
| very well for me.
| joeiq wrote:
| Spot on: the toxic culture around the language was a nail in its
| coffin.
|
| A classmate who introduced me to Linux in the early 2000's was a
| Perl enthusiast who completely embodied the RTFM mindset. If
| someone didn't already know something they were mocked. We ceased
| to be friends after a number of these interactions.
| giantrobot wrote:
| The cult of RTFM is so painful to interact with and off
| putting. The _concept_ is sound, reading documentation is
| important. However simply responding to all questions with
| "RTFM" is not only not helpful but as often as not useless
| advice.
|
| The documentation for something may not exist, may not be
| clear, or may just be wrong. Unless you specifically know the
| answer to a question is laid out clearly in the documentation,
| blindly telling someone to read the documentation is just being
| a dismissive asshole.
|
| A much more productive and helpful response is "did you RTFM?"
| or "check section X of the manual". But those sorts of
| questions require the desire to _not_ be a dismissive asshole.
|
| The cult of RTFM has always been an impediment to Linux
| becoming more popular. When I was first learning Linux...almost
| thirty years ago now...the cult of RTFM nearly put me off the
| whole endeavor. I was asking for help with "Xwindows" on IRC
| and the responses were either RTFM (which I had done) or pedant
| diatribes about "it's X, not Xwindows newbie! It's not
| micro$oft!" Which was a super fun to deal with. The experience
| steeled my resolve to at least _ask_ someone if they read the
| manual before assholishly telling them to do so.
| PaulRobinson wrote:
| Of course it was cultural. This article covers it all in more
| detail, but I was coding a lot in this period of Perl's decline,
| and in hindsight it was all so obvious.
|
| I wrote a lot of Perl 3 and Perl 4 to date my experience.
|
| Rails was designed to be a luxury hand-holding experience using a
| language that was intended - as a design goal - to make
| programming fun. There was even for a while in the late 2000s the
| culture of _why and MINSWAN.
|
| PHP was fast, easy, forgiving. It also led to such awful code
| that several companies banned it. I think nearly all of us who
| got to deploy code with nothing more than FTP miss that. Of
| course today it runs more of the web than any other language.
|
| Perl on the other hand wasn't interested in any of that, so many
| people just left because they were pulled by better ecosystems
| that took the web seriously, or pushed by a culture that believed
| the priesthood was real.
|
| For me, Rails and Ruby were genuinely joyful discoveries after
| spending a couple of years wrestling J2EE and .NET apps in the
| ~2002-2005 era, and the Perl community felt crusty and unwelcome
| and immature by comparison.
|
| Today I'm no fan of come of the politics of people being some
| popular Ruby frameworks _cough_ , but I enjoy Ruby and I'm
| enjoying my dive back into systems programming via re-learning C
| and taking a long look at Zig. I'm not sure I'll ever write
| "production" Perl again.
| majormajor wrote:
| But could a different culture have actually changed Perl to be
| friendly and fun like Ruby? Without completely torpedoing
| compatibility with existing code and essentially creating a
| whole new language anyway?
|
| Or did the language itself just get outdated and replaced?
| (there's nothing wrong with that! most things don't last
| forever!)
| wting wrote:
| This requires those with power to relinquish authority and/or
| try new, unfamiliar practices and accept possible failure.
|
| Any company/organization can theoretically change its
| culture, but it's quite difficult in practice.
| klodolph wrote:
| I feel like I grokked Perl enough and I still write Perl
| code, but I also think that there are some technical reasons
| why it declined in popularity in the 2000s and 2010s. All
| those differences between $ % @, the idea of scalar or list
| context, overuse of globals, and references. These features
| can all make sense if you spend enough time in Perl, and can
| even be defended, but it creates a never-ending stream of
| code that _looks right_ but is wrong, and it all seems to
| create a lot of complexity with very little benefit.
| begueradj wrote:
| > PHP was fast, easy, forgiving. It also led to such awful code
| that several companies banned it.
|
| That's not the case nowadays with PHP 8.5 for example... and
| Laravel framework.
| lambdas wrote:
| > [..] as a design goal - to make programming fun. There was
| even for a while in the late 2000s the culture of _why and
| MINSWAN.
|
| It was a great time - titles like Learn You A Haskell For Great
| Good and Land of Lisp really capture the zeitgeist.
| broken-kebab wrote:
| This theory may only sound convincing if you ignore parts of
| history which don't fit. Which is pretty much all of them. RTFM-
| culture was the norm for _all_ online computer-related
| communities until 00s. Nothing of this phenomenon is Perl-
| specific.
|
| In late 80s and early 90s professional knowledge was way harder
| to get. Learning required significant devotion, and often was
| obtainable through experience only, and at the same time
| computer-related work wasn't as well-paid as it will become
| later. And had controversial social standing. Like, my brother
| said "It will hurt your chances with girls, bro!" when I told him
| I want to be a programmer, and with typical sibling-love added
| "This, and your ugly face of course".
|
| RTFM emerged naturally with all of these: people paid with their
| time and social life for this knowledge, and wrote down what they
| found in manuals, most often for free, and you can't just bother
| to read them?
|
| FWIW most BOFH types in my memory were C programmers, and early
| Linux UGs. Perlists in comparison were mild, and way more open
| (Perl community included biologists, linguists, and other non
| stereotypically computer people).
|
| Perl decline was to some extent a cultural thing. But absolutely
| not the culture the author means. In Perl Larry Wall promoted a
| sort of expressive style of writing code where you can chose
| between several compiler-equivalent ways to implement logic:
| There is More Than One Way To Do It (aka Tim Toady) principle.
| The alleged reason is that the choice you make conveys some
| subtle nuances of your thinking which 1) gives you more comfort
| while coding, 2) gives potentially more information to someone
| who will read your code. This was outrageously contrary to the
| mainstream tendency of commoditization of software development
| (and software developers) which started to gain the steam at
| those times. Managers wanted (and I guess still want though to
| the date the idea mostly failed) THE one and only right way to
| code each task, peferrably with the only one language (with Java
| as the main contender), standard training programs, and
| certifications - all across all domains, and as a result
| replaceable and transferrable coders. Perl was clearly unfit for
| this perfect future with its proud selection of 4 or 5
| implementations of OOP, and it hurt the language promotion a lot.
| And then there was disastrously optimistic declaration about
| soon-to-be major uprgade to Perl 6 which in reality will take 15+
| years, all while lots of interesting things happening outside.
| astrange wrote:
| I remember Perl programmers as being weird but nice enough.
| It's Lisp programmers who were impossible to talk to and mostly
| responded to any questions by telling you to kill yourself.
|
| I remember reading those BOFH stories because I thought it was
| how you became a cool technical person at the time, but never
| figured out why he was so angry. Eventually I realized it's
| because he was Gen X and in academia, so they probably had no
| money and all had lead poisoning.
| lagniappe wrote:
| Nobody will agree with this hot take, but I was around in the
| perl years, so maybe take this opinion with a grain of salt:
|
| Perl wasn't arcane on purpose, the bar for being a programmer was
| just that much higher, born through necessity as we didn't have
| as much material to easily turn someone into a capable engineer,
| so to make anything work you had to -really- be motivated to
| learn, and that extended to the entire skill tree of things that
| happen _before_ learning to code, like simply navigating the
| machine and being able to reach the realization that you needed
| to write something on your own.
|
| Perl evolved to suit the needs of those that used it at the time,
| and it reflected their interests, skills, and abilities.
|
| These days everything is so abstracted, so available, so easy,
| all of the material to learn literally anything is free and at
| your fingertips, programmers don't _need_ to be that
| knowledgeable to identify a need and generate some code that
| mostly addresses that need.
| majormajor wrote:
| There were programming envs that were easy to pick up in
| contemporary times. Hypercard is one that's often especially-
| fondly referenced as a non-traditional-programmer friendly
| example. Basic was much less arcane syntax-wise too. It's been
| a LONG time since I used Pascal but I also remember it being
| simpler to pick up.
|
| But Perl specifically came out of a fairly arcane sysadmin-y
| corner of the world full of other already-arcane tools like awk
| and sed. And _those_ were a decade older, but by the late 80s
| they weren 't the only thing around to compare to.
| more_corn wrote:
| Or was it that Perl is a write only language and readability is
| maintainability?
| worik wrote:
| > Any requirements for more modern application patterns that are
| emerging in the broader web development environment, like idk....
| asynchronous I/O,
|
| A good article, but there is nothing new about asynchronous I/O
|
| This is a good article, but Golly, that was a faux pas!
| nahuel0x wrote:
| Perl was a bad language, line noise. It was better than using
| bash and awk for complex scripting, and better than using C for
| CGI pages. But Python and PHP were better and more readable for
| those use cases, and killed Perl.
| jonathaneunice wrote:
| Perl's decline was cultural in the same way VMS's decline was. A
| fantastic approach and ecosystem--just one overtaken by a world
| that was moving on to a different set of desires and values.
|
| PHP emerged as a separate language and community and "ate Perl's
| lunch" when it came to the dominant growing app style of the
| Aughties... web pages and apps. Had PHP instead been a Rails-like
| extension of Perl for the web, sigils would have reigned for many
| years more. But there was never a WordPress, Drupal, or similar
| in Perl, and no reason for anyone who wasn't already highly
| connected to the Unix / sysadmin community to really give Perl
| another look.
|
| By 2005 if you weren't already deep into Perl, you were likely
| being pulled away to other communities. If you were into Perl,
| you were constantly lamenting why newbies and web devs weren't
| using your language, just like the DECUS and VMS crowd did a
| decade earlier as Unix and Windows consumed all the oxygen and
| growth opportunities in the room.
| panick21_ wrote:
| VMS decline was bound to a failing hardware business and
| company. That's a very different thing. Unix was around in the
| 80s and VMS did fine, its when DEC hardware business went down
| the tubes VMS lost out big time.
| t43562 wrote:
| Perl was super for little scripts hence it became popular. I
| think the killer feature was its fantastic regular expression
| language which beat everything at the time. All other languages
| had to do to was neutralise that one advantage and they did.
|
| Perl was horrible to build, IMO, and seemed to require 100s of
| options to be selected which would mean that some script would or
| would not run with that particular build of Perl depending on
| what you chose.
|
| Python had a more clunky but still excellent regexp package, it
| was a doddle to build and most of the things that affected
| compatibility were things you could install _after_ the python
| executable was built and installed - i.e. users could get their
| code to work more reliably.
| unixhero wrote:
| Is anyone programming in Rakudo/Perl6?
| lizmat wrote:
| Technically, no. As Rakudo is not a programming language, and
| Perl6 is a deadname.
|
| But there are indeed plenty of people doing projects with the
| Raku Programming Language.
| rini17 wrote:
| No mention of taint mode, you had to untaint all data coming from
| user. By comparing to fixed string or convert to number or filter
| through regexp at least. If this were more broadly adopted, would
| save everyone so many headaches.
___________________________________________________________________
(page generated 2025-12-07 23:01 UTC)