少即是极多

少即是极多

感谢网友 @innocentim (Twitter) 投稿

这是一篇翻译练习。力图保留原意。若有不准确处,求速速指出。猛击此处(墙)看原文。作者为Rob Pike,贝尔实验室来的大牛,现在就职于Google。他主导了Go语言的创建工作。下面是正文——

——————————————正文分隔线——————————————

这是我在2012年6月的Go SF上演讲的文本。

这是一个个人演讲。 我承认,虽然面前的团队让Go诞生并延续,但是我的观点并不代表任何其他Go语言小组成员的意见。 我也想感谢Go SF的组织者提供这个和你们交流的机会。

几星期前我被问起:“你在推出Go的过程中遇到的最大的惊奇是什么?”我立即意识到了答案: 虽然我们希望C++程序员意识到Go是个较好的选择,但是令人意外的是,大多数Go程序员来自Python和Ruby这样的动态语言,而很少有来自C++的。

我们——Ken,Robert和我——是C++程序员(译者: Ken也用C++?),当时在为解决我们所写的这类软件产生的问题设计一个新的语言。 这似乎有点自相矛盾,因为别的C++程序员根本不关心这些问题,更不会去设计一个语言。

我今天想说的是关于那些激发我们创造Go的事情,和为什么它本不应令我们如此惊讶。 我保证这些内容更多与Go相关而不是C++,所以即使你不很了解C++你也能跟得上。

回答可以这样归结: 你认为”少即是多”呢,还是”少就是少”?

这里有个比喻,将以真实故事的形式给出。 贝尔实验室中心原来发放3位数号码: 物理研究是111,计算科学研究是127,如此这般。 1980年代早期,一个便笺飞过来说”鉴于你们对研究的理解有所加深,将为你们的号码多加上一位,以便更好地体现你们的工作”。 所以我们中心的号码变成了1127。 Ron Hardin半当真地开玩笑说如果我们真的理解我们的世界更好一点的话,我们将丢掉一位数字,将127变成27。 当然主管没听到这个笑话(这也不是我们希望的),但是我想这里面有点值得思考的东西。 少即是多。 你理解得越好,你将变得越简洁。

先记住这句话。

回到2007年9月,我在做一个庞大的Google C++项目的细微但核心的部分。 开发必须交互进行,但是我这部分在我们的Google编译集群上要编译45分钟。 同时,有个消息传过来说一群在C++社区的Google员工将开一场讲座,介绍即将到来的C++0x(现在称为C++11)。

在那场持续一小时的讲座中,我们听说了诸如计划中的35个新特性的说法——事实上还有更多,但是那场讲座只说有35个。 有些特性当然是细微的,但是讲座中谈到的至少是足够重要的。 提到的特性中,有些十分微妙并难以理解,比如右值引用(rvalue references); 有些特别符合C++范儿,比如可变参数模板(variadic templates); 还有些十分疯狂,比如用户定义的字面量(user-defined literals)。

那时候我问了自己一个问题: C++社区真的觉得C++错在没有足够多的特性么? 显然,从Ron Hardin的笑话的角度看,简化语言将比添加新特性取得更好的效果。 当然,对C++来说这很不靠谱,但是先记住这点。

在这场讲座的几个月之前我做了一场讲座(你可以通过YouTube看到),讲的是一个我1980年代做的一个玩具并发编程语言。 这个语言叫Newsqueak,而且显然地,它成为了Go的前身。

在我在Google工作的过程中,我发现我丢掉了Newsqueak中的一些点子。 现在我将重新思考它们,所以我才做了那场讲座。 我相信它们会让服务器端编程变得更容易,而且Google能真正从中获益。

我真的尝试将这些点子加入到C++中,可惜失败了。 我实在难以将一组并发操作融入到C++的控制流程中去——当真融进去的话,它们将变得十分丑陋,从而难以看到优越性。 另外,C++将它变得十分臃肿(虽然我从来没真正发现C++苗条过)。 所以我放弃了这个想法。

但是C++0x的讲座使我再次思考。 一件事十分困扰我——我相信也困扰着Ken和Robert——C++的新内存模型居然新增了原子类型。 为这个不堪重负的类型系统加上这么个细致精巧到极致类型机制�