7 ms·

Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.

by mffnbs 7y ago

Kaiyou 7y ago
Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.
- fwip 7y ago
  You can keep running Python 2 just like you keep your COBOL systems running, nobody's gonna stop you except common sense.
  - Kaiyou 7y ago
    Right, but in engineering it's kind of expected to get support for a version for at least 60 years. Software engineering is just really weird in that it moves so fast and nobody seems to care to break things.
    - joshuamorton 7y ago
      What free things are supported for 60 years in engineering applications? Name one.
      - greglindahl 7y ago
        Fairly ancient Fortran compiles OK in open source compilers. Not quite 60 years old, yet, but it'll be there soon.
        TheRealKing 7y ago
        It's already >65 years old. The 65th birthday was this summer 2019.
    - ZWoz 7y ago
      They (in engineering general) aren't expected support something free though. Putting it another way: You can get you support with Python2, if you pay.
  - protomyth 7y ago
    IBM does quite a good job of making sure that COBOL is supported long term with all needed updates for many many years to come. Python 2 is not in that position.
    - jhall1468 7y ago
      You mean, IBM does quite a good job of making sure IBM COBOL is supported long term. They are maintaining their compiler, which is exactly what PSF is doing. They are maintaining their interpreter, which is Python 3.
      - protomyth 7y ago
        The GP post missed the fundamental difference between keeping COBOL running and keeping Python 2 running. Python 2 was also PSF's interpreter. IBM handling a COBOL upgrade like PSF handling the 2-3 transition would be unacceptable.
        WorldMaker 7y ago
        Would PSF exponentially increasing support and maintenance costs for Python 2 into multimillion dollar contracts and bundling over-margined hardware in with the bundle to make it more of an IBM-like transition help?
        protomyth 7y ago
        Yep, someone has to pay in one way or another like Red Hat customers on 7, but to say Python has near the life cycle of COBOL is just disingenuous. Old COBOL still runs, but Python 2 programs will not. It really shows what the achievement languages like COBOL, RPG, and Fortran are in terms of longevity and migration.
        mynameisvlad 7y ago
        > but Python 2 programs will not Er, why not? It's not like there's some kill switch in Python 2 that will make it stop working after January 1st, 2020. If it works now, then it'll still work, you're just not guaranteed fixes anymore. At least, not for free. As stated in the article, paid support options exist from several vendors.
- BeetleB 7y ago
  >considering timelines in engineering are to support a version for 60 years. In the vast minority of cases. Not in most electrical engineering (except power plants), nor in computer engineering. 60 years ago was 1959. What software/computer project from that time is still running? Even moving outside of the electrical domain, how many physical products outside of civil engineering is expected to last that long. I certainly can't expect support for my car for longer than 25 years.
  - deleted 7y ago
    [deleted]
  - djsumdog 7y ago
    Classic cars can still get parts after 25 years, but a lot of times its custom machine shop stuff. There is a market for it. Really there's also a market for restoring old computers (look at The 8-Bit Guy, LGR, The Living Computer Museum (Seattle) and all those other people who restore old hardware for fun and education. But I get your point, those are special cases for preservation. For mainline things, especially with today's processes for continual integration, dependency checking and advance build tooling, dependency rot is something that should be accounted for in all software project plannings. If your dependencies are a few months out of date and you don't have the time to update them and re-run tests (people write tests right?) things are just going to hurt more and more later.
  - WorldMaker 7y ago
    If there's a difference it's not time scale necessarily, it's that CPAs are better at amortizing support/maintenance costs across decades. CPAs have amazingly detailed depreciation charts for non-software engineering lifecycles. If you build a civil engineering project, you figure out asset depreciation versus maintenance schedules, and you budget accordingly. I've yet to see a CPA adequately depreciate software assets, anywhere. Maybe we should help them out by building better depreciation schedules. There seems to be a lot of CPAs that don't believe software depreciates over time, and maybe that's the largest disconnect in labeling it "tech debt", because accountants hear that term and think they can ignore it on a balance sheet they don't care about, but "tech depreciation" might actually scare them straight (until they find the tax advantages in calling it that).
- _fizz_buzz_ 7y ago
  We sell welding systems to weld stainless steal, copper pipes, etc. We always give a warranty of 24 month, guarantee paid support for 10 years, and support older machines only if possible. I am not sure which industry you are talking about, but 60 years is the exception in my experience.

Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.

by mffnbs 7y ago

Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.

Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.

fwip 7y ago
You can keep running Python 2 just like you keep your COBOL systems running, nobody's gonna stop you except common sense.
- Kaiyou 7y ago
  Right, but in engineering it's kind of expected to get support for a version for at least 60 years. Software engineering is just really weird in that it moves so fast and nobody seems to care to break things.
  - joshuamorton 7y ago
    What free things are supported for 60 years in engineering applications? Name one.
    - greglindahl 7y ago
      Fairly ancient Fortran compiles OK in open source compilers. Not quite 60 years old, yet, but it'll be there soon.
      - TheRealKing 7y ago
        It's already >65 years old. The 65th birthday was this summer 2019.
  - ZWoz 7y ago
    They (in engineering general) aren't expected support something free though. Putting it another way: You can get you support with Python2, if you pay.
- protomyth 7y ago
  IBM does quite a good job of making sure that COBOL is supported long term with all needed updates for many many years to come. Python 2 is not in that position.
  - jhall1468 7y ago
    You mean, IBM does quite a good job of making sure IBM COBOL is supported long term. They are maintaining their compiler, which is exactly what PSF is doing. They are maintaining their interpreter, which is Python 3.
    - protomyth 7y ago
      The GP post missed the fundamental difference between keeping COBOL running and keeping Python 2 running. Python 2 was also PSF's interpreter. IBM handling a COBOL upgrade like PSF handling the 2-3 transition would be unacceptable.
      - WorldMaker 7y ago
        Would PSF exponentially increasing support and maintenance costs for Python 2 into multimillion dollar contracts and bundling over-margined hardware in with the bundle to make it more of an IBM-like transition help?
        protomyth 7y ago
        Yep, someone has to pay in one way or another like Red Hat customers on 7, but to say Python has near the life cycle of COBOL is just disingenuous. Old COBOL still runs, but Python 2 programs will not. It really shows what the achievement languages like COBOL, RPG, and Fortran are in terms of longevity and migration.
        mynameisvlad 7y ago
        > but Python 2 programs will not Er, why not? It's not like there's some kill switch in Python 2 that will make it stop working after January 1st, 2020. If it works now, then it'll still work, you're just not guaranteed fixes anymore. At least, not for free. As stated in the article, paid support options exist from several vendors.
BeetleB 7y ago
>considering timelines in engineering are to support a version for 60 years. In the vast minority of cases. Not in most electrical engineering (except power plants), nor in computer engineering. 60 years ago was 1959. What software/computer project from that time is still running? Even moving outside of the electrical domain, how many physical products outside of civil engineering is expected to last that long. I certainly can't expect support for my car for longer than 25 years.
- deleted 7y ago
  [deleted]
- djsumdog 7y ago
  Classic cars can still get parts after 25 years, but a lot of times its custom machine shop stuff. There is a market for it. Really there's also a market for restoring old computers (look at The 8-Bit Guy, LGR, The Living Computer Museum (Seattle) and all those other people who restore old hardware for fun and education. But I get your point, those are special cases for preservation. For mainline things, especially with today's processes for continual integration, dependency checking and advance build tooling, dependency rot is something that should be accounted for in all software project plannings. If your dependencies are a few months out of date and you don't have the time to update them and re-run tests (people write tests right?) things are just going to hurt more and more later.
- WorldMaker 7y ago
  If there's a difference it's not time scale necessarily, it's that CPAs are better at amortizing support/maintenance costs across decades. CPAs have amazingly detailed depreciation charts for non-software engineering lifecycles. If you build a civil engineering project, you figure out asset depreciation versus maintenance schedules, and you budget accordingly. I've yet to see a CPA adequately depreciate software assets, anywhere. Maybe we should help them out by building better depreciation schedules. There seems to be a lot of CPAs that don't believe software depreciates over time, and maybe that's the largest disconnect in labeling it "tech debt", because accountants hear that term and think they can ignore it on a balance sheet they don't care about, but "tech depreciation" might actually scare them straight (until they find the tax advantages in calling it that).
_fizz_buzz_ 7y ago
We sell welding systems to weld stainless steal, copper pipes, etc. We always give a warranty of 24 month, guarantee paid support for 10 years, and support older machines only if possible. I am not sure which industry you are talking about, but 60 years is the exception in my experience.