6 ms·

"in the context of a non-trivial project, vi[m] offer no real gains, particularly when one considers timelines, code quality, bugs, costs, etc." "Give us, vi[m

"in the context of a non-trivial project, vi[m] offer no real gains, particularly when one considers timelines, code quality, bugs, costs, etc." "Give us, vi[m] neophytes, steps to follow in order to understand how one might do a specific task more efficiently " I believe this is the strawman that was being alluded to in the previous thread. Nobody is going around saying "Hey, if you don't use vim, you are producing less than I am!" Okay maybe some people do say that, but that's really not the reason people love vim. The real reason (in my opinion, of course) has to do with flow. It's hard to explain, which is why these discussions tend to digress. But when you're in flow, or the zone, you don't want things like your text editor to get in your way. You want it to be a harmonious extension of your intentions to the machine. When you connect with vim, that is what you get. Other people might get that connection with emacs, or some other editor. But for the most part, you just don't get it with editors that don't allow a rich communication vocabulary between you and the machine. Does flow matter on the scale of business deliverables within a project budget? Not really. It matters to the enjoyability of the creation experience that the programmers are involved in. They could probably still produce the work without that additional enjoyability, but less enjoyable work can sometimes lead to lower quality. And perhaps more importantly, it always leads to less joy. For the past several years I've been using a keyboard that doesn't require me to move my hand away from the home row in order to manipulate the mouse cursor. There's a similarity there in that it reduces flow interruption. I've recently started learning vim because I see this same potential in it. As for "recipes", there is a post here taken from the previous thread: http://www.viemu.com/a-why-vi-vim.html http://www.viemu.com/a-why-vi-vim.html

robomartin 14y ago
I am going to ignore the first part of your comment because, well, I asked that this thread not go that way. The problem with the other thread is that claims were made about vi efficiency and not one bit of data of any kind was provided to support these claims. Nobody learns this way. This thread is already very different as many have provided very interesting comments with valuable insight, including yourself. I understand flow very well of course. I can't say that I've ever used an editor that prevented me to enter that state. I a not countering your statement, just providing my own experience. Aside from programming I play the piano and classical guitar. When I play music I am in flow. That didn't happen until I had reasonable command of the instruments. With vi (or any other tool) the same is required. I wonder how much time it would take to go from vi neophyte to playing it like a piano? That initial phase is painful if you have to get work done. I also understand the value of playing a good instrument and using good tools. And, while this value may not provide any hard quantifiable benefits to the project timeline it does provide benefits for the practitioner. The project might still be six months late, but there will be more daily enjoyment, if you will, for the practitioner to remain on focus. That could have value. Whether or not there is a difference between someone who has never touched vi and a vi expert remains to be determined. The vast majority of programmers don't use vi. After reading your post and others on this thread my immediate reaction is that vi advocates might want to consider not characterizing vi as "more efficient" but rather highlight what it might do for a programmer. I can't come up with the words right now, but "more efficient", in my book, calls for having quantifiable data at the project level (not the file level). We all know that saving a few keystrokes here and there isn't going to bring a project to conclusion any sooner. We had a project where we spent six months tracking down a bug that was due to a rounding error someone made in a calculation of lookup-table data used in a polyphase FIR filter module. It was one of those things that was right in front of you but nobody could see it. The project was late by an additional six months (it was already late) because of that bug. That's the kind of thing I think about when I say that saving a few keystrokes on the editor doesn't matter in the context of a project. I'll read the article you pointed out and see what else I can learn. Thanks for your input and valuable insight.
- tysonjennings 14y ago
  You are one dedicated anti-vi troll. Seriously, bravo!
- aidenn0 14y ago
  I just think "efficient" is ill-defined. Nobody (or nearly nobody, I can't speak for everyone) that says vi[m] is more efficient is talking about project-level efficiency. They are talking about saving a few keystrokes (or more importantly a tiny amount of attention) when manipulating text. Manipulating text is just one part of writing software, but it's the part that developers want to spend the least amount of thought on, as it's (as you point out) not that important at the project level. Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by some, not because it leads to better software, but because it leads to better quality of life. And I stand by the statement that vi[m] is more efficient at manipulating text, while not disagreeing with you that it makes no difference at the project level.
  - robomartin 14y ago
    > Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by some, not because it leads to better software, but because it leads to better quality of life. And I stand by the statement that vi[m] is more efficient at manipulating text, while not disagreeing with you that it makes no difference at the project level. I can absolutely agree with you on that. Learning vi[m] in order to get to that level seems to be the hit lots of people are not willing to (or simply can't) take. In the context of a busy shop it makes almost no sense to bring productivity down to almost nothing while everyone has to slow down to learn a new tool (any tool, not just vi[m]). The only time one can justify this sort of thing is when there are real and measurable business or code quality benefits to the interruption. An example of that is sending everyone out to a one week course on a new technology. When they come back they absolutely rock. I've sent people out to take courses costing the company tens of thousands of dollars on more than one occasion. In every case it pays off within days. I can't say that about vi[m] yet. Not wanting to voice opinion from a context of ignorance I will spend time over the weekend to force myself to dive into vim and see what I can learn. Happy programmers, hell, happy people, are always more fun to work with and be around. If vi[m] can bring that to the table I have no problem promoting its learning and usage at our shop (when we can afford to take the initial productivity hit while everyone learns).

robomartin 14y ago

I am going to ignore the first part of your comment because, well, I asked that this thread not go that way. The problem with the other thread is that claims were made about vi efficiency and not one bit of data of any kind was provided to support these claims. Nobody learns this way. This thread is already very different as many have provided very interesting comments with valuable insight, including yourself. I understand flow very well of course. I can't say that I've ever used an editor that prevented me to enter that state. I a not countering your statement, just providing my own experience. Aside from programming I play the piano and classical guitar. When I play music I am in flow. That didn't happen until I had reasonable command of the instruments. With vi (or any other tool) the same is required. I wonder how much time it would take to go from vi neophyte to playing it like a piano? That initial phase is painful if you have to get work done. I also understand the value of playing a good instrument and using good tools. And, while this value may not provide any hard quantifiable benefits to the project timeline it does provide benefits for the practitioner. The project might still be six months late, but there will be more daily enjoyment, if you will, for the practitioner to remain on focus. That could have value. Whether or not there is a difference between someone who has never touched vi and a vi expert remains to be determined. The vast majority of programmers don't use vi. After reading your post and others on this thread my immediate reaction is that vi advocates might want to consider not characterizing vi as "more efficient" but rather highlight what it might do for a programmer. I can't come up with the words right now, but "more efficient", in my book, calls for having quantifiable data at the project level (not the file level). We all know that saving a few keystrokes here and there isn't going to bring a project to conclusion any sooner. We had a project where we spent six months tracking down a bug that was due to a rounding error someone made in a calculation of lookup-table data used in a polyphase FIR filter module. It was one of those things that was right in front of you but nobody could see it. The project was late by an additional six months (it was already late) because of that bug. That's the kind of thing I think about when I say that saving a few keystrokes on the editor doesn't matter in the context of a project. I'll read the article you pointed out and see what else I can learn. Thanks for your input and valuable insight.

tysonjennings 14y ago
You are one dedicated anti-vi troll. Seriously, bravo!
aidenn0 14y ago
I just think "efficient" is ill-defined. Nobody (or nearly nobody, I can't speak for everyone) that says vi[m] is more efficient is talking about project-level efficiency. They are talking about saving a few keystrokes (or more importantly a tiny amount of attention) when manipulating text. Manipulating text is just one part of writing software, but it's the part that developers want to spend the least amount of thought on, as it's (as you point out) not that important at the project level. Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by some, not because it leads to better software, but because it leads to better quality of life. And I stand by the statement that vi[m] is more efficient at manipulating text, while not disagreeing with you that it makes no difference at the project level.
- robomartin 14y ago
  > Being more efficient at manipulating text means less energy spent, which makes for happier programmers. So the more efficient text-editing is preferred by some, not because it leads to better software, but because it leads to better quality of life. And I stand by the statement that vi[m] is more efficient at manipulating text, while not disagreeing with you that it makes no difference at the project level. I can absolutely agree with you on that. Learning vi[m] in order to get to that level seems to be the hit lots of people are not willing to (or simply can't) take. In the context of a busy shop it makes almost no sense to bring productivity down to almost nothing while everyone has to slow down to learn a new tool (any tool, not just vi[m]). The only time one can justify this sort of thing is when there are real and measurable business or code quality benefits to the interruption. An example of that is sending everyone out to a one week course on a new technology. When they come back they absolutely rock. I've sent people out to take courses costing the company tens of thousands of dollars on more than one occasion. In every case it pays off within days. I can't say that about vi[m] yet. Not wanting to voice opinion from a context of ignorance I will spend time over the weekend to force myself to dive into vim and see what I can learn. Happy programmers, hell, happy people, are always more fun to work with and be around. If vi[m] can bring that to the table I have no problem promoting its learning and usage at our shop (when we can afford to take the initial productivity hit while everyone learns).