I might be in the minority here, but I don’t particularly enjoy how IDEs at the level of abstraction above vi/emacs encourage the normalization “things aren’t working well; and I’m powerless to fix it.”
To illustrate my point, if my colleague’s VSC config is broken, or if it’s taking way too long to detect python tests, or what have you, my colleague’s unfamiliarity with the layer of abstraction just below the editor (jedi, pytest, pylanguageserver), means they view the situation as inevitable, impenetrable, and part of the necessary cost of development.
With vi and emacs, you are usually aware of the programs that your IDE is dependent one, and you learn how to tune them. One might say that one shouldn’t need to concern oneself with things at that level of detail, but in practice you need to, if you’re interested in being the most effective composer of programs, no matter what IDE you choose.
For the curious and patient among us, it’s an eye-opening experience, to try and replicate your most used features of VS Code in vi or emacs. It’ll take you a while, but you’ll come out of it armed to debug and solve the kind of meta problems that most people (in my experience) view as the Sisyphean “cost of doing business”.
I think this is prevalent in computer use generally. I came up on Dos & Win 3.1, and at every level the OS is trying to abstract the functionality from you.
Imagine trying to understand what a "driver" is without having a sense of what computer programming does... no way.
What i'm saying is: it's not just the IDEs... it's a mentality about computing.
And for one thing, it's the "i can do this quicker with an IDE" or "i can do this faster with a computer"
surely a computer can make things happen quickly, but truly understanding your tools takes much much longer than anybody realizes.
To illustrate my point, if my colleague’s VSC config is broken, or if it’s taking way too long to detect python tests, or what have you, my colleague’s unfamiliarity with the layer of abstraction just below the editor (jedi, pytest, pylanguageserver), means they view the situation as inevitable, impenetrable, and part of the necessary cost of development.
With vi and emacs, you are usually aware of the programs that your IDE is dependent one, and you learn how to tune them. One might say that one shouldn’t need to concern oneself with things at that level of detail, but in practice you need to, if you’re interested in being the most effective composer of programs, no matter what IDE you choose.
For the curious and patient among us, it’s an eye-opening experience, to try and replicate your most used features of VS Code in vi or emacs. It’ll take you a while, but you’ll come out of it armed to debug and solve the kind of meta problems that most people (in my experience) view as the Sisyphean “cost of doing business”.