[jointhefuture]

The article on editors is basically "here's the names of 5 editors, now learn vim"

I know this will piss off vim users but in my experience vim users are seriously out date when it comes to dev tools. It's like they never left the 70s. vim might be great, it might be available everywhere but when I see a vim user I then see them use something like gdb and have clearly never experienced a modern debugger because if they had they'd be infuriated at how their debugging tools haven't improved in 30 years.

I'm sure others could go into all the features a modern editor or IDE provide. The vim users will say they don't need that crap. They sound like some grandpa saying "back in my we had to walk to 5 miles to school, no one had invented bicycles or cars or buses. Don't need those new fangled things, now Get off my Lawn!"

[flukus]

My experience of IDE users (myself included much of the time) is that they don't know how limited their debugging experience is, just breakpoints and how to step through code. Things like breaking when a variable is set, debugging from a core dump, creating a core dump under certain conditions, viewing the assembly, setting variables on the fly etc, are features of a good debugger (often the one they're using) that are obscured from them.

If you want that shallow level of debugging you can do it from inside vim though: https://github.com/idanarye/vim-vebugger

[jointhefuture]

Exact opposite of my experience. IDEs let me easily add conditional break points, toggle between source, disassembly, source+disassembly, set variables just by clicking on them, view multiple areas of memory in different tabs/windows. Set how that memory is viewed (bytes, words, dwords, floats, as a type of class/struct, array of classes/structs), show different contexts at once, have multiple windows per thread/process, never seen someone use one that didn't know those features exist as they are all obvious to discover in an IDE.

sounds like you've never used one but then that's what I'd guess from watching most vim users. All of those have been standard features of visual IDE debuggers for over 30 years. Mean while instead of seeing every thing update live I watch the vim users type various gdb print and dump commands at the command line and then watch that data scroll off their terminal instead of being updated live as they progress like an IDE debugger.

[flukus]

> sounds like you've never used one but then that's what I'd guess from watching most vim users

You'd be mistaken, I've spent a huge chunk of my adult life inside Visual Studio. IME most devs don't even know you can add a condition to a breakpoint (hiding feature behind right clicks aren't obvious) and anything complicated turns into a very convoluted process very quickly. Even setting conditional breakpoints are basically an input into the command interface, essentially what the windows run menu is to the command line.

Take this short tutorial (https://amazingdim.wordpress.com/2014/02/01/gdb-script/) on gdb scripting and show me how to do similar through an IDE. With Visual Studio at least it is much more complicated, here are a few google results on that path:

1. https://docs.microsoft.com/en-us/visualstudio/debugger/using... 2. https://blogs.msdn.microsoft.com/debugger/2009/12/30/what-is... 3. https://stackoverflow.com/questions/47513337/howto-debug-a-n... 4. https://docs.microsoft.com/en-us/windows/desktop/wer/collect...

[MrEldritch]

>IME most devs don't even know you can add a condition to a breakpoint (hiding feature behind right clicks aren't obvious)

Can confirm: I sure didn't. ...honestly most of my debugging is with print statements.

[roryokane]

You’re assuming that Vim users use only Vim. I use Vim all the time for editing config files, small Ruby scripts, and JavaScript projects without types – for these cases it is among the best tools for the job. And when I work on, for example, big Java projects, I use IntelliJ IDEA plus a Vim keybindings plugin, so I can use the IDE’s debugger and its refactoring support. Don’t make sweeping generalizations about Vim users not knowing when other tools are appropriate.