6 ms·

Interesting. I always hear "you don't need a full blown IDE, vscode/neovim/other text editor should be enough". Then I read those articles about which plugins/b

by SvenL 2y ago

Interesting. I always hear "you don't need a full blown IDE, vscode/neovim/other text editor should be enough". Then I read those articles about which plugins/bundles/addons I need to install and I wonder at which point do we call it IDE instead of text editor (with plugins).

imron 2y ago
My .exrc file is about 10 lines long and has no plugins. Combined with ctags and a terminal it’s all I need for the languages I’m familiar with (c, c++, rust, python and several others)
- SvenL 2y ago
  I always wonder, how do you debug which such a setup?
  - imron 2y ago
    Gdb, lldb or pdb in the terminal. It took a bit of getting used to at first, but then it just becomes normal.
TacticalCoder 2y ago
> I wonder at which point do we call it IDE instead of text editor The most hilarious to me is when people refer to Emacs as a "text editor". I'm not talking about the fact that Emacs shall happily display pictures (inlined in a file like in org-mode for example or in their own window), open binary files, open PDF files, manipulate files over SSH (Tramp), etc. Heck, as a statement some made Emacs run as PID 1. But many seem to honestly think Emacs is "notepad with bad shortcuts".
ramon156 2y ago
There are people out there who don't even use an LSP with autocompletion or type handling, just syntax highlights. There's a theory that actively thinking about this will prevent u from making mistakes like forgetting a semicolon. I do agree that some nvim setups are just IDE's in your shell, but it's also nice to have everything in one place. I don't like vsc's and Jetbrains's terminals at all, as it gets clunky too quick. To each their own though!
- Carrok 2y ago
  > There's a theory that actively thinking about this will prevent u from making mistakes like forgetting a semicolon. I never want to waste a single brain cycle on a missing semicolon. That is what the editor (or autocomplete or AI or whatever) should be doing for me.
  - xigoi 2y ago
    Ithe computer can reliably tell when you forgot a semicolon, why does the semicolon need to be there in the first place?
  - robenkleene 2y ago
    I used to think like this too, but I now categorize this as "making easy things easier" and I try to focus only on things that "make hard things easier". Now the main thing I value is flexibility, and that's mainly achieved by mainly spending my time in a programmable environment (the shell), and a CLI editor like Vim fits the most smoothly into this approach. To give an example, let's say you want to make pull requests for an API change across several interdependent repos (e.g., an API change in a framework). So you want to you want to do a find and replace in each repo, then push the changes to a branch, and create a pull request for each one. This can be achieved entirely from the command line, making it really easy to repeat across all the repos that need to be updated. (With all the above said, I do use most LSP features, like live error checking and autocomplete, but if I were forced to choose, I would give that up before I give up the flexibility of a programmable environment.)
    - lolinder 2y ago
      Using a powerful IDE does not preclude dropping into the command line for that kind of repetitive, scriptable work, and many of us do use both.
      - wiseowise 2y ago
        I’m curious to see how you’ll automate this in e.g. IntelliJ, that doesn’t allow you to open multiple projects side by side. No, opening multiple instances of IntelliJ is not the answer.
robenkleene 2y ago
Today I generally think of an IDE supporting one language (or a few complementary languages) without any configuration, whereas a text editor usually requires configuration to get the same features. Although it's true the features are almost identical now. Though IDEs typically still offer some special sauce features, usually things that still don't fit cleanly into LSP and DAP (language server and debugger protocols respectively) models. On the flip side, text editors typically (lightly) support more file formats out of the box, and scale better, e.g., equally comfortable editing a single file or an entire project. TLDR: the trade off is between flexibility (text editor) or specificity (IDE).
vbezhenar 2y ago
There's a spectrum. notepad.exe, vi, emacs/vim/notepad++, vscode, idea. Every new layer adds more features and adds more bloat. You can upgrade to the next layer by installing enough extensions (if editor allows it and those extensions exist). You can certainly turn your bare vim into vscode comparable editor with enough extensions. And you can certainly install enough extensions into vscode to make it comparable with idea. An important thing is to find a personal sweet spot. For me, using Idea with hundred plugins is just not worth it. Spring plugin comes with thousands of features, but when I disable it, miss very few things, and the bloat is real: slow start, lots of new menu items and icons, new bugs. I, personally, prefer to use editor on steroids like vscode, with full language-aware support. At the same time I'm using external terminal a lot, doing builds and stuff there. So IDE for me is an entire computer and vscode is part of this IDE.
- tsimionescu 2y ago
  > notepad.exe, vi, emacs/vim/notepad++, vscode, idea You forgot the natural root of this hierarchy: ed, the standard text editor. https://www.gnu.org/fun/jokes/ed-msg.en.html https://www.gnu.org/fun/jokes/ed-msg.en.html
- The_Colonel 2y ago
  > And you can certainly install enough extensions into vscode to make it comparable with idea. No, you can't. Comparable plugins don't exist.
  - bitzun 2y ago
    Also the quality of vscode is strictly worse. I tried it a few years ago and syntax highlighting a basic python program using stock vscode would get stuck (highlighting the wrong characters in random colors) in nondeterministic ways. I tried it again recently and I still see syntax highlighting bugs. Vim does a better job.
Kwpolska 2y ago
You don't need a full-blown IDE to write HTML. Maybe for Python. But for languages like Java, you're leaving a lot of productivity and error prevention on the table.
- gf000 2y ago
  Or different interpretation: languages that don't have IDEs with the feature set and productivity of Java IDEs are leaving a lot on the table.
rat87 2y ago
The I stands for Integrated. Although technically I think the big 3 Java IDEs are written as a pile of plugins largely to support multiple languages. But they do tend to feel more "integrated"/look more cohesive. I guess the point is that if you feel like opening a text file in something it's a text editor. If you don't it might be an idea. I do try to open up individual text files outside of a project in pycharm sometimes but usually it feels weird. Maybe that's why they added scratch files. Somehow shift+shift new scratch file json and copy/pasting feels easier then making a new file outside your project with the IDE
serial_dev 2y ago
It heavily depends on the language, the frameworks and the actual project. Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work. Languages that have 3 decades of legacy warts, languages with no or poorly implemented LSPs, languages where the ecosystem relies heavily on runtime language features, frameworks that rely on behind the scenes magic and conventions, projects where for ten years the whole team only ever used one IDE… yeah, it’s not where vim/helix/vsc shines, and you will fight an uphill battle.
- rafaelmn 2y ago
  > Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work. The only language that comes to mind fitting this description is Go ?
  - nobleach 2y ago
    Rust also has great tooling. Clippy, Rust analyzer (the LSP). Developing Rust in NeoVim is just as fun as Go. Other languages that do ok are OCaml, Elixir/Gleam, Typescript. Go and Rust just have what I consider a "cut above" the others when it comes to both tooling and standar language features.
    - serial_dev 2y ago
      Dart’s tooling is also good and basically the whole ecosystem use these tools provided by default.
- ghm2180 2y ago
  > the frameworks and the actual project. This. e.g. Android studio has a great preview feature for composable which makes it a joy to build them. It gives you an option to run just see the live effects of updating code for that composable in (a) IDE (b) Emulator (c) Device.
mardifoufs 2y ago
I also need to configure which "plugins" I want whenever I install regular Visual Studio. In fact you can't really even start using it before that initial setup window. The time it takes to install and configure a plugin on vscode, for example, is basically 0 for most languages and platforms.
o11c 2y ago
The full statement is "You don't need a full-blown IDE, just use (vim or whatever), unless you are writing in Java". Among mainstream languages, Java is uniquely hostile to being written by humans. The statement is usually shortened under the assumption that nobody is writing Java by choice, and if you're writing it for work you're forced to use (Employer-provided development tool). There are other languages that are hard to use without an IDE, but they always are relatively obscure ones and/or blatantly integrate the language itself tightly into the IDE, like Smalltalk or Scratch. Most languages, it's feasible to write with nothing more than a regex-based keyword detector and symbol tagger. LSPs are overrated, other than the fact that they're a narrow waist for supporting multiple languages in multiple editors.
- singpolyma3 2y ago
  As someone who writes a lot of java (mostly for android) without any plugins I'm curious what about Java you think requires them?
  - o11c 2y ago
    `System.out.println` is ridiculous, and you're likely to use it many times unlike `public static void main`. Well, since there are only 2 of these I suppose you can simplify this to it's not hard to customize your editor to expand `sout` or something to that. Java culture promotes long class names and method names, which are often neither unambiguous by prefix nor by initials, which are the 2 basic autocomplete styles (though really, I shouldn't allow the pro-Java argument to consider autocomplete at all, even a stupidly basic one). Java culture (and to some extent the language itself, due to package-private) expects separation of classes within a project into multiple/nested packages, but package names are expected to be very long and there are no relative imports. And classes from third-party packages will also have horribly long names. New-file templates can help a little if you're willing to suppress "unused import" warnings. The lack of support for "free functions" (outside a class) adds a ton of verbosity, if you can't fake them via dummy interfaces. Meanwhile, the fact that `this` is implicit makes the question of "what identifiers are in scope" almost as complicated as C++. But yes, if you're paying attention, Java-the-language can be made somewhat nicer if you ignore Java-the-style (notably, many developers of Java itself are famous for doing this internally). But then you basically give up on the library ecosystem, which is the only reason to write Java in the first place. You can't even add interfaces retroactively! Yes, I know they say "speed of programming isn't limited by how fast you can type", and it's usually true. But Java proves it can be bad enough to drop your cache.
Sins_621 2y ago
I agree I think a lot of people do tend to go overboard with the plugins they add to Neovim. I only use a hand-full of plugins myself; Telescope for fuzzy finding, LSP for navigation and Rainbow-delimiters. I've found attempting to add anything "un-neovim-like" such as tabs or a debugger to be more of a hassle and jankier than just using something better suited to that task. I actually think the best way to learn Neovim is to build your own configuration with as little plugins as necessary for you to get the job done because it'll force you to learn the Neovim way of doing things. For example instead of relying on tabs I learnt to use the Mark system and it was a great addition to my workflow.
singpolyma3 2y ago
Thu people saying the former are different people than the ones installing all dhise plugins. I just run without plugins mostly
theonething 2y ago
I like working in terminals. An IDE will never run in the terminal. Vim with the plugins I like run in my terminal.
- pjmlp 2y ago
  Showing the age, Borland IDEs for MS-DOS, as one data point among many other ones. In fact, the whole TUI craziness of IT world fashion is getting back to what used to be daily business in the 1980's and early 1990's.
- lolinder 2y ago
  Sincere question from someone who doesn't understand this: why do you like working in terminals?
  - bionsystem 2y ago
    Not the op but I like it too and here is why : - I like awk grep sed find and many more... and piping things together - I like the low latency of vim and love walking through code with just a few movers - I like the ubiquity of using the same tools on any machine, local or remote (including windows now that it has wsl) and bash All of this even more so than "no mouse setup" or anything, I don't mind using the mouse sometimes.
  - camgunz 2y ago
    I find that terminal apps are a lot more respectful of my machine's resources and whatever workflow I want to build. I can make them work like I want to. GUI apps make me work the way they want to, which as an incorrigible non-conformist is a real fly in the ointment.
  - maxbond 2y ago
    A programming language is a good abstraction for interacting with the computer. It's a metaphor for how a computer works. Graphical tools usually provide metaphors for how a certain set of tasks are done. The terminal is a REPL for a programming language designed for this purpose. Simple command line tools become primitives in this language, and they compose together. Learn a few dozen and you have something quite powerful. You can remain in the same mental model to accomplish many tasks. Graphical tools tend to be monoliths that rarely compose, each premised off of a different mental model. This creates friction when moving from one to another. For better and for worse, the terminal looks pretty much the same now as it did 30 years ago. (There are important improvements in zsh and fish.) Graphical tools tend to evolve quickly. If I don't use a command for 5 years, I can get back up to speed in a few minutes using it's built-in documentation (`--help`). If I don't use a graphical tool for 5 years, I'm pretty close to square one, and need to spend some time with the manual (in a separate application, the browser or PDF reader). If something is missing from your toolkit, throwing together a proof of concept level CLI is pretty easy. Presumably some people can throw GUIs together very quickly as well. But the CLI is a simpler programming model. (Immediate mode GUIs do narrow this gap, however.) And now your new CLI can integrate with all your other CLIs out of the box. Eg, a tool that tweaks some values in a JSON file can be used with the `find` command to tweak many JSON files. (Your mileage may vary. I'm just trying to present a distilled intuition, if I seem to be speaking in absolutes, it's figurative. Whatever workflow works for you is the right one.)
lkramer 2y ago
I use Vim (recently switched to Neovim on my work laptop) as my daily driver with a minimum set of plugins. My primary language right now is Go, but used to be C++. It works just fine for my purpose. I have tried using IDEs in the past, most recently vscode when I was trying to learn Rust, I always end up going back to Vim, I find it more a more enjoyable and streamlined experience. For IDEs it's usually a struggle getting everything to work for me, and if there is a new version it just ends up breaking everything. I'm sure it's just a matter of what I'm used to. However I learned JAVA at university and it's the one language I have never managed to come to terms with using vim. At university I used Netbeans and I think that remains my one positive experience with IDEs. I really liked how that worked (or maybe I just hadn't been conditioned that much at that point). Java seems to be designed around the idea that you should user an IDE though. Sooo Verbose, and so many frameworks...

by SvenL 2y ago

imron 2y ago

My .exrc file is about 10 lines long and has no plugins. Combined with ctags and a terminal it’s all I need for the languages I’m familiar with (c, c++, rust, python and several others)

SvenL 2y ago
I always wonder, how do you debug which such a setup?
- imron 2y ago
  Gdb, lldb or pdb in the terminal. It took a bit of getting used to at first, but then it just becomes normal.

TacticalCoder 2y ago

> I wonder at which point do we call it IDE instead of text editor The most hilarious to me is when people refer to Emacs as a "text editor". I'm not talking about the fact that Emacs shall happily display pictures (inlined in a file like in org-mode for example or in their own window), open binary files, open PDF files, manipulate files over SSH (Tramp), etc. Heck, as a statement some made Emacs run as PID 1. But many seem to honestly think Emacs is "notepad with bad shortcuts".

ramon156 2y ago

There are people out there who don't even use an LSP with autocompletion or type handling, just syntax highlights. There's a theory that actively thinking about this will prevent u from making mistakes like forgetting a semicolon. I do agree that some nvim setups are just IDE's in your shell, but it's also nice to have everything in one place. I don't like vsc's and Jetbrains's terminals at all, as it gets clunky too quick. To each their own though!

Carrok 2y ago
> There's a theory that actively thinking about this will prevent u from making mistakes like forgetting a semicolon. I never want to waste a single brain cycle on a missing semicolon. That is what the editor (or autocomplete or AI or whatever) should be doing for me.
- xigoi 2y ago
  Ithe computer can reliably tell when you forgot a semicolon, why does the semicolon need to be there in the first place?
- robenkleene 2y ago
  I used to think like this too, but I now categorize this as "making easy things easier" and I try to focus only on things that "make hard things easier". Now the main thing I value is flexibility, and that's mainly achieved by mainly spending my time in a programmable environment (the shell), and a CLI editor like Vim fits the most smoothly into this approach. To give an example, let's say you want to make pull requests for an API change across several interdependent repos (e.g., an API change in a framework). So you want to you want to do a find and replace in each repo, then push the changes to a branch, and create a pull request for each one. This can be achieved entirely from the command line, making it really easy to repeat across all the repos that need to be updated. (With all the above said, I do use most LSP features, like live error checking and autocomplete, but if I were forced to choose, I would give that up before I give up the flexibility of a programmable environment.)
  - lolinder 2y ago
    Using a powerful IDE does not preclude dropping into the command line for that kind of repetitive, scriptable work, and many of us do use both.
    - wiseowise 2y ago
      I’m curious to see how you’ll automate this in e.g. IntelliJ, that doesn’t allow you to open multiple projects side by side. No, opening multiple instances of IntelliJ is not the answer.

robenkleene 2y ago

Today I generally think of an IDE supporting one language (or a few complementary languages) without any configuration, whereas a text editor usually requires configuration to get the same features. Although it's true the features are almost identical now. Though IDEs typically still offer some special sauce features, usually things that still don't fit cleanly into LSP and DAP (language server and debugger protocols respectively) models. On the flip side, text editors typically (lightly) support more file formats out of the box, and scale better, e.g., equally comfortable editing a single file or an entire project. TLDR: the trade off is between flexibility (text editor) or specificity (IDE).

vbezhenar 2y ago

There's a spectrum. notepad.exe, vi, emacs/vim/notepad++, vscode, idea. Every new layer adds more features and adds more bloat. You can upgrade to the next layer by installing enough extensions (if editor allows it and those extensions exist). You can certainly turn your bare vim into vscode comparable editor with enough extensions. And you can certainly install enough extensions into vscode to make it comparable with idea. An important thing is to find a personal sweet spot. For me, using Idea with hundred plugins is just not worth it. Spring plugin comes with thousands of features, but when I disable it, miss very few things, and the bloat is real: slow start, lots of new menu items and icons, new bugs. I, personally, prefer to use editor on steroids like vscode, with full language-aware support. At the same time I'm using external terminal a lot, doing builds and stuff there. So IDE for me is an entire computer and vscode is part of this IDE.

tsimionescu 2y ago
> notepad.exe, vi, emacs/vim/notepad++, vscode, idea You forgot the natural root of this hierarchy: ed, the standard text editor. https://www.gnu.org/fun/jokes/ed-msg.en.html https://www.gnu.org/fun/jokes/ed-msg.en.html
The_Colonel 2y ago
> And you can certainly install enough extensions into vscode to make it comparable with idea. No, you can't. Comparable plugins don't exist.
- bitzun 2y ago
  Also the quality of vscode is strictly worse. I tried it a few years ago and syntax highlighting a basic python program using stock vscode would get stuck (highlighting the wrong characters in random colors) in nondeterministic ways. I tried it again recently and I still see syntax highlighting bugs. Vim does a better job.

Kwpolska 2y ago

You don't need a full-blown IDE to write HTML. Maybe for Python. But for languages like Java, you're leaving a lot of productivity and error prevention on the table.

gf000 2y ago
Or different interpretation: languages that don't have IDEs with the feature set and productivity of Java IDEs are leaving a lot on the table.

rat87 2y ago

The I stands for Integrated. Although technically I think the big 3 Java IDEs are written as a pile of plugins largely to support multiple languages. But they do tend to feel more "integrated"/look more cohesive. I guess the point is that if you feel like opening a text file in something it's a text editor. If you don't it might be an idea. I do try to open up individual text files outside of a project in pycharm sometimes but usually it feels weird. Maybe that's why they added scratch files. Somehow shift+shift new scratch file json and copy/pasting feels easier then making a new file outside your project with the IDE

serial_dev 2y ago

It heavily depends on the language, the frameworks and the actual project. Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work. Languages that have 3 decades of legacy warts, languages with no or poorly implemented LSPs, languages where the ecosystem relies heavily on runtime language features, frameworks that rely on behind the scenes magic and conventions, projects where for ten years the whole team only ever used one IDE… yeah, it’s not where vim/helix/vsc shines, and you will fight an uphill battle.

rafaelmn 2y ago
> Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work. The only language that comes to mind fitting this description is Go ?
- nobleach 2y ago
  Rust also has great tooling. Clippy, Rust analyzer (the LSP). Developing Rust in NeoVim is just as fun as Go. Other languages that do ok are OCaml, Elixir/Gleam, Typescript. Go and Rust just have what I consider a "cut above" the others when it comes to both tooling and standar language features.
  - serial_dev 2y ago
    Dart’s tooling is also good and basically the whole ecosystem use these tools provided by default.
ghm2180 2y ago
> the frameworks and the actual project. This. e.g. Android studio has a great preview feature for composable which makes it a joy to build them. It gives you an option to run just see the live effects of updating code for that composable in (a) IDE (b) Emulator (c) Device.

mardifoufs 2y ago

I also need to configure which "plugins" I want whenever I install regular Visual Studio. In fact you can't really even start using it before that initial setup window. The time it takes to install and configure a plugin on vscode, for example, is basically 0 for most languages and platforms.

o11c 2y ago

The full statement is "You don't need a full-blown IDE, just use (vim or whatever), unless you are writing in Java". Among mainstream languages, Java is uniquely hostile to being written by humans. The statement is usually shortened under the assumption that nobody is writing Java by choice, and if you're writing it for work you're forced to use (Employer-provided development tool). There are other languages that are hard to use without an IDE, but they always are relatively obscure ones and/or blatantly integrate the language itself tightly into the IDE, like Smalltalk or Scratch. Most languages, it's feasible to write with nothing more than a regex-based keyword detector and symbol tagger. LSPs are overrated, other than the fact that they're a narrow waist for supporting multiple languages in multiple editors.

singpolyma3 2y ago
As someone who writes a lot of java (mostly for android) without any plugins I'm curious what about Java you think requires them?
- o11c 2y ago
  `System.out.println` is ridiculous, and you're likely to use it many times unlike `public static void main`. Well, since there are only 2 of these I suppose you can simplify this to it's not hard to customize your editor to expand `sout` or something to that. Java culture promotes long class names and method names, which are often neither unambiguous by prefix nor by initials, which are the 2 basic autocomplete styles (though really, I shouldn't allow the pro-Java argument to consider autocomplete at all, even a stupidly basic one). Java culture (and to some extent the language itself, due to package-private) expects separation of classes within a project into multiple/nested packages, but package names are expected to be very long and there are no relative imports. And classes from third-party packages will also have horribly long names. New-file templates can help a little if you're willing to suppress "unused import" warnings. The lack of support for "free functions" (outside a class) adds a ton of verbosity, if you can't fake them via dummy interfaces. Meanwhile, the fact that `this` is implicit makes the question of "what identifiers are in scope" almost as complicated as C++. But yes, if you're paying attention, Java-the-language can be made somewhat nicer if you ignore Java-the-style (notably, many developers of Java itself are famous for doing this internally). But then you basically give up on the library ecosystem, which is the only reason to write Java in the first place. You can't even add interfaces retroactively! Yes, I know they say "speed of programming isn't limited by how fast you can type", and it's usually true. But Java proves it can be bad enough to drop your cache.

Sins_621 2y ago

I agree I think a lot of people do tend to go overboard with the plugins they add to Neovim. I only use a hand-full of plugins myself; Telescope for fuzzy finding, LSP for navigation and Rainbow-delimiters. I've found attempting to add anything "un-neovim-like" such as tabs or a debugger to be more of a hassle and jankier than just using something better suited to that task. I actually think the best way to learn Neovim is to build your own configuration with as little plugins as necessary for you to get the job done because it'll force you to learn the Neovim way of doing things. For example instead of relying on tabs I learnt to use the Mark system and it was a great addition to my workflow.

singpolyma3 2y ago

Thu people saying the former are different people than the ones installing all dhise plugins. I just run without plugins mostly

theonething 2y ago

I like working in terminals. An IDE will never run in the terminal. Vim with the plugins I like run in my terminal.

pjmlp 2y ago
Showing the age, Borland IDEs for MS-DOS, as one data point among many other ones. In fact, the whole TUI craziness of IT world fashion is getting back to what used to be daily business in the 1980's and early 1990's.
lolinder 2y ago
Sincere question from someone who doesn't understand this: why do you like working in terminals?
- bionsystem 2y ago
  Not the op but I like it too and here is why : - I like awk grep sed find and many more... and piping things together - I like the low latency of vim and love walking through code with just a few movers - I like the ubiquity of using the same tools on any machine, local or remote (including windows now that it has wsl) and bash All of this even more so than "no mouse setup" or anything, I don't mind using the mouse sometimes.
- camgunz 2y ago
  I find that terminal apps are a lot more respectful of my machine's resources and whatever workflow I want to build. I can make them work like I want to. GUI apps make me work the way they want to, which as an incorrigible non-conformist is a real fly in the ointment.
- maxbond 2y ago
  A programming language is a good abstraction for interacting with the computer. It's a metaphor for how a computer works. Graphical tools usually provide metaphors for how a certain set of tasks are done. The terminal is a REPL for a programming language designed for this purpose. Simple command line tools become primitives in this language, and they compose together. Learn a few dozen and you have something quite powerful. You can remain in the same mental model to accomplish many tasks. Graphical tools tend to be monoliths that rarely compose, each premised off of a different mental model. This creates friction when moving from one to another. For better and for worse, the terminal looks pretty much the same now as it did 30 years ago. (There are important improvements in zsh and fish.) Graphical tools tend to evolve quickly. If I don't use a command for 5 years, I can get back up to speed in a few minutes using it's built-in documentation (`--help`). If I don't use a graphical tool for 5 years, I'm pretty close to square one, and need to spend some time with the manual (in a separate application, the browser or PDF reader). If something is missing from your toolkit, throwing together a proof of concept level CLI is pretty easy. Presumably some people can throw GUIs together very quickly as well. But the CLI is a simpler programming model. (Immediate mode GUIs do narrow this gap, however.) And now your new CLI can integrate with all your other CLIs out of the box. Eg, a tool that tweaks some values in a JSON file can be used with the `find` command to tweak many JSON files. (Your mileage may vary. I'm just trying to present a distilled intuition, if I seem to be speaking in absolutes, it's figurative. Whatever workflow works for you is the right one.)

lkramer 2y ago

I use Vim (recently switched to Neovim on my work laptop) as my daily driver with a minimum set of plugins. My primary language right now is Go, but used to be C++. It works just fine for my purpose. I have tried using IDEs in the past, most recently vscode when I was trying to learn Rust, I always end up going back to Vim, I find it more a more enjoyable and streamlined experience. For IDEs it's usually a struggle getting everything to work for me, and if there is a new version it just ends up breaking everything. I'm sure it's just a matter of what I'm used to. However I learned JAVA at university and it's the one language I have never managed to come to terms with using vim. At university I used Netbeans and I think that remains my one positive experience with IDEs. I really liked how that worked (or maybe I just hadn't been conditioned that much at that point). Java seems to be designed around the idea that you should user an IDE though. Sooo Verbose, and so many frameworks...