That's because at some point the industry lost the plot.

The fundamentals are fundamental. They don't change very fast.

Applications change all the time. So do frameworks. But there's very little genuinely new in most frameworks, or in most languages for that matter. They're mostly repackagings of the same few ideas.

Which is why it's a lot easier to pick up applications and do a good job with them if you know the fundamentals than if you're hacking away without any contextual or historical understanding.

Meanwhile someone is going to have to do the next generation of pure research, and it's a lot harder to do something creative and interesting in CS if all you've ever known is js, Python, and Ruby.

The reality is that software quality is decreasing. Never mind maintainability or even documentation - applications are becoming increasingly buggy and unreliable.

It's common in the UK now for bank systems to crash. Ten years ago it was incredibly rare, and twenty years ago it was practically unthinkable.

Software is too important to be left to improvisation and busking. So "just learn to make applications from other applications" is not a welcome move.

I wonder how much of this is due to the idea: 1) non-technical users need to be able to use our software. How much code today is about preventing users from doing something they should know better? 2) we're less and less able to say "no, that goes way beyond the project's scope" to our bosses. Our bosses will quickly reply "yeah well Google's ______ does it, so why can't we?".

this is due to the idea that modern sw developers do not care what they do, but care a lot about how they do things. They pay no attention to the business problem at hand (in my experience they get very upset when I try to draw their attention to the business requirements) but spend all their time discussing what *-pad framework is the best candidate.