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!
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.
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.
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”.
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
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.
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.
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.
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.
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.
Hopefully I am paraphrasing you correctly.
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.")
> 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!"
- 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?
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.
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)
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.
$_ 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.
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.
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.
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.
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.
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.
Rubyists vs. Pythonistas isn't any better.
Programming languages as counter-cultural lifestyle choices is pretty "cringe" as the kids say.
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')
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.
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.
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).
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.
man 3pm Errno
my $fh;
unless (open($fh, "<", "/fangorn/spouse")) {
if ($!{ENOENT}) {
warn "Get a wife!\n";
} else {
warn "This path is barred: $!";
}
}
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 `$_`?
- What is this BEGIN block at the start of this Perl file? Why is that necessary?
- What does chomp do when it's just on its own line, with no arguments given to it?
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.
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.
I write bash scripts only because I can rely on it being there.
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.
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.
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.
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
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.
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.
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.
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.
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()
preloop:
if condition:
do_more_stuff()
goto preloop
else:
wrap_it_ip()
while condition:
do_more_stuff()
else:
wrap_it_up()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!
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.
Do you not? The pace of anthropic/Claude tool development is pretty bonkers, AI hype reminds me of the 90s a lot.
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.
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.
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.
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.
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.
Also, the early 2010s are not that recent: https://books.google.com/ngrams/graph?content=Pythonista%2Cp...
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
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.
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.
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.
> "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 ×/ 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 }
> "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]
{⍵≠' '} ' 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
└─────────┘
{⍵/⍨∨\⍵≠0} Dv # Remove leading zeroes [from a numeric vector]
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.
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#the-...
+ - * / 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).
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.
Administrative work by nature leaves you a bit bored, if you do it right. So you sometimes pick something up just to play with.
I can't speak about every sysad experience, but in mine a lot of scripts tend to be in a "make once, remember for ten years" category, and even a bit of creative naming can help a long way.
Working with a larger codebase with "creative" code, on the other hand, is frustrating. And if you don't have to write code, you might as well go take a walk, "monitoring" isn't in your job description.
I can highly recommend reading at least the first chapter of Programming Perl, it's highly insightful even if you don't plan to write or read any Perl.