3 ms·

>> Emacs and VIM use has actually been going down since the 90s as a percentage of the developer community My Google-Fu is coming up short, i can't corroborate

>> Emacs and VIM use has actually been going down since the 90s as a percentage of the developer community My Google-Fu is coming up short, i can't corroborate this. Can you provide any links to data confirming this claim up? I took a stab at getting some stats by searching stack overflow / server fault / super user for vim questions, emacs questions, textmate and sublime, vim comes out top by a long way, emacs next, the other 2 are a rounding error.

seanmcdirmid 14y ago
No surprise that there are lots of questions about VIM, it has a really sharp learning curve. You didn't include Visual Studio, Eclipse, IntelliJ, etc...which is a significant omission. This is all informal and anecdotal, but I'll try to explain my reasoning/experience. In the mid/early 90s, you weren't really a great programmer unless you used a real text editor, so we would all eventually evolve into using Emacs (or VIM for the more daring). But then in 1997, Visual Studio got support for code completion (in VB), and Java and even C++ eventually followed. These language editors improved productivity for programming in those languages so much that it was hard to be competitive staying on Emacs. So perhaps most (~90%) of the Java/C#/C++ code written today is done with a well supported language aware editor (Eclipse, Visual Studio, JetBrains, ...). Of course, if you are programming in a dynamic language, or a language with lousy tool support (C), then the language-aware editor doesn't really give you much (no static type system --> no static type feedback). There is a greater chance you are programming in Emacs (or VIM), but then you might not want to bother with the learning curve, or you might want something with a more modern non-ASCII UI, so maybe you are programming in Sublime or TextMate. There is nothing really wrong with this, you can be a great developer and prefer to avoid UX-archaic tooling, especially if you happen to also be a strong designer. There are strong trends away from text-based tools to visual tools, and I have no reason to believe that this isn't at play here. The emacs community is vocal, and is particularly magnified in my field (systems/PL/PhD-level computer science) and demagnified at my place of employment (Microsoft, though keep in mind MSR has lots of Emacs/VIM users). But look at what the students prefer: they have no patience to learn these weapons from a more civilized time. They'll take whatever is the path of least resistance, and honestly who blames them!? Its not like they are losing much.
- 3amOpsGuy 14y ago
  >> UX-archaic Why then, in circa 40 years, have we still not managed to find a better alternative? I can't help drawing parallels with windows / unix in the 90s and more so 00s. Yes, a point and click GUI is much easier to wing it with than a CLI, but, it doesn't deliver nearly as much power to the user as a proper CLI with a small number of reusable tools that can be composed to solve many problems. To give a concrete example, if the GUI designer of your chosen deployment tool didn't imagine anyone would want to filter nodes to target a deployment by a substring of the node name, then you are out of luck - resorting to hacking your hosts file on windows to null route all the hosts you don't want to hit, followed by deploying to all nodes from the brain dead GUI. With a proper CLI, only your imagination reduces your ability to solve whatever business problem (and they are infinite). The net result of this shallow learning curve? We got a lot of people who refused to learn how to manage a network, winging it and being employed in positions of significance - average corp. with hopelessly leaky data safeguards and so on. So back to the ux archaic editor, nothing has surpassed it despite 40 years of continual focus. While I wouldn't dismiss attempts to improve it out of hand (I'm a paid up customer of ST2), I also wouldn't count on an revolution relegating vim to the history books anytime soon. As for VS, Idea etc. they are merely a chapter 11 filing away from being forgotten. Eclipse could live on. Who knows.
  - seanmcdirmid 14y ago
    Emacs is only about 30 years old (VIM is only 20 yro), I guess you are talking about text-based interfaces in general? I'm not going to completely disagree with you here. There are lots of time I've found a shell to be useful, but I've also changed my workflow to minimize the amount of time I spend there. Learning curve for shell is steep, not shallow, but I've gone through much of that 20 years ago. If there is an old tool I can use to do something, I'm all for it, but if its a new tool, I'll go for the visual one with the lower learning curve, because I'm quite busy. Still, nothing beats shell for composability and flexibility, I definitely lose something with my approach. I find lots of promise in projects like Mozilla's Ubiquity, but I have a feeling the next step are actually Siri-like dialogue systems (whether typed or spoken). But we are talking about editors that are used to edit code. I'll argue that language aware editors (in Eclipse, Idea, VS) have already greatly surpassed VIM/Emacs in terms of productivity, but then you could argue back that VIM/Emacs could re-support these features (and people have crammed them in at some points, though these have failed to stick). So let's just assume equal footing for now, and evaluate the experience. Given that we have a good understanding of the development process now, I'll argue that an IDE with high-discoverability of its capabilities is easier to use than Emacs/VIM which require substantial training to master. Now what Emacs/VIM give you is lots of power, but I don't think most of us need that. Heck, I've even moved away from Emacs for Latex programming, where the "build project/view PDF" menu option in TeXniCenter is good enough for me.

seanmcdirmid 14y ago

No surprise that there are lots of questions about VIM, it has a really sharp learning curve. You didn't include Visual Studio, Eclipse, IntelliJ, etc...which is a significant omission. This is all informal and anecdotal, but I'll try to explain my reasoning/experience. In the mid/early 90s, you weren't really a great programmer unless you used a real text editor, so we would all eventually evolve into using Emacs (or VIM for the more daring). But then in 1997, Visual Studio got support for code completion (in VB), and Java and even C++ eventually followed. These language editors improved productivity for programming in those languages so much that it was hard to be competitive staying on Emacs. So perhaps most (~90%) of the Java/C#/C++ code written today is done with a well supported language aware editor (Eclipse, Visual Studio, JetBrains, ...). Of course, if you are programming in a dynamic language, or a language with lousy tool support (C), then the language-aware editor doesn't really give you much (no static type system --> no static type feedback). There is a greater chance you are programming in Emacs (or VIM), but then you might not want to bother with the learning curve, or you might want something with a more modern non-ASCII UI, so maybe you are programming in Sublime or TextMate. There is nothing really wrong with this, you can be a great developer and prefer to avoid UX-archaic tooling, especially if you happen to also be a strong designer. There are strong trends away from text-based tools to visual tools, and I have no reason to believe that this isn't at play here. The emacs community is vocal, and is particularly magnified in my field (systems/PL/PhD-level computer science) and demagnified at my place of employment (Microsoft, though keep in mind MSR has lots of Emacs/VIM users). But look at what the students prefer: they have no patience to learn these weapons from a more civilized time. They'll take whatever is the path of least resistance, and honestly who blames them!? Its not like they are losing much.

3amOpsGuy 14y ago
>> UX-archaic Why then, in circa 40 years, have we still not managed to find a better alternative? I can't help drawing parallels with windows / unix in the 90s and more so 00s. Yes, a point and click GUI is much easier to wing it with than a CLI, but, it doesn't deliver nearly as much power to the user as a proper CLI with a small number of reusable tools that can be composed to solve many problems. To give a concrete example, if the GUI designer of your chosen deployment tool didn't imagine anyone would want to filter nodes to target a deployment by a substring of the node name, then you are out of luck - resorting to hacking your hosts file on windows to null route all the hosts you don't want to hit, followed by deploying to all nodes from the brain dead GUI. With a proper CLI, only your imagination reduces your ability to solve whatever business problem (and they are infinite). The net result of this shallow learning curve? We got a lot of people who refused to learn how to manage a network, winging it and being employed in positions of significance - average corp. with hopelessly leaky data safeguards and so on. So back to the ux archaic editor, nothing has surpassed it despite 40 years of continual focus. While I wouldn't dismiss attempts to improve it out of hand (I'm a paid up customer of ST2), I also wouldn't count on an revolution relegating vim to the history books anytime soon. As for VS, Idea etc. they are merely a chapter 11 filing away from being forgotten. Eclipse could live on. Who knows.
- seanmcdirmid 14y ago
  Emacs is only about 30 years old (VIM is only 20 yro), I guess you are talking about text-based interfaces in general? I'm not going to completely disagree with you here. There are lots of time I've found a shell to be useful, but I've also changed my workflow to minimize the amount of time I spend there. Learning curve for shell is steep, not shallow, but I've gone through much of that 20 years ago. If there is an old tool I can use to do something, I'm all for it, but if its a new tool, I'll go for the visual one with the lower learning curve, because I'm quite busy. Still, nothing beats shell for composability and flexibility, I definitely lose something with my approach. I find lots of promise in projects like Mozilla's Ubiquity, but I have a feeling the next step are actually Siri-like dialogue systems (whether typed or spoken). But we are talking about editors that are used to edit code. I'll argue that language aware editors (in Eclipse, Idea, VS) have already greatly surpassed VIM/Emacs in terms of productivity, but then you could argue back that VIM/Emacs could re-support these features (and people have crammed them in at some points, though these have failed to stick). So let's just assume equal footing for now, and evaluate the experience. Given that we have a good understanding of the development process now, I'll argue that an IDE with high-discoverability of its capabilities is easier to use than Emacs/VIM which require substantial training to master. Now what Emacs/VIM give you is lots of power, but I don't think most of us need that. Heck, I've even moved away from Emacs for Latex programming, where the "build project/view PDF" menu option in TeXniCenter is good enough for me.