> The damn text box I am using in this browser to enter this comment is far more user-friendly than VIM.
Either you're a terrible Vim user or you have a pretty awesome browser text box. I had to install a third party browser extension just to make the damn thing resizeable - woe is me if I want to do search/replace, indent anything, or do anything but the most trivial undo/redo operation. And who hasn't permanently lost stuff they've written into a form by hitting the wrong key?
Yes, I am a terrible VIM user. I have far more important things to do than to get good at using modem-age text editors. My efficiency comes from planning, not counting keystrokes.
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 the estimate is weeks, it might take months. If it is months, it might take a year or more. In that context, arguing that a text editor will make everyone more efficient is just silly. Get my damn project done on time BECAUSE you are using vi/vim and then I'll drink the cool-aid. Until that happens I will continue to believe that the use of vi/vim is just tribal behavior rather than these tools offering any real business value in the context of a project's timeline, maintainability, quality of code and bug density.
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. I suspect that this is not the case.
>>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.
<start quote>
Back in 1999, the mag asked Joy what inspired him to write vi:
What happened is that Ken Thompson came to Berkeley and brought this broken Pascal system, and we got this summer job to fix it. While we were fixing it, we got frustrated with the editor we were using which was named ed. ed is certainly frustrating.
We got this code from a guy named George Coulouris at University College in London* called em - Editor for Mortals - since only immortals could use ed to do anything. By the way, before that summer, we could only type in uppercase. That summer we got lowercase ROMs for our terminals. It was really exciting to finally use lowercase.
So we modified em and created en. I don't know if there was an eo or an ep but finally there was ex. [laughter] I remember en but I don't know how it got to ex. So I had a terminal at home and a 300 baud modem so the cursor could move around and I just stayed up all night for a few months and wrote vi.
Linux Mag then asked: "So you didn't really write vi in one weekend like everybody says?"
No. It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.
9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore.
<end quote>
This is from Bill Joy, who wrote vi. The last line is very much on point and mirrors my point of view: "Now that computers are so much faster than you can think, nobody understands this anymore."
Also: "I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem."
If one was given the task to write a text editor today, even one without a GUI, I would be surprised if anyone reached for some of the things Bill had to do in the context of 300 baud modems and a terminal (not window, but physical).
In the context of large projects vi/vim don't offer any real measurable gains. The fact that programmers who take the time to learn these tools feel good about them does not constitute proof of anything other than that fact.
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 impression that when people talk about editing efficiency that they are meaning to imply business efficiency. This is what I was saying when I said you have constructed a straw man.
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 offer quantifiable data, but programmers who know
it swear by it and talk about how much more efficient
it is."
MGR: "It only makes sense to me if you can prove and
guarantee that switching from our current text editor
to vi/m will result in true and measurable productivity
and quality gains. Otherwise there's nothing in what
you are saying that justifies changing over."
Big difference between hobby and business.
Boy, does one have to have a thick skin to voice contrasting opinion on HN sometimes.
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.
And yet, the only thing you know about me is that I am not willing to grind my team of over ten programmers to a halt just to have them learn a tool (any tool, not just vi) that offers no quantifiable code quality or project-level productivity enhancements at all. By some accounts on other threads, mastering vim isn't a one-week stint, it could take weeks.
If you are saying that, in your own business you make decisions that would bring your entire team to almost an absolute without solid business or product quality justification. Well, more power to you. Live long and prosper.
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 why some are so passionate about vi. Here it is:
If those who post to this new thread stay within the proposed framework what will come out of it is a set of recipes that show (and support) the claims about vi efficiency. I hope you will be one of the first to join that thread and offer a few examples. There are many who know absolutely nothing about vi. Some have avoided it like the plague. And then, those like me, who only use it when absolutely forced to. This is an opportunity to educate all of us. Thanks in advance. I think it is safe to say that this thread is over (save those who want to talk about the foot-pedal).
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.
I am in complete agreement with everything you said.
I too have had to administer and support remote systems where vi was the only viable way to edit config files and the like. And, much like you, if I could, I would go for bringing the files into my local system for editing with a non-vi editor (a secondary reason being that if I screwed something up by accident I wouldn't take down a system).
In over twenty years of programming my intersection with being forced to use vi was never frequent enough to warrant spending the time to get good at it. None of my work suffered for it, of course. In my current business nobody uses vi and we get quality work out the door like anyone else. And, I should say, without the need for foot-switches :) --had to throw that in for a little dose of levity.
Either you're a terrible Vim user or you have a pretty awesome browser text box. I had to install a third party browser extension just to make the damn thing resizeable - woe is me if I want to do search/replace, indent anything, or do anything but the most trivial undo/redo operation. And who hasn't permanently lost stuff they've written into a form by hitting the wrong key?