Python says you know nothing, but want to automate a small task. The community will help you. More so than any other language.
Then again, Python 2 and Python 3 are two different languages.
Very few projects are willing to have such a massive migration.
It was Django and the people involved with it.
Culture?
But, shell scripting has already become somewhat of an arcane skill. I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn, both in terms of reading and writing. In other words, it encourages broadly maintainable code. Ruby is quite similar (although I think people massively overstate how much the language itself generally encourages understandable semantics)
Python is a crappy shell scripting language because the syntax around pipe and subprocess is really clunky.
Perl managed to have decent data structures and also have decent syntax around subprocess calls.
But I feel like the Python invoke module gives me everything I need wrt subprocess calls. I basically write any nontrivial "shell script" these days as a Python invoke command.
GvR explicitly describes the motivation behind Python in similar terms (I can probably find a timestamp in that recent documentary for this). But the goal there was to be fully "general purpose" (and readable and pragmatic, more than artistic) while trying to capture what he saw as the good things about shell languages.
And it's changed quite a bit since then, and there are many things I would say with the benefit of hindsight were clear missteps.
We all joke about the hard problems of computer science, but it seems to me that the hard problems of programming language design, specifically (and perhaps software engineering more generally?) include having good taste and figuring out what to do about reverse compatibility.
> I think the article nailed that Perl was just too hard to learn for the value it provided to survive. Python is not nearly as, erm, expressive as perl for working in that space, but it is much easier to learn
The use cases have also changed over time. Quite a lot of developers ended up on Windows (although that pendulum is perhaps shifting again) where the rules and expectations of "shell" are very different. To say nothing of e.g. web development; long gone are the days of "cgi-bin" everywhere.
And that could be one of major reasons why it lost in popularity. It was and still is easy to write but hard to read.
my @var = @array # copy the array
my $var = @array # return the count of elements in arrayHis 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.
Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.
Python 3 almost killed Python.
It's normal. Once a community loses faith, it's hard to stop them from leaving.
People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.
I still remember spending time with my coworkers on bench outside of building trying to figure out #@$%$^&$%@something = []sd[dsd]@$#!&lala lines written by previous developers
maybe its painful for guys to admit that languages could be a lot better designed, and when such langauges appeared, everyone flocked to them.
Perl was my first language because I wanted to make interactive websites and that was the most common way to do it in the late 90s. Shortly after, everyone switched to PHP because mod_php was much faster than Perl CGI scripts.
superkuh•25m ago
This kind of ubiquitous availablility (from early popularity) combined with the huge drop-off in popularity due to raku/etc, lead to a unique and very valuable situation unmatched by any other comparable language. Perl just works everywhere. No containers, no dep hell, no specific versions of the language needed. Perl is Perl and it does what it always has reliably.
I love it. The decline was a savior.
keepamovin•17m ago
amiga386•9m ago
By comparison, Python can barely go one version without both introducing new things and removing old things from the language, so anything written in Python is only safe for a a fragile, narrow window of versions, and anything written for it needs to keep being updated just to stay where it is.
Python interpreter: if you can tell "print" is being used as a keyword rather than a function call, in order to scold the programmer for doing that, you can equally just perform the function call.
cedilla•4m ago