联合杯

 

『教练,我想打比赛。』

『哦?你的期望是什么?』

『当然是夺冠。』

『凭什么?』

 

『凭我们有最强的阵容。』

『阵容不足恃。湖人F4倒在活塞手下,银河战舰年年输给里昂。难道是因为他们的阵容不够强吗?』

『那,我们有最强的教练。』

『教练不足恃。上场的毕竟是队员,不是教练。强如拉里布朗,也没能拯救尼克斯于水火之中。』

『我们有最强的团队。』

『不错。可是你听说过「三个和尚没水喝」的故事吗?』

 

『……。那,凭我们有最充分的准备。』

『有点意思了。准备不足恃,比赛总有意外,开场三分钟的一个任意球就可能打破你的全盘计划。』

『我们有最娴熟的技战术。』

『战术不足恃。它是胜机也是枷锁。当你的套路被研究透,你还有什么东西可以拿来赢得比赛?看看贝尼特斯。』

『我们有最出色的配合。』

『恩。不足恃。有着华丽配合的队伍太多,可是它们往往不能一锤定音。』

 

『那,到底有什么制胜良方呢?』

『其实你知道的对不对,「阵容」「教练」「团队」「备赛」「技战术」「配合」,只是要防止一些小小的意外。』

『意外?』

『比如说教练没办法给出好的战术,比如说准备的时候找不到合适的资料,比如说在后半场队员体力不支,比如说你需要一个神来之笔打破局面……』

『啊……好可怕,那如何才能预防呢?』

『很难预防。哪场加时赛还没有几个抽筋的?』

『……』

『到那个时候,才是比赛的开始。面对身体的极限,解脱的诱惑,巨大的压力,你还能不能向前跑?还能跑得动,你就能夺冠。It ain’t over till the fat lady sings.』

『那,如何才能跑得动呢?』

『这,就要问你有多想赢了。如果你还记得曾经输了比赛的哭泣,记得自己当初踏上这片赛场的理由的话。』

『可是我还以为,只要阵容齐整,做好准备,冠军就是囊中之物。就没有办法轻轻松松夺冠吗?』

『孩子,这是竞技体育。如果夺冠那样简单的话,我们哪里会那样向往这个冠军呢。』

====================================================

各位,看上周的我是歌手了吗?有没有想过,以韩磊对音乐的追求和掌控,为什么还愿意把最后一首歌,留给听上去很俗套的《向天再借五百年》?

赛场上,我们想证明的事有千种万种,但是什么样的证明,都不如击败所有的对手来得实在。各位勉之。

How I met your mother[剧透]

本文地址: https://blog.hoppinglife.com/?p=29 

 

 

Mixed feelings about it.

1

我能理解这个结局。

HIMYM其实不是一部关于幸福和温馨生活的剧,它是关于如何幸福和温馨的看待生活的真相。

整部剧可以在22集结束,几个闪回,几句温馨的话,就可以让我们含泪告别整部剧集:幸福,感人,CP们终于走到一起。

可这显然不是编剧的期望。

生活不完美,你和一见钟情的姑娘未必适合;你和你的初恋终会分离,你会为工作痛苦,会为感情纠结,会担心和铁哥们慢慢疏远,会爱上女友的闺蜜或者男友的铁磁,会在前任和现任之间摇摆不定;会和情侣吵架,会慢慢淡忘浪漫。

但是当你回顾这样不完美的生活的时候,你能从当时苦涩的味道品出甘甜:学到的经验,曾经的浪漫,从天真疯狂到慢慢成长,快乐和悲伤,相聚和别离,以及,曾经的记忆和遇到的人。你会发现,曾经的痛苦可能是命运的考验,也可能是老天赐予你的珍宝。

这才是胖瘦想要讲的故事,这才是寻妈记的主题——不是生活的温馨与甜蜜,也不是生活的痛苦与折磨。

寻妈记想讲的故事,是生活本身。

2

我不喜欢这个结局。

草率和匆忙吧。Barney花了三季的时间,从大男孩成长成男人,然后在半个小时的时间里倒退回过去,又在剩下的半个小时奇迹般的喜欢上刚出生的婴儿。Robin好不容易从女强人变成小姑娘,两集时间又奇迹般的变回去。老妈匆忙出现,又匆忙离开,美好的故事仿佛是Ted追求Robin的工具。

老实说,我们都知道Barney的Awesome说到底是因为他是个浪子,Robin还是那个女强人,Ted还是爱着Robin,每个人总有一刻要做回自己,情侣会分手,恋人会得病。从某种意义上来说,这些都没错,这些,和之前的九季一样,也是成长的一部分,生活的一部分。

但是这一切发生的太快了。

在三季的美好与温馨,在所有的期望与暗示,在一个冗长的周末之后,所有的迹象,都指向五人组幸福的生活在一起,这是一个美好的故事。

但是,Hey,你不能只用一个小时告诉观众:不是你想要的童话。

Barney和Robin终归会发现不合适。Ted深爱着老妈但是终究不得不接受现实。Ted心目中,Robin永远是喧闹酒吧里那个漂亮姑娘;Robin的心里也终归会有属于Ted的某块地方。没错,但是对于剧中人物这是很多很多个月,很多很多年才能慢慢接受的现实,对于观众也一样。

这应该是一个更长,更费时间的故事。把前因后果隐去,就会变得生硬而冷漠。应该有更多的篇幅给Robin和Barney的性格,给Ted与Tracy的爱情而非那个长长的周末——一定要结束在『met』,给了这个故事太大的限制。

在我的心里,这个故事不该讲在在Ted要和Robin之前,而是应该在很久之后,Ted坐在客厅里回忆五人组的快乐与悲伤,Robin在她身边。

——爱过,痛过,领悟过美好,感受过寂寥,终归回到原点,这才是生活。

3

不管怎么样,HIMYM都是一部好电视剧。结局成功也好,失败也罢,都只是几百个小时中的一个小时。

我无意去重复那些曾经让我心潮澎湃的台词,那些让我或悲或喜的瞬间。我没有那么出色的笔。

我只想说,无数次,我看完这部剧,关上电脑, 心中冒出一个念头。

『这,大概就是生活的力量。』

隔行如隔山

本文地址: https://blog.hoppinglife.com/?p=2

一般来说,要让程序能运行,除了你自己的代码之外,要有很多『现成的代码』来节省你的工作量,也就是所谓的『标准库』。可是光有代码还不够,我们还需要把接近英语的高级语言『编译』成机器语言的编译器,把一个大程序不同的部分『啮合』在一起的连接器。到了运行时,操作系统要分配有限的CPU和内存来处理不同程序和设备的请求,具体的指令要被CPU『解码分析』然后分配到『流水线』上执行。还有更多的细节,这里从略。

项目大了,编译的时间就会很长,于是偶尔会想,我在多大程度上,能够理解我所写下的几行代码在一台计算机上是怎么运行的呢?

『库』的部分,我大概知道该怎么写,但是真让我写,一定会『漏洞百出』且『效率极低』。至于其他的部分,编译器、操作系统和CPU的工作原理都是计算机专业最重要的核心课程。可是对于不负责设计这些的我来说,这些部分太复杂太庞大,只能了解一点点皮毛而已。更不要说集成电路如何实现这些功能,或者是如何构成集成电路——那是硬件工程师的工作了。

事实上,大多数时候,计算机对我来说就是一个『可以运行高级语言代码的黑盒子』。至于『进程调度』,『寄存器分配』,『中断处理』——我一点都不关心。这样的例子不难举:对于很多人来说,数学和物理,也只是『拿结论来用』的黑盒子。

从工业革命到如今不过数百年,现代文明已经发展到这样一个程度:全才不复存在,事实上,我们不仅无法理解别人的专长,甚至连自己的领域内的成果,也往往只能了解一个有限的梗概了。

这当然不是坏事。但是当我们享受这种『无需牵扯细节』的好处的时候,也很容易忘记,今天拿出手机就可以顺畅的让鸟撞上管子或者是看到心仪妹子的照片,蕴含着多少次的计算与多少距离的信息传递,而为了让这些计算和连接能力唾手可得,整个行业在50年间经历了多少次技术革新。

每次的性能提升,都意味着无数次的改动CPU的设计,意味着通过提高制造工艺来压榨出最后一点性能,意味着重写编译器的无数代码,意味着无数人的不分昼夜的努力工作。而对于一个外行人来说,说不定他会觉得『今年性能只增长了10%啊,比去年也没有很厉害嘛』。

这就是『专业』的含义。它意味着不同的知识架构,意味着不同的工作实践,意味着不同的能力偏重。是的,从某种意义上来说,理工科学生的『人文素养』就是比不上人文类专业的学生;文科生的『科学素养』也很难比得过理科生:这本来就是知识体系和教育背景决定的。或许有例外,但是以今天知识体系的复杂和庞大,就算有例外也很有限。而承认我们在知识结构和经验上和专业人士存在差距,尊重和信任专业人士,『让专业的人,做专业的事』是现代社会得以继续运转和创造财富的基础之一。

可是很遗憾,面对争议,往往揣测流言和廉价的质疑大行其道,仿佛专业分析遍地可见,真正的专业意见却湮没无闻——因为简单的图景和阴谋论永远受欢迎,而复杂的专业分析往往没有那么『爽』和『顺』。也因为,人人都喜欢参与感,喜欢『这些人忽悠不了我』的感觉。

可是如果一切以『常识』和好恶来做出判断,到底我们接近的是真相,还是想象呢?

隔行如隔山。

对比的力量

本文地址:https://blog.hoppinglife.com/?p=24 

韩磊的演唱,简直是『欲扬先抑』的范本。

从『慢』开始,从『弱』开始,一点点的加快,变强,换音色,一点点撩拨你的情绪,当你试图抓住它的时候,又悄悄的逃开,回归平静,哪怕是第一遍副歌,留着余地,留着空间,浅尝辄止.

终于,你被撩拨的心痒难耐,满身的情绪只期待一个出口的时候。他轻轻的按下开关。足够了。

 

 

如何掌握观众,如何点燃观众,是一门值得好好学习的学问。

Mac OS X不是unix

本文地址:https://blog.hoppinglife.com/?p=19

警告:这是一篇高度个人化的文章,不适者请跳过。

这篇文章不是要探讨OS X的可用性或者设计优劣:尽管那个题目很热闹。我要讲的话是:『Mac OS X不是unix』。

从字面角度上,这句话不太正确:OS X通过了SUSv3,这使得它成为地球上不超过十个可以自称自己是『UNIX』的操作系统之一。其他的成员包括AIX, HP-UX, Solaris等等。

但是Linux和BSD都不是这个家族的成员,而它们加起来占了Unix服务器的绝大部分,所以让我略加修改APUE的名言:

On the other hand, if it does not look like a duck, does not walk like a duck, and does not quack like a duck, then it’s probably not a duck.

所以我们来看看Mac OS X是不是unix:Again,这无关某个动物或者鸭子是好还是坏,我只想说明某只特定的动物是不是鸭子。

一 内核

『Mac的底层是Darwin,Darwin是BSD』大概是最常听到的关于Mac和BSD的关系的描述。但事实上不是这回事。

事实上这个内核的核心还是mach:内存管理、进程管理都由mach负责,而mach不管从历史还是特征上都更像NT内核。部分Darwin kernel的源代码来自4.4BSD – 和Berkeley有关的最后一个版本。但是这部分代码运行在Mach的上层,几乎只负责提供SUS/POSIX子系统的API,而且被大规模的修改过. 除此以外,Darwin kernel拥有自己的Driver API和I/O Kit,(面向对象的),从这个角度上来说,与其说Darwin kernel像unix, 还不如说它像VMS/Windows。

二 API

让我从一个问题开始:『装着cygwin的Windows』是unix吗?

OS X的感觉与这个类似:你确实可以使用POSIX的API,但大多数OS X的GUI会基于闭源的cocoa,会使用特有的thread API,会使用launching API来运行daemon,会使用GCD来做消息处理,会使用不一样的动态链接库。

简而言之,除了使用了Posix的API,OS X和BSD/Linux并不share太多的共同点。你可能会使用一些POSIX的API,但你几乎同样必须使用Apple专有的API。

与其说你在开发unix软件,不如说你在开发OS X软件。

三 Look’n’Feel

OK,回到使用上,Mac OS X到底有多unix-y呢?

事实上,Apple在努力隐藏这个系统的unix部分:Apple有自己的路径规则和文件系统。用户使用Applescript来做自动化。时至今日,安装软件很多时候还是运行一个installer或者把文件copy到Application folder。App Store里找不到wget或者macvim,你可以清晰的区分出两类程序——一类装在/usr下面,一类装在/Applications里。

你的用户感受是『Mac OS』,不是『unix』。与其说Mac OS X像unix,不如说它更像Mac OS 9。

四 哲学

“Keep it simple and stupid”

“Do not reinvent the wheel”

“Write prog1rams that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.”

unix的最核心的价值之一,在于它提供的模式:充分利用已有的成果,给最终用户以选择的机会,系统高度透明和模块化,高度可配置。

Mac OS X不是这样的一个系统。Apple搭建了一个自有的平台,通过限制功能和封闭来达到稳定性,通过复杂的封装来达到可用性。macports和homebrew能够很好的反映这一点:你要么选择冗余(重新安装所有文件),要么选择匮乏(被系统工具的版本限制).

五 

如果从内核,API,操作方式到哲学,Mac OS X都更像Mac OS 9而非unix的话,为什么我们还要叫它unix呢?

我对Mac OS X没有什么意见——出于个人的偏爱,我不会用它,但我相信它是一个出色的系统。

但我不喜欢Apple用Unix当商标来推广Mac OS X,unix不仅仅是一个『好用的shell』而已,它的价值,也在于『类似的系统路径和配置方式』,更重要的,在于『高度透明和可配置』,在于『充分利用既有的社区成果而非重新发明轮子』。对这些哲学的坚持,是unix社区成功的要素之一。

但OS X是一个和unix社区从理念到实践都相差甚远的OS。它有着特有的操作方式和配置规则,有着比Windows还厚的封装,重新发明了比Ubuntu还多的轮子。

它只是碰巧能兼容一部分BSD程序而已。认为『Mac OS X有Unix认证所以是unix』和认为『Windows + cygwin是POSIX兼容的所以是unix』没有什么本质不同。就算猩猩和老鼠99%的基因相同,猩猩也不是老鼠。

你可以喜欢unix,也可以讨厌它,但是希望你喜欢或讨厌unix的原因,不是因为你喜欢或者讨厌Mac OS X。

Several Thoughts

本文地址:https://blog.hoppinglife.com/?p=13

最近有好几个小朋友跑来问我有关学习啊前途啊推荐导师方向啊的问题,我猜我的答案不是很让你们满意。正好,今天又看到一篇『ACM大牛太厉害怎么办』式的文章,有感而发,写一点我此刻的感触。个人意见,水平有限,仅供参考。

一 轨迹和距离

要讲的,大概就是乔布斯『dot』那个演讲的意思。你从来不知道自己的现在会以怎么样的方式影响未来。恩,这个话题很俗,但是在此时此刻,我希望我更早一些懂得这个道理。

我在大学里有几个领域不愿意碰:不喜欢数学,不喜欢Machine Learning,不喜欢并行编程。

结果是代数和概率没学好,Boss的一个很有趣的题目不敢接。前不久项目要用到基本的机器学习和MPI,翻出教材重看了好几天;课上讲到CUDA自己浅尝辄止,现在天天抱着Nvidia的资料啃。

专业课程的设置终究有它的原因,你永远都不知道,你不喜欢的那件事,在什么时候会挡住你的路。如果运气不好,说不定连是什么挡住了你的路都不知道。

二 游戏与现实

有一个很有名的段子,医学院的学生找老师去划重点,老师说,你打算跟将来的患者说,不好意思,这个病不是重点?

课堂、考试和大作业,终究是一种『游戏』。它不能太难以至于大多数人阵亡,它不能耗时太长以至于很多人饿死,它也不能太无趣,以至于大家觉得它很无聊。

但是教材那么厚,还有那么多参考书终究是有原因的,实践中的问题不会顾及你是否曾经对这个问题详加练习;不等式的难度是否超过了你算法课的习题;或者问题的规模是不是超出了你习惯的问题。

更何况,太多的问题书本上没有答案。C++书上,不太会讲到实践中tuple奇奇怪怪的用法或者是decay_copy对线程安全的意义,也不会讲到什么样的代码能内联什么样的代码不会被优化;算法课上,也不太会讨论B+树的节点插入的时候可以rebalance或者实践中B树的性能到底跟什么有关。

『考试内容』和『书本知识』天差地别,『书本内容』和『工程实践』又隔着鸿沟,想真正掌握一门学科,课堂讲义和教科书远远不够。

三 天赋与先发优势

最常听到的问题,是『成绩还行,编码不好怎么办』。

我就笑,因为我觉得,如果真的用心去『学』了相关的课而不是仅仅应付考试,编码应该有所提高才对:c++大作业让写链表的时候,有没有去翻翻std::list的实现?OS课上让写shell,有没有去翻翻类似的代码?做算法大作业的时候,有没有去查查工程实践中的代码是什么样的?做编译大作业的时候,有没有让自己的code尽量clean?学软工的时候,有没有仔细看看设计模式?

或许有人天生擅长coding,或许有人通过ACM的锻炼coding提高;但这绝非唯一的提高之途。作为一个工程师,对『先例』的熟悉和『自身经验』的累积,是远比天赋更宝贵的财富。

顺便说一句,在我ACM水平最高的时候,代码是变量乱飞作用域稀里糊涂的。很多ACMer编码水平高,是因为他们对待代码(和其他知识)比我认真。

四 结果与目的

别人看你的学生生涯,会有很多『评价因子』:成绩如何,奖学金和荣誉,科研,课外活动。加权平均一下,给你的学生生涯打个分数。

所以挺多小朋友从进大学开始,就开始奔着这个方向去努力:GPA,GT,进实验室。而当问起『你的兴趣是什么?』『你擅长什么?』的时候,往往很茫然:『其实我也没有什么特别的兴趣啦』。

但这些都是『结果』,不是『原因』。它们终究是衡量一个人的专业水平和综合素养的工具,而后者,才是大学应该给予你的东西。学数学也好,学编程也好,都是为了,当有一天用这些创造什么的机会摆在面前的时候,你可以把那份工作干得更漂亮,让自己更满意,幸运的话,惠及更多的人。

大学四年的意义,不仅仅是『换个敲门砖』,你可以做的多得多:认真寻找到一个自己擅长和感兴趣的领域;把基础知识认认真真学扎实;培养良好严谨的工程习惯;积累一些初步的经验。做好这些,那些你所在意的『敲门砖』,自然会水到渠成。

相信我,你今后不会有太多的机会做这些事的。

 

 

 

交互设计这件事

本文地址:https://blog.hoppinglife.com/?p=9

最近有两个客户端让我很闹心。

Android上的Twitter客户端Carbon更新了,新的Carbon有一个很漂亮的界面。(图片摘自Google Play)

问题?——我找不到我想要的功能在哪。

按Menu键没有反应,按返回键会退出程序,按那个加号是发新推。设定呢?帮助呢?为什么点twitter里的链接没有反应?

经过一段时间的研究,我发现打开菜单要点右下角你自己的头像——是的,那个加号和右边的头像不是一个按钮。是的,想要搜索、设定或者查看教程(教程藏在设定里面,如果你能找到教程,基本上你已经会用这个app了),你得猛击自己的头部——我的头很圆吗?和搜索功能有什么关系?

想要查看twitter的List,从边缘的右向左滑,但是要小心,如果你从中间滑,那你会来到conversation页面。用两个指头向上滑会跳到最新的tweet,但是要小心,如果你不小心用两个指头点中了一条twitter,那你会触发retweet功能。想要点击twitter里面的人名和链接?你要先点一下twitter,但不要点最左边发推人的图片——那会访问那个人的profile。——要想看到全部的对话,你要再点击一个按钮。

另外一个类似的应用是BeyondPod – 这是个podcast播放软件。在这个软件升级了新的版本之后我有两周都找不到怎么调整播放进度——没有提示,没有按钮;直到今天我不小心滑动了一下,发现『Now Playing』页面藏在播放列表右边。

这些软件坚定了我的判断——今天的app设计者,越来越把『酷』看得比『易用』来得重要。手势的滥用,就是最明显的例子。

其实,在我看来,今天的『手势』,其实和『命令行』没有什么不同:

-在GNU Screen的界面下,按<C-a><C-n>可以切换到下一个窗口
– 在Carbon主页的边缘从右向左滑动,可以调出list功能
-在FreeBSD下,ps aux会列出所有进程,包括它们是由谁调用的

有很大的区别吗?手势滑动看上去比命令行来得简单,但是它们同样要求用户记忆——哪个屏幕,哪个功能应该怎么调用。区别是,我愿意花时间学习shell来工作,我不想花时间学习怎么快速发推。而且在命令行下,我起码还有man page和–help可以救急。

我至今还记得第一次在展会上看到Windows 95——当时7岁的我只花了60s找到『扫雷』。除了『好看』,GUI的最大优点在于『易用』。这就是我们为什么愿意忍受繁多的菜单和按钮——当我需要一个功能的时候,我不用查阅500页的manpage就能找到它。

今天的交互设计师似乎早就忘了这件事——他们喜欢『最小化』和『直觉式』的设计,换个说法,他们喜欢把所有界面的功能都藏起来,让用户用第六感来找到它们。不幸的是,我的第六感和它们从来步调都没一致过。拜托,我的第六感有个名字,叫做Android Design

最后,对于有耐心看到这里的朋友,弱弱的问一句,Spotify新版里,怎么随机播放一个歌手所有的歌曲?

场外因素

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

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