36 ms·

Old Code Gets Younger Every Year

240 points by mbellotti 6y ago

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.
kbenson 6y ago
Kinda surprised to not see Perl in there in some form, since it's still around as the glue holding a lot of older systems together (and for new stuff, but that's not the point of this article). Then again, it's got a little bit different of a story, since most (almost all) the old Perl from decades ago will run find on a brand new Perl interpreter released recently.
- hedora 6y ago
  Perl 5 is still actively supported, unlike python 2.
- pinewurst 6y ago
  I have a Perl problem right now. It's not the Perl interpreter at all, which as you say runs the old code fine. It's the hierarchy (read as "dungheap") of package dependencies that have changed since the last primary software version was installed.
  - kbenson 6y ago
    Well, the good thing is all those old versions of modules are archived[1] and you can still get them if you really need to, and there are utils to spider the dependency chain and tell you the packages and versions (and I think stuff that will make sure those versions get fetched) on CPAN itself, so it shouldn't be too hard to get the prior stuff up and running if you go that route (even if it might have security implications). The only stuff it would be hard to back down in versions would be core stuff, but I'm not aware of any core Perl modules that have had breaking API changes. 1: http://backpan.cpantesters.org/ http://backpan.cpantesters.org/ Edit: Cleaned up an ambiguous sentence in the middle there.
dsdklfjskldj 6y ago
Meanwhile, Android still doesn't fully support java 8.
- _old_dude_ 6y ago
  > from the TFA, The end of life for Java 8 was supposed to be 2019 Nope, that the EOL of the free support of Oracle JDK 8. Currently, the OpenJDK 8 is maintained mostly by RedHat, so EOL of Java 8 is at least 2026 [1] [1] https://access.redhat.com/articles/1299013 https://access.redhat.com/articles/1299013
- pjmlp 6y ago
  My schadenfreude regarding Android is that some Kotlin cool library on the JVM ends up requiring Java 8+ features and then all those #KotlinFirst heads on Android will finally get it why compatibility with newer versions is a must. However most likely what will happen is some fork to make it somehow work on Android, even if with less features.
ChrisMarshallNY 6y ago
I'm happy I found Marianne Bellotti. Good stuff. I'm following her now.
- yoz 6y ago
  She has so many great pieces on Medium. It's worth looking through them.
wvenable 6y ago
Some companies that have large COBOL code bases don't hire "software developers" -- they hire people who have worked in other careers and want to switch to software development and then they extensively train them internally. This could explain the median age of COBOL developers remaining constant.
- bryanrasmussen 6y ago
  what other careers do they prefer to draw future Cobol developers from?
  - NegativeLatency 6y ago
    a guess: something with domain experience banking/finance?
  - wvenable 6y ago
    I worked with a former construction worker who was going through the training. He saw this as his opportunity to get out of that kind of work. A lot of the hires had non-technical and non-domain backgrounds.
  - pydry 6y ago
    I met one who was trained out of school in Austria. He was in his 20s.
yoz 6y ago
Quoting the article: Around 60% of packages on npm have not been updated in a year or more. Despite the lack of maintenance these packages are still downloaded billions of times. This is a problem across many other languages/frameworks as well. Many popular packages have a single maintainer and the entry in the package manager index is accessible only by that maintainer. If that maintainer stops paying attention, the problems could be worse than the package just bitrotting, as we've seen from supply-chain attacks like event-stream[1]. There are volunteer orgs like Jazzband[2] which take group ownership of popular packages to ensure ongoing maintenance, but I've not seen many of those so far. [1] https://www.hillelwayne.com/post/stamping-on-eventstream/ https://www.hillelwayne.com/post/stamping-on-eventstream/ [2] https://jazzband.co/ https://jazzband.co/
- jedberg 6y ago
  Yeah, this is a big problem with pip. If you can't get the old maintainer to add you as a contributor, you can't update a package on pip. So now you have to fork it, come up with a new name, and then publish that instead. And then hope everyone who depended on the old package switches to your package. Reddit had this same problem with abandoned subreddits. They instituted a policy where you could apply to take over an abandoned subreddit, so if there had been no mod activity you could take over. Pip needs a process like that. They need a way to take over an inactive project. Safety would be a big concern, you don't want someone malicious taking over a popular but abandoned package and then hacking it. But safety the other way is important too. There is also the odd situation where you could end up owning the code and not the package on pip. When my company acquired another, we got all their code. We only realized later that we didn't get the credentials for pip. Luckily the old owner was kind enough to just give us the credentials, but we could have been stuck owning the code but not the pip package.
  - pydry 6y ago
    There's now a PEP for that that seems to have had some work on it recently: https://github.com/pypa/warehouse/issues/1506 https://github.com/pypa/warehouse/issues/1506 (I got an email referencing it a couple days ago from an old project I asked to take over).
netcyrax 6y ago
Couldn't read the article because I've "read all of your free stories this month". I would prefer a few ads rather than the Medium's garden.
- valbaca 6y ago
  there's a trivial workaround to medium's paywall: open a private/incognito browser window
- Sophistifunk 6y ago
  I suggest you get a "Cookie Autodelete" browser extension. Not for Medium per se, but if you have one this problem also goes away.
deckard1 6y ago
> The real horsemen of the legacy apocalypse is the depth of the dependency tree. I won't speak for Java or Python. For Node/JS, I do not see this being a problem for the future. The reason is because npm is so fragile that the entire thing falls over today if you just look at it wrong. The very second you run "npm install" you have a mountain of instant tech debt. The primary reason for this is because the people writing JavaScript do not know what they are doing. They have not cut their teeth on libraries in C/C++ or other languages and have no clue how backwards compatibility or versioning works. If you doubt what I'm saying, then I invite you to do your own quality inspection of any major JS library or framework out there. I'm not going to name names, but the vast majority of it is pure shit. In my experience, JS code has a life expectancy of about a year and a half. Give or take. After that, it is rewritten. Which also contributes to the lack of quality in the JS ecosystem. There is a built-in assumption that this code won't survive past the time your average dev gets bored of it. People, today, do not realize there are JS frameworks that predate React/Angular/etc. and have already died. Once popular frameworks. And I'm not talking jQuery. You don't see them because JS development = churn. You don't even see CoffeeScript mentioned today, and that was just a few years ago.
- vturner 6y ago
  Recently came back to a React GUI at work. Doing the Docker build is almost comical as the npm red text rolls by :). You would think the thing is surely going to explode. Of course, when you run the app React reminds us of all the new best practices which were non existant 6, 8 months ago
- sergiotapia 6y ago
  marionette, backbone, knockoutjs! lol the list is endless. in 5 years, react??? who knows.
  - jcheng 6y ago
    In fairness, a lot has also changed/churned in Windows desktop UI development, iOS development, and Android development over the same time period. (I know a lot less about the latter two, but didn’t they at least both change languages and see the significant rise of PhoneGap/Titanium and then React Native and then Flutter?) And those are all ecosystems that, for better or worse, have a single dominant corporation lording over it.
basscomm 6y ago
Young programmers do not have the option of learning COBOL. The university I went to still offers COBOL classes.
jonnycomputer 6y ago
As I once told an interviewer, "Legacy code is the future!"
awake 6y ago
Python’s standard library is essentially a Swiss army toolkit for manipulating data. It has email and imap parsing built into it! I’m sure this doesn’t completely explain the dependency tree size but it does explain the proliferation of simple packages in JavaScript. Even data structures are difficult to find in JavaScript. Try looking on npm for a max heap. Python has heapq built in. JavaScript has ten libraries that are all equally unpopular.
_bxg1 6y ago
> I’m just not inclined to agree that civil society can’t continue to run on millions of lines of COBOL for another 60 years. It certainly can. > Java 8 and Python 2 on the other hand are a far more serious threat. When systems can’t get off end of life technology they miss security updates, performance enhancements, and new features. This seems contradictory. Is it not also a problem that COBOL hasn't been getting security updates for years (I assume)? Are COBOL systems typically isolated from the outside world in some way?
- bokwoon 6y ago
  I think it's probably because COBOL has almost no dependencies. Correct me if I'm wrong. > The real horsemen of the legacy apocalypse is the depth of the dependency tree. Modern software development stacks abstraction on top of abstraction.
- mech422 6y ago
  Sort of... COBOL programs are usually batch programs, and grab input from tape rather then the net. Interactive stuff tends to only be run on internal networks (3270 terminals used to be the norm).
  - _bxg1 6y ago
    Yeah, I wondered if it was something like that. Sounds like input is sanitized before it even touches that system. Which begs an interesting train of thought: could we make systems that last longer by doing a better job of isolating pieces of them from the outside world? If malicious input never reaches your code, does it even need security updates?
    - mywittyname 6y ago
      The rubber has to meet the road. Users have to interface with the software. "Backend" software tends to be very long lived because it's not client facing. Clients don't care that the software was written in Java2 and uses some weird-ass collection of korn shell scripts to keep things moving. These scripts usually just need to eat data from one location, and poop it into another. And because these systems are old, they are well tested and battle hardened. But that backend is no good without some form of user interface. This is almost always the place where things break down. There are many more people involved in the decision making for UX, and we have more and more devices with different use-cases. Most tech-ish companies can't afford to ignore completely new computing paradigms for decades.
Wowfunhappy 6y ago
There's a fundamental question here which no one ever seems to ask: Why is the modern software industry in such a constant state of flux? Are we really becoming so much collectively smarter every year, and if not, why did the previous version of Software X make the wrong decision? Is there an end point where we all actually figure out how to develop software properly? As I see it, truly mature software should introduce breaking changes twice a decade at most, and ideally less often than that. I don't doubt that most software updates provide a net benefit, but what of the inherent cost of change? Changes require every single user to put in extra work, to adapt to the new version's functionality. Why are software projects so cavalier with their users's time? And this applies to end-user software too, by the way. Every time Slack redesigns its interface, users need to relearn where all the buttons are. Nothing can possibly justify rolling out ten million redesigns; if a facelift is in order, leave it in the oven for long enough to get it right, and then be done.
- save_ferris 6y ago
  > Why is the modern software industry in such a constant state of flux? I see huge software frameworks sort of like political parties. The community around each of them promotes the benefits of using their framework over someone else’s, and we “vote” by hitching our products to these tools. If you didn’t choose wisely, or the framework didn’t develop in a way that benefited you or your org, you’re probably keeping an eye out for what’s next. The other component to all of this is figuring out how to stay relevant in the industry, and I see more and more frameworks making design decisions around this fact. Take Gatsby, for example. I still can’t figure out why they use graphql to populate templates other than developers wanting graphql experience, ergo let’s use gatsby. The whole point of graphql was to minimize data transfer from server to client, but somebody thought this was somehow more beneficial to generating a static page than a vanilla JS object. > Every time Slack redesigns its interface, users need to relearn where all the buttons are. Nothing can possibly justify rolling out ten million redesigns; I think this partly falls on engineering orgs with development teams that need to justify their existence by constantly rolling out these kinds of changes. Because of Slack decides to freeze the UI, how many front end devs are going to need to be reallocated? This rant was somewhat aimless, but I think ultimately that many of your rightful criticisms are the product of the politics of engineering companies and communities.
ncmncm 6y ago
She found plenty to talk about without even mentioning the Lava Flow anti-pattern. Her other essays are also insightful. The one about Steve Jobs is the best about him I have read, even considering Isaacson.
tehjoker 6y ago
This is one of the better tech articles I've seen on here recently. The analysis of why Python vs. node ecosystems vary in dependency depth and breadth is good food for thought. Python has long been a "batteries" included language whereas node has not. Node makes it easy to publish packages whereas my experience with python is that it is quite difficult to get a handle on doing PyPI (versus Anaconda!) the right way. Publishing wheels versus source is confusing and it took me a while to understand the nuances. There's also the idea of supporting python2 vs python3, which people from different quarters will criticize no matter what approach you take. Publishing binaries on Python is also difficult and a highly skilled endeavor requiring additional knowledge of compiling shared objects, docker, and the baroque manylinux concept. Once you have a system down, it becomes easy, but that took me about 6-12 months of accepting increasingly complex requirements before I could get a decent handle on it. I have not tried publishing binaries on npm so I can't say what the relative experience is.
czbond 6y ago
A bit of fun - "That's what I love about this code, man. I get older, it stays the same age”. “Alright, alright, alright.”
stuff4ben 6y ago
I'm banking on Java still being needed when I'm 65 (~20 years from now) and close to retirement. When my 401k is worthless, I'll still be able to make a living until I'm dead and buried. Seriously though, Java is the COBOL of tomorrow.
hinkley 6y ago
> In all likelihood the reason the average age of COBOL programmers is stable is because COBOL programmers develop their depth of experience and expertise in other languages before moving over to COBOL later in their career. No, it's probably that there's a steady but small influx of new developers coming in and the bell curve is throwing off the 'average'. Lies, damned lies and statistics. Answering questions with statistics is a rookie mistake.
mcv 6y ago
I can't help but look at this from the other direction: why does code constantly have to be updated? There's something to be said for something that, once built, simply works. People love plenty of old things: antique furniture, oldtimer cars, classic books from centuries ago, monumental buildings. But software needs to be constantly rewritten en updated, and that takes a lot of work. On the one hand I don't want to make the case for outdated languages and systems, but on the other, we are spending a lot of effort just keeping things up to date with the latest technologies. Sometimes that's really necessary of course; security holes need to be fixed, and frequently new features are necessary. Better ways of doing things have been discovered or developed. But man, there's a lot of effort going into these legacy systems. Although I love learning new things, I also kinda hope that some day we'll reach systems and languages that are so well-designed that they don't need to be changed much, or at least keeping them up to date will become trivial.
- Cthulhu_ 6y ago
  It's because the landscape moves on. Take Windows applications; plenty of apps were built for Windows 95 or Internet Explorer 6, but they no longer work in newer versions of Windows or IE. Companies are holding back on updating their users' browsers because they depend on these applications. This leaves them with two options; invest to have the application updated or rebuilt for modern browsers, or take the risk of outdated and insecure software. I guess it can work with sandboxing and virtualization and the like (how they nowadays keep old mainframe applications working on modern hardware), but it's a patch.
  - mcv 6y ago
    I know why it happens, but I still regret it when that means old things become inaccessible. Old games become unplayable, or websites stop working (not to mention that they are frequently unfindable on search engines), etc. We treasure the writings of the distant past, but the 1990s are already becoming surprisingly inaccessible. For games, there's fortunately gog.com that tries to keep old games playable, and archive.org of course tries to preserve old web content, but that only really works for static content. And then there's all the cool stop-motion lego animation I found before Youtube came along, and now I can't find them anymore. Internet sometimes feels like a city bulldozering their entire city center to rebuild everything according to the latest standards. It's certainly convenient, but you lose so much history. But now I'm talking more about the loss of content than about the fact that everything requires constant updating and is never done. These are two different concerns, but I feel them both.
nonsince 6y ago
I know the Rust Evangelism Strike Force is a meme, but Rust genuinely has a good solution to language rot with its "edition" concept, where the language can be updated and the compiler just converts all code to a mutually-interoperable internal representation. It’s not dissimilar to using something like Babel for JS, except that because this internal representation is extremely simple, it’s far easier for the language to change more, add restrictions, remove restrictions, and so forth, while still being interoperable. Sadly, Rust has no good equivalent when it comes to libraries, and it’s not unheard of to have two libraries that should be interoperable fail to compile because there’s no way to find a single version of a shared library that satisfies both of their version constraints, even though the actual types in question are identical. I’m not sure if the error messages still look like this, but they used to say something like `expected foo::Bar, got foo::Bar`.

240 points by mbellotti 6y ago

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.

kbenson 6y ago

Kinda surprised to not see Perl in there in some form, since it's still around as the glue holding a lot of older systems together (and for new stuff, but that's not the point of this article). Then again, it's got a little bit different of a story, since most (almost all) the old Perl from decades ago will run find on a brand new Perl interpreter released recently.

hedora 6y ago
Perl 5 is still actively supported, unlike python 2.
pinewurst 6y ago
I have a Perl problem right now. It's not the Perl interpreter at all, which as you say runs the old code fine. It's the hierarchy (read as "dungheap") of package dependencies that have changed since the last primary software version was installed.
- kbenson 6y ago
  Well, the good thing is all those old versions of modules are archived[1] and you can still get them if you really need to, and there are utils to spider the dependency chain and tell you the packages and versions (and I think stuff that will make sure those versions get fetched) on CPAN itself, so it shouldn't be too hard to get the prior stuff up and running if you go that route (even if it might have security implications). The only stuff it would be hard to back down in versions would be core stuff, but I'm not aware of any core Perl modules that have had breaking API changes. 1: http://backpan.cpantesters.org/ http://backpan.cpantesters.org/ Edit: Cleaned up an ambiguous sentence in the middle there.

dsdklfjskldj 6y ago

Meanwhile, Android still doesn't fully support java 8.

_old_dude_ 6y ago
> from the TFA, The end of life for Java 8 was supposed to be 2019 Nope, that the EOL of the free support of Oracle JDK 8. Currently, the OpenJDK 8 is maintained mostly by RedHat, so EOL of Java 8 is at least 2026 [1] [1] https://access.redhat.com/articles/1299013 https://access.redhat.com/articles/1299013
pjmlp 6y ago
My schadenfreude regarding Android is that some Kotlin cool library on the JVM ends up requiring Java 8+ features and then all those #KotlinFirst heads on Android will finally get it why compatibility with newer versions is a must. However most likely what will happen is some fork to make it somehow work on Android, even if with less features.

ChrisMarshallNY 6y ago

I'm happy I found Marianne Bellotti. Good stuff. I'm following her now.

yoz 6y ago
She has so many great pieces on Medium. It's worth looking through them.

wvenable 6y ago

Some companies that have large COBOL code bases don't hire "software developers" -- they hire people who have worked in other careers and want to switch to software development and then they extensively train them internally. This could explain the median age of COBOL developers remaining constant.

bryanrasmussen 6y ago
what other careers do they prefer to draw future Cobol developers from?
- NegativeLatency 6y ago
  a guess: something with domain experience banking/finance?
- wvenable 6y ago
  I worked with a former construction worker who was going through the training. He saw this as his opportunity to get out of that kind of work. A lot of the hires had non-technical and non-domain backgrounds.
- pydry 6y ago
  I met one who was trained out of school in Austria. He was in his 20s.

yoz 6y ago

Quoting the article: Around 60% of packages on npm have not been updated in a year or more. Despite the lack of maintenance these packages are still downloaded billions of times. This is a problem across many other languages/frameworks as well. Many popular packages have a single maintainer and the entry in the package manager index is accessible only by that maintainer. If that maintainer stops paying attention, the problems could be worse than the package just bitrotting, as we've seen from supply-chain attacks like event-stream[1]. There are volunteer orgs like Jazzband[2] which take group ownership of popular packages to ensure ongoing maintenance, but I've not seen many of those so far. [1] https://www.hillelwayne.com/post/stamping-on-eventstream/ https://www.hillelwayne.com/post/stamping-on-eventstream/ [2] https://jazzband.co/ https://jazzband.co/

jedberg 6y ago
Yeah, this is a big problem with pip. If you can't get the old maintainer to add you as a contributor, you can't update a package on pip. So now you have to fork it, come up with a new name, and then publish that instead. And then hope everyone who depended on the old package switches to your package. Reddit had this same problem with abandoned subreddits. They instituted a policy where you could apply to take over an abandoned subreddit, so if there had been no mod activity you could take over. Pip needs a process like that. They need a way to take over an inactive project. Safety would be a big concern, you don't want someone malicious taking over a popular but abandoned package and then hacking it. But safety the other way is important too. There is also the odd situation where you could end up owning the code and not the package on pip. When my company acquired another, we got all their code. We only realized later that we didn't get the credentials for pip. Luckily the old owner was kind enough to just give us the credentials, but we could have been stuck owning the code but not the pip package.
- pydry 6y ago
  There's now a PEP for that that seems to have had some work on it recently: https://github.com/pypa/warehouse/issues/1506 https://github.com/pypa/warehouse/issues/1506 (I got an email referencing it a couple days ago from an old project I asked to take over).

netcyrax 6y ago

Couldn't read the article because I've "read all of your free stories this month". I would prefer a few ads rather than the Medium's garden.

valbaca 6y ago
there's a trivial workaround to medium's paywall: open a private/incognito browser window
Sophistifunk 6y ago
I suggest you get a "Cookie Autodelete" browser extension. Not for Medium per se, but if you have one this problem also goes away.

deckard1 6y ago

> The real horsemen of the legacy apocalypse is the depth of the dependency tree. I won't speak for Java or Python. For Node/JS, I do not see this being a problem for the future. The reason is because npm is so fragile that the entire thing falls over today if you just look at it wrong. The very second you run "npm install" you have a mountain of instant tech debt. The primary reason for this is because the people writing JavaScript do not know what they are doing. They have not cut their teeth on libraries in C/C++ or other languages and have no clue how backwards compatibility or versioning works. If you doubt what I'm saying, then I invite you to do your own quality inspection of any major JS library or framework out there. I'm not going to name names, but the vast majority of it is pure shit. In my experience, JS code has a life expectancy of about a year and a half. Give or take. After that, it is rewritten. Which also contributes to the lack of quality in the JS ecosystem. There is a built-in assumption that this code won't survive past the time your average dev gets bored of it. People, today, do not realize there are JS frameworks that predate React/Angular/etc. and have already died. Once popular frameworks. And I'm not talking jQuery. You don't see them because JS development = churn. You don't even see CoffeeScript mentioned today, and that was just a few years ago.

vturner 6y ago
Recently came back to a React GUI at work. Doing the Docker build is almost comical as the npm red text rolls by :). You would think the thing is surely going to explode. Of course, when you run the app React reminds us of all the new best practices which were non existant 6, 8 months ago
sergiotapia 6y ago
marionette, backbone, knockoutjs! lol the list is endless. in 5 years, react??? who knows.
- jcheng 6y ago
  In fairness, a lot has also changed/churned in Windows desktop UI development, iOS development, and Android development over the same time period. (I know a lot less about the latter two, but didn’t they at least both change languages and see the significant rise of PhoneGap/Titanium and then React Native and then Flutter?) And those are all ecosystems that, for better or worse, have a single dominant corporation lording over it.

basscomm 6y ago

Young programmers do not have the option of learning COBOL. The university I went to still offers COBOL classes.

jonnycomputer 6y ago

As I once told an interviewer, "Legacy code is the future!"

awake 6y ago

Python’s standard library is essentially a Swiss army toolkit for manipulating data. It has email and imap parsing built into it! I’m sure this doesn’t completely explain the dependency tree size but it does explain the proliferation of simple packages in JavaScript. Even data structures are difficult to find in JavaScript. Try looking on npm for a max heap. Python has heapq built in. JavaScript has ten libraries that are all equally unpopular.

_bxg1 6y ago

> I’m just not inclined to agree that civil society can’t continue to run on millions of lines of COBOL for another 60 years. It certainly can. > Java 8 and Python 2 on the other hand are a far more serious threat. When systems can’t get off end of life technology they miss security updates, performance enhancements, and new features. This seems contradictory. Is it not also a problem that COBOL hasn't been getting security updates for years (I assume)? Are COBOL systems typically isolated from the outside world in some way?

bokwoon 6y ago
I think it's probably because COBOL has almost no dependencies. Correct me if I'm wrong. > The real horsemen of the legacy apocalypse is the depth of the dependency tree. Modern software development stacks abstraction on top of abstraction.
mech422 6y ago
Sort of... COBOL programs are usually batch programs, and grab input from tape rather then the net. Interactive stuff tends to only be run on internal networks (3270 terminals used to be the norm).
- _bxg1 6y ago
  Yeah, I wondered if it was something like that. Sounds like input is sanitized before it even touches that system. Which begs an interesting train of thought: could we make systems that last longer by doing a better job of isolating pieces of them from the outside world? If malicious input never reaches your code, does it even need security updates?
  - mywittyname 6y ago
    The rubber has to meet the road. Users have to interface with the software. "Backend" software tends to be very long lived because it's not client facing. Clients don't care that the software was written in Java2 and uses some weird-ass collection of korn shell scripts to keep things moving. These scripts usually just need to eat data from one location, and poop it into another. And because these systems are old, they are well tested and battle hardened. But that backend is no good without some form of user interface. This is almost always the place where things break down. There are many more people involved in the decision making for UX, and we have more and more devices with different use-cases. Most tech-ish companies can't afford to ignore completely new computing paradigms for decades.

Wowfunhappy 6y ago

There's a fundamental question here which no one ever seems to ask: Why is the modern software industry in such a constant state of flux? Are we really becoming so much collectively smarter every year, and if not, why did the previous version of Software X make the wrong decision? Is there an end point where we all actually figure out how to develop software properly? As I see it, truly mature software should introduce breaking changes twice a decade at most, and ideally less often than that. I don't doubt that most software updates provide a net benefit, but what of the inherent cost of change? Changes require every single user to put in extra work, to adapt to the new version's functionality. Why are software projects so cavalier with their users's time? And this applies to end-user software too, by the way. Every time Slack redesigns its interface, users need to relearn where all the buttons are. Nothing can possibly justify rolling out ten million redesigns; if a facelift is in order, leave it in the oven for long enough to get it right, and then be done.

save_ferris 6y ago
> Why is the modern software industry in such a constant state of flux? I see huge software frameworks sort of like political parties. The community around each of them promotes the benefits of using their framework over someone else’s, and we “vote” by hitching our products to these tools. If you didn’t choose wisely, or the framework didn’t develop in a way that benefited you or your org, you’re probably keeping an eye out for what’s next. The other component to all of this is figuring out how to stay relevant in the industry, and I see more and more frameworks making design decisions around this fact. Take Gatsby, for example. I still can’t figure out why they use graphql to populate templates other than developers wanting graphql experience, ergo let’s use gatsby. The whole point of graphql was to minimize data transfer from server to client, but somebody thought this was somehow more beneficial to generating a static page than a vanilla JS object. > Every time Slack redesigns its interface, users need to relearn where all the buttons are. Nothing can possibly justify rolling out ten million redesigns; I think this partly falls on engineering orgs with development teams that need to justify their existence by constantly rolling out these kinds of changes. Because of Slack decides to freeze the UI, how many front end devs are going to need to be reallocated? This rant was somewhat aimless, but I think ultimately that many of your rightful criticisms are the product of the politics of engineering companies and communities.

ncmncm 6y ago

She found plenty to talk about without even mentioning the Lava Flow anti-pattern. Her other essays are also insightful. The one about Steve Jobs is the best about him I have read, even considering Isaacson.

tehjoker 6y ago

This is one of the better tech articles I've seen on here recently. The analysis of why Python vs. node ecosystems vary in dependency depth and breadth is good food for thought. Python has long been a "batteries" included language whereas node has not. Node makes it easy to publish packages whereas my experience with python is that it is quite difficult to get a handle on doing PyPI (versus Anaconda!) the right way. Publishing wheels versus source is confusing and it took me a while to understand the nuances. There's also the idea of supporting python2 vs python3, which people from different quarters will criticize no matter what approach you take. Publishing binaries on Python is also difficult and a highly skilled endeavor requiring additional knowledge of compiling shared objects, docker, and the baroque manylinux concept. Once you have a system down, it becomes easy, but that took me about 6-12 months of accepting increasingly complex requirements before I could get a decent handle on it. I have not tried publishing binaries on npm so I can't say what the relative experience is.

czbond 6y ago

A bit of fun - "That's what I love about this code, man. I get older, it stays the same age”. “Alright, alright, alright.”

stuff4ben 6y ago

I'm banking on Java still being needed when I'm 65 (~20 years from now) and close to retirement. When my 401k is worthless, I'll still be able to make a living until I'm dead and buried. Seriously though, Java is the COBOL of tomorrow.

hinkley 6y ago

> In all likelihood the reason the average age of COBOL programmers is stable is because COBOL programmers develop their depth of experience and expertise in other languages before moving over to COBOL later in their career. No, it's probably that there's a steady but small influx of new developers coming in and the bell curve is throwing off the 'average'. Lies, damned lies and statistics. Answering questions with statistics is a rookie mistake.

mcv 6y ago

I can't help but look at this from the other direction: why does code constantly have to be updated? There's something to be said for something that, once built, simply works. People love plenty of old things: antique furniture, oldtimer cars, classic books from centuries ago, monumental buildings. But software needs to be constantly rewritten en updated, and that takes a lot of work. On the one hand I don't want to make the case for outdated languages and systems, but on the other, we are spending a lot of effort just keeping things up to date with the latest technologies. Sometimes that's really necessary of course; security holes need to be fixed, and frequently new features are necessary. Better ways of doing things have been discovered or developed. But man, there's a lot of effort going into these legacy systems. Although I love learning new things, I also kinda hope that some day we'll reach systems and languages that are so well-designed that they don't need to be changed much, or at least keeping them up to date will become trivial.

Cthulhu_ 6y ago
It's because the landscape moves on. Take Windows applications; plenty of apps were built for Windows 95 or Internet Explorer 6, but they no longer work in newer versions of Windows or IE. Companies are holding back on updating their users' browsers because they depend on these applications. This leaves them with two options; invest to have the application updated or rebuilt for modern browsers, or take the risk of outdated and insecure software. I guess it can work with sandboxing and virtualization and the like (how they nowadays keep old mainframe applications working on modern hardware), but it's a patch.
- mcv 6y ago
  I know why it happens, but I still regret it when that means old things become inaccessible. Old games become unplayable, or websites stop working (not to mention that they are frequently unfindable on search engines), etc. We treasure the writings of the distant past, but the 1990s are already becoming surprisingly inaccessible. For games, there's fortunately gog.com that tries to keep old games playable, and archive.org of course tries to preserve old web content, but that only really works for static content. And then there's all the cool stop-motion lego animation I found before Youtube came along, and now I can't find them anymore. Internet sometimes feels like a city bulldozering their entire city center to rebuild everything according to the latest standards. It's certainly convenient, but you lose so much history. But now I'm talking more about the loss of content than about the fact that everything requires constant updating and is never done. These are two different concerns, but I feel them both.

nonsince 6y ago

I know the Rust Evangelism Strike Force is a meme, but Rust genuinely has a good solution to language rot with its "edition" concept, where the language can be updated and the compiler just converts all code to a mutually-interoperable internal representation. It’s not dissimilar to using something like Babel for JS, except that because this internal representation is extremely simple, it’s far easier for the language to change more, add restrictions, remove restrictions, and so forth, while still being interoperable. Sadly, Rust has no good equivalent when it comes to libraries, and it’s not unheard of to have two libraries that should be interoperable fail to compile because there’s no way to find a single version of a shared library that satisfies both of their version constraints, even though the actual types in question are identical. I’m not sure if the error messages still look like this, but they used to say something like `expected foo::Bar, got foo::Bar`.