zlacker

[return to "Perl's decline was cultural"]
1. superk+P2[view] [source] 2025-12-06 18:09:16
>>todsac+(OP)
Perl's "decline" saved it from a fate worst than death: popularity and splitting into dozens of incompatible versions from added/removed features (like python). Instead Perl is just available everywhere in the same stable form. Scripts always can just use the system perl interpreter. And most of the time a script written in $currentyear can run just as well on a perl system interpreter from 2 decades ago (and vice versa). It is the perfect language for system adminstration and personal use. Even if it isn't for machine learning and those kinds of bleeding edge things that need constant major changes. There are trade-offs.

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.

◧◩
2. cedill+D5[view] [source] 2025-12-06 18:29:41
>>superk+P2
What incompatible versions of pythons do you mean? I'm entirely unaware of any forks, and the youngest version I have to supply at the moment is 3.9, which is over 5 years old and available in all supported platforms.
◧◩◪
3. superk+Z5[view] [source] 2025-12-06 18:32:21
>>cedill+D5
Try to run any random python program of moderate dep use on your python 3.9 system interpreter without using containers. Most likely you'll have to use a venv or the like and setup a special version of python just for that application. It's the standard now because system Python can't do it. In practice, pragmatically, there is no Python. Only pythons. And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.
◧◩◪◨
4. jkrejc+AP[view] [source] 2025-12-07 01:10:47
>>superk+Z5
> And that's not even getting in to the major breakages in point version upgrades or the whole python 2 to 3 language switch.

Python doesn't use semver and never claimed to do so, but it's probably worth treating "x.y" releases as major versions in their own right (so like 2.7 -> 3.0 is a major version and so 3.10 -> 3.11). If you do that, the versioning makes a bit more sense

[go to top]