I think there's a difference between giving you powerful, easy to use tools to solve your problems with, and solving your problems for you.
I am primarily a vim user with VS Code as my secondary editor. I have never ever used their one-click solutions.
I have seen someone choosing "Yes" to everything VS Code said after installation, and in no time their machine was filled with bloat that they would never ever need.
But I see this as a good thing. It is making programming set up easier for the uninitiated, which is good.
The uninitiated should begin with a bare-bones text editor and a shell prompt. If you don't understand what is happening from that level, you will never understand what is going on in complicated frameworks. You will be the programming equivalent of your grandmother who thinks Facebook is the internet.
> We have to remember that that is the end goal -- spend less time programming computers, and less time solving problems, and more time with a working solution.
I of disagree that time-to-solution is the true end-goal. It might be, depending on your use case, but there may be other constraints. For instance, let's say I make a piece of software, and I have a choice between choosing an "easy" solution which takes me 100 hours to complete, or a hard version which takes 500 hours. And let's say the easy version allows the user to complete their task in 30 seconds, where the hard version allows them to complete their task in 10 second. That means every time my code is executed, I have saved 20 seconds of the user's time by doing things the hard way.
Now let's say my code is executed on average 1000 times per hour. That means every hour my product is out there, I save about 5.5 hours of user time for doing things the hard way. In only 72 hours, that 400 hours of productivity I "lost" is made up for, and for the rest of the lifetime of the product it's pure upside.
At the end of the day, programming is about making computer hardware do what you want. If we let ourselves get too far away from the computer, it's hard for us to do that well.
If you know the basics you can apply them to any tool. If you only learn to build software using a specific framework, IDE etc. you're probably going to have problems if anything in the setup changes. One day in a simple text editor and a shell taught me more about how Java builds work than years of formal education, because all those years were spent in an IDE and nobody even explained what the classpath is.
If your goal to solve a problem, then you should use something that helps you solve that problem quickly. If your goal to learn how to solve problems, then you probably shouldn't. Those are both valid use cases, but they are very different.
Get people excited and empowered, then teach them some arcana.
For instance, I think basically everyone can agree that moving from assembly to C and other high-level languages was basically a strict upgrade, and obviated the need for assembly programming in all but a few specific use cases.
By contrast, using the command line and shell programming is every bit as relevant as it was 20 years ago, and I don't see that changing any time soon.
Both assembly and the shell are difficult and alienating to newcomers. But learning is mostly academic at this point, while learning the other opens up entire new worlds in terms of what you can do with a computer.
In other words, learning assembly is like learning latin. Maybe interesting, but not particularly useful. Learning bash is like learning Chinese. Not particularly easy, but there's a lot you can do with it right now.
On the other someone could have said the same to your regarding assembly code and so on.
Just building more tooling to cover up pain points by wrapping them in more and more layers of bloat is just making a mess. You wind up needing a super complex system to do simple things, which nobody really understands, and which uses a ton of unnecessary resources. If you extend that strategy ad infinitum, you need Moore's Law to persist just to keep performance stable while running more and more layers of VSCode plugins.
I also don't necessarily think some barriers to entry are always a bad thing. Things like notebooks are great for giving people access to a simple programming environment which is easy to set up. But if someone is going to be committing code to a serious project I'm working on, I don't mind if they have to know enough about computers to at least run a few commands in the terminal.
Lower level technologies need to be more flexible to allow usage in many different cases. On top of that we build different abstractions that are suitable for only a restricted number of uses cases, but that make them much simpler to think about and work with. By thinking at this higher level we are able to build much more complex logics than we would have before.
I certainly wouldn't want to be stuck in a world where we still have to do everything in assembly because we were too afraid to embrace the compiler.
Progress isn't only about building and endlessly taller stack of abstractions such that we eventually can't see the computer underneath. Sometimes it's about looking at the stack we have, and building a smaller and smarter one based on the lessons we learned along the way.
If they're an enduser, btn click is exactly what they should use. If they are an engineer, and clicking btns is all they know, then they are going to be a very limited engineer. This too is fine and there is a place for that. But, if such an engineer starts to think that they are a great engineer because they solve all the problems quickly whenever there are btns, they are going to be a liability for teams when there aren't any btns to click. Because they are going to be too arrogant to listen to those who might know how to solve them which aren't necessarily btn clicks (because to them all solutions must be btn clicks). You see, it's more than a matter of principle. It's about the calibre of the engineer you want to produce.