alt Hacker NewsYou know, one of these days I really need to sit down and play with some of these "legacy" languages, like Fortran or COBOL or Ada or APL; languages that have certainly fallen out of popularity but are still used in some critical places.
It does make me wonder about millions and millions of lines of Java out there; Java has more or less eaten the enterprise space (for better or worse), but is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems?
Replies
Ada is an order of magnitude more modern and sophisticated than your other examples.
I expect Ada will capture 0.05% of the market for the next 100 years.
I program an Android app for a Fortune 100 company. Last commit where someone edited a Java file was last week.
Most of the new code from the past few years has been in Kotlin though.
I feel like APL is worth the experience, because it's such a different paradigm.
I've got a soft spot for it as well because I actually used it. At work. On a PC. In the 90s. My assignment was to figure out how to get data into it, for which I ended up writing a routine that operated on floating point numbers as vectors of 1s and 0s and swapped the bits around to convert from Microsoft to IEEE format. While wearing an onion on my belt, of course.
Fortran is pretty nice to write in if you are just writing numerical stuff. If I were just doing a pure numerical simulation, I would rather do it in fortran than c++ or python (without numpy which is just fortran and c++)
Fortran is not a legacy language.
Tryapl.org exists if want to play with APL - John Scholes' Game of Life and other excellent videos (https://www.youtube.com/watch?v=a9xAKttWgP4) might spark your interest
Other newer array languages exist too - https://aplwiki.com/wiki/Running_APL if want to explore the current space.
>but is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems?
It feels like we're getting into that space already.
Similar thing applies to SAP ABAP. It is like Java from a parallel world, where the accumulated cruft for maintaining backward compatibility is 3-4 times more than Java. It also like a low code/no code environment where the language, the UI, ABAP IDE etc is tightly coupled to one another. Like Java, it has continued to add more language features with time, but the legacy code using old constructs is still there in the codebase of many of the orgs.
Initially and up to some extent still now, it is verbose and wording wise, very similar to COBOL, then somewhere I guess in the late 90s, OO paradigm wave came in, and it had "OO ABAP" with classes and methods. Now cloud wave is influencing it and ABAP now has a new cloud flavor "ABAP for cloud" where most of the old constructs are not supported.
"is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems?"
I don't think so. But it's pretty much guaranteed that a lot of the people who are complaining about COBOL today are writing systems that will be legacy in 30 years. And the generation of programmers then will be complaining about today's programmers.
Especially when I look at node or python with tons of external packages (.NET going the same way), I don't see a good long term future.
I wrote a small program in Algol 68 once. It was horrible because it didn't even have heap allocation in the language, so things you'd think of doing in C (e.g., tree data structures) just didn't work. That and all the compiler errors were pure numerical codes which you had to go look up in the manual (not provided). And forget about getting line numbers.
I am very much glad I wasn't alive at the time this was the state of the art.
IBM offers a free COBOL plugin for VSCode and a nice tutorial with it.
I started programming in COBOL (circa 1990) and took the tutorial just for fun earlier this year.
I’m not sure I’d choose to use Fortran, but at one point I had to maintain an app that had a Delphi UI and Fortran business logic. The Fortran, although spaghetti, was much less frustrating to work with.
> in 30-40 years the only people writing Java will be retirees maintaining old banking systems?
I kinda suspect that if Java is still around in 30 years, what we call Java will be - at best - vaguely recognizable.
Fortran is alive and well in science and engineering. The more modern standards are much nicer to work with, but largely backwards compatible with stuff written 50 years ago.
I can't say whether Java as a whole will ever become the next COBOL, but Java 8 already is well on the way there.
Cobol is still there not because of cobol itself, but because of vendor and platform lock-in. And I guess having monolithic codebase/platform.
it’s not even esoteric and difficult, just a lot of it without much structure visible to you.