> Perhaps the distributions would be more inclined to include up-to-date version if the standard in the python community was not to break everything all the time.
Yep... Perl is a godsend... take a code from 20 years ago, run it on a modern system, and everything works.
Python? Three different software versions need three different versions of the same library, and new library versions are not backwards compatible with their older versions... Even Python 2.x -> 3.x was a pain in the ass too, and even within minor versions, you sometimes get breaking changes.
> Perl is a godsend... take a code from 20 years ago, run it on a modern system, and everything works.
That's more or less like "take a VB6 binary from 20 years ago, run it on some modern Windows, and everything works" - that's just because the ecosystem is effectively dead, so supporting it on new releases just means carrying over some stuff that worked 20 years ago.
But it works... it's universally supported on pretty much every os, even by default on most *nix based ones, and new versions and new CPAN modules are still written.
In 10 years, with python 4, or even maybe 5, everything will still be broken, and you'll still be claiming perl is dead, and i'll still be using the same stuff I use now, that worked years ago, works now, and will work then.
And people will still be shipping code faster and more efficiently than they would do in Perl. Because in the end, the advantages of using Python, in terms of readability and productivity, easily offset a bit of packaging pain - whereas the disadvantages of using Perl don't offset whatever marginal gain you get by using old infrastructure.
And people will still be shipping code faster and more efficiently than they would do in Perl.
I feel that quite a bit of software written these days is designed to have a short shelf life. I wonder how many of the "Show HN" posts will work, or even be useful, in five years? How much will be maintainable?
I've been thinking a lot about Matthew Crawford's writings on mechanical things[0] and how they might apply to my own craft as a software developer. The work, as described generally on HN, is still all about moving fast and breaking things. It doesn't matter if the Python code I crank out today works in five years (or is maintainable in five years) -- I just need to get my product to market. Some of us work in other domains where sustainability and repair-ability are important: if my software is going to be in the field, in users' hands, for ten years, I need to consider how reasonable it might be fix bugs. If I have to fight just to get the software to run, I've already lost that battle. In these cases, the dependability of something like Perl is really great. The complaint against Python here isn't about the language itself (I think many people would agree it is quite nice to use), but rather the larger ecosystem, which makes it very hard to maintain software over the long haul.
[0] See Shop Class as Soulcraft, The World Beyond Your Head, and Why We Drive.
> I feel that quite a bit of software written these days is designed to have a short shelf life. I wonder how many of the "Show HN" posts will work, or even be useful, in five years? How much will be maintainable?
Yep, all the python2 code from 5 years ago doesn't work anymore... It's sad how getting python2 to work on newish distros is becoming a great pain in the ass.
HN has been around for at least 5 years, right? Probably some interesting stats on how many 'Show HN's are live, dead or decomposed. Live: updated in the last year Dead: not updated in the last year, but still available. Decomposed: not findable/available.
But that code won't work in five years, because all the distros will remove python3 in favour of python4. (also, the code from 5 years ago written for python 2.x doesn't work now, becauses distros removed python2)
Do you really want to rewrite all your stuff every 5 years?
As an end user, I care more about code quality and stability than I do speed of shipping code. I don't want to use some buggy code that was pushed through production too quickly just because the devs are lazy!
Yep... if a thing works, don't fix it.... Modern devs "fix it" until it's broken. Just look at google and their communication platforms... every few years a new one that kills off the previous one, with practically no added value.
There is a lot of software, from 7zip, total commander, putty, vlc, windirstat, etc., that do one (or few things), people have been using them for decades, and pretty much all the features have been there for that long, without an artificial need to "ship something new, fast" every few weeks.
Or instead use another modern language? I avoid any python that I can’t apt-get/brew and haven’t considered writing anything with it for a very long time. There is always go/ruby/c# which seem to generally avoid the problems discussed here
This is the sad reality of modern development... new project? Why take some stable tech, when you can take a 2month old framework and an alpha version of a library, and do two rewrites, before the project fails due to breaking changes and abandoned software. It seems as if people actively avoid anything stable.
use Lingua::Romana::Perligata;
adnota Illud Cribrum Eratothenis
maximum tum val inquementum tum biguttam tum stadium egresso scribe.
da meo maximo vestibulo perlegementum.
maximum comementum tum novumversum egresso scribe.
meis listis conscribementa II tum maximum da.
dum damentum nexto listis decapitamentum fac
sic
lista sic hoc tum nextum recidementum cis vannementa listis da.
dictum sic deinde cis tum biguttam tum stadium tum cum nextum
comementum tum novumversum scribe egresso.
cis
That's a really weak gotcha: Perl 4 was deprecated 28 years ago and Perl 6 is a completely different language that's been called Raku since 2019. There are no dependencies to resolve between them. It's like worry about dependency resolution between Javascript and Java. They're not even the same platform.
True. But Raku (https://raku.org #rakulang) does have an Inline::Perl5 module, which allows you to use 99.9% of modules on CPAN (basically, only the ones using source-filters, and ones that are really, really deep into the Perl internals). So there *can* be dependencies between Perl and Raku.
Yep... Perl is a godsend... take a code from 20 years ago, run it on a modern system, and everything works.
Python? Three different software versions need three different versions of the same library, and new library versions are not backwards compatible with their older versions... Even Python 2.x -> 3.x was a pain in the ass too, and even within minor versions, you sometimes get breaking changes.