Hacker News Reader

Comment by nineplay | Hacker News Reader

I probably used vim exclusively for about a decade. I've worked with a handful of developers who've only used vim and I've only known one who was anywhere near as effective with it as most IDE users. A few examples

-- debugging with print statement because they don't know how to use a command line debugger

-- using find and grep to find files/methods

-- hand-formatting files because they don't have a inline formatter or something to notify them when they've missed a semicolon or spelled a method wrong.

I strongly encourage them to move to an IDE because I can't stand looking over their shoulder and watching them code so inefficiently. There probably are vim plugins to handle many/all of these things, but if a developer doesn't put the effort in to find them than they're just hurting they're own productivity.

View on HN

I'm kind of doubtful of this. Just to take print debugging as an example. While there is definitely a time and place for debuggers, i think print debugging can be shockingly efficient in many circumstances.

Besides, typing speed is usually not the limiting factor in programming speed. I think overall efficiency needs to take a broader look.

I default to printf debugging myself, but it can be an indicator that someone doesn't know their tools.

Breakpoints are likely to screw up a lot of concurrent user requests, so in prod we debug microservices by comparing pushed logs.

The typical bell curve meme: https://imgflip.com/i/9a9gm7

The fun begins when you can't debug by printf because the buffer is shared by multiple processes that change it while the printf command is running.

Yeah, network logging has latency but it does pack the messages into structs and demux them. The remaining debugger problems are:

- Do you know which service tier has the issue?

- Can you halt one thread that sees the issue, not all of them on an instance?

- When the request times out, do you have to start over and make another prod user sad?

A person not using an IDE is more likely to be proficient in command line tools, not less.

Those developers frankly sound like idiots, I don't think they should be coding at all. Also yes, all of those things are easily done in both vim and emacs.

Care to elaborate what's wrong with find and grep?

It takes seconds or more to grep for a function, especially if it has a common name. It takes milliseconds to Go To Definition / Find Usages (either with an IDE or a LSP extension for any text editor).

If they're not using fzf, ctags or LSP at all, sure. But find and grep absolutely have their place, and I tend to use them even when using IntelliJ/VSCode.

Yes, no one said find or grep are useless, far from it. The original premise was people using grep to look for a function in a code base, or find to get to a file (presumably to get to an include file or imported module by name). And they are definitely sub optimal for this - as you mention, even outside of an IDE, there are plenty of better tools to integrate with vim or nano or ed (the standard text editor!) or whatever you prefer.

And then you go full circle when the project is bigger and Find Usages no longer works across projects (specifically in the context of a typescript monorepo) and it's back to grepping for usages.

Do those miliseconds also include the time where you have to move your hand from the keyboard to the mouse to ctrl+click the function name? ;)

I see your point though. I guess I just disagree with the premise that using an IDE will increase productivity.

The developer will always have to invest some effort into learning the tools, be it find and grep or an IDE.

The premise is that using proper code navigation functions will increase productivity over grep. Not that using an IDE will increase productivity over vim, assuming you use actual code navigation tools in vim.

As for the click: all IDEs and all code navigation tools for popular text editors like vim or emacs have full keyboard support. And M-. Or F2 or whatever are much quicker to type than "grep function_name".

Reply on news.ycombinator.com