>Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years.
I think if you pick a concrete example of this phenomena (say, Java applets vs. WebAssembly) and you ask "so why didn't someone take Java Applets and update them, why do we need WebAssembly?", the answers to why this happens start to become more apparent. It's not so much that Java applets were good and then we decided they were unfashionable, as that Java applets were always kind of ugly and we eventually stopped tolerating them.
For examples from before say, 2000, say Turbo Pascal a lot of the answer is because the thing in question was a proprietary product so once the financially backed dev team stopped working on it users were forced to move on to something else. Other times it's because the thing was written for an 80's computer platform that no longer exists outside of emulation and retrocomputing collections. Sometimes it's that the graphical standards the original used were for hardware with very different capabilities and making the thing usefully work on a newer system would almost require a total rewrite anyway.
Even beyond all that, there's another problem: Software is fairly hard to do literature review for. If I want to know if a particular research idea has been done before, I can hop on Google Scholar and figure it out with a few hours of carefully constructed search queries. Doing the same thing for software is very difficult, especially because most products for the majority of the fields history were proprietary. As a consequence, we don't have our history available to analyze in any easily accessed form. The Internet Archive has been doing what they can to rectify this situation. (See: https://archive.org/details/BeyondCyberpunkMacintosh) Nonetheless, there are still serious problems in this area.
I'm a younger person (23) who shares your frustrations, but I don't think that you can really wag your finger at people when there are real barriers to what you're proposing.
> I think if you pick a concrete example of this phenomena (say, Java applets vs. WebAssembly) and you ask "so why didn't someone take Java Applets and update them, why do we need WebAssembly?", the answers to why this happens start to become more apparent. It's not so much that Java applets were good and then we decided they were unfashionable, as that Java applets were always kind of ugly and we eventually stopped tolerating them.
I've been asking this exact question on various HN threads with WebAssembly announcements, and the answer is always one of "Applets are insecure" or "Java is insecure".
So I don't really follow your example here... whatever security model you want to have, it seems much more obvious to implement it for Java applets than to implement WebAssembly and then implement your preferred security model for WebAssembly. Why do you think we replaced applets with WebAssembly?
(It's kind of a leading question -- my experience as a browser user suggests that we stopped using applets, spent a while not having them, and then started working on WebAssembly. By that analysis, we never replaced applets with WebAssembly -- we replaced applets with nothing, and then replaced nothing with WebAssembly. That would tend to support the more crotchety answer of "people developed WebAssembly because they just forgot about applets".)
My understanding was that the concern wasn't necessarily that the jvm was insecure, or the browser was insecure (although they've all had vulberabilities at one time or another) it was the integration between the jvm and the browser that was difficult/impossible to get right. This not only held for Java but any browser plugin (flash, silverlight). The entire concept was just bad.
Now where webassembly comes in is a compilation target for anything to the browser. I had the sorry misfortune of working on a project that had an applet that interacted extensively with the host page. It was excruciating, the api's were not up to the task. At the time, before the canvas tag, that's the length we had to go to get "advanced" functionality into a page. Nowadays that could all be done with js (or X compiled to webassembly) and canvas element. Things evolve.
Native plugins only work on desktops/laptops. They don't work on mobiles because hardware and software diversity, also because security model is more friendly towards consumers. And mobile users are now more than 50%.
The move into the web alone was responsible for a lot of that killing. Up to this day web tools are not as good as the old desktop ones, but those old ones are all dying. Mobile devices also killed some stuff, but much less.
Before that, computer networking killed most of the running systems. And before those, any new computer would require all new software, so there was no continuation at all.
Things seem to be getting slower with time... maybe except on Javascript frameworks.
Well, in my comments I was restricting my examples mostly to server side software running on UNIX.
This eliminates much of the proprietary lockin and portability problems you mention. I never was saying people should just keep using Delphi into the 21st century.
Also, my comments apply to broad categories of solutions not just software implementations in the narrow sense.
For example: I just replaced (had to for perf reasons) a NOSQL solution in one of our applications with MySQL.
Ironically, the application would actually scale better with NoSQL in theory, but the choices the developers made along the way (data modelling and API design) made it perform worse on the NoSQL DB than on MySQL.
The tactical solution, which fits our needs and the size of our user base, turned out to be to replace a new shiny thing, with an older technology. The benefit gained was more flexibility with queries, which in turn allowed us to speed things up significantly with little effort.
The previous team burned a lot of time learning the new NoSQL thing to then not get any benefit from it at all.
WebAssembly is definitely a great example of a technology looking for a problem to solve. Java Applets are more comparable to conventional JavaScript, and the latter’s advantage (DOM integration) isn’t even in WASM yet. WASM is probably for something else.
I think if you pick a concrete example of this phenomena (say, Java applets vs. WebAssembly) and you ask "so why didn't someone take Java Applets and update them, why do we need WebAssembly?", the answers to why this happens start to become more apparent. It's not so much that Java applets were good and then we decided they were unfashionable, as that Java applets were always kind of ugly and we eventually stopped tolerating them.
For examples from before say, 2000, say Turbo Pascal a lot of the answer is because the thing in question was a proprietary product so once the financially backed dev team stopped working on it users were forced to move on to something else. Other times it's because the thing was written for an 80's computer platform that no longer exists outside of emulation and retrocomputing collections. Sometimes it's that the graphical standards the original used were for hardware with very different capabilities and making the thing usefully work on a newer system would almost require a total rewrite anyway.
Even beyond all that, there's another problem: Software is fairly hard to do literature review for. If I want to know if a particular research idea has been done before, I can hop on Google Scholar and figure it out with a few hours of carefully constructed search queries. Doing the same thing for software is very difficult, especially because most products for the majority of the fields history were proprietary. As a consequence, we don't have our history available to analyze in any easily accessed form. The Internet Archive has been doing what they can to rectify this situation. (See: https://archive.org/details/BeyondCyberpunkMacintosh) Nonetheless, there are still serious problems in this area.
I'm a younger person (23) who shares your frustrations, but I don't think that you can really wag your finger at people when there are real barriers to what you're proposing.