I just wanted to raise awareness on "VIM priests" that spread their false gossips around, I probably sound more passive-aggressive then it should.
You just "forget" to mention that it is a personal preference, and state that "Vim is the perfect IDE" (for me?!), knowing in fact that is not even an IDE and not perfect. You "forget" to mention that you spent maybe years of being prolific, where in IDE's most of the things "just works".
VIM is great when you have many small scripts/projects, or you alter big projects with minimal invasion, edit big files, or you are a sys admin, or ...(insert here a lot of stuff you didn't mention), but ....
It is "a common trap" that I've seen are with web dev juniors, they usually:
find a post like this
decide to try VIM and like it
they are getting very good at coding (typing fast,and moving around the document)
they have the false productivity feeling (the amount of code != solving more business problems)
they advance to bigger projects (as in scope and LOC count), and hit some walls. Then invest more and more time in their VIM skills and configs, and in the end being less productive.
This combined with the fact that people hate change, leads to bigger problems once the developer gets involved in bigger and more complex projects.
I just want to make things clear for the juniors and next generation of developers to make a big difference between "personal preferences" and "best tool for the job", and posts like this doesn't help at all.
I tend to agree with BG. Tooling becomes vastly important when working with larger and more complex codebases. The kind of code analysis provided by actual IDEs simply cannot be replicated in Vim no matter how it's customized.
Vim is great, but Vim is ultimately just a powerful text editor. BG is correct in that the anti-IDE stance is alluring for junior devs, providing false machismo in the absence of experience and well-honed skills.
We really need to change the way we talk about Vim. Here are my suggestions:
Stop comparing it to emacs. They are vastly different things.
Let's distinguish Vim "the concept" from Vim "the application."
What's important here is Vim, the concept
Vim, conceptually, is mode-based text editing with consistent, highly optimized keybindings. The beautiful thing about vim-as-a-concept is that it's available in some form or fashion in nearly every IDE and text editor.
In my line of work, I've seen little to no benefit with static analysis. I am working on a highly dynamic codebase. Sure, if your language is static its great, but I really don't see this as being a reason for not using VIM. I've actually seen VIM autocompletion be more accurate than IDE's (for newer languages such as Rust).
wow ok, your team is great then! I was part of teams that didn't used but we ended up regretting.
I usually saw linters solving a lot of (very small) problems in large teams and projects, like (forces a coding standard, find small bugs like forgetting to type a var or forgetting a switch default, fewer git merges/conflicts) which leads to a better codebase in general (if you enforce the rules at commit/build).
As a sidenote linters are builtin in most IDEs so maybe you use them already, but only at a basic level.
We use eslint (for the older projects, a combination of jshint and jscs). The plugin I use for vim (ale) works with pretty much any kind of linter I've encountered.
This isn't the sort of static analysis I'd expect from and IDE though, this is what I'd expect from any kind of programmers editor (vscode, sublime, etc). What I meant by static analysis is the ability to goto definition, display documentation, refactor, etc. This is the sort of stuff which doesn't work consistently enough with our codebase to even bother trying.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I just wanted to raise awareness on "VIM priests" that spread their false gossips around, I probably sound more passive-aggressive then it should.
You just "forget" to mention that it is a personal preference, and state that "Vim is the perfect IDE" (for me?!), knowing in fact that is not even an IDE and not perfect. You "forget" to mention that you spent maybe years of being prolific, where in IDE's most of the things "just works".
VIM is great when you have many small scripts/projects, or you alter big projects with minimal invasion, edit big files, or you are a sys admin, or ...(insert here a lot of stuff you didn't mention), but ....
It is "a common trap" that I've seen are with web dev juniors, they usually:
This combined with the fact that people hate change, leads to bigger problems once the developer gets involved in bigger and more complex projects.
I just want to make things clear for the juniors and next generation of developers to make a big difference between "personal preferences" and "best tool for the job", and posts like this doesn't help at all.
Please keep in mind that everything you've said so far is anecdotal. Others, such as me, may have different experiences.
I tend to agree with BG. Tooling becomes vastly important when working with larger and more complex codebases. The kind of code analysis provided by actual IDEs simply cannot be replicated in Vim no matter how it's customized.
Vim is great, but Vim is ultimately just a powerful text editor. BG is correct in that the anti-IDE stance is alluring for junior devs, providing false machismo in the absence of experience and well-honed skills.
We really need to change the way we talk about Vim. Here are my suggestions:
Vim, conceptually, is mode-based text editing with consistent, highly optimized keybindings. The beautiful thing about vim-as-a-concept is that it's available in some form or fashion in nearly every IDE and text editor.
"vim-as-a-concept is that it's available in some form or fashion in nearly every IDE and text editor." ... and browser.
In my line of work, I've seen little to no benefit with static analysis. I am working on a highly dynamic codebase. Sure, if your language is static its great, but I really don't see this as being a reason for not using VIM. I've actually seen VIM autocompletion be more accurate than IDE's (for newer languages such as Rust).
I am very curious in what languages/line of work there are no benefits for static analysis, can you give some examples?
Javascript - we use dependency injection heavily.
wow ok, your team is great then! I was part of teams that didn't used but we ended up regretting.
I usually saw linters solving a lot of (very small) problems in large teams and projects, like (forces a coding standard, find small bugs like forgetting to type a var or forgetting a switch default, fewer git merges/conflicts) which leads to a better codebase in general (if you enforce the rules at commit/build).
As a sidenote linters are builtin in most IDEs so maybe you use them already, but only at a basic level.
We use eslint (for the older projects, a combination of jshint and jscs). The plugin I use for vim (ale) works with pretty much any kind of linter I've encountered.
This isn't the sort of static analysis I'd expect from and IDE though, this is what I'd expect from any kind of programmers editor (vscode, sublime, etc). What I meant by static analysis is the ability to goto definition, display documentation, refactor, etc. This is the sort of stuff which doesn't work consistently enough with our codebase to even bother trying.