5 ms·

I'd say language support is the most important for productivity if we talk about programming. Having the whole API under your fingertips, doing safe refactoring

I'd say language support is the most important for productivity if we talk about programming. Having the whole API under your fingertips, doing safe refactorings easily, etc. are much more important for productivity than simple editing. If you can refactor a class, move functions, rename variables across the whole project safely (string replace is not enough) with a few clicks then you are much faster than when you have to do all of these manually. I'm saying that as an emacs user. I prefer emacs, but if I had to work with a language (e.g. Java) where language support is much more sophisticated in a tool like, for example, IntelliJ, then I'd use that instead, because it would make me much more productive.

fhennig 7y ago
This. First of all, I don't know about vim/neovim, but I think a lot of the issues apply there as well. When I develop software, I don't need an editor, I need a development environment. I spend 90% of my time reading code, so reading and navigating the codebase should be very straightforward. Most importantly I want to have a tree view of the files in the project, I want to be able to jump to function/class definitions and I want to show usages of functions. Another big thing is debugging. IntelliJ has really good debugging capabilities. Also auto-completion. I think some of these you can get in vim/emacs, but it doesn't come out of the box. I sometimes miss some of my emacs shortcuts/features, but not enough to drop all the amazing things that IntelliJ is offering.
- simias 7y ago
  I often switch between several programing languages, I often switch between projects, I like being able to dig into the code source of some tarball I found online without configuration. I find that deep editor integration gets in the way more often than not. For navigating the project I use helm on emacs, fzf on vim. I can just fuzzy-match anything I'm looking for instantly. I find filesystem treeviews useless, they use a lot of screen real estate and they're annoying to navigate, I don't see the point. For navigation ripgrep does most of the job complex language engines do and it works across languages without any configuration. For C I sometimes use cscope and ctags but even there I often just call ripgrep because why not? For auto-completion I also find that a very naive algorithm completing words from existing buffers works reliably and efficiently, with zero configuration and tweaking. Sure you don't get context-aware completion but that never bothered me too much to be honest. For debugging I can't really disagree with you, both Vim and Emacs are very limited in that regard (Vim especially so). That being said, maybe if I gave those big IDEs a chance I'd never go back, who knows. Besides I could spend an hour listing things I think Vim and Emacs do wrong so it's not like I think they're perfect editors.
- htfu 7y ago
  Tree view and go to def plus basic autocompletion (through tags) are very much built into vim. The rest can be done through plugins, these days very painlessly - but admittedly even a few years ago rather a hassle to set up. Debugging, while perfectly doable depending on language, is I'd say the one thing still rather awkward.
- 314 7y ago
  For most of the code reading tasks that you list I would use a bash terminal in the project directory. What is the advantage of having them as functions in your editor?
Lio 7y ago
There's no reason to not have that sort of support available in Vim or other CLI based tools especially now that LSP servers are available. Language support tools are not dependant on running GUI based IDEs any more.
L0stLink 7y ago
>language support is the most important for productivity That is a great point, and this is precisely the goal of the Language Server Protocol[0] (LSP). I agree that dedicated tools have more sophisticated support but LSP is quickly bridging that gap. With how extensible editors like vim and emacs are coupled with there powerful text manipulation capabilities the development experience offered by them in combination with a good Language Server and Client is not to be underestimated. Although editor ergonomics are very subjective so I know this topic can get very controversial. [0] https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/
drbojingle 7y ago
In terms of what's been available for developers I'd agree with you that IDE's (especially JetBrains and especially for languages like Java) have had an advantage for some time. Language Server Protocol is taking this advantage away. It's not as if turning code into AST and transforming tree data structures is out of the reach :P.

fhennig 7y ago

This. First of all, I don't know about vim/neovim, but I think a lot of the issues apply there as well. When I develop software, I don't need an editor, I need a development environment. I spend 90% of my time reading code, so reading and navigating the codebase should be very straightforward. Most importantly I want to have a tree view of the files in the project, I want to be able to jump to function/class definitions and I want to show usages of functions. Another big thing is debugging. IntelliJ has really good debugging capabilities. Also auto-completion. I think some of these you can get in vim/emacs, but it doesn't come out of the box. I sometimes miss some of my emacs shortcuts/features, but not enough to drop all the amazing things that IntelliJ is offering.

simias 7y ago
I often switch between several programing languages, I often switch between projects, I like being able to dig into the code source of some tarball I found online without configuration. I find that deep editor integration gets in the way more often than not. For navigating the project I use helm on emacs, fzf on vim. I can just fuzzy-match anything I'm looking for instantly. I find filesystem treeviews useless, they use a lot of screen real estate and they're annoying to navigate, I don't see the point. For navigation ripgrep does most of the job complex language engines do and it works across languages without any configuration. For C I sometimes use cscope and ctags but even there I often just call ripgrep because why not? For auto-completion I also find that a very naive algorithm completing words from existing buffers works reliably and efficiently, with zero configuration and tweaking. Sure you don't get context-aware completion but that never bothered me too much to be honest. For debugging I can't really disagree with you, both Vim and Emacs are very limited in that regard (Vim especially so). That being said, maybe if I gave those big IDEs a chance I'd never go back, who knows. Besides I could spend an hour listing things I think Vim and Emacs do wrong so it's not like I think they're perfect editors.
htfu 7y ago
Tree view and go to def plus basic autocompletion (through tags) are very much built into vim. The rest can be done through plugins, these days very painlessly - but admittedly even a few years ago rather a hassle to set up. Debugging, while perfectly doable depending on language, is I'd say the one thing still rather awkward.
314 7y ago
For most of the code reading tasks that you list I would use a bash terminal in the project directory. What is the advantage of having them as functions in your editor?

Lio 7y ago

There's no reason to not have that sort of support available in Vim or other CLI based tools especially now that LSP servers are available. Language support tools are not dependant on running GUI based IDEs any more.

L0stLink 7y ago

>language support is the most important for productivity That is a great point, and this is precisely the goal of the Language Server Protocol[0] (LSP). I agree that dedicated tools have more sophisticated support but LSP is quickly bridging that gap. With how extensible editors like vim and emacs are coupled with there powerful text manipulation capabilities the development experience offered by them in combination with a good Language Server and Client is not to be underestimated. Although editor ergonomics are very subjective so I know this topic can get very controversial. [0] https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/

drbojingle 7y ago

In terms of what's been available for developers I'd agree with you that IDE's (especially JetBrains and especially for languages like Java) have had an advantage for some time. Language Server Protocol is taking this advantage away. It's not as if turning code into AST and transforming tree data structures is out of the reach :P.