6 ms·
It would be interesting to see whether Python 2 is the longest supported major version for a programming language.
by smaili 9y ago
It would be interesting to see whether Python 2 is the longest supported major version for a programming language.
- santaclaus 9y agoLLVM recently got support for Fortran (through Flang), so Python 2 has at least 30 years to go...
- pm215 9y agoPython 2 came out in 2000 and goes EOL 2020 I think. Perl 5 was released in 1994 and has no planned EOL date, so it is currently winning by a fair margin.
- brians 9y agoAnd 2 vs 1 is really only a licensing issue. Python 1.4, from 1996, is not so different!
- eesmith 9y agoI agree that they were not very different languages. I did port code from Python 1.5.2 to Python 2. It required two minor changes, because "from X import *" was no longer allowed inside of a function. As a similar example, the transition from 2.5 to 2.6 meant that an assignment like "as = 0" (which might initialize a counter for the number of 'a's found) was no longer legal either.
- makapuf 9y agoWhich makes me wonder how much of the incompatible changes that triggered the python 3000 change could have been introduced gradually. I mean 10 years could have been a long time to introduce small breaking changes one from future import at a time...
- eesmith 9y agoThe future import technique works well for syntax changes which only affect a single module. It doesn't help with objects passed between modules. For example, if s is a byte string, then "for c in s" returns a 1-byte string in Python 2 and integers in Python 3. But if the string was created in a Py2 module and passed to a Py3 module, then what API should it present? In principle there could be a wrapper to present the correct API. However, that's complicated, and not interesting compared to, say, a new methods for doing asynchronous programming. This sort of backwards compatibility can be done. I've heard about IBM doing it for ... REXX, perhaps? .. where a program and perhaps even a module could declare which version to use. But it's expensive. And despite its popularity, there aren't scores of companies paying millions of dollars to ensure this level of compatibility,
- makapuf 9y agoYou're right on principle. For the bytes vs char, maybe you can make it more gradual : make unicode possible and non default (py2), make it possible, non default but deprecate raw strings literals, make unicode literals default one year after. Not TEN. Or maybe JUST make it the ONLY check to go from python 2.7 to 2.8 and focus on supporting the change during one whole year. Or provide both APIs - maybe as a compile time switch- but all the new APIs using text would be unicode only. Wait for all libs to change focusing on just that. Make developers go 10 times that amount of verifications and changes. Python had incompatible changes before so it wasn't a "take any 1.2 python code and it runs on py 1.5.2" level backwards compatibility (by example : string exceptions, new keywords ..). There hasn't been any drama for this, not ten-year level one at least. My point was that maybe py3 transition could have been smoother had it be done this way - it's very difficult to handle, and shall be glad to have the python 3.6+ we have now anyway)
- eesmith 9y agoAnd you are right on principle. The fundamental limitation is the economic cost of doing something along the lines of what you propose.
- kzrdude 9y agoHow do we compare it with C89 implementations out there?
- CJefferson 9y agoWhat? No! Python 2 is only 17 years old. I can still run Java, C, C++ and Perl 5 (picking the first 4 languages that occur) that were written before then, with no problems.
- xapata 9y agoWhich version? Aren't we on Java 9 now?
- qznc 9y agoThat is actually Java 1.9. They decided to kind of hide the leading "1." at Java 1.5. https://en.wikipedia.org/wiki/Java_version_history#Versioning_change https://en.wikipedia.org/wiki/Java_version_history#Versionin...
- shagie 9y agoThat was part of Sun's "people pay more attention to the first number" reversioning. Solaris 2.6 was followed by Solaris 7. This was partly because of the competitors (e.g. IRIX) were raving the first digit with each major version. When Solaris was version 2.6, IRIX was version 6. As I recall it, Management had less confidence with things called "1.X" or "2.X" than things called "5.Y". So, Sun went through and started dropping the small leading digit from the versions of their products.
- CJefferson 9y agoI can still run java 1.2 code fine (I say 1.2 as I have a bunch of 1.2 code).
- jhasse 9y agoMost C++ code wont compile for multiple reasons. For example using namespace std will result in errors if your code calls a function which is now part of std.
- throwaway613834 9y ago
- Elv13 9y agoANSI C (C89), Fortran 66 and COBOL 61 will easily be the most serious contenders.
- eesmith 9y agoI think the OP is looking for something a bit different, not oldest supported programming language but longest time between major updates to the language. This is a bit hard to address because Python does incremental language changes, as well as major changes, while the languages you listed have formal specifications. Python 2 from creation in 2000 to end of new development will be 19 years. Fortran 66 was around for 11 years, replaced by Fortran 77 and then Fortran 90, 95, 2003, and 2008. I think those dates are what the OP is looking for. C89 to C99 was 10 years. Then C11 12 years later. COBOL 61 was followed by 65, 68, 74, 85, and then the poorly supported 2002 followed by 2014. I think a better contender is MUMPS, made an ANSI standard in 1995 and ISO standard in 1999. It's still in use in healthcare and financial applications. https://en.wikipedia.org/wiki/MUMPS https://en.wikipedia.org/wiki/MUMPS Another contender is Rexx, ANSI X3.274 / 1996. Both Rexx and MUMPS are ranked in the range 50-100 on TIOBE. Then there's FORTH, with FORTH-79, FORTH-83 (both de facto) and then ANS Forth in 1994. But that might be cheating as I think (based on hearsay) most Forth users specialize their implementations rather follow ANS Forth. Those are still in reasonably wide-spread use. I think something like ALGOL, last revised in 1973, is outside of what the OP was thinking about.
- Elv13 9y agoStill, ANSI C89 is still being "developed" in the sense modern optimizing compilers still improve the state of the art and their STD (glibc/musl) still supports them as primary targets for development (rather than the newer C99/C11). The same is true for Fortran and COBOL. Both are actively being developed as programming languages. Python2 is both a framework (extended std) and language, so the line is blurry. I would even say that Python2, as a language/runtime, has not been under development since quite a while meanwhile C89 development is still going full speed.
- fredley 9y agoDefine 'supported'? Many banks are still writing COBOL.
- kinkrtyavimoodh 9y agoBy that logic any language can be supported by never upgrading the system. Support implies some kind of active support from the creators / maintainers of the language, not active use by people.
- projectramo 9y agoExactly. Otherwise I could argue Commodore still "supports" the Commodore basic in a Commodore 64.
- ken 9y agoPicking a version longevity winner probably depends on whether you mean specification, or implementation. ANSI Common Lisp was standardized in 1994, and there have been no updates to the language since then. There are several supported implementations (though the implementations have probably all incremented their major version at least once since then). It seems that JavaScript gave up numbering at 1.8.5 [1], so you might consider it to still be on "JavaScript 1.x", which dates back to 1996. [1]: https://en.wikipedia.org/wiki/JavaScript#Version_history https://en.wikipedia.org/wiki/JavaScript#Version_history
- neuronexmachina 9y agoI guess there's TeX. Knuth released version 3.0 in 1989, and it's currently on 3.14159265.