Perl's decline was cultural

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

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

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.

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.

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

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)

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 ?

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

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

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!

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.

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.

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.

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.

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