3 ms·
One (planning) results in efficiency gains that are far more significant than the other.
by robomartin 14y ago
One (planning) results in efficiency gains that are far more significant than the other.
- sofal 14y agoYeah, 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.
- 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.
- jlgreco 14y agoWhat I said: "As if the two are mutually exclusive..." Emphasis added.