Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasons To Give The Vim Text Editor A Chance

makeuseof.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Reasons To Give The Vim Text Editor A Chance

#61

Post by jamesbritt »

dekz wrote: post #10
jamesbritt wrote: post #8

Earlier quoted context omitted.

I never understood how people can code without debugging, profiling, code exploring. I'm sure many vim users wonder the same thing. They may also wonder how people can develop using tools that are coupled to each other rather than choosing the various development tools as they see fit. In any event it's not either/or. The times I've needed Netbeans, for example, I use vim for actual code editing and the IDE for assor…

Theres also Eclim for Eclipse which will let you have one of a running modes: Headless eclipse, VIM embedded in the editor, or you can just open it externally.

Does the embedded vim use the users' config files? I've gotten quite used to assorted macros and helpers.

Re: Reasons To Give The Vim Text Editor A Chance

#62

Post by jrockway »

eropple wrote: post #49
jrockway wrote: post #41

Earlier quoted context omitted.

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.

OK, so say you have some test that creates a foobar object and invokes the method baz, which does some stuff that you care about. The test fails. What do you do? Do you pick apart the implementation of baz in the REPL, or do you add some print statements inside baz?

The second option is easier. You obviously remove them once your understanding (and tweaking) of the code leads to a passing test.

Re: Reasons To Give The Vim Text Editor A Chance

#63

Post by doorhammer »

gnosis wrote: post #53
doorhammer wrote: post #18

I've been tooling around with emacs, having plopped down vimpulse and viper on it. I get slime for clojure, the power of elisp for modifications and so on, as well as my preferred editing style, which is modal. It's not for everyone, but it works for me. It helps that my life isn't terribly busy, and I enjoy taking the time to make everything work together. Of course, caps rebinding is a must for either. It's been fu…

When I started learning Lisp, I tried using Emacs with viper and vimpulse. Although it did make using Emacs less painful, it still required way too much knowledge of Emacs to use effectively and configure than I had time to dedicate to learning it. Emacs+SLIME+vimpulse+viper might be good enough for someone who already knows Emacs or who hasn't invested a lot of time in learning vim. But for someone fluent in vim, I…

That's completely understandable. I really don't have a huge reason to be doing things this way. I've just been going through The Joy of Clojure and decided to give emacs a spin, and I wanted some similar editing idioms while messing with it.

I've basically been translating the shortcuts and techniques I use in vim into some ugly elisp, bit by bit, assuming they don't work as expected with vimpule/viper. I wouldn't say it's an amazing solution, but mucking through the emacs docs to get things working has been a quick way to get a basic proficiency in how emacs works, and how elisp can be used.

Ultimately I still end up in vim for most of my editing, and I keep tacking things onto emacs as I go, but mostly when I'm just writing some clojure. I wouldn't say it's efficient at all; it's just interesting enough to kill time with because my life isn't very busy and it seems 'nifty'.

Re: Reasons To Give The Vim Text Editor A Chance

#64

Post by jrockway »

eropple wrote: post #58
Total_Meltdown wrote: post #56

Earlier quoted context omitted.

I'm not sure what code you write or what it's for, but in the real world, sometimes we deal with buggy, archaic and downright bizarre code that we didn't write, and sometimes we have deadlines. So, yes. I use a debugger, so that I can spend some time at home too. Because as nice as the office is, it's summertime, and there's beer in my fridge. Back when I was seventeen and staying up all night writing a video game en…

Honest question (as I avoid Perl like the plague) - is there an introspective debugger on par with Visual Studio's in Perl-land? Because if you're leaning on print statements in absence of appropriate tooling, I can understand that. When the tooling is available, however, I am skeptical of claims as to enhanced productivity or any other positivity coming from it.

There's a way to get a good answer from someone, compare his language of choice to a deadly disease. And then ask if it's as good as some proprietary crapware.

What does visual studio? Show the value of variables in separate windows as the code runs? Yes, the perl debugger can do that. You can also inject code and poke the entire program state.

The perl debugger is a perl function that is called for every line and every subroutine entry. Use that to build whatever tool you want, and good luck finding that in Visual Studio.

Re: Reasons To Give The Vim Text Editor A Chance

#65

Post by jrockway »

eropple wrote: post #46
jrockway wrote: post #20

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…

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…

You "step over" instead of "step into". Now what? You have to start over.

With test cases and print statements, starting over is free. If you need more information, edit the code to give it to you and re-run.

Getting a debugged program back to the desired state is, in my experience, difficult even with an automatic test. Not only does the program state have to be right, but so does the debugger state. Without the debugger, you have half the state to bother with.

Re: Reasons To Give The Vim Text Editor A Chance

#66

Post by japherwocky »

jrockway wrote: post #62
eropple wrote: post #49

Earlier quoted context omitted.

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

OK, so say you have some test that creates a foobar object and invokes the method baz, which does some stuff that you care about. The test fails. What do you do? Do you pick apart the implementation of baz in the REPL, or do you add some print statements inside baz? The second option is easier. You obviously remove them once your understanding (and tweaking) of the code leads to a passing test.

you set a trace point inside baz, investigate with the REPL, and fix your code.

Re: Reasons To Give The Vim Text Editor A Chance

#67

Post by 2muchcoffeeman »

jcromartie wrote: post #48
davidtgoldblatt wrote: post #2

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.

And what windows installation comes with any dev tools by default? You are going to have to install a bunch of stuff anyway. Install Vim.

Re: Reasons To Give The Vim Text Editor A Chance

#68

Post by eropple »

jrockway wrote: post #64
eropple wrote: post #58

Earlier quoted context omitted.

Honest question (as I avoid Perl like the plague) - is there an introspective debugger on par with Visual Studio's in Perl-land? Because if you're leaning on print statements in absence of appropriate tooling, I can understand that. When the tooling is available, however, I am skeptical of claims as to enhanced productivity or any other positivity coming from it.

There's a way to get a good answer from someone, compare his language of choice to a deadly disease. And then ask if it's as good as some proprietary crapware. What does visual studio? Show the value of variables in separate windows as the code runs? Yes, the perl debugger can do that. You can also inject code and poke the entire program state. The perl debugger is a perl function that is called for every line and ev…

"Proprietary crapware." Yeah, that's the sign of a really well-balanced, competent developer.
Post reply on HN