It's so strange to me that people still choose to disregard the benefits of a full featured IDE. Things like live debugging with minimal configuration, automatic refactoring tools, finding all users or definitions of some class or function, these aren't just nice-to-haves, they make you a better and more productive developer.
The only point you're raising that truly cannot be disputed is the minimal configuration part, anything else can be achieved with Vim one way or another.
The thing is, there's a sense of accomplishment in creating your own Vim environment, something that perfectly fits your needs, so in a sense thats more attractive than using some other IDE.
Another important positive point about learning and mastering Vim is that most of the things you learn with Vim can help you outside of just Vim, in my case I learned regular expressions because I needed to use them to better make searches and substitutions inside Vim, also Vim comes already installed in most Linux distros, so if you find yourself constantly ssh'ing into Linux servers knowing Vim will help you a lot.
Glad you raised the point about learning vim gives you transferable knowledge. I've actually pointed that out in a few talks. For example, if I learn vim then with one command I can set my shell to use vim keybindings and my shell navigation is completely familiar (and efficient). Then tmux can be mapped similar fashion. So too, regex becomes second nature, then you realize that any tool that uses regex becomes much more flexible. The more transferable knowledge a tool brings to the table, the more likely I am to use it.
If you invest the time required to make vim even functional as your main editor then the minimal installation of vim you find when you ssh into those servers will be only slightly less alien to you than it would be to someone who used a functional text editor or ide.
I guess if you value tooling around and spending hours and hours configuring vim to make it still significantly less intuitive, feature rich, and user friendly than most editors come 'out of the box' over and above doing actual software development then we just have different goals.
It all depends on each person if it's not for you, that's Ok. Software Development is not the only thing I do every time I sit on my PC, I'm a long-time Linux user, and everything that allows me to use the touchpad or mouse less is a plus.
I don't need to use Vim for software development, I choose to.
There are a couple reasons I disagree with this mentality.
You still have to tack on some half-assed vim plugin to any IDE to get ergonomic and efficient movement, so a minimally-configured IDE isn't perfect either. And why not spend a few hours one weekend fully customizing vim? It's kinda fun, really not difficult, and supremely flexible. There isn't any feature of an IDE that I haven't found replicable in vim.
You can't customize nearly as much with an IDE as you can with vim. This leads to little nagging friction that, long-term, takes up more time than the individual moments you lose.
When you choose an editor/IDE, it's very high-friction to switch. How many people decided to use atom or sublime or (shudder) eclipse only to find that language servers that vscode initiated were something so useful they wanted to switch? With vim, every new innovation that comes along is quickly implemented by the passionate community around it, and the community has been around so long that it's really difficult to imagine that it will not continue (especially now that neovim exists and development has become easier).
IDEs are often at the whim of a company, and companies have a strong tendency to degrade over time, and with that abandon efforts. What was developed heavily several years ago by a developer darling can quickly go by the wayside if, e.g. the investment bubble pops and companies actually start looking to make a short-term profit at the cost of passion projects.
Vim gets you closer to your devops stack. Instead of having terminals running your CLI applications and logging output separately, they can all be in the same window (with tmux). The layouts and configuration of this are all much more ergonomic than the rigid display of previews and command running in IDEs. In general, if you live in the shell for your editor and don't rely on an IDE to implement custom commands for devops etc, you're more motivated to actually learn about what's going on under the hood.
Visually, vim has as much or, in my case, as little chrome as you want so you can preserve your screen real estate for actual code.
Vim is portable and if you ever need to develop natively on a more powerful remote instance, it's trivially easy to backup and restore your config there. If you decide to use a different operating system, you don't have to cross your fingers that the trendy IDE du jour is supported on it. If your laptop breaks and you have to borrow your mom's 2 GB ram crapbook, you can still actually write code because you don't have some memory-hogging beast of an IDE to install. Side note, vim takes an imperceptably-small amount of time to start; I've seen some IDEs take minutes.
So, if the only benefit to an IDE is that you don't have to spend a few hours customizing it to your liking (and, really, aren't motivated to customize it or learn more efficient ways of moving), I wouldn't consider that preferable at all.
Since I posted this I have truly tried hard to think of something that an IDE can do that is imposible to do in Linux with a combination of tools like tmux and vim.
I guess that much of this hate towards Vim comes from a place of simply not knowing how to implement with Vim the things they love about others IDE.
Question: How do I implement semantic completion for C++ in vim with MinGW? coc supports lsp, but all the C++ lang servers are for clang, not gcc/MinGW.
Unfortunately, it ceased being strange a long time ago that people choose to disregard the benefits of simplicity, precision, and ubiquity. What are you going to do when you don't have access to an IDE? If you haven't been in that position, the odds are you are either a specialist, work for a completely siloed company in which you write code and throw it over the wall never to be seen again, or you haven't been a developer very long.
Is EC2 part of your development or production cycle? Goodbye IDE. Have to parse through 200M of logs that can only be viewed on a production server? Use docker? Only have ssh access to the server? Development box only has 8G of ram and the project is large enough that you can't start the IDE because you run out of memory?
No, these are not contrived situations. I have experienced every one of them, as stupid as it sounds, that last one was within the past month. And many people I've work with experienced those situations a lot more often than I have. A lot of devops people I know regularly throw the IDE away for weeks at a time because it's just easier to use vim since can be installed everywhere if it isn't already installed by default.
Just to play devil's advocate for a moment regarding the benefits of an IDE:
I have watched many people over pull out hair trying to figure out why a project doesn't compile when it turned out the IDE wasn't configured properly for that project. If you look at the sheer quantity of configurable options under the IntelliJ preferences menu, I understand why many people spend just as many hours playing with their IDE configurations as I do with my vim. Sure, an IDE works great out of the box, until it doesn't. Vim is no different. It, too, works great out of the box, until it doesn't meet your needs.
Setting aside for a moment that you can get live debugging in vim if you want to work for it, I'll instead point out that, for myself, if I've been forced into using a live debugger, I've probably already gone wrong somewhere. Most likely because I've screwed up my testing, it's too complex to write a test, which usually means I've written too much production code without writing a test for it. My goal is to not need to use a debugger, so not having it? That's not a problem, that's me configuring my environment to encourage outcome I desire.
As far as automatic refactoring tools, I'm kind of in the same boat as with needing a debugger. I like having to refactor by hand, it forces me to pay attention to my code quality. Also, most automated refactorings in an IDE are pretty simple. Simple enough that I don't really need an IDE to do them quickly.
Vim gives me the ability to find class/function definitions out of the box in an uncomplicated way. Check out ctags.
Better is a subjective term, my "better" and your "better" may be different.
Like "better", productive can also be a subjective term unless you're going to attach specific metrics to it. If you can do that, I would honestly like to see the metrics you use and why you chose them. There's a reason that even after decades of trying there is still no way for management to accurately measure developer productivity. This has been a holy grail for them since they hired software developers.
Anyway, vim works most of the time for me but that's just my opinion, I could easily be wrong.
Agree with everything except the live debugger which I use all the time when working on Magento extensions. For me iterating with VdebugEval is the quickest way I've found to code that works. Maybe I should try a more test driven development approach?
In fairness, I am unfamiliar with Magento, but if you're referring to the php e-commerce platform, I'd say that there are several things I'd look at in your position. First, I'd say if you're wondering if you're not using enough of a test driven approach, you probably aren't. I can also fairly fairly fanatic about it, more than is probably good for me.
I will start with the most degenerate of tests when I need to write a function, as in, write a test that tells me I return something other than 'null' from the function, and then start refactoring to add more specifics.
Second, I would look at the platform itself. Is it hindering me from writing good clean tests? If it's easier for me to run a debugger than it is to write a test, I'd feel like something was wrong somewhere.
The bottom line is that using a live debugger solves the same problem that REPL's solve, namely, tightening the feedback loop between the moment you write the code and the moment you know if it works. This is great for prototyping but it isn't sustainable for something intended for production. Production code will probably live much longer than you think it will and if you've been relying on anything other than automated tests to prove something behaves as expected, you're doing everyone, yourself included, a disservice.
Having said all that, using TDD is a choice, and as much as some of my colleagues may disagree with me, there are times it isn't appropriate. On the other hand I have come across very few instances outside of prototyping and investigation of production issues where the convenience of using a live debugger outweighed the advantages of writing a test. Also, if I have to use a debugger to solve it, I'm going to write a test to cover that exact situation because clearly it needed a test.
Agree about automated testing, but never thought of it as a substitute for a debugger. I'm sure I've used ipdb to debug new pytest unit tests. I'm bought in on automated testing, used to work in the semiconductor industry where mistakes are very expensive. Still some clients refuse to pay for them. At least so far...
I started to write a long-winded reply to this and realized I was rambling. Specifically, I don't think of a debugger as a substitute for testing, case in point is your comment about using a debugger to find unexpected issues with unit tests. I think debuggers serve a specific and related purpose to tests, which is to shorten the feedback loop used to validate the expected, specific behavior of code.
I do think that the way debuggers are typically used is as a substitute for testing.
I feel you on the semiconductor testing. Many (many) years ago I worked for a company called Pintail Technologies as the test automation guy. They company specialized in using statistical techniques to sample test chips and it was stunning how expensive a process testing chips was at a hardware level and how manufacturers would do anything to drop the cost.
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.
It's so strange to me that people still choose to disregard the benefits of a full featured IDE. Things like live debugging with minimal configuration, automatic refactoring tools, finding all users or definitions of some class or function, these aren't just nice-to-haves, they make you a better and more productive developer.
The only point you're raising that truly cannot be disputed is the minimal configuration part, anything else can be achieved with Vim one way or another.
The thing is, there's a sense of accomplishment in creating your own Vim environment, something that perfectly fits your needs, so in a sense thats more attractive than using some other IDE.
Another important positive point about learning and mastering Vim is that most of the things you learn with Vim can help you outside of just Vim, in my case I learned regular expressions because I needed to use them to better make searches and substitutions inside Vim, also Vim comes already installed in most Linux distros, so if you find yourself constantly ssh'ing into Linux servers knowing Vim will help you a lot.
Glad you raised the point about learning vim gives you transferable knowledge. I've actually pointed that out in a few talks. For example, if I learn vim then with one command I can set my shell to use vim keybindings and my shell navigation is completely familiar (and efficient). Then tmux can be mapped similar fashion. So too, regex becomes second nature, then you realize that any tool that uses regex becomes much more flexible. The more transferable knowledge a tool brings to the table, the more likely I am to use it.
If you invest the time required to make vim even functional as your main editor then the minimal installation of vim you find when you ssh into those servers will be only slightly less alien to you than it would be to someone who used a functional text editor or ide.
I guess if you value tooling around and spending hours and hours configuring vim to make it still significantly less intuitive, feature rich, and user friendly than most editors come 'out of the box' over and above doing actual software development then we just have different goals.
It all depends on each person if it's not for you, that's Ok. Software Development is not the only thing I do every time I sit on my PC, I'm a long-time Linux user, and everything that allows me to use the touchpad or mouse less is a plus.
I don't need to use Vim for software development, I choose to.
I just clone my dot files to the server and :PlugInstall to get the same Vim setup everywhere.
There are a couple reasons I disagree with this mentality.
You still have to tack on some half-assed vim plugin to any IDE to get ergonomic and efficient movement, so a minimally-configured IDE isn't perfect either. And why not spend a few hours one weekend fully customizing vim? It's kinda fun, really not difficult, and supremely flexible. There isn't any feature of an IDE that I haven't found replicable in vim.
You can't customize nearly as much with an IDE as you can with vim. This leads to little nagging friction that, long-term, takes up more time than the individual moments you lose.
When you choose an editor/IDE, it's very high-friction to switch. How many people decided to use atom or sublime or (shudder) eclipse only to find that language servers that vscode initiated were something so useful they wanted to switch? With vim, every new innovation that comes along is quickly implemented by the passionate community around it, and the community has been around so long that it's really difficult to imagine that it will not continue (especially now that neovim exists and development has become easier).
IDEs are often at the whim of a company, and companies have a strong tendency to degrade over time, and with that abandon efforts. What was developed heavily several years ago by a developer darling can quickly go by the wayside if, e.g. the investment bubble pops and companies actually start looking to make a short-term profit at the cost of passion projects.
Vim gets you closer to your devops stack. Instead of having terminals running your CLI applications and logging output separately, they can all be in the same window (with tmux). The layouts and configuration of this are all much more ergonomic than the rigid display of previews and command running in IDEs. In general, if you live in the shell for your editor and don't rely on an IDE to implement custom commands for devops etc, you're more motivated to actually learn about what's going on under the hood.
Visually, vim has as much or, in my case, as little chrome as you want so you can preserve your screen real estate for actual code.
Vim is portable and if you ever need to develop natively on a more powerful remote instance, it's trivially easy to backup and restore your config there. If you decide to use a different operating system, you don't have to cross your fingers that the trendy IDE du jour is supported on it. If your laptop breaks and you have to borrow your mom's 2 GB ram crapbook, you can still actually write code because you don't have some memory-hogging beast of an IDE to install. Side note, vim takes an imperceptably-small amount of time to start; I've seen some IDEs take minutes.
So, if the only benefit to an IDE is that you don't have to spend a few hours customizing it to your liking (and, really, aren't motivated to customize it or learn more efficient ways of moving), I wouldn't consider that preferable at all.
Since I posted this I have truly tried hard to think of something that an IDE can do that is imposible to do in Linux with a combination of tools like tmux and vim.
I guess that much of this hate towards Vim comes from a place of simply not knowing how to implement with Vim the things they love about others IDE.
Question: How do I implement semantic completion for C++ in vim with MinGW? coc supports lsp, but all the C++ lang servers are for clang, not gcc/MinGW.
Unfortunately, it ceased being strange a long time ago that people choose to disregard the benefits of simplicity, precision, and ubiquity. What are you going to do when you don't have access to an IDE? If you haven't been in that position, the odds are you are either a specialist, work for a completely siloed company in which you write code and throw it over the wall never to be seen again, or you haven't been a developer very long.
Is EC2 part of your development or production cycle? Goodbye IDE. Have to parse through 200M of logs that can only be viewed on a production server? Use docker? Only have ssh access to the server? Development box only has 8G of ram and the project is large enough that you can't start the IDE because you run out of memory?
No, these are not contrived situations. I have experienced every one of them, as stupid as it sounds, that last one was within the past month. And many people I've work with experienced those situations a lot more often than I have. A lot of devops people I know regularly throw the IDE away for weeks at a time because it's just easier to use vim since can be installed everywhere if it isn't already installed by default.
Just to play devil's advocate for a moment regarding the benefits of an IDE:
I have watched many people over pull out hair trying to figure out why a project doesn't compile when it turned out the IDE wasn't configured properly for that project. If you look at the sheer quantity of configurable options under the IntelliJ preferences menu, I understand why many people spend just as many hours playing with their IDE configurations as I do with my vim. Sure, an IDE works great out of the box, until it doesn't. Vim is no different. It, too, works great out of the box, until it doesn't meet your needs.
Setting aside for a moment that you can get live debugging in vim if you want to work for it, I'll instead point out that, for myself, if I've been forced into using a live debugger, I've probably already gone wrong somewhere. Most likely because I've screwed up my testing, it's too complex to write a test, which usually means I've written too much production code without writing a test for it. My goal is to not need to use a debugger, so not having it? That's not a problem, that's me configuring my environment to encourage outcome I desire.
As far as automatic refactoring tools, I'm kind of in the same boat as with needing a debugger. I like having to refactor by hand, it forces me to pay attention to my code quality. Also, most automated refactorings in an IDE are pretty simple. Simple enough that I don't really need an IDE to do them quickly.
Vim gives me the ability to find class/function definitions out of the box in an uncomplicated way. Check out ctags.
Better is a subjective term, my "better" and your "better" may be different.
Like "better", productive can also be a subjective term unless you're going to attach specific metrics to it. If you can do that, I would honestly like to see the metrics you use and why you chose them. There's a reason that even after decades of trying there is still no way for management to accurately measure developer productivity. This has been a holy grail for them since they hired software developers.
Anyway, vim works most of the time for me but that's just my opinion, I could easily be wrong.
Agree with everything except the live debugger which I use all the time when working on Magento extensions. For me iterating with VdebugEval is the quickest way I've found to code that works. Maybe I should try a more test driven development approach?
In fairness, I am unfamiliar with Magento, but if you're referring to the php e-commerce platform, I'd say that there are several things I'd look at in your position. First, I'd say if you're wondering if you're not using enough of a test driven approach, you probably aren't. I can also fairly fairly fanatic about it, more than is probably good for me.
I will start with the most degenerate of tests when I need to write a function, as in, write a test that tells me I return something other than 'null' from the function, and then start refactoring to add more specifics.
Second, I would look at the platform itself. Is it hindering me from writing good clean tests? If it's easier for me to run a debugger than it is to write a test, I'd feel like something was wrong somewhere.
The bottom line is that using a live debugger solves the same problem that REPL's solve, namely, tightening the feedback loop between the moment you write the code and the moment you know if it works. This is great for prototyping but it isn't sustainable for something intended for production. Production code will probably live much longer than you think it will and if you've been relying on anything other than automated tests to prove something behaves as expected, you're doing everyone, yourself included, a disservice.
Having said all that, using TDD is a choice, and as much as some of my colleagues may disagree with me, there are times it isn't appropriate. On the other hand I have come across very few instances outside of prototyping and investigation of production issues where the convenience of using a live debugger outweighed the advantages of writing a test. Also, if I have to use a debugger to solve it, I'm going to write a test to cover that exact situation because clearly it needed a test.
Agree about automated testing, but never thought of it as a substitute for a debugger. I'm sure I've used ipdb to debug new pytest unit tests. I'm bought in on automated testing, used to work in the semiconductor industry where mistakes are very expensive. Still some clients refuse to pay for them. At least so far...
I started to write a long-winded reply to this and realized I was rambling. Specifically, I don't think of a debugger as a substitute for testing, case in point is your comment about using a debugger to find unexpected issues with unit tests. I think debuggers serve a specific and related purpose to tests, which is to shorten the feedback loop used to validate the expected, specific behavior of code.
I do think that the way debuggers are typically used is as a substitute for testing.
I feel you on the semiconductor testing. Many (many) years ago I worked for a company called Pintail Technologies as the test automation guy. They company specialized in using statistical techniques to sample test chips and it was stunning how expensive a process testing chips was at a hardware level and how manufacturers would do anything to drop the cost.