Perl's decline was cultural

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.

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”.

> 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.

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.

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.

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.

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.

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!"

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?

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.

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.

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.

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.

> 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.

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'.

> 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.

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.

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.

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.

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.

> 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.

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.

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.

>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.

I only recently learned about this, maybe a month ago. It made a lot of sense to me.

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.

>>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.

Seems somewhat related to Iverson's 1979 Turing Award lecture, "Notation as a Tool of Thought" (https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...)(https://news.ycombinator.com/item?id=25249563)

People summit Qomolangma. (with logistics)

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.

If I am familiar with sed, awk, grep and xargs, was I a sysadmin ?

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.

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.

$_ 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.

>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.

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.

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.

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

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.

At least you have bash scripts. Most of my coworkers write tcsh scripts :|

(And yes, I have been pushing for bash or posix sh).

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.

> 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()

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!

> 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.

> 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.

> 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.

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.

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.

> 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.

Throw in nc and a while loop, and you can have a server too!

You might also enjoy Janet https://janet-lang.org/

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.

>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

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

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.

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).

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.

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 ×/ 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/

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.

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#the-...

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).

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).

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.

> 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.

Wow that IS cool!! Almost sounds too good to be true lol. Green threads? Repl? Event loop? One <1MB binary? What the heck!!

While I'm not a fan of Perl per se, I find it fascinating. One of the reasons for that is that its creator, Larry Wall, is a linguist by trade. This shows in a lot of ways, for example by the fact that, like natural languages, Perl has context: A variable can behave differently whether it is used in a scalar context or an array context. At the same time stuff like this is responsible for Perl's reputation as a write-only language, a cliche which has at least some merit to it.

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.