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.
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.
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.
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.
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.
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.
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.
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.
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.
teeny tiny link at the bottom, oy. A site almost totally free of context. No date on the post, even. In the context of how history/journalism of this sort is normally delivered, it is absolutely bizarre.
Ironic that someone specializing in security doesn't understand how to make their information trustworthy. But I suppose it's easier and more fun to try and understand machines than other human beings.
This is what the article recommends by the way.
reply