5 ms·
Yeah, but the efficiency gains are not mutually exclusive. Why would you think they are?
by sofal 14y ago
Yeah, but the efficiency gains are not mutually exclusive. Why would you think they are?
- robomartin 14y agoBecause 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.
- jlgreco 14y ago> "efficiency gains from the use of vi/vim are insignificant in the context of a non-trivial project" They are important to programmers. You are arguing against a strawman that I suspect you do not even realize you have constructed.
- robomartin 14y agoHere's opinion from the horse's mouth: <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. Let's just agree to disagree and move on.
- jlgreco 14y agoEditing 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.
- robomartin 14y agoUnless 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.
- jlgreco 14y agoThis 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.
- robomartin 14y agoThat 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: http://news.ycombinator.com/item?id=4145060 http://news.ycombinator.com/item?id=4145060 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).
- kamaal 14y ago>>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.