少即是极多

少即是极多

感谢网友 @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++的新内存模型居然新增了原子类型。 为这个不堪重负的类型系统加上这么个细致精巧到极致类型机制十分的不靠谱,不是么? 将语言和今日的硬件绑在一起似乎有点目光短浅并且不明智,因为硬件过几年就有大变。

那场C++0x讲座结束之后,我们回到办公室。 我开始了另一个编译(译者笑),转过转过我的椅子,面对Robert,然后开始问一些尖锐的问题。 在编译完成之前,我们拉拢了Ken,并决定做些什么。 我们再也不想写C++了,并且我们——尤其是我——在写Google代码时,想让并发拿来就用。 同时我们也想解决”大系统编程”的问题,容后细说。

我们在白板上写下一组我们需要的东西——迫切需要的那种。 我们规划出大体的轮廓,忽略了语法细节和语义。

我仍然有一条碉堡了的那周的邮件线索。 这是一些摘录:

Robert : 起点: C,修补一些显而易见的瑕疵,去除繁杂的东西。 新增一些特性。

Rob : 命名为’go’。 你可以为这个名字编造各种理由,但是它确实拥有很多好的特性。 它短小,易于打出。 工具么: goc,gol,goa。 如果有个交互式调试器/解释器,可以直接叫’go’。 代码后缀是。go。

Robert : 空接口: interface {}。 将被所有接口实现(译者: 原文如此),并且可以取代void*。

我们并没有立即全部设计出来。 比如我们花了一年多才设计出了数组(array)和切片(slice)。 不过相当一部分重要的设计在最初的几天中浮现。

注意到Robert说C是起点,并非C++。 对于这点我不是很确定,不过我相信他说的是C,因为Ken在场(译者笑)。 但是最后我们并没有从C开始,这倒是真的。 我们从最初的草稿开始,仅仅从其它语言中借鉴琐碎的东西,比如运算符,各种括号和一些常见的关键字。(当然我们也借鉴了我们所知道的语言中的思想。)不管怎么说,我们破而后立,从头做起,以此来响应C++。 我们并非想做一个更好的C++,甚至不是一个更好的C。 它仅仅是一个对我们所关心的软件来说更好的语言。

最后,我们得到了既不同于C也不同于C++的东西,甚至比许多人意识到的还要不同。 我列了一个对于C和C++的Go的重要的简化的列表:

  • 常规的语法(不需要一个符号表来辅助解析)
  • GC机制(仅仅是GC)
  • 没有头文件
  • 显式依赖关系
  • 没有循环依赖
  • 数字常量仅仅是数字(译者: 没有类型)
  • int和int32不是同种类型
  • 字母大小写将确定可见性
  • 任何类型都可以有方法(没有类)
  • 没有子类型继承(没有子类)
  • 包级别的初始化和良好定义的初始化顺序
  • 同一个包的文件一起编译
  • 包级别的全局定义可以以任意顺序进行
  • 没有算术类型转换(常量可以弥补)
  • 接口是隐式实现的(没有”implements”声明)
  • 嵌入的结构体(没有类型提升和子类)
  • 方法像函数一样定义(不必定义在特殊的地方)
  • 方法就是函数
  • 接口就是方法(没有数据)
  • 方法仅仅靠名字匹配(不是靠类型)
  • 没有构造函数和析构函数
  • 后置增量/减量运算符仅仅是语句,而不是表达式
  • 没有前置增量/减量运算符
  • 赋值号是语句,不是表达式
  • 表达式求值顺序在赋值和函数调用时确定(没有所谓的”sequence point”)
  • 没有指针算术
  • 内存总是初始化为0
  • 对本地变量取地址是合法的
  • 方法中没有叫this的指针
  • 分段式栈
  • 没有常量或其它类型的注记
  • 没有模板
  • 没有异常
  • 内建字符串,切片和映射(map)
  • 数组边界检查

并且,我相信通过这一系列的简化,Go将比C或C++更具有表现力。 少即是多。

但是我们没法一下子把所有部分都做出来。 我们需要构建最基础的部分,比如说类型系统的表示,能良好应用于实际的语法,和一些无法形容的但能让库更容易相互操作的东西。

我们同样增加了C或C++中没有的东西,比如切片和映射,组合字面量(?),文件顶层的表达式(这虽是件大事,但是几乎不为人知),反射机制,GC等等。 自然,还有并发。

一个显眼的缺少的东西是类型的继承。 请允许我粗暴地对待它一分钟。

早先构建Go的时候有人跟我说,他无法想象用一门没有泛型的语言工作。 正如我在别处说明的那样,我觉得这是个很诡异的言论。

公平起见,他用自己的话说可能是他真的很喜欢C++中STL的那些容器。 以辩论为目的的话,我们来正面看看他的言论。

他说的意味着: 他发现写一个容器,比如以int为元素类型的链表,或字符串映射是一种不能忍的重负。 我发现这是个很诡异的言论,因为我几乎没把时间花在那些个问题上,即使我在用没有泛型的语言。

但是,更重要的是,他说的那些表示 类型系统 将会解除这种负担。 类型系统 。 不是多态函数,或语言级原语,或其它类型的辅助手段(helpers),而仅仅是 类型系统

这就是粘住我的那个细节。

从C++或Java来Go的程序员怀念和类型系统在一起的日子,特别是带继承和子类的那部分。 也许我在类型系统方面是粗暴了些,但是我绝不觉得那套玩意非常具有表现力。

我已故的朋友Alain Fournier一次告诉我说他认为学术工作的最底层是分类学。 然后信不信由你,类型继承正是分类学。 你必须决定哪个萝卜扔哪个坑里,每个类型的父类型,A是否继承B或者B是否继承A。 一个可排序的数组是一个带有sort方法的数组呢,还是一个长得像数组的排序器呢? 如果你觉得类型系统能解决所有设计上的问题,你必须做出这个无意义的选择。

我相信对编程来说那是个荒诞的思路。 真正的重点不在于事物之间的继承关系,而在于它们能提供些什么。

因此,接口这个概念进入了Go。 但是它们都是主要部分——真正的Go之道——的一部分。

如果C++和Java注重类型继承和类型系统的分类学,那末Go就注重组合。

Doug Mcilroy,Unix管道的最终发明人,在1964年(!)写道:

我们应该有一些机制能将程序耦合(串)起来,像花园软管那样——当我们需要另一种方式传送数据时,拧紧另外一段即可。 I/O也可以这么做。

这也是Go所提倡的道路。 Go吸收这个观点,然后把它推进得十分远。 这是一门关于(功能上的)组合和(调用上的)耦合的语言。

一个显然的例子是接口是组合各部分的途径。 关键是,那些部分是什么并不重要,如果某类型实现了M方法我就可以把这个方法填到接口里去。

另一个重要的例子是如何让并发性提供给我们不同的独立计算部分的组合。

并且还有一种不同寻常(但十分简单)的类型组合形式: 嵌入。

————————————————————————

我想提一个和之前不太相关的Go设计: Go被设计为大型团队用来写大型程序的语言。

这里有个概念是”大型编程”,并且不知何故C++和Java主宰了这个领域。 我相信这只是因为其历史巧合,或者是工业上的巧合。 但是被广泛接纳的观点是他们和面向对象设计有关。

我压根不相信这点。 大型软件需要确定的方法,但是更重要的是它需要强依赖性管理,干净的接口抽象和优越的文档工具。 C++没一点做得好的(虽然Java明显要好很多)。

我们还不知道Go语言能做到何种程度,因为现在还没有足够的软件是用Go写的。 但是我非常有信心于Go将会成为一个优越的大型编程语言。 时间会说明一切的。

————————————————————————

现在,回到我们演讲开始提的那个问题:

为什么Go,作为从头被设计为符合C++使用者习惯的语言,没有吸引很多C++程序员?

严肃点说,我觉得是因为Go和C++在哲学方面有着巨大的不同。

C++是将所有东西提到你指尖上(译者: 即多范式)。 我在C++11的FAQ上找到了这段引用:

C++能优雅地,灵活地,零损耗地(相比于手工操纵代码)表达抽象的能力大幅提升了。

Go并非这种”围绕式”的。 你并不需要所有的东西都内建好。 你不需要对每个执行细节进行精细的控制。 比如,你不需要RAII,但你拥有一个垃圾回收器,也意味着你不需要执行释放内存的操作。

你得到的是一组非常强有力但易于理解,易于用来构建积木的功能,这些积木可以用来组合出一个你需要的问题的解法。 这并不意味着它能像别的一些语言创造的解法一样快速,复杂,或带来思想上的激励,但是它总能保证易于书写,易于阅读,易于理解,易于维护,而且可能更安全。

从另一个角度说,这当然算作过度简化:

Python和Ruby程序员转到Go,因为他们不需要牺牲表达能力,却获得了性能的提升,并且能好好玩并发系统了。

C++程序员 并没有 转到Go是因为他们好不容易获得了对程序的精细控制,并且不想牺牲它们的任何一部分。 对他们而言,写软件不仅包括把事情做完,而且包括用特定的方式完成。

关键是,在将来,Go的成功将会颠覆他们的世界观。

并且从一开始我们就应该意识到这点。 对于C++11的新特性很兴奋的人们并不关心一个拥有如此少特性的语言。 即使最后他提供了如此多。

谢谢。

(全文完)

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊 有点差 凑合看看 还不错 很精彩 ( 31 人打了分,平均分: 4.29 )
Loading...

少即是极多 》的相关评论

  1. 这则有的深广了,先来讨论简单的也许更好:也是go的作者说的
    泛型编程的困境是:要么苦了程序员,要么苦了编绎器,要么降低运行时效率。

  2. 好玩的一个事情, GO 主页上的示例还有中文哪,『 fmt.Println(“Hello, 世界”)』。
    是他们为了显示国际化能力,还是纯粹幽默下啊。

  3. @chai2010
    chai2010提到的翻译版本比本文好不少。只举一例:
    “C++能优雅地,灵活地,零损耗地(相比于手工操纵代码)表达抽象的能力大幅提升了。”
    汉语里的逗号能像英语里面那么用么???

  4. GO语言挺优美,但是正则表达式太丑陋了!这一点让我对GO的印象大大降低,以为GO会改进目前CPP里面的RegEx,没想到是这样。还是继续期待C++11和Perl6了。

  5. @zhang
    由于个人习惯, 我提交的时候都是英文标点, 而在英文中没有顿号. 陈皓老师为方便大家阅读, 不仅配了图, 还将所有英文逗号和点号替换成中文逗号和句号了, 包括文中后缀”.go”变成了”。go”. 我想说明的是, 这不是译者中文修养的问题, 而是译者的个人癖好被误解了. 至于别处, 我对比了两篇译文, 各有到位之处. 本想修改, 只是我貌似没有该文的编辑权限了:(

  6. 纠正下“我已故的朋友Alain Fournier一次告诉我说”翻译成“我已故的朋友Alain Fournier曾经告诉我说“更好点吧!

  7. @stavka0619
    正如Rob Pike所说, 他最惊讶于Python, Ruby等动态语言程序员的到来. 那末Python是怎么做的呢? 热点部分用C封装即可. Go对C也有非常好的支持(cgo), 所以如果能将科学计算的热点部分, 即计算核心用C实现, 然后Go操纵全局, 比如并发, 通信什么的, 未尝不可.
    另外, 不知你是如何得出”gc一定慢”这个观点的.
    对于边界检查, 还是那句话, 热点部分用C. 没有谁强迫你只能用一种语言.

  8. 关于Go的效率取舍, 可以参考rsc的回答:
    http://research.swtch.com/gotour

    Q. What is an example of the kind of application you’re working on performance for? How will you beat C++?

    Our goal is definitely not to beat C++ on performance. The goal for Go is to be near C++ in terms of performance but at the same time be a much more productive environment and language, so that you’d rather program in Go.

  9. @Tim Shen

    那篇文章什么时候开始翻译的, 我也不太清楚.

    英文刚出来时我已经看了, 然后就是在 golang-china 看到那个译文了.
    开始的 名字是 “少是指数级的多”, 后来是参考 邮件里别人的建议 才该为 “大道至简” 的.
    因为发在了 golang-china 和 水木 可能流传得更广一些.

    golang-china 里人比较多, 关于Go的消息也比即时. 有空可以去那边看看 :)

  10. Go语言的表现手法是非常不错的,我曾今试图研究Go,但后来还是放弃了,原因如下:
    1、缺少函数库的支持,这一点是不可想象的;任何一个人想要做点有价值的东西,很多东西还要自己打造,就是不可取
    2、运行效率和Java差不多,并不是如他所宣称的达到c的运行效率
    3、没有对GPU计算的支持,对搞图形图像的程序员简直是一种羞辱
    Go语言只适合Google这样的公司做去他妈的网络编程

  11. @thkfly

    thkfly :
    Go语言的表现手法是非常不错的,我曾今试图研究Go,但后来还是放弃了,原因如下:
    1、缺少函数库的支持,这一点是不可想象的;任何一个人想要做点有价值的东西,很多东西还要自己打造,就是不可取
    2、运行效率和Java差不多,并不是如他所宣称的达到c的运行效率
    3、没有对GPU计算的支持,对搞图形图像的程序员简直是一种羞辱
    Go语言只适合Google这样的公司做去他妈的网络编程

    1.python才开始的时候也是库少,这不是go team该做的事,第三方库会越来越多的,需要时间;
    2.那是因为go团队还没怎么做性能优化的部分,编译器和gc也在改进中。《unix编程艺术》中有句话叫做”不要过早的优化”。
    3.同样,需要时间,不论是第三方还是官方支持。goang-nuts里倒是有不少关于集成opengl方面的讨论。

  12. go语言很多设计还是太随意了,使得代码可读性很糟糕,而且本来应该忽略的细枝末节去无线放大比如{ 在下一行还是行末。

  13. go选择了降低效率,用的interface {}的方式。

    haitao :
    这则有的深广了,先来讨论简单的也许更好:也是go的作者说的
    泛型编程的困境是:要么苦了程序员,要么苦了编绎器,要么降低运行时效率。

  14. C++程序员并没有转到Go是因为他们好不容易获得了对程序的精细控制,并且不想牺牲它们的任何一部分。 对他们而言,写软件不仅包括把事情做完,而且包括用特定的方式完成。
    如果go在前。我倒觉得c是为了go/c++这帮程序员而设计出来的了

  15. 我觉得C++的发展已经越来越玩具化(某些学院派专家的玩具),脱离实际问题,走入了一跳死胡同,C++的演进总是纠结与模版和一些无关大局的语法糖。请问:难道没有那么多模版形式,我们就不能写代码吗?一堆堆砌的模板除了把问题搞的更隐晦以外,没有其它任何好处。现代编程语言应该再OS之上,再建立一个虚拟机,这个虚拟机封装了领域内的基本问题,譬如垃圾回收,譬如并发通信(go,erlang, c#….)。用C++写OS?似乎不太合适,但C++并没有比OS提供更多的抽象机制,C++写图形库比较合适,这也是C++开始应用的领域,不过在这方面:2000前的C++已经足够好了,所谓C++0x, C++1x 除了把问题搞得更麻烦,没有任何好处

  16. “请允许我粗暴地对待它一分钟。”,这个粗暴,应该是rough的意思,是粗略,我想说。你的文章翻译的很好。这里只是提一个可能是我认识误解的地方。

发表回复

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