A good IDE is not a toy, it is a very powerful tool.
How do you work in a large C++ code base using only a text editor? You will certainly need a couple of plugins, e.g. for linting, definitions/implementation look up, auto complete, etc. Then what is the actual difference to an IDE?
As an additional point: I've been working on a "polyglot" project for some years now, most of it is in Python (data-analysis) and C# (Unity), but there is also C/C++ (real-time components) and even some Haskell (some small "scripts") in there.
I do all my programming in vim with basically just syntax highlighting, relying on the web for "definition look up" and typing fast instead of "auto complete".
Code lookup (i.e. "where did that function go") is handled by RipGrep, continuous builds are handled from the command-line (with fsnotify), etc.
=> Definitely just "my 2 cents", but I've been using Vim for so long that every IDE text editing feels very sluggish in comparison.
In the beginning I felt I needed linting, definitions, etc, so I began by stuffing Vim with plugins. Then I discovered that I was much more productive when I didn't use any of that, but actually kept the documentation close by.
Now I just remember most of the definitions or quickly look them up and combine the usage of console applications like grep, find, sed, etc. with Vim. I have about 3 custom made Vim functions that serve as shortcuts for at few of the things I need often.
Personally it's the most productive for me and the tool gets out of the way.
This sounds strictly worse than what IDEs have to offer (I am thinking specifically about C++).
> Now I just remember most of the definitions or quickly look them up
May I ask with which languages you work and how large the code bases are?
Personally, I work with what I'd call medium-sized C or C++ code bases (100k - 200k LOC) with hundreds of functions/methods. There is no way I can remember their signatures. When I start typing a method, my IDE will immediately show all the possible overloads with their parameters. When I hit F2, it immediately jumps to the definition. I seriously can't imagine how abandoning these features could make me more productive.
I'm always stumped when I hear people saying they are more productive in a text editor, even if they had already tried IDEs. I honestly like to understand how this is possible.
Only problem is that the code can sometimes become a bit terse if you do not have an autocomplete, a dumb autocomplete is often enough though.
Namespaces are also a good solution to use instead of globals or magic globals. But it might become a category theory problem like where in the hierarchical structure you should put something.
The best solution of course is to keep the code base small :)
> The best solution of course is to keep the code base small :)
Hehe, that's the trick. Unfortunately, I came late to the party.
Even just adding NERDTree or ctags to vim dramatically improves productivity. Repeat ad nauseam and you have the modern IDE.
The advice “get rid of the toys and learn the tools” doesn’t do much other than reveal your (subjective) bias for “toys” vs “tools”.
The problem is when a developer can't make that jump when necessary. A big part of our ability to build systems for computers relies on our ability to traverse those computers at a low level, and that means command line instructions. It means being able to work with the filesystem, and streams of input/output. I don't use Vim because I think it's a superior text editor, I use it because of the fluidity it offers me in terms of getting streams of text from the console in and out of an editor. I can just pipe things to it, or execute arbitrary commands and capture the output, and so on.
Now, granted, seasoned developers can often get that same degree of command-line fluidity while still working in an IDE. But I think that requires them knowing the importance of that fluidity in the first place, which is something that you aren't necessarily going to learn as long as the IDE is holding your hand and doing a lot of it for you.
I couldn’t agree with you more. I feel like at some point in a career, a developer should try to shove off from an IDE if that is their daily driver.
I also feel this way about high level languages.
Speaking personally, I have ALWAYS benefited by doing those uncomfortable deep dives.
Vim is a great text editor, and that is exactly what I want it to do. The IdeaVim plugin gets the job done for me.
I would never go back to VIM for coding.
I don't feel I'm learning anything useful by wrestling with the fiddly JSON build configurations in VS Code.
There will be another new and _modern_ IDE tomorrow. Why invest and learn something that keeps changing? It’s like spending most of your time learning React or Angular, while you could have spent the same time learning JavaScript itself. I am not saying tools are not useful. IDEs, high level frameworks absolutely boost productivity. If your goal is to get something done fast, sure use these tools. But if you want to make long term investments, you should learn the fundamentals and later potentially use these frameworks (when you understand how they work) to further boost your productivity.
But people often get used to the tools they use, so people with a learning mindset, who start with the fundamental tools tend to stick with them. That’s why I think a correlation exists between engineers who have a good deep understanding of how a system works and engineers who use basic tools.
Maybe that needs to be controlled for, too.
I learned to code like you suggest. I started with C, in vi, I learned it from the words of Kernighan and Ritchie and I had no forums or syntax highlighting or anything to hold my hands, and when stuff didn't work, I got compiler error messages so obtuse they might as well have been in Linear B, I walked uphill both ways and it was -40 and blizzard even in the summer. I do absolutely concede the type of language-understanding and skill set this promotes does make you a better developer.
However.
I do not think that stubbornly refusing to use an IDE makes you a better developer. A good IDE is powerful, and can be a real force multiplier that makes you able to work with much larger systems and significantly cuts down on the amount of time you spend doing menial repetitive typing.
You can absolutely subsist on the simplest of tools, but you can absolutely do more with the more powerful ones.
Do people think it is still the case for large code bases and Java? I find the ability to quickly jump to definition in the IDE a huge help when on boarding into a new codebase.
Visual Studio Code's Java support is not great and I do not have jump to definition. Find " name_of_function(" in files is good enough and catches a few useful cases outside Java's understanding, particularly when you have naming consistency throughout a codebase.
Code's not as good as Emacs, but it's reliability installed on nearly every developer's machine regardless of discipline or at least the subset who are willing to ask for help when they encounter problems.
It’s certainly possible to code without support, but if you value your productivity, why spend five minutes doing a manual renaming when your ide can do it in a few seconds? Why wouldn’t I want my ide to indent correctly, according to eslint rules in the given project?
Sure for none coding task emacs is great, and git is more powerful on the command line. I therefore use the most powerful tool I can.
Edit: this comment became overly critical, it is quite possible that it is a coincidence, my N is quite low.
Vi is not just an text editor in the terminal. It's a different way to interact with text. To say that Vi users are close minded is like saying people who use the terminal are closed minded.
GUIs and the mouse have significantly improved the way we interact with computers. However, many things are still better in the terminal with a keyboard.
In that same vein, IDEs have improved the way we write code but it has not improved on the way we interact with text enough. For those of us who love Vi as an expressive language to interact with text, we choose to forgo the benefits that IDEs give us when writing code.
Personally, when I write code, I love the experience of tmux with neovim. It's something I try to replicate in the gui every couple of years in MacOS but it always so bad.
On the point of manual renaming, Vim is perfectly capable of project based search and replace.
>On the point of manual renaming, Vim is perfectly capable of project based search and replace.
I think that is my point, stated better than I could, code is not just text.
I have no issue whatever accepting that Emacs/Vim is much much better at dealing with text - I use Emacs for text in preference to just about everything else.
My preference is IntelliJ, but essentially all the IDEs treat the code as a representation of the abstract syntax tree it is. Put your cursor over an identifier and IntelliJ will highlight all the other instances of that identifier. It will not highlight the same word when used in a comment, because it is not the same.
When you treat code like text, you are limited to search and replace. When you treat it as an AST, your editor can rename your private backing field without renaming your property, because it knows they are two different things. In Java it can push methods up and create a new parent class, all while updating all the code that uses it and give you the confidence that it does so without screwing up your code base.
The best example is this, imo. you have a function call that is: `combineFirstAndLastName("John", "Smith")`
If your cursor is in the `"John"` part, and you want to change that, you can just input `ci"`, (c)hange (i)nside ("), to instantly start typing with John being removed. Lets say you want to change all the text inside the parenthesis, you just type ci), (c)hange (i)nside `)`.
There's commands like this all over, and you can compose all of them. For example, `ct"`, (c)hange un(t)ill ("), which will erase any text until the next available `"` on the line.
Or, (d)elete un(t)ill `char`. It's a whole language when you're editing with VIM, and while it might sound like that's very hard to learn, it's not. Because you can slowly add these verbs and sentences into your habits until it's completely natural
Once you learn the keys that correspond to your desired actions, everything else feels wasteful (Especially as I'm writing this on my phone). I turn on vim keys for anything that has it. It takes a long time to build up your vim vocab (I recommend you learn the simple stuff and incrementally look up better ways to approach things as you go). A great way to get started is vimtutor, which is built in when you install vim; just run vimtutor from shell and start reading. There's a lot more depth to what is possible, buffers, plugins, etc. but that's what stands out to me.
"How much wood would a woodchuck chuck?"
If you cursor is on the letter "H", you can type the "dw" to delete the word "How".
You can use "dt" to delete up to a letter. If your cursor is at the letter "H", "dtw" deletes up the letter "w" which will delete "How much ".
This barely scratches the surface. There is a steep learning curve involved but it's totally worth it if you need to edit text on a regular basis.
That's a LSP feature, you do not need an IDE.
Somehow my 35 years of coding experience have shown me that I rather play with those toys than be frozen in past I grew up on (ZX, MS-DOS, UNIX and CP/M).
If all you have is a basic text editor, you are limited by what can fit inside your head. If your IDE makes navigation too easy, you end up writing callbacks that call callbacks that call callbacks until you end up in abstraction hell and have no idea what your code is doing anymore.
Then again, better tooling makes refactoring/simplifying code easier so it may just as well lead to easier to understand code...
Terminal + Vim or Emacs/VSCode (depending on configuration) is not only all you need, it also produces developers who understand the systems they work with.
I know a lot of people will disagree but my advice to more junior guys is always get rid of the toys and learn the tools.