4 ms·

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 wri

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.

toyg 5y ago
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.
- katbyte 5y ago
  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
- bmj 5y ago
  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.
  - ajsnigrutin 5y ago
    > 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.
  - pjz 5y ago
    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.
- ajsnigrutin 5y ago
  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?
- kymaz 5y ago
  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!
  - ajsnigrutin 5y ago
    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.

toyg 5y ago

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.

katbyte 5y ago
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
bmj 5y ago
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.
- ajsnigrutin 5y ago
  > 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.
- pjz 5y ago
  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.
ajsnigrutin 5y ago
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?
kymaz 5y ago
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!
- ajsnigrutin 5y ago
  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.