4 ms·

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

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

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.