5 ms·

> The real horsemen of the legacy apocalypse is the depth of the dependency tree. Modern software development stacks abstraction on top of abstraction. I think

by jnxx 6y ago

> The real horsemen of the legacy apocalypse is the depth of the dependency tree. Modern software development stacks abstraction on top of abstraction. I think Python2 will be 2050's COBOL.

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.
hedora 6y ago
I’m going with the author on this: npm, pip, and friends will be the 2050’s cobol, but supporting them will be an order of magnitude harder. Startup idea: snapshot package managers every 6 months or so. Provide access to the snapshots for free. Once enterprises are “hooked”, and fall off the nightly upgrade train, charge out the nose for backported security updates. I guess this is similar to the RHEL model, but I suspect it’s even stickier.
ChrisMarshallNY 6y ago
I totally agree. I think that we are headed for a "Dependecalypse," with Jurassic-scale disasters over the horizon. Dependencies are not per se bad, but some dependencies are just bad. Also, we can get these hideous cocktails, where dependencies are mixed together, with alarming results. A fairly common issue with me, is if I am setting up a Web site, I need to be very careful what theme I use (assuming I don't write my own), because the themes tend to come with a fair bit of "baggage," that does not play well with others. I'm the original author of a fairly ambitious system that has been getting a lot of traction, lately (partly because I stepped back, and let some "new blood" take the reins). I am constantly reading reports of dependency collisions. When I wrote the original framework, it had zero dependencies, and fit everywhere. But I can't argue with the results. When these new folks came in, and started adding dependencies (sometimes, under protest from me), the utility of the system skyrocketed. So did the problems. These guys are pros. I trust them implicitly, and they have been anything but reckless, yet they have still had some issues. I cannot say the same for a lot of folks out there. I see people throw together massive systems, with hardly a thought to the dependency debt.
jonnycomputer 6y ago
I've very much started to trade expediency for limiting dependency. Of course, since I have to reinvent the wheel, some claim that has many of the same costs as any dependency. But since the code use is all in-house and doesn't have to satisfy the needs of a very broad user-base or too wide a spectrum of use-cases, its not much of a problem at all, compared to finding that your code depends on something someone else supposedly maintains, but doesn't really, or who decides that backwards compatibility is not terribly important. All kilometer-age will vary, of course.
Cthulhu_ 6y ago
I'm sure Java will be, given how it's being applied in a lot of large back-ends for e.g. banking, administration, etc. That's my making-some-quick-money-before-retirement plan set at least. I'm not a great Java developer but it'll probably be good enough.

by jnxx 6y ago

> The real horsemen of the legacy apocalypse is the depth of the dependency tree. Modern software development stacks abstraction on top of abstraction. I think Python2 will be 2050's COBOL.

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.

hedora 6y ago

I’m going with the author on this: npm, pip, and friends will be the 2050’s cobol, but supporting them will be an order of magnitude harder. Startup idea: snapshot package managers every 6 months or so. Provide access to the snapshots for free. Once enterprises are “hooked”, and fall off the nightly upgrade train, charge out the nose for backported security updates. I guess this is similar to the RHEL model, but I suspect it’s even stickier.

ChrisMarshallNY 6y ago

I totally agree. I think that we are headed for a "Dependecalypse," with Jurassic-scale disasters over the horizon. Dependencies are not per se bad, but some dependencies are just bad. Also, we can get these hideous cocktails, where dependencies are mixed together, with alarming results. A fairly common issue with me, is if I am setting up a Web site, I need to be very careful what theme I use (assuming I don't write my own), because the themes tend to come with a fair bit of "baggage," that does not play well with others. I'm the original author of a fairly ambitious system that has been getting a lot of traction, lately (partly because I stepped back, and let some "new blood" take the reins). I am constantly reading reports of dependency collisions. When I wrote the original framework, it had zero dependencies, and fit everywhere. But I can't argue with the results. When these new folks came in, and started adding dependencies (sometimes, under protest from me), the utility of the system skyrocketed. So did the problems. These guys are pros. I trust them implicitly, and they have been anything but reckless, yet they have still had some issues. I cannot say the same for a lot of folks out there. I see people throw together massive systems, with hardly a thought to the dependency debt.

jonnycomputer 6y ago

I've very much started to trade expediency for limiting dependency. Of course, since I have to reinvent the wheel, some claim that has many of the same costs as any dependency. But since the code use is all in-house and doesn't have to satisfy the needs of a very broad user-base or too wide a spectrum of use-cases, its not much of a problem at all, compared to finding that your code depends on something someone else supposedly maintains, but doesn't really, or who decides that backwards compatibility is not terribly important. All kilometer-age will vary, of course.

Cthulhu_ 6y ago

I'm sure Java will be, given how it's being applied in a lot of large back-ends for e.g. banking, administration, etc. That's my making-some-quick-money-before-retirement plan set at least. I'm not a great Java developer but it'll probably be good enough.