别碰我，VIM

某晚，被某 VIM 折腾了。

我最近是很无聊的：玩了一轮《植物大战僵尸》和《大富翁 4》，看了两部周星驰，外加一部 32 集连续电视剧，做了两道 ACM 题目，看了 100 页左右的《什么是数学》，整理了大一到大三的文件，跑了两趟黄埔医院，吃了三天的药，等等不一而足。

所以，折腾一下传说中的世界第二的编辑器 VIM（传说世界最强是 Emacs），毫不为奇。

大家都说用 VIM 的是高手，我说不对，请看上面我截下的程序图片，简直就是绝世高手用的编辑器。我折腾了半夜，反而被它给折腾了，因此为了朋友们的幸福着想，我不再一一列举它的用法。其实最大的原因是：不好意思，我也没能学会传说中的绝世武功。

据说，VIM（编辑器）+GCC（编译器）+GDB（调试器）是 Linux 下最常用的开发工具链。自小被 VS2005 浸染的我，不习惯 VIM，不习惯 GCC，不习惯 GDB，叫我怎么敢跑到 Linux 下写程序。高手们似乎很喜欢用 VIM 加上一大堆插件来写程序，根据我看到的做法，要想有 VS 那样的智能补全功能，VIM 首先要 Ctags（这是要输入一长串命令的），接着输入几个字母再按一下 Tab 键（需要 SuperTab 插件），才能出现智能提示。

这还不是最紧要的，在 VIM 里面，删除一行字，请按 d 两下，删除一个字，请按一下 x。以及一长串的需要记忆的命令列表，例如 gg 是跑到文章的最前面，shift+4 是跑到行首，等等。我不自觉地想起了小学五年级那个暑假学的 WPS，要输入一大堆的指令才能输出一篇格式整齐的文档，在别人眼里看起来绝对是很牛的事情。现在会用 Office2007 的，也不止你我他吧? 至于那个时候所学的一大堆 WPS 控制指令，还有五笔字型，到现在全忘了。

我肯定不是个记忆强的人才。帅哥拿起个 Ubuntu，手中熟练地敲打着一堆我看不懂的指令，看得我眼花缭乱。用 Linux，我最头疼的事情是干什么事情我都要先敲入一个命令，然后–help 找帮助来看，否则绝不会记得那个命令是怎样用的。一开始还说这是学习阶段要好好熬，尝试多了以后就会觉得这事真的很折腾。

你说，好好一个软件为何就不写个 gui 界面，非得让我敲命令去记忆每个参数什么意思，好好一个配置为何就不写个 gui 界面，非得让我把整个配置文件研究完才知道我该去哪里修改配置参数。

他们说：Unix 哲学是：一个程序只做一件事，并做好。但是不知道为什么，Linux 下的软件作者似乎就是懒得写个 gui，或者他们认为他们只需把软件的逻辑做好就可以了，至于 gui 方面，根据简单原则，应该由其他有兴趣的人去做。其实我觉得原因有二，一则是没有强大的开发工具（要像 C#那样拖个控件就可以写 gui），二则程序员也懒。

为什么没有强大的开发工具呢，为什么 Linux 下没有 VS 这样的重磅武器? 我再从 VIM+GCC+GDB 说起吧。VIM 的难刚才说过了，GCC 的话，要是有几个文件你非得自己手动写一个 makefile 不可，GDB 我基本没试过，据说也有些图形界面的调试工具，可以像 VS 那样按一下快捷键就能调试（这个肯定也是要配置 N 久的），我看过一份 GDB 的使用手册，又要记忆很多调试指令，我觉得我快要崩溃了。

上面所说的 “一个程序只做一件事，并做好” 现在已经造成了许多弊端，最可见的是依赖性。

相信在 Linux 下稍微深入过进行开发的知道，GCC 的版本号是件很痛苦的事情，有些程序要 A 版本的 GCC 编译，有些程序要 B 版本的 GCC 编译，高点低点版本号都不行。再加上相应的头文件库文件版本号，你是不是有种抓狂的感觉。悄悄地，我再告诉你，Linux 现在发展很快，版本号一直在不停地变，你可以去发疯了。

譬如，A 作者维护一份 A 程序，B 作者维护一份 B 程序，两个程序之间是有依赖的（可能的情况是 B 程序是 A 程序的 gui），突然 B 作者想去周游世界不继续开发 B 程序了，A 作者继续开发下去，接口变了，那 B 程序基本就没用了。作为使用者的你，要么只能怨天尤人，要么改行帮 B 继续开发。

开源模式无疑是有很多长处的，但是其短处一直没有被正视。开源意味着源代码开放，人人都可以修改提交，可是就实际情况而言，更多的是做横向的，而不是做纵向的。我所说的横向是指开发配套软件，纵向是指对软件进行更深入的开发。因为横向的容易，只需要知道要配套的接口就可以了，而做纵向则需要将源码读懂。

继续说为什么 Linux 下不可能出现 VS 这样的重量级应用。VIM+GCC+GDB 一样可以实现 VS 的功能，可以进行编码，编译以及调试，但为什么它们合起来就不是 VS? 因为没有架构。

现在开源的开发模式说到底还是陈旧的开发模式。软件工程的概念已经提出来好几十年了，可是当你想深入了解某个开源软件，接着去下载其源代码的时候，会很悲哀地发现：你找不到任何对应的开发文档。所有能帮助你理解源代码的只是程序源代码中的注释。

假如你很牛，想要做一个 Linux 下比 VS 还强的 IDE，要用到 VIM、GCC 和 GDB，你要做哪方面的工作呢? 以进行一次小小的开发为例吧。先不管 VIM 中代码智能提示是怎么来的（至今我还不知道如何写好函数名后提示我参数列表），辛辛苦苦写好代码后，要编译是吧? 假设编译出错了，GCC 会提示你哪里错了，还显示出一个行号提示是哪里的错误，错误是什么。想快速定位到错误的地方吗? 不好意思，GCC 说我是编译器这事不归我管，VIM 是个编辑器，这事归它管。可我总得知道是哪里错吧? 谁给我这个定位的参数?GCC 只能输出信息，它意识不到 VIM 的存在。这时候你得写个适配接口，将 GCC 的输出信息转换一下，然后提交给 VIM，VIM 再跳转到出错的地方。当然这个 VIM 插件是有的，叫做 quickfix。

诸如此类的问题很多，VIM、GCC 和 GDB 是基本没什么关系的软件，要想使它们可以通信，你必须写一大堆的适配程序，写适配程序还得考虑 VIM 的接口是怎样的，GCC 的接口是怎样的，GDB 的接口又是怎样的，这些你又得去学习。而在 VS 中，这是一个设计好了的架构，不同模块之间的接口是已经定义好了的，它们之间传输的数据也是定义好了的，想要通信是吧? 简简单单在内存传送一个变量过来就可以了。而在 VIM+GCC+GDB 的通信中，数据的传送是很麻烦的事情，有时候还要通过写入读出硬盘，很神奇吧?

由于没有架构，所以要写一大堆的适配器才能将它们集成起来，还有些是适配器做不了或者做得不够好的功能，譬如刚才所说的代码智能提示，的确是有 VIM 插件可以做，但是如果你看过写 C#时候 VS 的行云流水，就知道那些插件做得远远不够。这不是插件的问题，而是 VIM+GCC+GDB 们在该内聚的时候没有内聚。当然这也不是它们的分内事，它们本来就不是打算做 IDE 的。这时候你还会觉得 “一个程序只做一件事，并做好” 是绝对好事吗?

知道了没有架构之后，你可能会想，要是有了架构，是不是就可以做出 VS 那样的 IDE 了? 这还得考虑开源开发者的软件工程水平。就我看来，还是有许许多多的开源开发者基本是没有软件工程概念的。在现实中，你可以要求一个开发者按照你的思路你的文档去开发，因为你掌握着他的薪酬。而在网络中，一则没有软件工程开发观念，二则他们也不会去学习新的一门学科，各种各样的软件工程开发模式，咱做开源只是兴趣而已，此处不留爷，自有留爷处。你拿什么来管理这些不想被束缚的开发者们呢?

除非，有架构，而且 VIM 和 GCC 和 GDB 按照架构去做，否则绝不会做出 VS 那样的 IDE。可是几乎在一盘散沙各自为政的开源界，有可能吗? 所以我断言，开源界不可能出现 VS 那样的重量级应用。

开源的道路，任重而道远。最后怨恨一下 VIM，害我衣服忘记洗，风扇忘记关，手机的充电器也忘记拔下来浪费了不少电，药也忘记吃了。