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

Vim clutch

github.com

Post reply on HN
Print view View original

201–210 of 227 posts

Re: Vim clutch

#201

Post by kamaal »

robomartin wrote: post #167
sofal wrote: post #162

Earlier quoted context omitted.

Yeah, but the efficiency gains are not mutually exclusive. Why would you think they are?

Because I am arguing that the purported efficiency gains from the use of vi/vim are insignificant in the context of a non-trivial project. Far more time can be gained (or lost) through activities that have nothing whatsoever to do with text editing. As an optimization problem, text editing is the wrong aspect of creating a software product to focus on. Software projects are notorious for being way behind schedule. If…

>>If you can point to a single project that was done on time and without bugs because it was edited on vi/vim then you have a point.

Software projects are late on schedule for reasons nothing to do with typing speed. Learning text editing is only important for you to make comfortable while you are doing other important tasks.

In other worlds like Java, Intellisense and auto-complete rule the world. You can't do any work sanely without those two things. In fact not knowing them might cause a delay in delivering projects. Using them only brings you on plane with other Java developers. Its a need not an advantage.

Re: Vim clutch

#202

Post by kamaal »

robomartin wrote: post #187
jlgreco wrote: post #180

Earlier quoted context omitted.

Editing efficiency, which is what everyone else here is talking about, is (I suspect), completely unrelated to business efficiency (which seems to be what you are primarily talking about). Your Bill Joy quote is talking about editing efficiency. I do not suggest that editing efficiency has a measurable impact on business efficiency, and I do not see anyone here suggesting that it does. You seem to be under the impres…

Unless your programming is a hobby, then it IS business. It sure is to the guy paying the bills. Imagine a conversation like this: PROGRAMER: "Hey, boss, on Monday we want to switch to vi/m because everyone says it is more efficient". MGR: "Do you have any data to support that? Will the project get done on-time, on-budget, faster, better and with less bugs?" PROGRAMMER: "Well, I can't guarantee any of that and can't…

Deciding to use an editor is not an event but a process. Its making gradual investments over time, those investments make you productive.

If you are a manager, its worth your time to study tools that help you manage things better. If the best managers in the trade say a particular tool 'x' helps them be productive, then its worth your time to learn that tool. Can you justify minor leaks in productivity while you are learning it day to day. May be no on the shorter run, but the productivity gains over time are going to be so drastically huge its going to be totally worth your time.

If this manager goes to his senior manager and explains all this, I believe the senior manager would understand this. Else these so-called managers are not managers. But glorified desk-supervisors, whose only job is pushing buttons on the blackberry.

Re: Vim clutch

#203

Post by cobbal »

pooriaazimi wrote: post #5

Very nice. But why put something like this on GitHub?!!

Another benefit of hosting something like this on GitHub is you get instant scaling in case you hit the front page of HN (or similar sites) and suddenly get thousands more visitors than some blog software can handle.

Re: Vim clutch

#204

Post by eraldcoil »

gte910h wrote: post #138
robomartin wrote: post #109

I'll be the one voicing a contrarian opinion here. vi and vim are holdbacks from the days of 300 to 9600 BAUD modems. A time when more sophisticated interfaces were prohibitive. Back in those days it wasn't too uncommon for people to actually write their own text editors. I wrote a few, mainly in Forth, as I would bring-up self-designed systems. While I use VIM today when I have to I continue to think that in today's…

Vim when you're learning feels like this. Vim when you're using it with 3-5 buffers, some specialized, on screen with lots of plugins feels just like an ide or something like Sublime Text 2 Vim keybindings in Sublime Text 2 or Visual studio/outlook/word via ViEmu is pretty good in my experience.

Sublime Text with vim bindings coupled with zen coding plugin was pretty good for me when coding html/css, till the zen coding plugin appeared for vim.

Now vim has everything I need for coding html/css. To me vim just makes everything better from my experience, it made me more efficient, more faster at coding. Visual Studio with vim key bindings made me love the VS IDE as well haha.

Re: Vim clutch

#205

Post by hq1 »

dllthomas wrote: post #177
hq1 wrote: post #135

Earlier quoted context omitted.

Just :set relativenumber You won't have to count anymore.

Not really going to help you for 20h...

Difficult to disagree. However if you use 20h, you're probably doing it wrong and should use w/e/f instead.

Re: Vim clutch

#206

Post by kapranoff »

One thing that jumped into my mind when I was thinking about using pedals at the computer is a pedal to switch the current shell into «su-mode». So that commands will be run as root while I'm holding the pedal.

Sadly, I don't think it will be trivial to implement.

Re: Vim clutch

#207

Post by gnur »

tsm wrote: post #184
SiVal wrote: post #141

Earlier quoted context omitted.

For what it's worth, I remapped vim's navigation keys from the awkward hjkl to the normal inverted-T arrangement i,j,k,l. Then I remapped the inserts, i & I, to h & H. With that, my natural finger movement on the arrowkeys and on the vim home row match each other. The reason vim's navigation keys (hjkl) today are arranged the way they are, left-means-down and right-means-up instead of up-means-up and down-means-down,…

People always treat hjkl as the single biggest roadblock to vi(m) adoption, and I don't get it. Two points: * First and foremost: If you rely on hjkl, you are doing it wrong anyway . You should be using f, w, ), :n (for integer n), ^d, ^f, etc. My biggest hjkl use case is using j to idly scroll through a file (or less/more/man page), in which case it's conveniently under my index finger and I love it. I also use l fo…

I agree, and getting used to using j/k for up and down also offers the advantage that a lot of web apps are supporting it recently. It is in gmail, google+, github, google reader and probably more, having the habit of using j/k for navigating really helps.

Re: Vim clutch

#208

Post by 9diov »

robomartin wrote: post #123
devth wrote: post #112

Earlier quoted context omitted.

I think you're missing the point that many developers choose vim over "modern" editors because of its highly efficient text-editing capabilities. The same points could be made about emacs. As to "user friendly" - depends on who the user is. Yes, this text box is infinitely more user friendly than vim when your mom is using it. That a foot-pedal might make vim more usable has nothing to do with vim being outdated or u…

OK, I'll bite. Please educate me. Give me a list of the "highly efficient text-editing capabilities".

Seeing is believing. Here is a video of an experienced Vim user: http://vimeo.com/8569257 . Note that the video is not sped up.

Re: Vim clutch

#209

Post by mgkimsal »

robomartin wrote: post #196
jlgreco wrote: post #193

Earlier quoted context omitted.

This is hopeless. You clearly have no interest in understanding what others are trying to sayto you. You came here to flame and it seems that is all you wish to do.

That is simply not true. Not one person has offered any data to support the assertions on vi efficiency. Not one. All I have gotten are the equivalent of "because we say so". I am not flaming, I am not caving-in to the bullying, which is a different matter entirely. In the interest of being constructive I decided to clear the bad blood and start another thread that is designed to educate us who might not understand w…

I suspect there never will be data, because there's too many variables (including developer skill levels), that measuring 'efficiency' of an editor is a pointless exercise.

I use vim sometimes locally, but almost exclusively remotely, because the context I'm in at the time precludes using 'real text editors' - GUI apps that get installed and have menus and such. If I have to deal with files on a remote box (example: to edit config files), pulling them down to edit in notepad is highly inefficient. Vim is far more efficient - my own data over the last 15 years proves that to me, and generally to other people who watch me, and I say that as someone who really disliked ssh/vim processes - I preferred to pull down files via FTP, edit, save, then FTP up. But efficiency won over after experimentation.

But that's just one context. I use intellij, phpstorm, zend studio and visual studio for different types of editing, and those editors provide a wealth of other tools that make my editing far more efficient in those contexts (development, debugging, creation, testing, etc).

So "vim efficiency data"... likely never to happen, but "eclipse efficiency data" or "emacs efficiency data" won't happen either.

Re: Vim clutch

#210

Post by slurgfest »

robomartin wrote: post #149
robomartin wrote: post #140

Earlier quoted context omitted.

Your first personal attack was subtle: "I understand that you like to click through your menus" Now you resort to calling me a troll? That's nice. There's nothing unfriendly about a helicopter cockpit. Even if you've only played with flight simulators anyone half-way intelligent can probably figure out most of it within a few minutes. Flying one is a different deal, as mastering and understanding the complex relation…

As a follow-up to that. When I hire programmers I only care about how well they can reduce a problem to a viable game-plan and how clean and well-documented their code might be. I could not give a crap about whether or not they are 3% more efficient at pounding out keystrokes on a text editor. We waste far more time in other areas than in the mechanics of editing code. In other words, if editor efficiency is adequate…

"modem-era" is entirely irrelevant. If you have a case to make, it has nothing to do with WHEN something was designed. And it is certainly possible to tweak the keybindings of vim if you need to, it is one of the key features.
Post reply on HN