本文地址：https://blog.hoppinglife.com/?p=4
(新网站缓慢建设中，尚无具体时间表。)
想了很久第一篇新Blog要写什么，现在想想就从天天在用的软件说起吧。
和很多同龄人一样，我开始接触编程的时候使用的是Turbo/Free Pascal/Lazarus的IDE， 后来转向C的时候用Dev C++/Code::Blocks, 接触Linux之后开始使用Emacs，用过一段时间的Eclipse写C/C++/Python/Java, 再后来开始长期使用vim/IDEA进行开发 – Java/前端代码用IDEA写，后端代码用vim写。
Coder总会不可避免的陷入圣战的泥潭 。 一开始是vim vs Emacs vs VS, 后来是Eclipse vs IDEA，再后来是vim vs sublime text, 总之有coder的地方就有江湖，有江湖的地方就有圣战。——这还只是文本编辑器。
不知道有没有像我一样的人，曾经觉得*nix下面没有一个出色的C/C++ IDE有那么一点奇怪(虽然Windows下大概也Visual Studio+Visual Assist X还活的比较好)。——几年之前最流行的组合包括vim/omni-complete和emacs/CEDET，用起来多少都有点奇怪，远远没有VS初上手来得正常。
大家似乎都这么想: 平均每3天我就会在不同场合看到论证Vim设计得很糟糕的文章。——反人类的设计，三十年前的键盘映射，糟糕的插件管理和界面，只是用来装X, 快点用acme/textmate/sublime什么的代替它吧。
但是大家还是在用vim/Emacs：如果有人问我做Linux下的C/C++开发用什么IDE, 我还是会说vim/emacs，十年之前是这样，十年之后还是这样。甚至今天的我，会费力把每个我会写字的地方都改成vim key-binding。
是的，我知道vim是很糟糕的设计，我知道配置它很麻烦（实际上有了vundle/janus/spf13之后并不复杂)，我知道它的语法识别并不出色，但我还是会用vim, 哪怕我要专门写个脚本来生成我的.vimrc.
因为这个世界上，『最优秀产品』评选，有很多『场外因素』。
- 通用
有机器的地方就有vim——不管windows/Linux/BSD，不管是server还是树莓派，不管是android还是ios, 我都可以轻松的找到一个vim(至少是vi)来用。更重要的是，让这些vim长得用着都一样，并不花太多力气。 - 社区大小
成百上千的coder这么写代码——不管是配置、工具链都已经非常成熟了。毫不夸张的说，只要你想到的idea, 就有人或多或少的实现在vim里。每当想做一件什么事的时候，搜搜vim tips wiki就找到解决方法了：庞大的社区，能够相当程度的减低学习的难度，也能够轻易的让你体会到社区的最新成果。 - 路径依赖
是的，当你已经适应了一种工作方式了之后，你会懒得更改到另一种工作方式。
毕竟，在ssh下工作，选择几乎只有vim/Emacs. - 免费/轻量
是的，不用支付额外的费用，可以直接在ssh上工作，节省屏幕空间——大家都挺穷的。 - It just works.
大家已经这样写代码写了很多年了，至少说明它没有大问题，何必花精力改它——发掘一个更好用的toolchain的时间，很可能超出你的想象。
这并不是说vim/Emacs不优秀——实际上它们优秀到超乎想象，那部分内容和本文无关；但我相信如果今天再去设计vim/Emacs, 肯定不会长成它们现在这样子。但是这无关紧要。那些『场外因素』，已经或者弥补，或者让我们忽略了它们的缺点；也让我们离不开这些老家伙的『特性』。
同样的道理也适用于C/C++/Java/Unix/make/tex：如果今天重新设计这些东西，它们很可能会长成Go/Rust/D/Dart/Plan9/Scon/texmacs的样子。但是绝大多数情况下，这种关公战秦琼式的比较毫无意义：后者的优点和这些『场外因素』比起来，并不重要。更何况，让前者变得方便使用，比让后者变得成熟，要简单太多。
所以我从来不是很买『那个设计不好所以应该换』的帐。用户从来不傻：站在巨人的肩膀上或许不难，但是真正成为巨人远没有那么简单。