场外因素

本文地址:http://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的样子。但是绝大多数情况下,这种关公战秦琼式的比较毫无意义:后者的优点和这些『场外因素』比起来,并不重要。更何况,让前者变得方便使用,比让后者变得成熟,要简单太多。

所以我从来不是很买『那个设计不好所以应该换』的帐。用户从来不傻:站在巨人的肩膀上或许不难,但是真正成为巨人远没有那么简单。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据