5 ms·

I'll be the one voicing a contrarian opinion here. vi and vim are holdbacks from the days of 300 to 9600 BAUD modems. A time when more sophisticated interface

I'll be the one voicing a contrarian opinion here. vi and vim are holdbacks from the days of 300 to 9600 BAUD modems. A time when more sophisticated interfaces were prohibitive. Back in those days it wasn't too uncommon for people to actually write their own text editors. I wrote a few, mainly in Forth, as I would bring-up self-designed systems. While I use VIM today when I have to I continue to think that in today's context these things are, well, ridiculous. There is no reason that the terminal can't switch modes on you and allow text editing with the same (or very similar) UI that traditional simple GUI editors provide. The damn text box I am using in this browser to enter this comment is far more user-friendly than VIM. There is no reason for a modern terminal to continue to support something like VIM. Put another way, I had editors running on 6502-based 2MHz clock (yes, 2 MEGA Hertz, not Giga) Forth machines that were far more user friendly than VIM or VI. We ought to have better tools today. In my opinion, there is no compelling reason to continue to promote something like VIM. Put a bullet in it already. As for the hack. Lots of fun. But, geez, how fucked-up is an text editor that you have to come-up with a foot-switch to make it more usable?

r00k 14y ago
The damn text box I am using in this browser to enter this comment is far more user-friendly than VIM. To the average user, sure; the text box is more friendly. But that's not the point with vim. At all. Vim's design goals are speed and efficiency. To date, non-modal editors haven't come anywhere near vim in that regard.
devth 14y ago
I think you're missing the point that many developers choose vim over "modern" editors because of its highly efficient text-editing capabilities. The same points could be made about emacs. As to "user friendly" - depends on who the user is. Yes, this text box is infinitely more user friendly than vim when your mom is using it. That a foot-pedal might make vim more usable has nothing to do with vim being outdated or unusable. Is your operating system broken / outdated because one might find a food pedal driving "alt-tab" more usable or fun?
- robomartin 14y ago
  OK, I'll bite. Please educate me. Give me a list of the "highly efficient text-editing capabilities".
  - sofal 14y ago
    Start here: http://www.vim.org/docs.php http://www.vim.org/docs.php
    - robomartin 14y ago
      That doesn't really answer the question, does it? The other poster made an assertion about VIM being more efficient. I would like to get a list from him (or her).
      - jlgreco 14y ago
        > I would like to get a list from him (or her). Why is an answer from sofal not acceptable?
        robomartin 14y ago
        Funny enough, not one person is stepping up to the plate to justify and quantify the claims that vi/vim are/have "highly efficient text-editing capabilities". Numbers. Not statements or links to the manual. I care about data. Show me a project that got done sooner and better because of the use of vi/vim and you'll have a point. I propose that not one person can make that claim and that the popularity of vi/vim are purely tribal. There's an interesting show on TV called "Head Games" (http://news.discovery.com/human/new-tv-show-plays-head-games-dnews-nuggets-120601.html http://news.discovery.com/human/new-tv-show-plays-head-games...). In this show they demonstrate, among other things, how tribal behavior can be taken to an extreme. It is very hard for some to go against group behavior. They show one example of a guy in a room that stands up when everyone else stands up and he doesn't even know why. To some extent I believe that some of these tools are like that. You work in a shop where the hot programmer swears by vi/vim and you adopt that without challenging any of it. Very soon everyone is playing the same tune, facts be damned. I happen to be one of those people that does not engage in crowd behavior. This can be a blessing and a curse. I never bothered to spend months on vi/vim because every time I used for days or weeks (out of not having other choices) I came out of it with the distinct idea that the whole thing was just short of lunacy. In the context of the project that needed to be completed these tools offered no real advantages. You are not going to impact the bottom line in any measurable way. Put another way: If you took two kids that knew nothing whatsoever about computers or programming and set out to teach them. One is taught with modern mostly-GUI tools with "conventional" keyboard shortcuts while the other has to use command line and vi/vim. Both of them have to complete the same project. The vi kid would be absolutely smoked by the other kid in no time at all. No question about it. OK, how about a second project. Maybe not smoked, but no significant gains would exist out of the vi camp. Programming is far more about things that have nothing to do with text editing. Projects are not late or buggy because of good or bad text editing tools. I'd still like to see someone quantify the gains offered by vi/vim over the course of a project.
sofal 14y ago
I don't think you'd find a military helicopter cockpit very "user friendly" either: http://www.helis.com/h/h53ecab.jpg http://www.helis.com/h/h53ecab.jpg We're talking about a general-purpose text editing tool used by experts for hours, days, and years on end. I understand that you like to click through your menus, but you'll have to excuse those of us who know what we're doing in vim and don't have the time or patience for that.
- robomartin 14y ago
  Who said anything about menus? And, yes, funny enough, it just so happens that I would find the cockpit of a military helicopter very user friendly.
  - sofal 14y ago
    With no justification of how you think a military helicopter cockpit is user friendly, I suspect you're just trolling now.
    - robomartin 14y ago
      Your first personal attack was subtle: "I understand that you like to click through your menus" Now you resort to calling me a troll? That's nice. There's nothing unfriendly about a helicopter cockpit. Even if you've only played with flight simulators anyone half-way intelligent can probably figure out most of it within a few minutes. Flying one is a different deal, as mastering and understanding the complex relations between collective pitch, power, torques and aerodynamics. As a simple example, it isn't immediately obvious that flying in ground effect is different from flying above ground effect. Or the interaction between collective pitch, the tail rotor and the demand for power. This is quite different from understanding what the knobs and dials in the cockpit might do. All of this from simply expressing a contrarian opinion on VIM. HN does have an unfortunate trait: If you say anything contrary to "tribal" beliefs you get pounded and sometimes brutally downvoted. That does not mean that the tribal belief is right, it just means that there are enough tribe members to bully others into either not participating or simply adopting the tribal memes and falling into compliance. Well, that's not me. If I believe that someone is bullshit you are going to hear it. Why do I believe that some of the hyper-keyboard-efficiency claims of VIM are bullshit? Because programming is not factory work. If a programmer is spending so much time at the keyboard that counting keystrokes becomes important they are not doing a good job. I spend far less time programming than I do planning and deciding how to solve the problem. I don't just sit down and start hacking away without direction. By the time I actually fire-up a text editor or IDE to program I have state diagrams, database structures and algorithms pretty much selected and reasonably-well thought out. If I've done such a shitty job at the pre-programming work that my text editor's keystroke count actually matters, well, I'm a hack, not a programmer. Some of the admittedly interesting things you can do with VI (http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 http://stackoverflow.com/questions/1218390/what-is-your-most...) are, in my opinion, somewhat of a corner case. These are things that one might not do with great frequency. The fact that you can do them is interesting, but that isn't going to be a deal breaker if you only have to do them once every few weeks or months. In some respects I can derive far greater efficiencies from using a tool such as Excel to sometimes cut hours of coding and formatting by using it intelligently to help generate code that is more maintainable. One such example is to use it to generate state machine lookup table code that can be copied and pasted into a text editor instantly. I've done state machines with hundreds of states this way. If you do it right they are easy to maintaing and update. No text editor can improve on this level of efficiency. Another very similar example is to use Excel to help generate JSON files from various tables and data. Easy to setup, maintain and modify. A simple copy and paste into an editor. When justified, I have taken the time to create more complex tools that automatically generate complex code based on database inputs. One example that comes to mind was a tool to automatically generate all of the code to manage a menu system on an embedded device consisting of an LCD display and a few buttons. Every time the menu structure or content was changed it took days to update the menu processor code. The tool took a month to create. Once in place, almost anyone could generate the code for an arbitrarily complex menu system within minutes. No degree of text editor efficiency can solve these problems. The point here is that, if I have to resort to counting keystrokes as a measure of programming efficiency then I have either reduced programming to factory work or I am so disorganized that I am spending a disproportionate amount of time typing crap that will have to be fixed many times over before it actually works. To beat the state machine example to death. In my case it is very rare that I have any bugs when I code state machines, even complex ones. Granted, I've been doing it for a while in both hardware (FPGA's, Verilog) and software applications. Regardless of that fact, this is because I do all of the thinking and planning ahead of firing-up the editor. The resulting code, generally speaking, works on first run. I've you've ever programmed a CNC machine manually (G-code) you understand this concept. You don't just stand there start hacking away. You take the time to plan it, do all the math, choose tools and verify the approach before you enter the code. If you don't, you'll learn the hard way. These machines are dangerous. I once made a programming error and had my Haas VF3-SS churn aluminum with a 3/4 inch roughing bit like it was butter. Amazing what something with that much power can do. I kept the fucked-up end-mill as a reminder of what not to do. A professor of mine, who introduced me to APL, took every opportunity to drive a point home. He said that data representation is one of the most important tasks in solving a problem. If you represent the problem using a flawed model it can take ten times longer to create a solution. He pounded that into us to the point that it became instinct. That's why I will never touch a text editor unless I know where I am going. That's my context. I also caution you and others when considering yourselves "experts" in any field. I learned a long time ago to never utter that word. One can be highly skilled in one particularly narrow area while being completely ignorant of other ideas. I certainly am. I am not just talking programming here. Having access to a larger context is sometimes very important. What makes sense in a myopic context might not make much sense when one is able to pull back to a different plane that covers other schools of thought. Be open minded. Now, if it makes all of you really happy, down-vote away. It's always fun to watch the tribe in action.
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.
gte910h 14y ago
Vim when you're learning feels like this. Vim when you're using it with 3-5 buffers, some specialized, on screen with lots of plugins feels just like an ide or something like Sublime Text 2 Vim keybindings in Sublime Text 2 or Visual studio/outlook/word via ViEmu is pretty good in my experience.
- robomartin 14y ago
  Sublime Text looks interesting. I am going to check it out. Thanks.
  - gte910h 14y ago
    I haven't been using it very long, but the vibrant plugin community (make sure you get BOTH vim plugins) and intelligent shortcuts make it feel like a winner.
- eraldcoil 14y ago
  Sublime Text with vim bindings coupled with zen coding plugin was pretty good for me when coding html/css, till the zen coding plugin appeared for vim. Now vim has everything I need for coding html/css. To me vim just makes everything better from my experience, it made me more efficient, more faster at coding. Visual Studio with vim key bindings made me love the VS IDE as well haha.

r00k 14y ago

The damn text box I am using in this browser to enter this comment is far more user-friendly than VIM. To the average user, sure; the text box is more friendly. But that's not the point with vim. At all. Vim's design goals are speed and efficiency. To date, non-modal editors haven't come anywhere near vim in that regard.

devth 14y ago

I think you're missing the point that many developers choose vim over "modern" editors because of its highly efficient text-editing capabilities. The same points could be made about emacs. As to "user friendly" - depends on who the user is. Yes, this text box is infinitely more user friendly than vim when your mom is using it. That a foot-pedal might make vim more usable has nothing to do with vim being outdated or unusable. Is your operating system broken / outdated because one might find a food pedal driving "alt-tab" more usable or fun?

robomartin 14y ago
OK, I'll bite. Please educate me. Give me a list of the "highly efficient text-editing capabilities".
- sofal 14y ago
  Start here: http://www.vim.org/docs.php http://www.vim.org/docs.php
  - robomartin 14y ago
    That doesn't really answer the question, does it? The other poster made an assertion about VIM being more efficient. I would like to get a list from him (or her).
    - jlgreco 14y ago
      > I would like to get a list from him (or her). Why is an answer from sofal not acceptable?
      - robomartin 14y ago
        Funny enough, not one person is stepping up to the plate to justify and quantify the claims that vi/vim are/have "highly efficient text-editing capabilities". Numbers. Not statements or links to the manual. I care about data. Show me a project that got done sooner and better because of the use of vi/vim and you'll have a point. I propose that not one person can make that claim and that the popularity of vi/vim are purely tribal. There's an interesting show on TV called "Head Games" (http://news.discovery.com/human/new-tv-show-plays-head-games-dnews-nuggets-120601.html http://news.discovery.com/human/new-tv-show-plays-head-games...). In this show they demonstrate, among other things, how tribal behavior can be taken to an extreme. It is very hard for some to go against group behavior. They show one example of a guy in a room that stands up when everyone else stands up and he doesn't even know why. To some extent I believe that some of these tools are like that. You work in a shop where the hot programmer swears by vi/vim and you adopt that without challenging any of it. Very soon everyone is playing the same tune, facts be damned. I happen to be one of those people that does not engage in crowd behavior. This can be a blessing and a curse. I never bothered to spend months on vi/vim because every time I used for days or weeks (out of not having other choices) I came out of it with the distinct idea that the whole thing was just short of lunacy. In the context of the project that needed to be completed these tools offered no real advantages. You are not going to impact the bottom line in any measurable way. Put another way: If you took two kids that knew nothing whatsoever about computers or programming and set out to teach them. One is taught with modern mostly-GUI tools with "conventional" keyboard shortcuts while the other has to use command line and vi/vim. Both of them have to complete the same project. The vi kid would be absolutely smoked by the other kid in no time at all. No question about it. OK, how about a second project. Maybe not smoked, but no significant gains would exist out of the vi camp. Programming is far more about things that have nothing to do with text editing. Projects are not late or buggy because of good or bad text editing tools. I'd still like to see someone quantify the gains offered by vi/vim over the course of a project.

sofal 14y ago

I don't think you'd find a military helicopter cockpit very "user friendly" either: http://www.helis.com/h/h53ecab.jpg http://www.helis.com/h/h53ecab.jpg We're talking about a general-purpose text editing tool used by experts for hours, days, and years on end. I understand that you like to click through your menus, but you'll have to excuse those of us who know what we're doing in vim and don't have the time or patience for that.

robomartin 14y ago
Who said anything about menus? And, yes, funny enough, it just so happens that I would find the cockpit of a military helicopter very user friendly.
- sofal 14y ago
  With no justification of how you think a military helicopter cockpit is user friendly, I suspect you're just trolling now.
  - robomartin 14y ago
    Your first personal attack was subtle: "I understand that you like to click through your menus" Now you resort to calling me a troll? That's nice. There's nothing unfriendly about a helicopter cockpit. Even if you've only played with flight simulators anyone half-way intelligent can probably figure out most of it within a few minutes. Flying one is a different deal, as mastering and understanding the complex relations between collective pitch, power, torques and aerodynamics. As a simple example, it isn't immediately obvious that flying in ground effect is different from flying above ground effect. Or the interaction between collective pitch, the tail rotor and the demand for power. This is quite different from understanding what the knobs and dials in the cockpit might do. All of this from simply expressing a contrarian opinion on VIM. HN does have an unfortunate trait: If you say anything contrary to "tribal" beliefs you get pounded and sometimes brutally downvoted. That does not mean that the tribal belief is right, it just means that there are enough tribe members to bully others into either not participating or simply adopting the tribal memes and falling into compliance. Well, that's not me. If I believe that someone is bullshit you are going to hear it. Why do I believe that some of the hyper-keyboard-efficiency claims of VIM are bullshit? Because programming is not factory work. If a programmer is spending so much time at the keyboard that counting keystrokes becomes important they are not doing a good job. I spend far less time programming than I do planning and deciding how to solve the problem. I don't just sit down and start hacking away without direction. By the time I actually fire-up a text editor or IDE to program I have state diagrams, database structures and algorithms pretty much selected and reasonably-well thought out. If I've done such a shitty job at the pre-programming work that my text editor's keystroke count actually matters, well, I'm a hack, not a programmer. Some of the admittedly interesting things you can do with VI (http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 http://stackoverflow.com/questions/1218390/what-is-your-most...) are, in my opinion, somewhat of a corner case. These are things that one might not do with great frequency. The fact that you can do them is interesting, but that isn't going to be a deal breaker if you only have to do them once every few weeks or months. In some respects I can derive far greater efficiencies from using a tool such as Excel to sometimes cut hours of coding and formatting by using it intelligently to help generate code that is more maintainable. One such example is to use it to generate state machine lookup table code that can be copied and pasted into a text editor instantly. I've done state machines with hundreds of states this way. If you do it right they are easy to maintaing and update. No text editor can improve on this level of efficiency. Another very similar example is to use Excel to help generate JSON files from various tables and data. Easy to setup, maintain and modify. A simple copy and paste into an editor. When justified, I have taken the time to create more complex tools that automatically generate complex code based on database inputs. One example that comes to mind was a tool to automatically generate all of the code to manage a menu system on an embedded device consisting of an LCD display and a few buttons. Every time the menu structure or content was changed it took days to update the menu processor code. The tool took a month to create. Once in place, almost anyone could generate the code for an arbitrarily complex menu system within minutes. No degree of text editor efficiency can solve these problems. The point here is that, if I have to resort to counting keystrokes as a measure of programming efficiency then I have either reduced programming to factory work or I am so disorganized that I am spending a disproportionate amount of time typing crap that will have to be fixed many times over before it actually works. To beat the state machine example to death. In my case it is very rare that I have any bugs when I code state machines, even complex ones. Granted, I've been doing it for a while in both hardware (FPGA's, Verilog) and software applications. Regardless of that fact, this is because I do all of the thinking and planning ahead of firing-up the editor. The resulting code, generally speaking, works on first run. I've you've ever programmed a CNC machine manually (G-code) you understand this concept. You don't just stand there start hacking away. You take the time to plan it, do all the math, choose tools and verify the approach before you enter the code. If you don't, you'll learn the hard way. These machines are dangerous. I once made a programming error and had my Haas VF3-SS churn aluminum with a 3/4 inch roughing bit like it was butter. Amazing what something with that much power can do. I kept the fucked-up end-mill as a reminder of what not to do. A professor of mine, who introduced me to APL, took every opportunity to drive a point home. He said that data representation is one of the most important tasks in solving a problem. If you represent the problem using a flawed model it can take ten times longer to create a solution. He pounded that into us to the point that it became instinct. That's why I will never touch a text editor unless I know where I am going. That's my context. I also caution you and others when considering yourselves "experts" in any field. I learned a long time ago to never utter that word. One can be highly skilled in one particularly narrow area while being completely ignorant of other ideas. I certainly am. I am not just talking programming here. Having access to a larger context is sometimes very important. What makes sense in a myopic context might not make much sense when one is able to pull back to a different plane that covers other schools of thought. Be open minded. Now, if it makes all of you really happy, down-vote away. It's always fun to watch the tribe in action.

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.

gte910h 14y ago

Vim when you're learning feels like this. Vim when you're using it with 3-5 buffers, some specialized, on screen with lots of plugins feels just like an ide or something like Sublime Text 2 Vim keybindings in Sublime Text 2 or Visual studio/outlook/word via ViEmu is pretty good in my experience.

robomartin 14y ago
Sublime Text looks interesting. I am going to check it out. Thanks.
- gte910h 14y ago
  I haven't been using it very long, but the vibrant plugin community (make sure you get BOTH vim plugins) and intelligent shortcuts make it feel like a winner.
eraldcoil 14y ago
Sublime Text with vim bindings coupled with zen coding plugin was pretty good for me when coding html/css, till the zen coding plugin appeared for vim. Now vim has everything I need for coding html/css. To me vim just makes everything better from my experience, it made me more efficient, more faster at coding. Visual Studio with vim key bindings made me love the VS IDE as well haha.