Made me smile. This is a great analogy. Tactics vs strategy. You can become more efficient at low-level tasks by doing faster text editing. However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency.
That applies to Java and C# only, where the language grammar is so simplified that you can be 99% confident semantic refactoring didn't screw your code up.
> You can become more efficient at low-level tasks by doing faster text editing.
It's not efficiency for efficiency's sake. It's for being able to code at the speed of thought, to tighten your feedback loop to the point where the act of writing & editing happens in your mind in larger syntactical units.
Also, for actual software engineering, nothing beats a pen and a piece of paper.
Sometimes I use pen and paper quite effectively, but between the slowness of writing and the difficulty of editing, I wouldn't describe it as ideal.
Some of us would say well-designed instead of simplified :-)
That's a longer topic. Having worked professionally both with Java (Eclipse, Netbeans, IntelliJ IDEA) and Common Lisp (Emacs + SLIME), I've experienced both sides of the coin. On the one hand, working with a language without a proper REPL and macros is painful to me. On the other hand, I frequently wish it was even possible to have semantic completion and automatic refactoring in Common Lisp, even at 10% of what you get for Java out of the box in an IDE...
With that, the only remaining thing in which IDEs are a better choice than vim or Emacs is debugging. I wish for decent and fully featured debugging TUIs.
https://code.visualstudio.com/api/extension-guides/debugger-...
I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.
And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true!
Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base.
And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky things like dll boundaries.
Isn't that a test coverage issue more than a navigation issue ?
Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.
> Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.
It doesn't solve it, but it makes it quicker and easier to navigate, it's not just the shortcuts but the navigation stack (go to declaration, go to declaration, go to declaration, pop, pop, got to declaration, pop, pop, etc) that make it easy. Tmux and/or vim are also much better at multi-window editing than IDE's which is also handy.
Most navigation is done using keyboard shortcuts, but I can use the mouse to click around menus if I forget where something is.
Visual Assist X is terrible and extremely slow. Also, it is a clutch, showing one of the biggest weak points of Visual Studio.
I use it in a daily basis for more than 7 years, and I just hate it. VS is such a mixed box of feelings, it is so bad for most of it but then there is a very good debugger, arguably the only thing holding VS alive.
I would prefer to switch to a better text based IDE or even vscode and use windbg, if it wasn't for co-workers with Stockholm syndrome that can't see how bad their tools are.
Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.