Hacker News new | comments | ask | show | jobs | submit login
Vim speed is not really the point (wrongsideofmemphis.com)
55 points by jaimebuelta on Mar 27, 2013 | hide | past | web | favorite | 62 comments



I'm a huge vim fan myself, but I haven't thrown IDE's out of the window entirely.

There are still 2 things that I can't give up that IDE's do better than vim (in my opinion):

1. Refactoring operations. I have yet to find a vim plugin that has the extreme refactoring awareness I've become accustomed to in IntelliJ IDEA and Eclipse. And writing a macro to do it for you is not the answer, because these tasks are non trivial to do a.) correctly, b.) in the general case, and c.) across an entire codebase. There's a reason people have sunk a gazillion years and R&D dollars in to creating IDE's, and some bullshit vim macro that I put together mid-day on a Thursday because I need to extract a method isn't going to compete.

2. Super-powerful auto completions. I get that vim has code completion plugins, and most of them are good (I'm currently using YouCompleteMe). But they aren't great. IntelliJ has it's legendary "index the world" mentality, and is really great at fuzzy match finding. Eclipse is a little clunkier, but its ability to drop in the entire method signature and provide tab-stops for quickly filling in the parameters is a boon.

The majority of my bias towards these features probably comes from the fact that I write Java code for a living at my day job, where the "documentation" is actually the code completion popup 90% of the time and most file operations or refactors are accompanied by some degree of boilerplate that is handily automated. Say what you will about verbose code and "enterprise" languages, but learning an API as you go by mindlessly mashing Ctrl+Space and skipping the inheritance/implementation rain dance is a huge productivity gain.

I do all of my C/C++, Haskell, HTML/CSS/JS, and Ruby in vim, where I have a pain-stakingly customized pathogen setup that I sync across all of my computers (personal and work). Code completion is good enough, between YouCompleteMe and ctags, but I still miss refactoring something fierce. But if FP Complete releases their Haskell IDE tomorrow and it isn't completely offensive to look at (Leksah!), has good refactoring, and has good code completion, I'd jump ship in a heartbeat.

I don't think that the whole IDE vs. vim/emacs war is real. I think that they're two completely different tools that are good at very different things; I will not argue that I am way, way, way faster at just editing text in vim; EasyMotion, ctags, never having to use a mouse... I love these things. But anybody that writes off an IDE without fully understanding just how powerful the two features I mentioned above can be when dealing with multi-million loc codebases is being narrow minded.


So, some languages demand some tools and other languages demand more complicated tools?

I'd rather have a language that didn't demand lots of tooling. Lots of tooling is expensive, unreliable and a time sink.

Which is why I like vim (and have used it for 16 years) :)


People have sunk a gazillion years into vim and its plugins. Java needs an IDE to achieve productivity because of the way that language is designed - this doesn't mean a big productivity boost in other languages. Anybody that writes off vim because it's free or because Java specifically needs something like IntelliJ is being narrow minded.


ITYM Java can take advantage of an IDE because of the language design, so you don't have to hack together scripts to do things like re-signature a method across a 100-person billion-dollar product, whereas other languages make refactoring a pain regardless.


You're both right. Java can take advantage of an IDE, but as a result is unusable without one.


I love Python but I reject the view that for dynamic languages IDEs wouldn't be as useful. I'd love to type "os." or the name of an instance and get great Java-like completion.

Many times I have thought that len was a method on any string...


Supposedly you can get this functionality from emacs jedi mode[0], although its a pain to set up; I have never gotten it to work properly.

[0]: http://tkf.github.com/emacs-jedi/


Incidentally, today I decided to Pimp My Vim and installed a whole slew of plugins and spent an hour screwing around with my .vimrc.

Jedi seems to work as intended, but it crashed occasionally so I uninstalled. I'm fairly certain that if you really want autocomplete, you can get it working with vim.


Did you try ipython?


Do you mean an enhanced repl for testing little bits of code? Or is it something more these days...

Its helpful, but not the same thing!


Both of those are in my use case outright impossible given the dynamicity/duck-typing-ness level of the code I operate with (Python, Ruby), where the editor has no freezing chance in hell of guessing what might come out of this variable (unless maybe if the editor is the runtime and everything is live... smalltalk!)

This is why for me "free-form refactoring without relying on fixed-form refactoring routines and plugins (i.e not just a glorified search and replace)."[0] (which is a comment by myself made 6 days ago, that actually makes the same point as TFA) is extremely important.

As for discovery through autocompletion, I find my need for it has been greatly reduced these last years, with a growing number of APIs that "make sense", hence discovery happens in your head, not on the screen. If the API is obtuse to the point it doesn't fit in my head, then I usually need the doc so I'll have it open nearby anyway.

[0]: https://news.ycombinator.com/item?id=5414050


You might be surprised at this. I've used the Python tools for Visual Studio and it has some type awareness; I think perhaps what it is doing is capturing the type of a variable at runtime when you execute your program and using that while you are coding. In either case, intellisense works quite well (though not when you first introduce a new variable). I've also used RubyMine and it has some pretty nice inspection features; it will highlight issues such as parameter agreement, unused locals and many other things. It is not like a static language but still quite helpful (and never unhelpfully wrong).

I use the VSVim plugin in Visual Studio and IDEAVim in IDEA/RubyMine and they work great (ideavim is kind of lame as it has no real keymap support, but its better than nothing).


But anybody that writes off an IDE without fully understanding just how powerful the two features I mentioned above can be when dealing with multi-million loc codebases is being narrow minded.

Yes! This is the crux of the confusion. Working with a multi-million LOC codebase is a very different problem than a 10,000 LOC codebase. Java+IDE is better for the former; dynamic language + text editor is (usually?) better for the latter.

When people voice angry opinions about static vs dynamic languages, and IDE's vs text editors, they should preface with how many lines of code are in the typical projects they work on. It just changes your working assumptions.


This is a self-perpetuating problem. It should be rare that one project has multi-million lines of code. But when your tools are oriented toward making huge balls of mud and your philosophy is oriented toward making huge balls of mud, you will make huge balls of mud. Somehow you will even make it some kind of virtue to work on huge balls of mud, as if people who don't are amateurs whose opinions don't matter...


"when your tools are oriented toward making huge balls of mud and your philosophy is oriented toward making huge balls of mud, you will make huge balls of mud"

New sig for me on forums ; )

Paraphrasing Rich Hickey: everytime you're using a "pattern" and have your IDE generate code for that pattern for you, then it means: "I have run out of language" : )


Please share how many billion users generating many billions of dollars you are serving with your elegant tiny project.

Bonus points if you use Heroku/EC2 or AppEngine and ignore the "giant ball of mud" that is a critical reason your business was able to launch.


I work between Emacs and IntelliJ pretty seemlessly. Bread and butter editing is done in IntelliJ, which has Emacs keybindings that I've tweaked to match my Emacs customizations (generally after the recommendations of Steve Yegge). But then I can drop into Emacs for the same file and line when I need to do more heavy duty transformations. Here's the IntelliJ setup:

File > Preferences > External Tools

Program: /Applications/Emacs.app/Contents/MacOS/Emacs

Parameters: +$LineNumber$ "$FilePath$"

Working Directory: /Applications/Emacs.app/Contents/MacOS

Then I map a key to open this (Cmd-E)

On the emacs side, I have the following to pick up changes to an open buffer that were made in Intellij

(global-auto-revert-mode 1)


For C# auto completions/intellisense, I've found Omnisharp works quite well. https://github.com/nosami/Omnisharp


Are there no good vim extensions for IntelliJ or Eclipse?


For me one of the draws to vim isn't vim in its bare state, but vim with my plugins of choice, and I have yet to find a vim emulation plugin that loads the vim runtime, with the exception being eclim for Eclipse; unfortunately, the vim-mode for eclim is just vim with a janky plugin, and the embedded mode doesn't work on OS X because MacVim can't be embedded the way vim-gtk can.


There's a good one for IntelliJ called IdeaVim.

I tried solutions for Eclipse back when I used it, but I couldn't find one that I liked.


When I was using eclipse, I found VRapper[0] a decent enough vim plugin. I also agree with you about IdeaVim, it's a good vim, and it's been open-sourced[1].

[0]: http://vrapper.sourceforge.net/home/

[1]: https://github.com/JetBrains/ideavim


Well, you could try to use NetBeans with the vim plugin instead. The ability to use vim, plus the undocking windows, are what made me switch from Eclipse to NetBeans.

Got tired of tiled windows crowding each "perspective", and constantly reaching for the mouse.


If I cannot use vim's : commands or plugins, then merely implementing a few keybindings like hjkl is worthless to me.


That would be the world backward: it's like when IntelliJ or Eclipse do offer Emacs shortcuts (Emacs shortcuts being the stupidest things ever invented --and this comes as a long time Emacs user), completely missing the point.

BUT there's light at the end of the tunnel: there's eclim (eclim.org), which allows you to use vim (the real one) as the text editor for Eclipse. Or if you want you can run Eclipse in headless mode and then have vim transparently contact the (local) eclim server and suggest you, right in your vim, the autocompletion hints from Eclipse etc.


I used to use Eclipse before switch to vim definitely. My memory skills have been improving a lot since.


One advantage to not having good refactoring support is that it encourages automated testing.


I learned to code on a broke-down Apple II, which crashed every 10 to 20 minutes. The advantage of coding on a broke-down Apple II is that it encourages you to save and back up as frequently as possible.


I guess if the dev in question is super lazy. Even with great refactor support, I never begin a refactor until the code I want to touch is covered by a test case.


So in other words: it is not the speed, it is the latency. I can agree with that.

As an aside...I always sucked at the speed part. I have always been a 2, maybe 3 finger typer, throwing in a pinky for CTRL and a thumb for the space bar. While my vimming is pretty fast, typing long segments is embarrassingly slow. Have any of you overcome this after > 10 years of bad habits? How did you do it?


You do realize there are actually courses in a technique called touch typing? Fortunately, it won't clash with your bad habits. I can hunt and peck on mobile keyboards yet my brain uses a whole different part of my memory to keep my touch typing sharp and untainted from the lazy use of iOS' autocomplete, never confusing the two.


I don't have the problem with needing to watch my hands press the keys. It is more that my hands hover needlessly high above the keyboard because the fingers need to move more.


Typing with 3 fingers is not touch typing, even if you don't look at the keys. Lean to touch type.


Get a rhythm going, so you type at a steady pace (slow at first, of course). Say each letter out loud. H-A-C-K-E-R space N-E-W-S period

Don't look at the keyboard, either. Just practice this for a little bit every day (re-type a blog post or two, including the source code) and you'll get the hang of it.


I was an 80WPM 3 finger typed after typing a ton playing runescape as a kid. After being forced to take two years of formal typing class, I became a 120WPM standard typist. I only had 2 or 3 years of bad habits to break, though.


Is it possible to force yourself to start from home row and not look at your fingers (e.g. put a blanket over)?


"Have any of you overcome this after > 10 years of bad habits? How did you do it?"

I had a secretary handing my arse to me... So after ten years of bad habits I decided to learn the proper way. She showed me the basics (which are really super trivial: it's so easy that a five minutes YouTube video about how to touch-type should get you started) and then... Practice. Practice. And practice.

And I did buy a split keyboard (warning, there are two schools concerning where the '6' is located and there are even very rare split keyboard who very intelligently did put the '6' on both the left and the right part of the keyboard, so that everyone's happy : )

Buying a split keyboard kinda helps.

After three months I was back at the speed I was before. Then I started typing faster.

It's not so much about the speed: it's about the economy of hand and fingers movement too. I'm sure it's better from an RSI standpoint.

You need to force yourself and keep your eyes on the goal: become faster than before.

Don't mind the obstacles: the very beginning is going to be the most painful.

Buy a real keyboard too: my keyboard / chair / monitor are my physical tools which I use all the time. I spent $$$ on them.

Now the issue is that a good split keyboard is very expensive. ANSI Cherry MX 5000 go for about $500, split IBM Model M15 will settle you a good $1000 to $1500, etc.

Junk like the split MS ergo 4000 have a nice shape but are, sadly, using super shitty rubber dome keyboard.

If you spend your life typing on a laptop then you're destroying your fingers' joints with the ultra-low profile scissor switches.

I'm using a HHKB Pro 2 on my workstation and I hook it to my laptop. Topre switches. Amazing stuff for about $300.

Now that I know how to touch-type I don't really care about my keyboard being split or not.


I'll have to read up on split keyboards a little more. It might be the push I need to stop for good. Practice seems to be the answer, but it is just too hard to remember when I'm typing a large amount.


This is definitely a good way to explain the appeal of vim, but this is exactly what IDEs let you do.

In intelliJ: oh I need to introduce a new parameter here, cmd-f6 -> add a new parameter, set a default and it does it across the entire codebase.

Another key press and it runs all the tests again.


Agreed. It's all about 'declarative' editing. I want to be able to declare my action and let editor take care of the 'details'.

But, IntelliJ (or Resharper which I use) is only good for the language they are written for. There are quite a few times where Resharper doesn't have what I am looking to do OR I am working on language/text where there is no Resharper or equivalent [especially for dynamic languages]. In such cases, Vim is a god send. And the best part is that once you know the Vim language, it can be used to edit any text (programming or non programming).


Really hoping for the day that editor-independent intellij-like functionality for all popular languages is available.. like Yegge told us he wanted to do.


Doesn't the menu of possible code transformations become somewhat large after a while? See also the comment somebody made here about the problem of huge code bases. (I understand that these are usually inherited, rather than created, but they are still a problem, not a virtue)

Does the IDE have a menu item / command to move 3 lines up into the end of this if/else block?

There are 2 ways to look at this problem, specialized IDE vs generalized editor. Both are right, at times. (I personally like to use the vim plugin within NetBeans)

Oh, example of moving the lines just after an if/else into the block:

(assuming sitting on the first line of to-be-moved text, which is just after a close-curly or end line)

Delete the 3 lines: 3 d d

Move back up 2 lines: k k

Paste the 3 lines: p

Indent the 3 lines: 3 > >

9 keypresses, no reaching for the right side of the keyboard, let alone a mouse. About is fast as you can think it, the block of lines disappear, the cursor moves back to the new block, the lines reappear, and then slide right. (ignoring the clumsy autoformat that most IEDs, er, IDEs want to inflict upon your code, I'll do the indent myself, just 3 keypresses)


"...add a new parameter, set a default and it does it across the entire codebase."

OK but why exactly does a new parameter with a default need to be repeated at different places across the codebase? Because you're using Java and Java is incredibly verbose and requires you to do crazy stuff and you end up with a super-complected codebase where instead of passing messages around you're actually telling objects "do this", "do that" and then when you have one parameter to a method you're in a world of hurt (because that method is used from different parts of your spaghetti codebase).

In Clojure, for example, you'd simply pass the parameters in an associative array (a map) and, even better, when you're constantly passing through the same set of parameter you'd simply wrap the method + its common parameters in a higher-order function and then you pass that higher-order function order. This makes for incredibly shorter codebases and incredibly easier refactoring.

Don't get me wrong: at 75% off during doomsday I did buy my IntelliJ IDEA licence but you're foolish if you think that the "text editor" part of IntelliJ is anywhere near close what vim or Emacs do offer you.

Also what's really great about Emacs is that you can add functionalities yourself to the "editor". Wanna run unit tests automatically and see the result in another frame/window/buffer? That's trivial to write.

No later than yesterday I missed IntelliJ's "goto declaration..." feature. I wrote a quick defun in elisp that had... Seven lines of code and did 90% of the job. Sure people are going to hard that it's for those 10% cases where my script doesn't work that IntelliJ really shines but that's not the point. The point is that you can program Emacs to suit your way of working.

You adapt vim / Emacs to yourself. With Eclipse / IntelliJ you have to adapt yourself to the IDE.


The real power of vim is its proven staying power. It is worth the investment to learn it. It's been around for a long time and is likely to be around for much longer. Newer, hip editors that depend on one person or small company to make a living maintaining their product cannot provide such assurances. Some have suggested open sourcing the application, but I am not sure that has worked for Text-Mate 2.

Vim has been around, will be around, and is available pretty much every where and has a giant community. That's the point.


you can replace vim with eclipse and all you said still stands valid.


To add some figures: * vi is 36 years old, vim is 21 years old * Eclipse is 12 years old

vim is on pretty much every linux box. Eclipse isn't.


it is on mine and it's all that counts. unless what you mean is that it doesn't work without an X session on remote hosts, but in general I don't work on live code.

'The real power of vim is its proven staying power' is a non-argument, today I work on stuff that didn't even exist 10 years ago, there is no guarantee vim will be even usable for the sort of work you will be doing in a decade, and for sure there is no guarantee it will be the best choice. both vim and eclipse are here to stay for the next years and both have a lot of support.

there are lots of reasons to learn/use vim, but a 10 years longer historical consistency isn't one.


But it should be! Imagine how productive you would be with an edipsesudo instead of visudo :)


How many Linux boxes do you spend >10hrs coding on in a year?


It's probably worth getting familiar with Eclipse, but it wont be on your ubuntu-server when you ssh into it.


I know, see my other comment in this tree. we are getting a bit off track with this, but since we are here, what is it with the arguments about editing live code on a server? source control + continuous integration + configuration management = never again touching live code on the server (unless in serious panic mode). editing code on an ssh session is not how I imagine my desired workflow to look like, to be honest I wish anyone doesn't have to do that.

btw, I know vim is amazing. I'm arguing the arguments, not the case.


you probably shouldn't, but if you needed to, it would be there for you


Sometimes, the IDE way of doing things seems to assume that your project is one of the "lifetime employment" variety -- that this is the only project and/or language you will ever work in the rest of your career, so you can take an "infinite" amount of time and setup customizing operations to just that one language and project, vs get in, hit hard, get out and move on.


> I was also forcing myself into improving my usage.

I can understand that people "force" themselves to go to the gym because there are obvious benefits to it, but I keep wondering why developers "force" themselves to use Vim. It's like playing and mastering a very hard videogame, except it's not a game and it's not that much fun to learn.


I like to think there are obvious benefits to Vim, too. Why do developers force themselves to touch-type? Because hopefully it will increase your productivity, in the long run.


Except millions of people do master very hard videogames, which has little benefit once you stop playing that game. Vim is a game I keep on playing eight plus hours a day throughout the years (at my day job then on my side projects.) Oh, and I find it a lot of fun to force limitations to improve my usage. Maybe you should only really get into vim if you find the whole thing fun in the first place.


Don't know for the OP, but for me discovering vim corners is fun, just as some videogames, except it is actually useful. Reading a vim tutorial is like reading a game walkthrough.


Well, like learning anything new, it has a point where is simply more comfortable to go give up and go back to the old way of doing things...

You can also say the same thing about playing an instrument. It is hard, and at the beginning you can't get any pleasant sound of it. You have to stick to it a little, keep practice, and everything starts working eventually!


I'd see it as akin to "forcing" yourself to learn a foreign language. You might think it is worthwhile but at the same time not find it a pleasant process.

(I'm of course not implying that everybody will find either of those tasks unpleasant).


It's a power tool, not a game. Realistically it isn't much harder than completely learning Eclipse. If you are only learning editors for fun, you are weird.


I rolled my own 'text editing version 2.0' with an eye toward both speed and logical commands for ease of use (and to ease the mental demand).

At first I found that the speed and ease allowed me to code faster and longer. Later I realized I was making mistakes more often, because of how little thought I needed to put into editing. I think there is a fundamental limit to how fast I can get ideas from my brain into code, and the limiting factor has never been my input method. I still prefer working with an advanced input system, but I now treat it the way the OP does: like a Samurai with his sword. Sit back, relax, think, then strike. Afterward take a moment to read over what just happened and make sure it is correct.


Is this a reason to do things awkwardly, that it is slower to do it awkwardly forcing you to think more? If so, where does this reasoning stop? Should editors intentionally make things awkward?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: