5 ms·

> 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

by Freaky 14y ago

> 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?

robomartin 14y ago
Bad comparison on my part at some level. 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.
- jlgreco 14y ago
  > My efficiency comes from planning, not counting keystrokes. As if the two are mutually exclusive...
  - robomartin 14y ago
    One (planning) results in efficiency gains that are far more significant than the other.
    - sofal 14y ago
      Yeah, but the efficiency gains are not mutually exclusive. Why would you think they are?
      - robomartin 14y ago
        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.
        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 ago
        Here'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 ago
      What I said: "As if the two are mutually exclusive..." Emphasis added.

by Freaky 14y ago

robomartin 14y ago

Bad comparison on my part at some level. 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.

jlgreco 14y ago
> My efficiency comes from planning, not counting keystrokes. As if the two are mutually exclusive...
- robomartin 14y ago
  One (planning) results in efficiency gains that are far more significant than the other.
  - sofal 14y ago
    Yeah, but the efficiency gains are not mutually exclusive. Why would you think they are?
    - robomartin 14y ago
      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.
      - 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 ago
        Here'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 ago
    What I said: "As if the two are mutually exclusive..." Emphasis added.