鱼是最后一个看到水的

By 刘未鹏(pongba)

C++的罗浮宫(http://blog.csdn.net/pongba)

TopLanguage(http://groups.google.com/group/pongba)

《你的灯亮着吗？》的最后一页画着一副大大的彩插：

鱼总是最后一个看到水的。

实际上，这句话有很多引申说法，其中最著名的一句是：

如果你有的是一把锤子，那么所有东西看起来都像是钉子。

不过后一句内涵文实在有误导嫌疑，因为这句话的表达方式很容易让人触摸不到问题的本质：即之所以所有东西看起来都像钉子，是因为人倾向于在既有框架下去解决问题；更重要的是，在这个过程中很难觉察到框架约束的存在，正如鱼觉察不到水的存在一样。而这一切背后的本质原因则是：

人是有很强的适应性的。

这个谚语应该作为问题解决者的座右铭之一：忽视既有框架的约束很容易导致sub-optimal的解决方案。

普通人遵守规则，牛人无视规则，伟人创造规则。

而要做到无视规则乃至创造规则，首先就要知道规则的存在才行。最近的“征途”事件就很好的说明了这一点：在既有框架下解决问题很多人都会，难就难在意识到框架的存在并突破它。

体现在程序员这个行业里面，也有很多相应的有趣现象：

#1 设计模式

《设计模式》被许多初学者奉为圭臬，认为那些看上去精巧的东西才是真正牛13的，值得学习的。而且，更聪明一点的人甚至会唯恐学的东西还不够复杂，因为越是复杂的东西搞出来越是有成就感。然而事实是，把简单的事情搞复杂的人比比皆是，把复杂的事情搞简单的人凤毛麟角。

实际上，《设计模式》里面曾经提到，其中大部分的模式都是建立在smalltalk/C++的前提之下的。这个前提（框架）很可惜的被所有人扔到了风中，并将那些模式泛化为放之四海而皆准的准则。Peter Norvig老大有一个著名的ppt，里面提到在《设计模式》的23个模式里面有16个模式放到动态语言（尤其是LISP）下面就根本不是什么模式，而是显而易见无需费力就能完成的任务。c2上的老大们则将Peter Norvig的言论进一步泛化，提出“设计模式象征着语言所缺乏内建支持的特性”的说法，并罗列了一个“设计模式<=>语言特性”的对照表。CodingHorror的Jeff也跟着掺和，换汤不换药的跟贴说“设计模式其实是语言进化的路标”（设计模式的大量重复使用便意味着应该集成到语言内建支持中去了）。

不管怎样，有一点是确定的，就是first-class的内建支持（简洁）永远优于补丁式的解决方案（绕来绕去）。新版Javascript加入对multi-method（VisitorPattern）的直接支持——Generic Function——就是一个极好的例子。当然，Rubyers肯定也不会忘了跟着Lispers叫唤一把Closure是如何一个each方法搞定所有的迭代过程，全面打败笨拙的IteratorPattern的，并顺便奚落一下石器时代的Java。

总而言之，大众对设计模式的定性存在严重的问题，许多人把设计模式当成是精巧的利器，就如同解数学题时神来之笔的技巧一样。然而实际上远非如此，设计模式是补丁，其出现往往意味着语言不够强大，其使用意味着大量的、与所要达到的编程目的无关的样板式代码。

著名的Head First系列的《Head First Design Pattern》在书的靠近结尾的地方也郑重提醒（Jeff同学觉得这个提醒应该用大号字体放在最前面）：

不要觉得不用设计模式就不够好不够强大，以尽可能简单的方式完成任务才是王道。

（不过值得注意的是，简单并不意味着邋遢。）所谓无码胜有码，设计模式，也是如此。

#2 语言之争

语言之争是程序员群落永远的话题。Flame war是个一触即发的东西。语言之争的原因之一就是人们容易在自己熟悉的语言框架下思考，并形成严重的偏见，只看到自己语言的好处，甚至于将并非好处的地方也觉知为好处。

#3 语言的使用

一个程序员越是熟悉一门语言，越是容易为这门语言所累。因为这门语言的特性对他来说就是鱼的水、木工的锤子。一遇到问题首先脑子里就会闪出若干语言特性，既有方案。当然，从统计意义上来说这并不是什么坏事，也许大多数时候是有助于问题的迅速解决的。但那20%的时候这种思路带来的害处也许就带来了80%的头大。

比如熟悉Java/C#/C++的程序员可能会觉得“迭代器”的概念是非常直观的，甚至是非常漂亮的；而介绍这个概念的书当然也不会上来就给自己一瓢冷水说迭代器的出现实在是没办法的补丁。所以大家也就觉得这玩意好使，优美了，因为很多时候我们是用“足够”来定义好坏的；只要还算能用，我们就可以觉得“不赖”。然而，事实上，正如前文所说，翻一翻《设计模式》的Iterator Pattern一节，再翻翻镐头书中介绍迭代的章节，就会发现更简单的迭代方案是根本无需定义多余的迭代器类和继承体系。

另一个思维被语言束缚的好例子是这篇“API考古之：C风格的Java API”，里面提到一个家伙设计了这样一个Java API：

int enumerate(Thread[] list); // list all the threads in the current ThreadGroup

避免思维被一门语言束缚的最好办法就是“学习其它语言”。

#4 C++

之所以加上C++有两个原因。一，这个Blog以往主要写C++。二，C++在所有语言里面有特殊性。在C++里面，存在无数的惯用法和技巧，好听一点叫技术。无数本书用无数比特的唾沫描述这些技术并将它们吹得精妙无比。然而，最近由TopLanguage的兄弟们群策群力汇集问题对Bjarne老大的一次“多对一”访谈（采访稿en版）中，我问了两个问题：

1. 学习C++的第一原则是什么？

2. 使用C++的第一原则是什么？

猜答案是什么？

关注基本的（fundamental）概念和技术，而并非特定的语言特性，尤其不是C++中细枝末节的语言细节。

有人肯定会问，那还叫学习C++吗？学习一门语言自然要从它的语言特性开始不是？否则还从何学起呢？这个问题的关键在于要意识到，我们当然是需要掌握语言特性的，但重点在于要从语言特性看到特性背后蕴藏的支持设计和编程的概念（concept）。比如类支持的概念，继承支持的概念，虚函数支持的概念，模板支持的概念... 这个论点泛化之后的结论就是：学习编程重在学习基本的概念和素养，这些是长期稳定不变的东西。投入精力学习特定的细节，学得越是细，就越是容易淘汰。Bjarne的说法就是：一旦掌握了基本的概念，要用到细节的时候，细节自然会fall into places。

2. 使用C++的第一原则是什么？

将你的（pongba按：与语言无关的）设计理念（概念）直接映射为C++中的类或模板。

也即是我前一阵子文章中建议的“脱离语言思考，使用语言实现”。脱离语言思考的好处是显而易见的：可以避免受到语言细节作为既有框架的干扰，避免过早被实现细节缠住，于是便容易找到最直观的解决方案，即便后来发现语言成了绊脚石，也可以选择换语言或者明确地知道自己做了什么折衷。

结论

Think out of the box.

发表于 @ 2008年01月04日 07:02:00|评论(loading...)|编辑