Live data from Hacker News

Reasons To Give The Vim Text Editor A Chance

makeuseof.com

41–50 of 68 posts

Re: Reasons To Give The Vim Text Editor A Chance

#41
post #7

Earlier quoted context omitted.

Most people that use vim also don't use graphical debuggers. I use the "print" statement.

Someday, you'll get to work in a language that has a good REPL, and you'll never want to go back to printing. :)

Someday, you'll want to run your code more than once, and you'll write tests instead of typing them into the REPL.

Re: Reasons To Give The Vim Text Editor A Chance

#42
post #40

It's not surprising to see that the logo isn't amongst the list :) I use a mix of Elvis and Vim as I'm training up on vi-likes, and I'm not sure which I prefer yet. Vim has more-intuitive-to-me stuff like character-by character deleting (ie characters are removed when you delete, not when you leave Insert mode), but elvis has things like pressing = twice to reflow paragraphs. Vim may win in the end as Elvis is hard t…

Vim can reflow too, but I will admit that 'gwap' is a bit unintuitive...

Re: Reasons To Give The Vim Text Editor A Chance

#43
post #15

My reason for using vi/vim is that it's the lowest common denominator text editor. You'll find it by default on most any Linux or BSD system.

That's my reason too. I use it on Linux, BSD, Mac OS X, and MS Windows. I like TextMate for some tasks better than Vim, but my ratio of time spent in both is still 9:1 (Vim:TextMate).

Re: Reasons To Give The Vim Text Editor A Chance

#44
post #40

It's not surprising to see that the logo isn't amongst the list :) I use a mix of Elvis and Vim as I'm training up on vi-likes, and I'm not sure which I prefer yet. Vim has more-intuitive-to-me stuff like character-by character deleting (ie characters are removed when you delete, not when you leave Insert mode), but elvis has things like pressing = twice to reflow paragraphs. Vim may win in the end as Elvis is hard t…

Vim can reflow too, but I will admit that 'gwap' is a bit unintuitive...

cool, thanks for that!

Re: Reasons To Give The Vim Text Editor A Chance

#45
post #32
post #27

Earlier quoted context omitted.

What about project-wide find and replace? I have been looking to switch to vim, but I do this fairly often and don't see anything that compares to what a good ide can do in vim (without bash command madness).

Try bufdo, argdo, windo, and tabdo depending on the subset of files you'd like to modify. E.g., to replace "foo" with "bar" in all open buffers: :bufdo %s/foo/bar/g | update Although I wouldn't knock `bash command madness' for this sort of task. :) The Unix shell is pretty much designed for advanced text manipulation across files. E.g., to replace all instances of foo with bar in HTML files, recursively: $ find . -na…

I agree. I've also found this perl script handy for recursive find/replace: http://www.neilgunton.com/doc/deep

$ deep replace "foo" "bar" "*.html"

Re: Reasons To Give The Vim Text Editor A Chance

#46
post #14

Earlier quoted context omitted.

Spewing print statements all over a piece of code is as bad as any other shotgun debugging technique. The reason breakpoints and watches were invented were to reduce reliance on bad ways of doing things.

What's good about print statements is that they don't require me to do anything more than once. When you run code in a debugger, there is a lot of manual interaction involved. continue, break, see where you are, think about that, poke around, repeat. With print statements, you run your test, analyze the output, and make the changes. It's all automated except for the analysis step, which is all the human should be doi…

Manual interaction? Sorry, but I'm still very skeptical. Pausing in a debugger does not require materially more "manual interaction" than endlessly running your program to spit out some printed statements--it just front-loads the manual interaction so you're doing it sooner and, if you're doing it right, doing less of it. A debugger allows live autopsy, which is far more valuable than this silly print-statement thing--when your print statement does not return as expected, you are not much better off with your print statements than just seeing the broken output of the program.

Couple live autopsy with live edit-and-continue and you've got a recipe for a considerably more effective way of debugging code.

And "your code is too complicated and unmaintainable if you need a debugger" is preposterous on its face if you've ever...oh, I don't know...written a driver? Or any other remotely complex (you're conflating complicated and complex) task with a significant number of interlocking parts? (Hell, one could just as easily say that your code is too complicated and unmaintainable if you're barfing print statements all over the place.)

Re: Reasons To Give The Vim Text Editor A Chance

#47
post #30

Earlier quoted context omitted.

What's good about print statements is that they don't require me to do anything more than once. When you run code in a debugger, there is a lot of manual interaction involved. continue, break, see where you are, think about that, poke around, repeat. With print statements, you run your test, analyze the output, and make the changes. It's all automated except for the analysis step, which is all the human should be doi…

I like logging for this, but the concept is basically the same. Being able to switch on debug logging on a running system has saved the day more than once for me.

Thing is, logging and debugging are not in opposition. My current web app is...well, verbose is probably putting it mildly. But when developing locally, if something goes sideways I just say "hey, stop here" and I can introspect the entire kit and kaboodle without even having to re-bounce the debug server (and certainly without stopping it to bung in a bunch of print statements).

Re: Reasons To Give The Vim Text Editor A Chance

#48

My reasons for being a vim user a lot more practical than those I see on these "top 10 reasons for trying X": - In the long run, it's faster to learn and use an "efficiency" editor, so I need to learn one of vim, emacs, notepad++, etc. The differences between these are probably negligible for a proficient user. - Of these, only vim will be installed (or vi, which has a big enough overlap that it won't matter to me) o…

There's a big exception to the "vim will be installed" rule: Windows.

Re: Reasons To Give The Vim Text Editor A Chance

#49

Earlier quoted context omitted.

Someday, you'll get to work in a language that has a good REPL, and you'll never want to go back to printing. :)

Someday, you'll want to run your code more than once, and you'll write tests instead of typing them into the REPL.

Print statements aren't meaningful tests, though. Hence the eight hojillion xUnit ports for pretty much every major language.

Re: Reasons To Give The Vim Text Editor A Chance

#50
post #14
post #7

Earlier quoted context omitted.

Most people that use vim also don't use graphical debuggers. I use the "print" statement.

Spewing print statements all over a piece of code is as bad as any other shotgun debugging technique. The reason breakpoints and watches were invented were to reduce reliance on bad ways of doing things.

Nobody is putting print statements all over the place. At least I don't do. I set it where I want to inspect values. If you want a separate piece of software for that, more power to you, but please don't tell me my nails must be crooked because I use a different hammer than you.
Post reply on HN