IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects. Anything beyond array of arrays or hash of hashes was a pain. It was and it still is way superior to Python for hacking of flat files, but once you needed to go beyond a hash the pain was real.

That was 20+ years ago, and Python filled this space with its easy definition of classes and candy syntax. Where Perl overdid on hackery, Python may have overdone on sugar -- but it clearly won the love of the masses.

Now, 25 years later, the ship has probably sailed for Perl, and -- while I still prefer it to sed/grep/awk and Python for simpler tasks, I don't see it conquering Python space for more complicated processing.

I think they lost it with Perl 6. Perl 6 was a bit late, but it could have been a better rejuvenation for Perl than Python 3 was for Python.

Instead it took way too long, had confusing naming with the various implementations and frankly some features that are not very useful for anyone but linguists. I mean, why would you want to redefine your language from within the language? To confuse your co-workers? To win the obfuscated perl contest?

Perl 6 also has some real innovation like its new regular expressions. I'm afraid they will never get widely adopted.

FWIW i never had a problem with nested data structures in perl. I found the perl documentation ("perldoc perldata") to be fantastic.

Please note that Perl 6 is no longer a thing: it has been renamed to the Raku Programming Language (https://raku.org). If you want to stay up-to-date, you can check out the Rakudo Weekly News at https://rakudoweekly.blog

This is precisely the problem

This was the problem. It's now been fixed. Or do you think Perl 6 was the more meaningful name?

Eh, it sorta still is? Not really, but if you spent ten years announcing an upcoming perl6, then you rename it to Raku... There will be confusion, at least.

They should have done what the YAML designers did when they suddenly realized to their great surprise that the language they themselves designed and named was NOT actually a markup language:

Keep the exact same name and a perfectly straight face, then recursively retronymonically redefine it to mean something completely different: the opposite of what it initially meant!

"Yet Another Markup Language" => "YAML Ain't Markup Language"

So "PERL 5" is to "Practical Extraction and Reporting Language 6", as "PERL 6" is a "PERL E___ R___ L___ 6".

(Pattern matching and filling in the blanks is left as an exercise for GTP-3.)

Programmers Embraced Rasmus Lerdorf?

Perl 6 wasn't "a bit late" - the path forward meandered for years, so the point even diehard perl fans (me, at the time) questioned whether it could/would ever happen. And as pointed out down thread, the branding completely changed at least once or twice along the way, to the point perl fans of 20 years ago don't even know "perl 6" became something else today.

Where Perl overdid on hackery, Python may have overdone on sugar

Haven't used Perl often, but that's sort of my impression as well. And that Python sugar feels mostly pretty well reasoned about. And fairly usable and readable as well. Whereas in Perl I sometimes had the impression a bunch of people with CS degrees made something they thought out while on LSD and just decided to add it. Cool at the moment, but not too usable by sober minds afterwards.

As you probably know, contrary to almost every other language out there, Perl was not designed by people with CS degrees adding things that sound cool.

Perl was designed by a linguist along the principles of "what would English look like if it was a programming language?"

Not in the superficial syntactic sense, but the underlying grammar. What is the implicit "it"? What can we derive from context and decision so we don't have to spell it out? And so on.

This makes it very convenient to express common things in different ways (just like English, there is no one true way to say something) but it also creates some peculiar constructs that make sense but you'd go "who says this?" (again, much like in English.)

Ok, then if not actually designed under the influence of LSD, then certainly under the influence of religious fanaticism.

The tired old "Perl was designed by a linguist" cliché is endlessly Parroted (pardon the pun!), but doesn't actually necessitate or imply good programming language design. But look at the actual factual source of that folklore -- it would be more accurate to say "Perl was designed by a wanna-be missionary", and that certainly shows ("Exegesis", "Apocalypse", "bless", etc):

https://en.wikipedia.org/wiki/Larry_Wall

While in graduate school at the University of California, Berkeley, Wall and his wife were studying linguistics with the intention of finding an unwritten language, perhaps in Africa, and creating a writing system for it. They would then use this new writing system to translate various texts into the language, among them the Bible. Due to health reasons these plans were cancelled, and they remained in the United States, where Wall instead joined the NASA Jet Propulsion Laboratory after he finished graduate school. Wall is an active member of the New Life, Church of the Nazarene.

Going on a missionary expedition in Africa to invent and teach illiterate people of color a written language to read the Bible in certainly sounds to me more like religious and linguistic imperialism than a sound motivation for programming language design.

https://en.wikipedia.org/wiki/Linguistic_imperialism

Linguistic imperialism or language imperialism is occasionally defined as "the transfer of a dominant language to other people". This language "transfer" (or rather unilateral imposition) comes about because of imperialism. The transfer is considered to be a sign of power; traditionally military power but also, in the modern world, economic power. Aspects of the dominant culture are usually transferred along with the language.

Translating CS literary classics like the "Pascal Users Manual and Report" and Anders Hejlsberg's "Turbo Pascal Reference Manual", or even textbooks about sustainable farming techniques, nutrition, medicine, sex ed, and birth control, into their invented written language would do more economic and life sustaining good for those poor Africans than translating the Bible.

kqr> "people with CS degrees adding things that sound cool"

People with CS degrees add cool things that are sound, not things that sound cool.

Do you really believe that programming languages should be intentionally designed to be MORE like religions, MORE imperialistic, MORE evangelical, instead of less?

Compare Larry Wall's contributions to this otherwise deep fascinating conversation about language design, versus the contributions of less religiously motivated, more scientifically trained programming language creators with CS degrees, like Guido van Rossum, James Gosling, and Anders Hejlsberg:

A Language Creators' Conversation: Guido van Rossum, James Gosling, Larry Wall & Anders Hejlsberg

https://news.ycombinator.com/item?id=19568378

https://www.youtube.com/watch?v=csL8DLXGNlU&t=49m41s

James was literally taken aback by Larry's macho IDE shaming:

https://news.ycombinator.com/item?id=19568381

"I think IDEs make language developers lazy." -Larry Wall

"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling

I think this is a silly line of inquiry at best, but if one were to attempt to take it seriously, surely “there is precisely one way to do it” is an approach that would better fit the “imperialist” frame than Perl’s actual approach.

Which Imperialistic Programming Language dictates that "there is precisely one way to do it"?

Not Python -- it has Zen-like practical suggestions about what matters, instead of ideological doctrine about how to do it:

https://www.python.org/dev/peps/pep-0020/

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Does The Zen of Python really sound "imperialistic" to you?

    The Zen of Python

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

Not exactly but I think the idea that Perl (or for that matter Christianity) is imperialistic is itself absurd, so that doesn’t seem like an answer.

Anyway, the closest I’ve experienced is Go, to answer your question.

Most historians and victims of its missionaries would beg to differ that Christianity isn't imperialistic.

https://en.wikipedia.org/wiki/Christianity_and_colonialism

Christianity and colonialism

Christianity and colonialism are often closely associated with each other because Protestantism and Catholicism participated as the state religions of the European colonial powers and in many ways they acted as the "religious arms" of those powers. According to Edward Andrews, Christian missionaries were initially portrayed as "visible saints, exemplars of ideal piety in a sea of persistent savagery". However, by the time the colonial era drew to a close in the last half of the twentieth century, missionaries became viewed as "ideological shock troops for colonial invasion whose zealotry blinded them", colonialism's "agent, scribe and moral alibi."

In some areas, almost all of the colony's population were removed from their traditional belief systems and were turned into the Christian faith, which the colonizers used as a reason to destroy other faiths, enslave the natives, and exploit the lands and seas.

"Colonialism is a form of imperialism based on a divine mandate and designed to bring liberation – spiritual, cultural, economic and political – by sharing the blessings of the Christ-inspired civilization of the West with a people suffering under satanic oppression, ignorance and disease, effected by a combination of political, economic and religious forces that cooperate under a regime seeking the benefit of both ruler and ruled." -Jan H. Boer of the Sudan United Mission

There should be one-- and preferably only one --obvious way to do it.

This always felt like an excessive over-reaction to Perl's "there's more than one way to do it" motto and never struck me as desirable or true.

In the earlier days of Python I remember reading StackOverflow questions which attracted differing solutions and Python advocates (who were a bit abrasive at the time) would reconcile this with the above by saying some answers weren't sufficiently "pythonic". It all seemed rather strange.

Going on a missionary expedition in Africa to invent and teach illiterate people of color a written language to read the Bible in certainly sounds to me [...] like religious and linguistic imperialism...

Honestly, this could only be said by someone who had never met anyone whose spoken language hadn't been written. I personally know people who have recently done exactly this: Developed a writing system for a tribe of people who previously had no writing system for their own language. The people themselves are amazed to see their language written down. They have generally internalized the negative attitudes of the larger culture they live in toward their own language; they'll say things like (and this is going to be offensive, but again, it's them saying it about their own language, having internalized it from the larger African language groups around them), "I thought our language was just a monkey language". Seeing it written down gives them a sense of value and pride toward their own culture they've never had before. This is exactly the opposite of "the transfer of a dominant language to other people". On the contrary, it gives people a powerful tool to fight linguistic imperialism.

This makes it very convenient to express common things in different ways

This story has been told for decades, but it just isn't true. What is particularly convenient to express in Perl? The only thing i can think of is the implicit use of $_. Everything else is no better than or worse than in a more conventional language.

What does "really obfuscated handling of nested data structures" mean? Can you give an example?

Probably dereferencing, since Perl never had multidimensional datastructures. You'd put a reference to an array into an array value, and then access it with $array[0]->[0] (iirc) to get the first value of the first array. That was the easy way to write it, the much more annoying way was like ${$array[0]}[0] (or $$array[0][0] if you really wanted to? my memory is fortunately fading), I believe, which got really out of hand when you went three or more levels deep.

Perl has sigils for different data types.

  $foo="bar"; #scalar/string
  %hash = { "key" => "value", "key2" => "val2" }; #hashmap
  @arr = ( 1, 2, "three", 4); #array

But, it also has references, like pointers.

  $array_ref=\@somearray; # array ref
  $hash_ref=\%somehash; # hash ref
  $scalar_ref=\$some_scalar; # scalar ref

So, you can put scalars into arrays and hashes, refs into hashes and arrays, etc, etc. At whatever nested depth you want. But you have to extract pieces later. And Perl, as usual, allows a zillion ways to do it. These are all exactly the same thing:

  $$arrayref[0] = "data"; 
  ${$arrayref}[0] = "data"; 
  $arrayref->[0] = "data";

So imagine you need to extract a string that's at the bottom of some data structure. Here's an example:

  @IP = ('192.168.1.10','192.168.1.15'); 
  @PORT = ("5000","5002"); 
  @TCP = ("Q931","H225","H245"); 
  @LAYER = ("ETHERNET","IP",\@TCP); 
  @PKT = (
         \@IP,
         \@PORT,
         \@LAYER
        );
  $array_ref = \@PKT;

I can extract something using different approaches, like:

  ${${${$array_ref}[2]}[2]}[1];# oof!
  
  # same result, looks better, but imagine 
  # we put a hash in the data structure, or
  # had deeper structures

  $array_ref->[2]->[2]->[1];

Or just the simple

    $array_ref->[2][2][1];

IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects. Anything beyond array of arrays or hash of hashes was a pain.

How was it a pain specifically? If you used references, then defining an arbitrary data structure shouldn't be an issue and accessing individual elements would be a matter of prefixing the reference with the appropriate sigil.

In python, you need to be aware of when you're making a copy of an element in a data structure rather than getting a reference of that element. In perl, you would know based on syntax whether you're dealing with a reference as opposed to a copy of an instance.

In perl, you would know based on syntax whether you're dealing with a reference as opposed to a copy of an instance.

Once you 'get' the sigils in Perl, you miss them everywhere else.

They're kinda just a barely-there static-typing system, but damned if that's not way better than none. And if one recalls that monochrome screens used to be a thing, and that syntax highlighting was wonky (because shortcutted to be usable on weak hardware) and/or too computationally expensive for computers for a while after that, one really understands the appeal of the sigils. Perl is one of the most notepad-friendly languages around.

PHP's weird half-assed copy of the sigil system ($ only, for everything) is one of my least-favorite things about it (but I don't really hate PHP the way some people do, so that may not be saying much).

$, %, and @ are why using complex multi-dimensional arrays & associative arrays in Perl is non-crazymaking. You can at least state the kind of thing you're intending to use at each layer of the array, and have that intention readable even when syntax highlighting isn't available, which is a lot better than nothing.

Isn't that just a half-assed mandatory Hungarian-notation system? :-/

I mean, sure, in Perl the language "casts" the value into an appropriate type for you, but only in a few select cases..

It is pretty similar to Hungarian notation, but it also denotes context. But is it half-assed? I'm not sure. It expresses the type of the variable over a very narrow set of types. If anything you could say that the type system is half-assed. I've thought a lot about this over the years and I have come to believe that it is really a minimal type set that offers an incredibly useful set of abstractions.

For me, the main advantages of sigils are that I can immediately see if I am looking at a variable or a function name and that the sigil effectively separates the name spaces between functions and variables. This has the side effect of making it easy to distinguish functions that have been passed in as variables from functions declared or imported into the particular scope.

Even with a nice IDE I miss the distinction that the sigils provide.

To me it was the documentation. Whenever I tried to get into it, I only came across books/tutorials(I dont remember) which start with, oh pearl, here are regular expressions. And then a very very unstructured heuristical explanation of regular expressions. Usually gave up at that point.

Exactly. Perl is hardly readable, difficult to understand, and simple things (like parsing a XML) becomes difficult in Perl.

IMHO the biggest issue that blocked Perl's broader adoption was the really obfuscated handling of nested data structures including objects

Oh man did we ever abuse the shit out of the loosy-goosy data structures you could make in perl. Almost any time you needed to debug or trace something, you'd pretty print the entire data structure you were passing around. Some of those suckers would be huge and you'd be passing that structure around to almost everything in your codebase!

As an outsider it might appear scary and a massive code smell... but when you worked on that codebase it just kinda all made sense somehow. It was just how perl programs rolled.

I have yet to work in any other language that let you use and abuse the native data structures quite like you could in Perl.

How are Perl's arrays and hashes any different from those in Python (lists & dicts), Ruby or Javascript in terms of practical usage?

The linked page is down for me.

Here are alternative links to the same emails by Paul "LeoNerd" Evans

external factors email https://marc.info/?l=perl5-porters&m=161688954811345&w=2

internal factors email https://marc.info/?l=perl5-porters&m=161688963311406&w=2

Odd that there's no mention of PHP: many developers who used Perl/CGI back in the early days of server side development moved to PHP and PHP was much easier for beginners, especially if you wanted to incrementally move from a static to dynamic site. Perl was, in its day, as much the king of web development as it was admin scripting.

It's not just that it was easier, it also ran everywhere, was fast (with mod_php), did not require chmod'ing files on the server, did work even if you uploaded the file with windows line breaks, had parameter parsing and sessions built in. It was pretty quickly superior to Perl for web-stuff in my opinion.

I think what changed was that when Perl was popular people were generally a bit more into lots of wacky way to do the same thing, deliberately whimsical terminology, puns in their programs, the program equivalent of creative writing, and being a bit different for the sake of it. I think I had a Perl book at the time that tried to make a serious case for Perl programs being poetry.

I think the culture has just changed since then and most people aren't into that any more. People now seem to value one clearer way to do everything, and more straightforward terminology. Look at the popularity of much more no-nonsense languages these days.

I think unfortunately Perl just now looks deeply unfashionable, and I think even the context of why it is the way it is and how people saw things back then has sort of been lost so it's somewhat hard to explain to younger people in the community.

I’ve heard this a few times but never really saw any of that creative culture working close to a few Perl folks, besides a few funny package names. More a culture of roughness, “hacker cred” and a defensive, short-sighted, we-know-better attitude that left people stranded and is totally not welcoming to creative types. I learned very little during this time.

What you describe is what the Ruby community was in the early 2000s.

My favourite example is the 'bless' function. It attaches a class to an object, if people didn't know. I can't imagine such a name getting approved in any other language. I think any other community would say 'hang on shall we give it a descriptive name that anyone can understand without context, rather than doing this whole faux-religion schtick that will need to be explained to everyone?'

Programming is filled with weird terminology that only means something because we've gotten used to it. String? Method? Abstract method? Stack? Sure, there's a weak link between pre-existing meanings and the programming one, but so is there with bless.

String? Method? Abstract method? Stack?

These aren't per-language terms that people have to learn just to use Perl, though are they? 'bless' is. A new term for something that could have been described so simply as 'set-class' or 'give-class' or anything else using plain language.

deliberately whimsical terminology, puns in their programs

Python was like this as well, the language is even named after a comedy group. Perhaps as the culture has changed, Python has done a better job of adapting (e.g. changing the name of the "Cheese Shop" to PyPI)?

As a late coming to Python, was PyPi actually named Cheese Shop?! That's great.

But well, I guess once libraries start to actually appear there, the name change was unavoidable.

Perhaps my experience with Perl is similar to that of others who have been programming since the 1970s.

I loved Perl back in the day, when it seemed like a great alternative to constructing unix pipelines of awk, sed, etc.

Although I mostly used Perl for interactive use, I also found it helpful for quite a few short programs, say in the 20 to 200 loc category. But I noticed a problem: these programs were tricky to understand a year later. Perl was still useful, mind you, but just not as pleasant at the edit stage as it was at the writing stage.

And then Python came along. It soon became clear that Python programs would "age well". For quite a while, Python and Perl coexisted in my toolbox.

And then Perl started to drift into it's present state. All the new goodness (and I'm sure it is good) just seemed to come at a cost of more complexity. But why should I learn the new way of doing Perl, when Python was already filling the gap for that sort of work?

Gradually, my use of Perl decreased, from every hour to every week, to ... well, never.

I wish Perl had just gone into bug-fix mode long ago, so that it could have remained a reliable and understandable tool for a certain set of tasks. And then I'd still use it for pipelines, as I use awk, sed and the rest.

I started with Perl and Python much later (mid-to-late-2000s) and my experience is the opposite. Python programs aged horribly (just after 6 months it could be a half day's work to get the build working locally again) whereas with Perl programs, written correctly with plenty of tests, I could jump into them two years later and everything just worked exactly as where I left it off.

I'm sure python has had several improvements in this regard since, but it just seems to me like it comes at a cost of more complexity (virtualenvs and whatnot.)

I still use Perl for occasional one-liners in pipelines as well (where it's simply more expressive than sed or awk), but I've given up on it for scripting in favor of (first) Ruby and (later) Python. About a decade ago, though (long after I'd switched to Python), I found that a regex-heavy program I'd written for processing terabytes of JSON files ran several times faster in Perl than in Python. I wonder if Perl still has a noticeable edge in text processing speed?

Having started with more modern scripting languages, such as ruby, javascript, or python, every time I touched perl I felt it was actively fighting me. Those sigils! God, those sigils! It's bad enough that we have to prefix variable names with a dollar sign in php, as if a language parser can't be smart enough to figure out whether you mean a variable or not; but having to use three different sigils for scalar variable, array variable and hash variable, and needing to know when to refer to the same variable with the array sigil or the scalar sigil — this is just vile. Things like $_ or @_ didn't help either.

Probably people who took up perl after something even more adversarial can learn to love it. I doubt I ever can.

What I did love about perl though — something I don't find in modern languages — is its carefree playfulness, which must have stemmed from the hacker culture associated with it. I still chuckle every time I use Carp for debugging. Carp::croak, Carp::confess, or Carp::cluck are genius!

I worked on and off on perl for about a year... Could never remember $_ and @_ which one was which..

The sigils are a feature that underpin perl's roots from practical linguistics (unlike other languages which have roots in theoretical linguistics).

$ - > the value of

@ - > the values of

% -> the collection of key value pairs

$_ is pronounced "it". @_ is pronounced "them". Don't use either of them except if it would make sense in english - e.g. you wouldn't refer to "it" in anything more than a sentence, so don't use $_ in anything longer than a couple of lines of code

The sigils are a feature that underpin perl's roots from practical linguistics

I am not sure this metaphor makes sense to me.

Imagine that I have a pack of dogs. When I use a language to say: "Remember that pack of dogs that I mentioned previously? Go ahead and give it to me" — I do not expect to also need to specify whether I want the pack with all the dogs in it, or whether I just want some value associated with that pack, which, if I remember perl's behaviour here, would be its length. I could understand if a language wanted me to specify whether I want the thing itself as opposed to a reference to the thing (I suppose it would make total sense as a Saussurian opposition of a signifier vs the signified); but the ternary opposition that perl enforces is neither here nor there linguistically — it's just bizarre.

What I did love about perl though — something I don't find in modern languages — is its carefree playfulness, which must have stemmed from the hacker culture associated with it. I still chuckle every time I use Carp for debugging. Carp::croak, Carp::confess, or Carp::cluck are genius!

As someone who works with a legacy system written in Perl (we're slowly moving to Go), I absolutely hate this. It's completely obscure for no reason, and that's just not fun. I'm glad no language does this anymore.

Same goes for Perl critic levels: --brutal | --cruel | --harsh | --stern | --gentle, they're all compleyely useless at conveying any meaning! why is brutal > cruel??

erg that's one thing I hate about modern tools, they love to use stupid terminology like helm with charts and salt with pillars and all this other childish shit.

they love to use stupid terminology like helm with charts and salt with pillars and all this other childish shit

Chef is the worst for this

That same feeling of carefree playfulness is also the reason I keep meaning to give Raku a visit. They're pretty explicit about it even with pages like https://raku.org/fun/ and https://raku.org/whatever/. It looks like they've done some interesting stuff around making text-based command line tools really easy to work with, which makes sense since that was a huge part of perl5's wheelhouse, so I think that may be a good place to start digging into Raku.

I concur. My English is pretty good, but to fully master these naming conventions, one needs to major in English.

For Christ's sake, I keep forgetting what "croak" and "cluck" even are in, you know, normal language usage.

Same, croak and cluck don't map with actual words or meaning in my mind. I just know croak is fatal and cluck is not. It's infuriating.

Sigils are for simpler visual parsing - they stand out and mark the 'nouns'. It is not about the compiler - but about people reading the code. I know you can get similar advantages with IDEs colouring the code - here it is in the language itself. I find it useful. I think people just don't like the typography of dollar sign. It is ergonomic because it stands out but it is uglier than other glyphs and that impresses people badly. Later they only look for confirmation of that first bad impression.

But I agree about the use of '$' for array elements. '$array[$index]' - this is kind of unintuitive - because the array is @array - and here you need to change the sigil. That is why in Perl6 (and Raku now) they got rid of that.

Sigils are for simpler visual parsing - they stand out and mark the 'nouns'. It is not about the compiler - but about people reading the code.

I would argue that python, ruby, javascript and similar languages have demonstrated that it's just as easy to read code without sigils as with them, probably even easier — let alone to write one. Uncle Bob and other evangelists of software craftsmanship suggest clear, descriptive names for variables that would convey their meaning to the reader. As far as I understand, perl programmers also don't dispute the value of meaningful names. At which point using additional twiddles for conveying intent to the reader becomes redundant.

The advantage with sigils, that little bit of standardized extra information means that I don't have to do any work to distinguish a verb from a noun. It makes it possible to use names that are just a bit shorter, on average, without sacrificing readability.

It's funny to me to see the same people who complain about sigils in perl whole heartedly adopt the Rx convention of naming streams with a tailing $.

It's literally just a sigil. Yeah, you put it at the end, but it serves the same exact purpose.

It's funny to me to see the same people who complain about sigils in perl whole heartedly adopt the Rx convention of naming streams with a tailing $. It's literally just a sigil.

This one is a naming convention. Same as how the previous generation of javascript developers used to prepend variable names with a dollar sign if those variables referred to jquery-wrapped objects. Same as starting class names with a capital letter, or using all capitals to name constants. It doesn't have any special meaning for the parser. Your program won't break if you don't follow these naming conventions. It's entirely a style thing.

I think the author is way to generous to the PERL community and the drama of PERL 6. I think the toxicity that eventually led to Larry Wall bowing out is being replicated in Python and Guido leaving. I left PERL for Python in the mid-2000s because it was clear with the Parrot engine and other misguided notions by the PERL bullies that the PERL leadership was bent. Now that Guido is out it will be interesting to see how long Python retains its perch. I think the demise of PERL would have been vastly different if Larry Wall hadn't been forced out.

One of the factors which lead to Perl's decline is there are too many ways to do it :-)

This is fine for a lot of stuff, but somewhere in the 2000s, it became increasingly annoying you could not properly use Perl's biggest value up to that time, CPAN, anymore, because when you brought in 5 dependencies, you ultimately had 5 different object systems, 15 type validator libraries, 5 different time libraries and probably 20 different exception systems in your project, all happily eating away at your memory and your sanity.

This is still a major problem today, where you basically cannot pull anything from CPAN anymore without the smallest package requiring a different fat object system.

A lot could have been avoided by early on building a proper standard library delivered with the language, but instead at that time Perl delivered a lot of obsolete cruft, simply because it always was part of Perl, instead of real basics.

That's at least my take on things. Though of course, npm proves many people do not give a damn about overly long dependency lists, so maybe it's just what I personally dislike about the direction Perl has taken.

External factors?!?! C'mon, admit it is just a terrible language.

There were 2 mails, one external and one internal.

I feel like the old Perl saying "There's more than one way to do it" Is what makes Perl a powerful tool for an individual, and an impediment to progress in an organization.

It's possible to be expressive enough in perl that your colleagues cant really fully understand what it is you're trying to accomplish.

I've made a presentation on this very subject to a hackers conference in 2013. It's very clear to me, it's because of Perl6. In 2013, Perl was 26 years and Perl6 was 13 years already, half as old as Perl itself but nothing close to production ready.

The launch in fanfare of Perl6 in 2000 had a general chilling effect on Perl: many people considered from that point that there was no point learning and using Perl 5, because Perl6 was "just around the corner" and was "the future of perl".

It's just last year that people finally came to their mind : Perl6 became Raku and is a different language, period. And Perl 5 is supposed to get out of its 20-years of maintenance cycle by becoming perl 7 and changing some defaults it should have done back in 2007 or so...

Well. That's life.

As someone who learned both well after the 2000s, it was painfully obvious to me that Python was easier to learn/use and had a lot more momentum than Perl (this was around 2012). I think that's really the nail in the coffin in that they both cover the same scripting niche, but Python won out and less people began to use Perl. Also, Perl5 has a modules approach in that there are several potential OO frameworks like Moose, while Python had it as part of the base language which a lot of people prefer. Python also became a solid data science and numerical methods language, so it ended up winning out. I never thought Perl5 was bad, just not as good as Python. As far as P6/Raku, I think the language design is good, but I won't use something like that professionally until it reaches a certain quality and production readiness. It really is pretty neat and is like a superior Python without the useful frameworks.

Edit: the Python REPL approach was also much better for debugging scripts than how I had to do things in Perl.

In one of my previous positions, part of my work was maintaining legacy build and automation scripts, many of which were written in Perl.

The one thing that stood out to me, was what happened when I had to show somebody else what a script did. (I was always showing somebody with some programming experience, but not always with the matching language).

It didn't matter what language they had experience with, Python was always easy to walk them through the code. I know this sounds scary to most, but when you are low on people and even lower on resources, you do what you can.

When I needed to explain Perl to somebody without Perl experience, the eyes would glaze over as soon as @ and $ and % characters started showing up (re: immediately).

It's not that Perl isn't a great or powerful language. It is. I use Perl style regex almost every day. Perl taught me hashmaps.

But Python code looks familiar to a lot more people. No mystery symbols. No needing to explain that the @ symbol is an array, except when reading from it. Then you use $.

When I explain Python code to someone who doesn't know Python, they ask me about the actual code. Why I made certain decisions regarding the design or functionality.

When I explain Perl code to someone who doesn't know Perl, they tell me it looks like gibberish.

When I explain Perl code to someone who doesn't know Perl, they tell me it looks like gibberish.

I had a very brief experience with Perl in school around 2001-ish.

All those concepts you brought up made me never want to touch it again. The language just comes across as a tool made out of necessity in the 1980s / 1990s, but then better tools came around.

But, more importantly, I will never apply for a job that lists Perl. It's just a relic from the past.

But, more importantly, I will never apply for a job that lists Perl. It's just a relic from the past.

Good. More Perl jobs for me then. Although I kind of got bored with Perl and would probably enjoy coding in Ruby or D or even Crystal.

That's not the issue.

The bigger issue is avoiding jobs where the management chose an "impossible" stack. IE, a stack where the technology choices actively impede productivity.

Unless the job basically involves modernizing something that's been around for a few decades, why would anyone do new development in an outdated language?

After working a python shop for few years one thing I always liked was it was rare that you could tell who wrote what bits of code. Not sure why that was... it might have been how the language itself forced certain idioms. But typing this out I also think it could be the shop’s practice of face to face code reviews. Before you’d merge anything into master you’d always snag somebody to sit next to you and look over your code.

So it could have been the language, but it could have been the culture too.

Python and Go are both like that. The language really encourages a single way of doing things, so when a new programmer sticks 20 lines of new logic in the middle of someone else’s file, it quite often aesthetically blends in. I like it, but sometimes there’s a trade off against power and flexibility.

I've had to read other people's Perl code before, and that experience basically made "flexibility" a bad word in this area for me.

Please stop the ^$%@#$%#@^@$%^&( nonsense, Perl hackers. That's not flexibility, it's childish bravado. Write code that people can read. If some of that precious "flexibility" is lost in the process, that's a net gain actually.

No needing to explain that the @ symbol is an array, except when reading from it. Then you use $.

Perl is stuffed with unforced errors like this. Lack of named parameters! Reading from filehandles by putting angle brackets around them! Filehandles being a distinct type from scalars! Hashes and arrays not being usable in the same way scalars are (can't put them inside an array or a hash, have to use a reference)! Even at the time, this stuff was distinctively bad. I wrote loads of Perl in the late '90s, and as soon as Python became viable, i leapt at it, because the language was so much simpler and more uniform.

All this is particularly wild considered in the light of the fact that awk, an explicit precursor to Perl, has a significantly simpler syntax. How did Larry Wall look at awk and think "i know, what i need to do is take out the named parameters, and add some more sigils!".

I do wonder if, it hadn't been for Perl, there might have been room for awk to grow into something more general. Probably not. But i don't see any technical reason why not.

I agree with you on a lot of this. Complex (nested) data structures are a real pain in the ass in Perl, especially back in the early 2000s.

However, named parameters have been a thing for ages. It's extremely common to call functions using an anonymous hash like so:

  $sock = IO::Socket::INET->new(PeerAddr => 'www.perl.org',
                              PeerPort => 'http(80)',
                              Proto    => 'tcp');

By named parameters, i mean:

  sub double($value) {
      return $value * 2;
  }

Which you can't write in Perl (or at least couldn't in 1998). You have to write this:

  sub double {
      my $value = shift(@_);
      return $value * 2;
  }

"Named parameters" probably isn't the right name. This is such a basic feature of programming languages that i don't even know what it's called.

The term you are looking for is "pass by reference".

Perl does not have pass by reference, you have to use pointers if you want to do it. It will even go so far as to duplicate an entire array or hash you pass to a function, which can surprise novice Perl programmers when they build a giant data structure and start passing it around only to discover their program running slowly. Or worse, finding their changes to the structure being undone when the function exits.

The term you are looking for is "pass by reference".

Nope, just parameter declarations. I also kind of doubt the by-value semantics will surprise anyone the way you describe: If you pass things by value without explicitly taking a reference, the structure (arrays and hashes, specifically) will be flattened into the argument list. If you're unaware of this, things will probably go wrong long before you've had time to be surprised by stuff getting copied...

This is the correct answer. Python and Ruby pretty much ate Perl's lunch. Depending on whatever you were working, one of those two languages, was almost always a strict improvement over Perl.

The only place really shines comparatively is in CLI one-liners. But even there, awk is usually a better tool.

" Also, Perl5 has a modules approach in that there are several potential OO frameworks like Moose, while Python had it as part of the base language which a lot of people prefer."

Perl's built-in OO, without Moose, works fine, and isn't substantially different from python's.

What is different is that "everything is an object" in python. That's not true for Perl. So Perl OO is a bit saddled with references (pointer like things) and sigils ($this, @that, %theother) and therefore intimidating looking data structures, dereferencing, etc. To me, that's what makes OO Perl painful. To be fair, it's also one reason why Perl is often a lot faster than Python...basic types don't have the same amount of overhead.

Personally, I love Perl and still use it often. But I can see why Python sucked away the user base.

I like Perl, and find the complaints about sigils weak given how many people swear by POSIX scripting, when there are so many better tools out there like Perl.

However I also found Perl’s OO to be painful. I’d call it a cruel joke. I could never comfortably wrap my head around its implementation because it always felt like a horrible kludge on top of the module system. Is it a module? Is it a class? Is it an object? Are they normal functions? Are they class methods? Or are they member methods? The answer to all for these questions is a resounding yes! TIMTOWTDI bites us once again.

Perl is great for its primary use case of being the thinking person’s BASH, and it has the greatest regexp and stdio support for any language I’ve used, but I wouldn’t build anything OO with it.

I didn't mean to say that sigils were a general issue. Just that they made complex data structures (and thus, OO) more complex...and intimidating for newcomers.

As for wrapping your head around Perl OO, really it's just bless(). Bless($thing,'namespace') says "this $thing is an object, in this namespace". You can make an object without adding a namespace beyond the default main namespace...

Like:

  sub test {print "whee\n";}
  my $foo={};
  bless($foo,'main');
  $foo->test();

That will print out "whee". Because I "blessed" $foo into the main namespace, calling $foo->test() is calling the subroutine "test" in the main namespace, with '$foo' as the first argument.

So OO in Perl is just mapping a namespace to a blessed reference via bless($ref,'namespace'). Then $ref->call($arg) runs the "namespace::call" sub, but as if you did namespace::call($ref,$arg).

It's very clear to me, it's because of Perl6.

It doesn't seem right to ignore the increased popularity of better and more user-friendly interpreted languages such as python, which has since became ubiquitous even in spite of the python2-python3 transition.

Also, there was the inception of node, which brought javascript front and center.

In fact, among the interpreted languages that were popular 20 years ago, which ones besides python still hold some relevance?

Perl, whether v5 or v6, can't exactly compete with javascript or python in terms of ubiquity and user-friendlyness.

If Perl's learning experience is harsher, and in the end there's less demand and job prospects, why would anyone pick Perl over any alternative?

PHP was popular 20 years ago and seems to still have wide adoption.

The fact that PHP was, in the era of shared hosting accounts, the default scripting language was like a slingshot maneuver around the sun. It's hard to understate the incredible momentum that surge of casual users brought to it that no other language received, and has sustained it over the long, painful modernization that was needed to make it relevant today. More than PHP, we're still using platforms that were begun in that era: WordPress, Drupal, etc. There's still Zencarts out there.

It's more remarkable that Python is still relevant, which is a testimony to the overall quality of its design and its usefulness in a large number of different areas. Had Python been only a web scripting language, it would have been eclipsed by PHP just like Perl.

I don't know about quality of design. Python's popularity is largely due to how much it dumbs down and being a first mover in the scientific world. Python has no built-in regex support and its crippled lambdas are nothing more than the indulgence of its BDFL who has a bias against functional programming. Compare that with Matz's approach to language design.

Python has no built-in regex support

Are you basing this claim on something like not having a special literal syntax? Python has had regular expression support for ages and it works quite well: https://docs.python.org/3/library/re.html

Yes, I'm comparing it to languages which have regex operators (Perl, Ruby) and where you don't have to `import re`.

Having been raised into the profession at a time when both Perl and Python were strong, the amount of times I have had to reach for regexes as a frequent solution to a problem is so rare that I can hardly see how it's a problem.

It's about as much of a problem as not having built-in linear algebra operators.

I think two major things, beyond the sheer audacity of it, really slowed Perl6 down. This is NOT meant to sound negative; I basically owe my entire career to Perl. I got paid to write Perl every day from 1993 until 2015, and I still really like the language, warts and all, and love the amazing features/ideas in Perl6/Raku.

The first is Larry Wall's basic personality. He is a really nice guy, all the way through. Along with that, I think he's fairly passive. Years ago, I read a comment from him where he noted that of all of the things he's posted online, the vast majority were replies. He rarely directly initiated.

Clearly he initiated Perl, as well as https://en.wikipedia.org/wiki/Patch_(Unix) (for those who might not know, this was basically the reverse of 'diff', and is effectively the spiritual ancestor of MANY of the tools and technologies we use today.)

But the genesis of Perl was really small; like Linux and many other projects, it was done to solve very specific problems, and also for the fun of it. Perl utterly exploded, effectively dragging Larry Wall along with it.

All that to say: even as Larry was able to put forward technical direction, as seen in the creation of Perl6 and subsequent design/development processes, I don't think he ever felt very comfortable being a community leader.

The second major factor early in Perl6 was that Larry had some substantial medical problems at really key, important times.

I don't know if these and other factors, if different, might have allowed Perl6(Raku) to become successful. It's possible that the sheer, awesome scope of Perl6 was just too big.

One way or another, what ended up happening was a damn shame. In retrospect, I think it's clear that Larry should have, in 2000, announced the creation of a new language, a language that shared many/most of the broad goals and ideas of Perl.

But 21 years ago, such an announcement would have been almost impossible. The total amount of hurt and divisiveness that ended up coming about due to Perl6 might have been minimized with such an action, but it would have been strongly front-loaded, with an unbearable amount of community pain concentrated into a single point.

I believe Jon Orwant's mug was largely responsible for Perl 6.

This is exactly it for me. Perl just seemed to be stuck in a stasis with the whole Perl6 mess for over ages while the world moved on. I still maintain some perl scripts and it's great for small tasks, but by the time they got everything sorted out no one under 30 knows perl at all anymore as it seemed like a dead end.

"while the world moved on"

yet the world still does not have half the features Perl 5 already had for 20 years :)

... from scoping to support for every major programming paradigm

Much as I like Perl I'm not sure I'd agree with you. What does Perl have that Ruby doesn't?

That's pretty much exactly it. The core of the perl community decided that what they really wanted to do was spend their time bathing lazily in their shared hubris, designing (with... surprising patience) a new perfect language. And I don't really blame them, that's a lot of fun.

But perl had become successful not by being a perfect embodiment of TMTOWTDI or whatever but by being a simply amazing practical language for practical problems. And without the support for the practice of perl, perl 5 rapidly withered as new problems became more practically solved in Python or Ruby.

It's worth noting that Python almost did exactly the same thing to itself, too. But it was saved because Python 3 wasn't nearly as incompatible as Perl 6, and that it actually shipped reasonably promptly. But IMHO it's no accident that the explosion of node.js happened just as Python broke the world with their incompatible upgrade.

It's worth noting that Python almost did exactly the same thing to itself, too. But it was saved because Python 3 wasn't nearly as incompatible as Perl 6, and that it actually shipped reasonably promptly. But IMHO it's no accident that the explosion of node.js happened just as Python broke the world with their incompatible upgrade.

Not totally sure that I agree here.

I wrote backend Javascript code when Node was beginning to become popular instead of Python because I needed to write a multiplexed socket server that was much better server by the JS asynchronous paradigm over Python. Socket.io was a much better experience than much larger, complex Python equivalents which performed worse, so I kept around most of my Python code and used Node for multiplexing.

At the time Python 3 wasn't even a question. There was no push to upgrade seriously, just patiently waiting for the libraries and frameworks to be ported.

To this day Node.JS and Python server fairly different purposes in most stacks, and although they can do the same job, for each domain generally one is better than the other.

I used Perl on and off for decades. It was fine.

It seemed that Perl allowed me to leverage my existing knowledge of UNIX utilities, regular expressions, etc. So using it wasn't completely like learning a new programming language and a set of libraries at the same time. In other words, the startup cost wasn't all that high.

I agree with comments about doing anything too complex with data structures in Perl. I am sure there are people that easily remember the syntax for returning a reference to a hash of hashes, or whatever. I'm not one of them. Every time I have to work on applications I wrote previously that did this, it's a couple of hours of googling and trying things out in the interpreter.

If I had to write or rewrite a large application today, I'd probably use Python. I learned it fairly well about ten years ago and enjoyed working in the environment.

In my secret inner fantasy world, I'd use Common Lisp exclusively, my colleagues would just agree that it is the best programming language ever, and we'd spend our days sitting in an outside cafe in San Jose, drinking espressos, hacking our .emacs files "for efficiency," and telling stories about how we used to boot computers by first toggling in the boot loader from the front panel.

I am sure there are people that easily remember the syntax for returning a reference to a hash of hashes, or whatever.

Ehhhhh. I appreciate the opaqueness of Perl, but you've described something like the easiest data structure in Perl to write and access: return {"foo" => {"bar" => "baz"}}; return {foo => {bar => "baz"}}; $data->{foo}{bar} = "quux"; etc etc.

It's when you drop away from the land of hashrefs and listrefs, and have to use plain old hashes and lists, that things actually get super weird - because most programming languages you're used to simply give you "refs" for everything, and they definitely don't have concepts like "list context" that let you merge lists by saying @a = @b, @c;

A wild Python suddenly appears:

  third_list = [*first_list, *second_list]

You don't even need a "list context" for this!

I wonder if you've hit on a major factor of Perl's decline. Like you say much of Perl's power was leveraging existing unix utilities, the whole duck tape development thing. As more developers started growing up on windows and then macs, fewer developers had knowledge of the tools to tie together. Without the unix tools to tie together, perl's value proposition drops.

I believe this is a major reason. Demographic shift.

Perl grew to prominence when being a creole of C, shell, sed, awk, and lisp was an advantage. Anyone who might reasonably use it would be familiar with at least a few of these tools.

Now, we live in a very different world. JavaScript is the new BASIC. Everyone has JsBASIC installed on their (virtual) machines. So that's what people learn on their own. Python and Java are closer to JS so, the transition is easier (at least superficially--I could argue that JS and Perl a lot in common, designwise).

I've been happily using Perl daily for 20 years. I still use it daily, despite slowly moving to NodeJS for most production work. There's just some things that Perl does better than everything else -- text processing and gluing external programs together, namely -- that I very frequently find myself doing.

I was a Perl coder, it was my first commercial job. I remember being excited for Perl 6. But looking back at it in retrospect after years, I'd now put it in the category of "languages that have a gimmick", something they follow too faithfully because it initially seems clever.

Perl's gimmick was "we had this text processing language based on linguistics theory, and we hung stuff off the side until it became a proper language". What the result was, really, was something that went through text like a swiss army chainsaw, but was a damn clunky mess doing real language stuff. Even if it was, for the time, pretty damn neat in its overall list of features. This neatness gradually paled as everything else caught up and surpassed it.

Nothing since has changed this. Raku still has the gimmicky feel - because that is what defines it as (a) Perl.

There are simply better syntaxes - better, even, nowadays, for text processing and sysadmin, where I'd reach for Ruby. And if I'm not too fond of Python, at least it's mostly uncomplicated.

I think at this point you can stick a fork in it, the gimmick has run its course, it's done.

I think it was more than a gimmick. It scaled down brilliantly. For people who mastered it, it was an incredibly powerful command-line tool, and it worked well enough for small scripts.

It scaled up horribly. It showed its weaknesses in larger scripts, and it was gratuitously bad at any scale above that. And of course, as a bundle of idioms with no surface coherence and no unifying logical principles, it was grotesquely hostile to anyone who had not spent a lot of time immersed in it.

But as a tool for command-line wizardry and small-scale scripting, for tasks that didn't need to be shared or maintained outside the priesthood of sysadmins, it was brilliant, and it hasn't been bested or even equaled as far as I know. I think the only reason it fell out of favor is that you can never be sure that a task won't grow beyond this little realm where Perl shines.

I was a bioinformatician who worked on the Human Genome Project [ https://www.foo.be/docs/tpj/issues/vol1_2/tpj0102-0001.html ]. I used perl daily for years. In ~2004(?) I attended a San Francisco Perl Mongers User Group meeting where Randal Schwartz confirmed that Perl6 would sufficiently break backwards compatibility that the CPAN would be started from scratch. I walked out of that meeting and said out loud "oh well, I guess it's time to switch to python".

I firmly believe that it wasn't specifically about the switch to perl6, it was about the loss of the cpan that broke the camel's back.

I guess it's time to switch to python

Which would go one to have its own breaking change.

I used to be on many mailing lists and noted the decline of traffic long before the announcement of Perl 6. While you could argue that everything that could be asked had been asked, I do not know if I buy that. Stack Overflow suggests that there's a baseline of questions out there because new people are always arriving; I would then expect that mailing list question rate to level off at some trickle, but it completely stopped in some groups.

Perl's readability is low, in my opinion, due to a few factors. First and most obvious is the reliance on, well, tons of symbols, resulting in the refrain "executable line noise." The second factor is the philosophy of there being more than one way to do it; this means that you have less local idiom in the language and so you have to spend more time guessing how this programmer did it. The third factor is what I would consider cultural: one-liners. The one-liner is an interesting exercise but it only proves how clever you are in writing the code for a very arbitrary restriction, the number of characters used, and the tradeoff is readability.

Another big arc would be CPAN. So many modules, each covering a different eighty percent of what you needed to do. And heaven help you if you were on Windows for some odd reason because many of those modules needed a compiler, or at least the ones I came across did. The standard library was simply too anemic, and so you were left trying to find just the right package and hope you could work around its shortcomings instead of doing something obvious and getting on with your day.

I do not buy into the network effect of the article. Perl was there before Python, and it was larger than Python for some time.

Culturally, it was a ticking time bomb, waiting to be supplanted by a language that was not a write-once, read-never design. In a similar sense, PHP's culture assured its fast adoption and rise, but also would bring it an ugly reputation, which it still struggles with -- perhaps now unfairly!

Any analysis of Perl’s decline that doesn’t mention PHP is incomplete. Between the height of Perl’s popularity in the 90s and today, web development was the single biggest growth area, and PHP ate Perl’s lunch in that domain.

Why did that happen? In my opinion, PHP had two major advantages over Perl:

1. mod_php for Apache could safely be run in a shared hosting environment, so hosting for PHP was cheap and ubiquitous. mod_perl couldn’t be run in shared hosting, so anyone doing web development in Perl was stuck with either using CGI, or paying for more expensive dedicated hosting.

2. PHP’s approach made it easier to get started for people who were new to web development, or new to programming entirely. This was important in the late 90s and early 2000s as a huge number of people started doing web development for the first time.

By 2000, PHP was already the dominant “scripting language for the web”. If the Perl community had focused on improving web development, then maybe Perl could have caught up, but they focused on Perl 6 instead, and PHP continued its growth without much serious competition from Perl for web development mindshare. MediaWiki was written in PHP in 2002, and both Facebook and Wordpress were written in PHP in 2003.

The article focuses on Python, but during the relevant time period (roughly 1995-2005) Python was a niche and unorthodox choice for web development. Python finally started to gain traction for web dev in 2005 (Django, Pylons, TurboGears, and web.py were all released that year), but by that point Python was mostly competing with PHP, and Perl was already much less relevant.

In summary - the article focuses on how Perl lost the market for scripting, but scripting was always a smaller and less important market than web development, and PHP killed Perl in the web development market. If Perl had stayed relevant for web development, it likely would have stayed relevant in scripting as well, because programmers like to use languages they already know (see: JavaScript). Perl 6 was the nail in the coffin that ensured Perl wouldn’t catch up in the web dev race that it was already losing.

Excellent point. For the same reason, Ruby/Rails is worth mentioning too. The article does mention Ruby, but not Rails.

Rails didn’t really pick up until 2005 either, by which point Perl had already faded considerably.

The most interesting counterfactual is “What if someone had written something like Rails for Perl before 2005?” It was definitely technically possible, and it might have made Perl take back off (Ruby usage grew from basically nothing due to Rails), but the community’s focus on Perl 6 at the time made it much less likely.

Perl had Mojolicious which was almost as good as Rails and a lumbering beast called Catalyst which was used at the BBC.

I agree with this. Deployment of Perl was a pain in the ass. With PHP you literally just FTP’d the files to your normal web directory and you were off to the races.

Even today PHP still has that advantage over many other languages. To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go.

That being said these days the other languages become their own http server and are usually fronted by a reverse proxy or two. But still that is like an order of magnitude harder to stand up than PHP.

To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go.

Doesn't that just depend on Apache settings? You can set up Apache to serve all requests ending in .py as CGI. As long as these scripts emit HTML the situation is the same as PHP.

Small nitpick: it doesn't, and never had to be, HTML that was emitted. Executables were/are responsible for headers (including `Content-type`) as well as the body.

An example of this was the old, classic, counter.cgi which, when accessed would:

* Read a file containing an integer

* Increment the integer in memory

* Emit a .gif with the new value

* Write the new value back to the file

That's a bad order to do things, is that how it worked?

There is a huge window while emitting the .gif during which other visitors may appear. At best a new visitor appearing during another visitor's "emit gif" phase does not increment the counter, at worst a visitor on a very slow line causes the cgi instance for this visitor to run for a long time and then write back a very old value to the file, making the counter run backwards.

For things that matter, the counter reading+increasing should be an atomic read-modify-write. But since this is just a web counter, I guess it's sufficient if you at least keep the hazardous window very small (by not doing the write-back at the end).

Heh yeah. It didn’t matter because there weren’t that many people hitting the pages. It was more of a thing to do that was cool because when it hit like a thousand you would be like “OMG a THOUSAND people all over the world have visited my page, what a world we live in”

For this case, eventually consistent is good enough

If you're not locking the counter whilst reading, incrementing, applying, and updating it, what you're eventually getting ... isn't really consistency.

"A widely shared myth" would be more accurate.

On PHP 25year birthday Rasmus Lerdorf talked about how php came to be. He literally thought something better would replace it at all times.

https://thenewstack.io/php-creator-rasmus-lerdorf-shares-les...

I think he thought it would be Perl:

"And Lerdorf tells an only-in-the-1990s story about the day when Perl finally also released its own optional embeddable module for Apache web servers — mod_perl. “They’d made it way too powerful… If you were on the virtual host on an Apache server, and you had mod_perl access, you could steal the requests from every other virtual host if you wanted to…” Because of this vulnerability, ISPs wouldn’t offer mod_perl alongside other clients in a single Apache instance.

“So if you came to an ISP and said ‘I would like mod_perl‘, they would say, ‘Okay, that’ll be $600 a month,’ because back then, we also didn’t have VMs, containers, anything like that. So you had to have a separate, physical bare metal box for mod_perl. Whereas on PHP, you could put 3,000 customers on one machine, versus one mod_perl customer.”

the 25 year php talk: https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s

Perl 6 wasn't the main factor. In the early/mid-2000s Perl lost mindshare because it's PHP equivalent - HTML::Mason - relied on mod_perl which cheap hosts were reluctant to offer for many reasons. Perl's main web framework, Catalyst, was a beast and only a few big companies took it seriously. There was also Mojolicious and Dancer but they never hit the big-time either.

Internally the Perl community fought with each other over how to implement OO. A Meta Object Protocal (MOP) was hotly debtated but the main implementation remained just a library. Likewise with Perl's main OO library Moose which spawned lightweight offspring such as Moo. TIMTOWTDI became a liability as competing scripting languages with built-in OOP (Ruby, Python & PHP5) ate Perl's lunch.

Perl also lost a lot of mindshare to Python in the an area it had dominated for many years - system administration.

Totally agree on point 2.

PHP's documentation was always excellent, available and was always a quick Google search away from finding the relevant materials. It was tangibly superior at the time.

Coding with other languages at the time always involved some kind of physical reference book (or some closed off "compiled" walled "context sensitive" help system whose search capability and discoverability was little-to-none).

Although I had sooo many O'Reilly reference books, I don't think I ever had an O'Reilly PHP reference book... (Not sure there ever even was one because it would be totally unnecessary)

I know both Python and PHP had numerous successful and moderately successful web frameworks. I don't know what it was like with Perl, was it still much more roll your own custom set for each app from libraries?

I started to make money writing in perl when it was long on decline already, in 2005-2007. I've switched to ruby after that. It's not widely known, but perl had a lot of influence on ruby, in much cleaner syntax and without baggage of text-only-processing scripts of early 1980-es

I was a Perl dev for more than a decade and the only problem we had was when we started to grow the company. We needed programmers who could do Perl but graduates had not even heard of it. How do you evaluate a graduate who had been taught Java as to how well they would do with Perl? Would they even want to learn it?

Learn Java. Work in finance. Take the money :)

Perl devs were self taught hackers. Finding them was nigh on impossible

We ended up with a bunch of Java devs and pivoted to Java for all new applications. As a commercial decision it was sound and the company is doing well

I'm doing Ruby now and facing the same problems but at least the graduates have heard of Ruby so they at least know what we are asking them to do

And yes Perl6 was a massive issue. At least they finally acknowledged that it was really a Perl inspired language and not Perl at all

I've been doing everything in my power to avoid perl since the early 90's. It's a garbage language. It thrived in spite of itself. Its obtuseness is fetishized. Its users have Stockholm Syndrome. I don't know what else to say. Bracing for downvotes.

"In practice, Python has snowballed simply because of network effect. Everyone knows Python so everyone uses it so everyone new has to learn it."

Sigh. You would think that reflecting on a thread the author knows is public would have better introspection than this, but there's that Upton Sinclair quote again:

“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”

Python didn't win simply by randomly being selected as the choice to snowball effect on. Ask any language-agnostic or new programmer to take take a gander at each one. 90% will find Python easier to use. That's where Python's strength is, and that is a huge market, as the general population just isn't that great at advanced lower-level programming like C++. So you have college intro courses and programming-adjacent fields in academics (stats, bio, etc) able to dabble into Python. Perl kept plodding on with it's diehard unix fanbase. You can't expect mass appeal when that's your focus. Still failing to acknowledge this is what contributed to Perl's downfall (random snowball effect, seriously?) at the expense of Python is why Perl continues its decline.

Not only that, but the "everyone knows Python so everyone uses it..." argument seems tautological (Python won because it won). You could argue that more people knew Perl in the mid-to-late 90s than Python - so why didn't "everyone knows Perl so everyone uses it so everyone new has to learn it" sustain Perl's adoption then?

It seems like people barely have to glance at Python to know it. Perl is harder, and for many people (or at least me) it didn't stick without constant practice. I put in the effort to learn Perl several times, but any time I left it alone for a month or two, my brain purged it. I finally embraced Python after realizing that I could still remember how to code in it after casually messing around with it a few months prior.

I started off professionally writing Perl 5. A few comments.

Perl 5 fails in separate areas.

* no standard OO system * no standard exception system * no standard module system * context-driven polymorphism * the standard library didn't have JSON and a few other key needs built in, so dragging in CPAN all the time was a hassle.

The first three issues generate maintenance issues that are not found in other languages that are roughly isomorphic. The fourth generates bugs. The fifth generates deployment problems out of line with its competitors.

Perl is also, as alluded to elsewhere, an expert tool. Those have not fared well for the past 25 years, sadly. Hopefully in the next 25 years, as the industry matures and stratifies, experts will have the opportunity to select and use difficult but high quality tools on the regular.

The Perl 6 horse got put together for another ritual beating, I see. Have at it.

Sigils and the other ideas from linguistics are a notion which I believe will be adopted down the road more and more. I see them as one of the best syntactic ideas of Perl, although the context-shifting use of them (@ vs $) is something I see as bug-prone.

Is there any sign that other languages are going to adopt sigils? I can't think of any new language that does, and no one ever talks of the idea. If anything, types are getting more popular and will probably totally subsume sigils?

KiCad has a scripting engine for automating boring repetitive tasks - it's Python.

This is actually a giant sore point for me as a programmer. Let me ask the HN collective for advice:

How do you set up an interface for a scripting language in a larger application?

Most applications like KiCad or Blender have their own Python baked very deeply into the software architecture. It works ... mostly ... but it seems to me like its suboptimal

1) you have to jump through an enormous amount of hoops to try to connect your "normal" development environment to the "captive" scripting engine.

2) controlling UI elements from the scripting language is a real PITA

3) you don't have a choice of scripting language

It seems like there ought to be a better way to do this, but I always wind up sort of landing on "open a socket and talk RPC" which has it's own failure modes (for example: how do you expose everything (including the UI) and how do you handle concurrent access).

What is the solution to this?

Perl is not a good developer experience.

Try working with a database such as sql server. If the sybase driver gets the string encoding wrong good luck debugging the problem.

Perl has a syntax that appears to be designed to make a google search impossible.

I'm not sure why they want you to explicitly work with references. Constantly having to dereference is nothing but noise.

Tooling is non existent. Want to step by step debug, good luck.

It's just not fun.

Have you asked for help? I would really appreciate an honest answer. I'm putting out this question because your post reads like you never did, and I can totally see having a bad time when someone voluntarily shuts himself out of the community and thus never gets to see frustrations addressed. I don't want my fellow hackers to suffer bad feelings when it's completely and easily avoidable.

• Support for database drivers exists, most notably the DBI mailing list where all the driver authors participate. This is mentioned prominently in the documentation.

• Perl predates Google, so it is tragically wrong to put the blame on Perl. Blame Google for not searching correctly for a long time. This is fixed since 2019. Other search engines did not make mistakes of the same kind. I personally do not see Google as the first and final means. It's not asking too much using other means of looking up information when Google falls short, e.g. the offline documentation shipping with language, or bookmarking some specialised Web sites and using their search.

• Explicit references are a consequence of Perl's early life (< v5) catering to programmers familiar with shell, and then adding the feature in a backward-compatible manner. When it came to adding the feature, it was the choice between explicit references with the benefit of keeping code running, or implicit references and invalidating existing code with the benefit of terser syntax (i.e. the dereferencing arrow -> would mostly disappear). The trade-off was made in favour of backward-compatibility, and this direction was the case ever since. Hope this explains it well enough, keep in mind that you have the advantage of judging the decision in hindsight.

• Debuggers not existing is just plain wrong.