3 ms·

> I think Python2 will be 2050's COBOL. I expect otherwise. My company has various tools and applications that weren't migrated to python3 and it's getting har

by onei 6y ago

> I think Python2 will be 2050's COBOL. I expect otherwise. My company has various tools and applications that weren't migrated to python3 and it's getting harder and harder to support then as dependencies keep dropping support for them (someone had the bright idea of not versioning dependencies). Sooner or later a nasty bug is going to be found that makes continuing to use it untenable and you'll be forced to upgrade. Python is still under development enough to make upgrading attractive. If a language manages to become hugely popular and then stops development, that's how you end up with Perl or COBOL.

cyberpunk 6y ago
I know of at least 3 banks that use python2 inside their trading platforms (the big two use python as the built in scripting languiage) -- which would be a multi-year multi-10s-millions project to migrate to 3.. We won't be saying goodbye for a while... For standalone stuff, yeah, it's not so bad. Upgrading between node releases has been more painful to me than python 2->3..
- iso-8859-1 6y ago
  Wow! What are the problems you encountered upgrading Node releases? I noticed how they removed tail-call optimization, which broke Lamdu.
  - giantrobot 6y ago
    Pinned dependency X stops working in Node X+1. Upgrading dependency X to work on Node X+1 breaks code using dependency X. Sorting out the mess stops development and leads to cascading breakage. So just say "fuck it" and wrap the project up on a Docker container running Node X. Now work can continue. Luckily the project is internal so missing security fixes is less of a problem than something customer facing.
- nawgszy 6y ago
  >Upgrading between node releases has been painful to me This is surprising to me. What kind of deps do you have that are changing? From my view starting around Node 4, only Buffer really went thru big API refactors, and otherwise going LTS -> next LTS is seamless
- deleted 6y ago
  [deleted]
xeeeeeeeeeeenu 6y ago
> If a language manages to become hugely popular and then stops development, that's how you end up with Perl or COBOL. Perl development didn't stop. In fact, Perl 5.32 will be released in a few days and it will introduce several new major features, such as operator chaining, the 'isa' operator or the ability to disable the indirect object syntax.
jnxx 6y ago
> Python is still under development enough to make upgrading attractive. > If a language manages to become hugely popular and then stops development, that's how you end up with Perl or COBOL. This contains two notions I am not sure whether they are right. First, you argue that Python is still under development. Sure, from a language designer's view, people who use Python2 can relatively quickly learn Python3, and the language designers have interest in people migrating, so they might sell it as the same language. But from the point of view of a language user who has a lot of legacy code and has no interest (or not even the resources) to rewrite and re-test it all, Python2 and Python3 are actually different languages. A program written in Python2 will not run with a Python3 interpreter, and there is no switch or option which would make it work. So, its different languages (which unfortunately share the same file extension for their source code files). The second argument is somehow that organizations and people keep using Python2 "in spite of" or "although" it is not developed further. But I think many of these organizations might also chose so (perhaps not even consciously) because Python2 is stable and is not going to have breaking changes, which is identical to one of the reasons why COBOL is still used. For these users, stability is far more important than the addition of fancy new libraries, or new syntactic features which make the code actually harder to read. Sure, there is the argument about security fixes. For web services, or software on desktops, this absolutely matters. But there are at least two domains where security fixes are far less relevant than stability and backwards compatibility: Large enterprises, and scientific research. In the first case, the code runs well shielded inside the corporate systems, and does not encounter untrusted input, so it does not matter whether it is secure. It matters more that the developer understands the code well and many edge cases are fixed. In the second case, security is, so far, a non-concern. And in addition, the people who wrote the code, which is almost always PhD students and researches which had to go for another temporary job, are no there any more in most cases, and there are no resources available to hire new people just to port the code. If new people are hired, they just will write new code, to produce new research results. Because this is what brings in the money which keeps the whole ship floating. (There are interesting exceptions to that, some research projects are that big and long-lived, and use so much software, that they employ people who actually know both science and software engineering, but that's more the exception). As a result, stability and backwards compatibility beats new features, and some people and organizations simply will not port because it does not meets their needs. There is another language which is in a slow but steady process of fragmentation, C++. So far, there have no (almost no) backwards-compatible changes. But, the main selling point of C++ in the 80ies was that it was compatible to C, and now the official C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) explicitly discourage the use of C constructs like pointers (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-resource https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...). At the same time, large users, such as Google, have their own C++ guidelines, which discourage C++ exceptions (https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html). The C++ Core Guidelines in turn require use of RAII which in many cases requires exceptions, especially in algorithms. A foreseeable effect of these opposed forces is that C++ is splitting into several communities which use significantly different idioms, and it is well imaginable if some part of the different user communities gives up on backwards compatibility as well.

by onei 6y ago

cyberpunk 6y ago

I know of at least 3 banks that use python2 inside their trading platforms (the big two use python as the built in scripting languiage) -- which would be a multi-year multi-10s-millions project to migrate to 3.. We won't be saying goodbye for a while... For standalone stuff, yeah, it's not so bad. Upgrading between node releases has been more painful to me than python 2->3..

iso-8859-1 6y ago
Wow! What are the problems you encountered upgrading Node releases? I noticed how they removed tail-call optimization, which broke Lamdu.
- giantrobot 6y ago
  Pinned dependency X stops working in Node X+1. Upgrading dependency X to work on Node X+1 breaks code using dependency X. Sorting out the mess stops development and leads to cascading breakage. So just say "fuck it" and wrap the project up on a Docker container running Node X. Now work can continue. Luckily the project is internal so missing security fixes is less of a problem than something customer facing.
nawgszy 6y ago
>Upgrading between node releases has been painful to me This is surprising to me. What kind of deps do you have that are changing? From my view starting around Node 4, only Buffer really went thru big API refactors, and otherwise going LTS -> next LTS is seamless
deleted 6y ago
[deleted]

xeeeeeeeeeeenu 6y ago

> If a language manages to become hugely popular and then stops development, that's how you end up with Perl or COBOL. Perl development didn't stop. In fact, Perl 5.32 will be released in a few days and it will introduce several new major features, such as operator chaining, the 'isa' operator or the ability to disable the indirect object syntax.

jnxx 6y ago

> Python is still under development enough to make upgrading attractive. > If a language manages to become hugely popular and then stops development, that's how you end up with Perl or COBOL. This contains two notions I am not sure whether they are right. First, you argue that Python is still under development. Sure, from a language designer's view, people who use Python2 can relatively quickly learn Python3, and the language designers have interest in people migrating, so they might sell it as the same language. But from the point of view of a language user who has a lot of legacy code and has no interest (or not even the resources) to rewrite and re-test it all, Python2 and Python3 are actually different languages. A program written in Python2 will not run with a Python3 interpreter, and there is no switch or option which would make it work. So, its different languages (which unfortunately share the same file extension for their source code files). The second argument is somehow that organizations and people keep using Python2 "in spite of" or "although" it is not developed further. But I think many of these organizations might also chose so (perhaps not even consciously) because Python2 is stable and is not going to have breaking changes, which is identical to one of the reasons why COBOL is still used. For these users, stability is far more important than the addition of fancy new libraries, or new syntactic features which make the code actually harder to read. Sure, there is the argument about security fixes. For web services, or software on desktops, this absolutely matters. But there are at least two domains where security fixes are far less relevant than stability and backwards compatibility: Large enterprises, and scientific research. In the first case, the code runs well shielded inside the corporate systems, and does not encounter untrusted input, so it does not matter whether it is secure. It matters more that the developer understands the code well and many edge cases are fixed. In the second case, security is, so far, a non-concern. And in addition, the people who wrote the code, which is almost always PhD students and researches which had to go for another temporary job, are no there any more in most cases, and there are no resources available to hire new people just to port the code. If new people are hired, they just will write new code, to produce new research results. Because this is what brings in the money which keeps the whole ship floating. (There are interesting exceptions to that, some research projects are that big and long-lived, and use so much software, that they employ people who actually know both science and software engineering, but that's more the exception). As a result, stability and backwards compatibility beats new features, and some people and organizations simply will not port because it does not meets their needs. There is another language which is in a slow but steady process of fragmentation, C++. So far, there have no (almost no) backwards-compatible changes. But, the main selling point of C++ in the 80ies was that it was compatible to C, and now the official C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) explicitly discourage the use of C constructs like pointers (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-resource https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...). At the same time, large users, such as Google, have their own C++ guidelines, which discourage C++ exceptions (https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html). The C++ Core Guidelines in turn require use of RAII which in many cases requires exceptions, especially in algorithms. A foreseeable effect of these opposed forces is that C++ is splitting into several communities which use significantly different idioms, and it is well imaginable if some part of the different user communities gives up on backwards compatibility as well.