3 ms·
> I don't know what editor the hip young kids of 2067 will be using, but I know that the folks getting stuff down will be using vi & emacs. I have yet to met a
by SadWebDeveloper 9y ago
> I don't know what editor the hip young kids of 2067 will be using, but I know that the folks getting stuff down will be using vi & emacs.
I have yet to met a developer that blame his inability to "get stuff down/done" because his editor don't let him write fast enough.
Developing isn't a who-can-type-faster contest is who can solve a problem in a fast and simple way, typing/coding is the thing you do _after_ you solve the problem.
- zeveb 9y ago> Developing isn't a who-can-type-faster contest is who can solve a problem in a fast and simple way, typing/coding is the thing you do _after_ you solve the problem. You're right, and that's the thing: emacs isn't better because it enables one to type more quickly; it's better because it enables one to do more. With emacs, a developer can build out his own environment, and he can share that customisation with others. As an example, magit is by far the best way to interact with git. Another example is org-mode. Another is gnus. Another is notmuch. And on and on. Indeed, it's this emphasis on extensibility which is why I prefer emacs (which is better-extensible) to vim (which, frankly, has a better text-manipulation language). There's simply no competitor to emacs when it comes to extensibly interacting with text. Even if SublimeText, Atom, IntelliJ, Eclipse, Visual Studio got perfect vi keybindings, I do not believe that they'd be as extensible as vim, let alone emacs. Since extensibility is the quality which enables a tool to be used for more than its designer imagines, and since no designer can imagine all his users' use-cases, I think that this means that SublimeText et al. will never be all one needs.