I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis.
Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job in a career that is almost entirely based around automating things.
Now, for C or Java or most other popular languages, you're absolutely right.
I use (a version of) visual studio, the first thing that I did was installing a vim extension.
Also vim itself already supports almost any of these features with some basic plugins for the completion logic. If I type "." in my vim I get the same thing I would in visual studio. If you are saying "vim is bad because it lacks X IDE feature" you are missing the point.
VScode: Of course I can do autocomplete bud. Here, search my package repo, I’ll tell you which plug-ins are the most popular and handle the entire download and install process for you.
There’s no comparison.
>There’s no comparison.
Read the first line of my post. There literally is no comparison, because there is a category error.
I did read your post Mr. snark.
> There literally is no comparison, because there is a category error.
Pure pedantry. VScode takes far less effort to get a high quality feature set when compared to vim. That’s the only point of debate that matters for most people.
Edit: vscode != visual studio. I’ll leave my comment.
EDIT: I'd also hardly call VSCode "performant", either, at least compared to the multitudes of editors that don't pull in a full-on browser engine for basic text rendering... but yes, it is indeed "performant" relative to Visual Studio.
I used to have that issue 5 years ago but since then it opens under 5 seconds and loads the solutions I need for not much more. Currently using it on a cheapish recent windows laptop but even on a 8gb x220 it works fine, just loads for 30 sec in the beginning and then it's smooth.
Granted I'm only opening .net solutions with under 100 projects each but anything above that is unnecessarily more difficult to navigate with just vim.
And in my experience VSCode is many times slower than Visual Studio on the same projects. None of them are as fast as barebones sublime or vim on an m1 mac but when I load the latter with plugins it's not a huge difference.
Your priority is evidently ease of configuration, VScode is definitely easier out of the box - there is no comparison.
My priority is hackabilty for streamlined editing and code navigation. Here neovim run circles around vscode.
Neither is “right”, just different preferences. Note that I’m not here to tell you my editor is better, I personally enjoy using it more, and that’s enough for me.
I hear this line a lot from hard-core vim users, but it's always talked about in the general. I'd like to hear a specific use case and exact scenario where a common workflow is faster in neovim over a more full featured IDE like JetBrains or Visual Studio.
https://github.com/microsoft/TypeScript/issues/37816
I edit the results of gotoDefinition on the way through so I always jump to the one I want.
Are you objectively more productive, or do you perceive yourself to be more productive?
I was an Emacs diehard for nearly two decades. Then I got introduced to CLion. In retrospect, Emacs was an inferior tool.
While it's certainly true that Emacs can be configured and extended to do all sorts of interesting things, I do suspect many of its users are deluding themselves when it comes to the sheer breadth and depth of functionality offered by a modern IDE. It also doesn't help that its maintainers are living several decades in the past, and haven't kept up with what the "competition" are doing.
I'm certainly not implying that Emacs is a poor editor. Very few IDEs have text editing capabilities on par with that. But its integration with other tools doesn't hold a candle to today's IDEs.
Kudos on the people who have ported this to Vim[2], but I suspect the support for LSP features will still be better in VS Code
LSP is cool though, an advancement certainly, but it is not a completely new thing.
Language servers run in a separate process to the editor, and they communicate over JSON-RPC. The nice thing about this is that the language server can be written in any programming language - which usually ends up being the language of the code being edited, rather than the language that the editor was written in.
This makes it a lot easier for language servers to be written and maintained by the people who maintain the compilers for those languages, e.g. gopls is written by the Go developers, clangd is part of LLVM.
Ctags is a better analogy, and LSP has fairly obvious advantages compared to it.
I can't speak for Vim, but Emacs has stepped debugging, code completion, etc.
Part of the reason I use Emacs is that I get those features and (and a ton more) with the same light weight interface across multiple languages and platforms. At the same time, it's usually very easy to make Emacs work with third-party tools. On Linux I can step through code using GDB through Emacs, but at work I spend most of my time in Emacs, but have it bring up the MSVC++ debugger when I need it. It's the best of everything.
Meanwhile, I get to listen to my coworkers celebrate new features in VSCode that I've used in Emacs for years...
There are no bonus points for learning a new IDE for every project, either.
I'm confused. The point of uber-IDEs (IntelliJ, Eclipse, NetBeans, VSCode): You only need to learn one IDE. Each language is just another plug-in.
These days, I use Neovim + LSP for a pretty decent approximation of an IDE-- it's quite good. Still not as good as Visual Studio + C#, but I'm on Linux now, and not writing C# anymore, and I definitely prefer an open-source, general purpose, light-weight, customizable editor.
Why do you think they are doing things "the hard way"? Emacs can have all the things you have described. And it can do that for languages that are not part of the .NET Framework, they just have to have a language server implementation.
The problem with "IDEs" was placing all your eggs into a single basket. You are on Visual Studio and then you need to do some Java(or Scala, or whatever). And now you have to get another IDE. Some tried to be one IDE to rule them all (Eclipse, Netbeans), didn't work all that well.
You need a good editor - most IDEs don't have one. You need integration with your language of choice. You need compilers and linters and a bunch of other things. Better to glue components that do one thing and do it well, than having one IDE trying to do everything. And those components can fell just as integrated.
In the first few years of my career I would try every few months to get these things actually installed and working in emacs. It was definitely the hard way.
>The problem with "IDEs" was placing all your eggs into a single basket
Eclipse is a uniquely terrible piece of software and I understand why it might polarize people against IDEs for life. The JetBrains products are pretty good and, importantly, modular and consistent enough across languages that I don't mind.
You’re not wrong, configuring these editors is 100% the hard way (that doesn’t stop me from doing it though).
Perhaps not from the technical perspective, but there are social advantages if you are a member of a clique that does things the hard way and considers it a sign of competence. ("Any idiot can write a code that compiles using autocomplete and syntax highlighting, but it takes a true master to achieve the same result using a decades-old Linux equivalent of Notepad.") They don't seem to understand that the ancient masters did things the hard way not as a pointless exercise, but simply because the easy way was not available back then.
IDEs have some use, and static analysis has proven to catch the same mistake over and over, but only as the authors of those tools have discovered that false positives cannot be allowed ever, once there is a false positive the tools is worthless.
Yes. I was kind of forced to think and do printf debugging at the beginning of my career, after having used before that (as a hobbyist) quite good asm debuggers.
Maybe that's just me, but I also was, I believe, a bit over-reliant on the debugger - I would just compile, run, see what happen, and launch the debugger if something didn't work.
Nowadays I could use sometimes a debugger - but the system I work with is sort of soft real-time so stopping at a breakpoint of even slight changes in timings can change the context - in some cases even printf debugging could make a bug vanish.
If nothing else, debugging without a debugger is a good exercise in logically thinking - and it can save time too.
I've also spent some effort into making it tolerate being interrupted. And there is also the good old technique of inserting break points while the code is running.
Perhaps illustrating the original point, microscopes aren't used to stare into space. A debugger is a microscope but the most pernicious bugs don't benefit from such a thing.
Talk about progress.