微软架构师谈编程语言发展（四）

本文是对微软Channel 9中采访几个语言大师的视频的翻译。这些语言大师高屋建瓴，有点有面地谈到了多个语言的发展和语言的相互关系，对于我们开拓视野非常有帮助。由于只能靠听来翻译，篇幅又长，译者程化将其分成了几部分。这是全文的第四部分，读者可以在文章末尾找到其他几篇的联接。

 

Charles：你这么一说，关于“函数型”编程，我马上想到一个问题是：在现有基础上再加一层必须考虑的抽象，实际上能不能增加程序员的生产率，是否真的有帮助？作为程序员，现在还要考虑“副作用”的问题。反正我现在用C#还是其他语言编程的时候，是不会像一个“函数型”程序员那样考虑副作用的。

 

Herb：往一个语言上增加更多的特性无法使其变简单，这是个我们面临的基本难题。

 

Anders：作为一个语言设计师，对于编程语言，我们所能做的是——减缓新特性不断累积的速度，从而避免最终的倒塌。我想说的是，你永远不能收回某个特性。理论上，你可以收回某个特性，实际中，你不能这样做，因为后果是若干代码的崩溃，这行不通。

 

Brian：是的，在从VB6到VB.NET的过程中，很多人已经感到饱受折磨了。是的，（微软的）解决方案是说那（VB.NET）是个完全不同的语言。但是，我认为，“函数型”编程的概念已经出现了不短的时间，新毕业的程序员至少听说过这个概念。他们在Python、JavaScript或者其他什么地方见过lambda表达式，或者他们学过Scheme，总之这不是个没听说过的东西，因此，当他们在C#或其他的更传统的编程语言，如VB或C++中看到这些概念的时候，他们并不会感到畏惧，因为他们了解这些概念的优点，他们知道这些东西如果用得正确，可以增加代码的可组合性。你知道，传统语言的可组合性靠的是程序员的自觉。在某些方面，Haskell编程比“命令型”编程要痛苦得多，然而反过来说，它也比“命令型”编程要简单些，因为你不会把事情弄得一团糟。呵呵呵。

 

Anders：这里我想插一句。我认为，在很大程度上，我希望我们在C#或VB上做的工作至少是——在很大程度上对“函数型”编程进行“去神秘化”。学院式的人总是倾向于让事情听起来比实际的要复杂，因为这样一来就显得他们自己比较聪明。“呃，我并不是针对任何人，但是，这里有不少符号代数和其他东西呢！（译者注：音频提高了，似乎在学某些人的语气）”。当我向人们解释lambda表示式时，大家是另一种感觉：“你的意思是他们就是函数？这有什么新鲜的？我们早就有函数了，lambda表达式只是些语法糖衣外壳吧？”是的，lambda表达式确实只是语法糖衣外壳，但这是种强有力的语法糖衣外壳，它使你能按照一种新的方式去思考问题，以前总是存在的一些语法噪音——必须声明函数，进行委托，等等——就会逐渐减少，最终，一个全新层次的表达式列表会产生出来。这才是关键所在！围绕着“函数型”编程还有非常多神秘，我希望我们能够（在打破神秘上）有所突破……

 

Herb：关于（Brian）说的教育问题，就是关于人们能够在学校中学到的东西的说法，我不太同意。我真的希望情况确实如此，但是我认为缺乏证据，或者说除了 “Pascal熟悉者”之外，我们无法获得更多。不管是在学校还是在今后的职业生涯中，人们都认为自己接触了多种语言，因为他们用过C、C#、C++、VB以及Pascal。但是，这些语言本质上是一样的，是同一族的语言。人们并没有接触过APL——编程就象在解释器外壳（译者注：可以想象DOS的命令行）上敲东西；不熟悉Prolog——任何东西都是规则；不知道Lisp——所有的都是链表。只有当你深入了2到3种这些东西后，你才知道，并不是所有的东西都是命令。也许在你今后的职业生涯中用的都是命令型语言，正如我们大多数人一样，但是，你不会对其他看待世界的观点一无所知。某人从小到大，如果没有离开过成长的城市，如纽约，超过一英里的话，会错过不少有趣的地方，不管你是否想在其他地方住下来，你应该知道它们，体验它们。

 

Brian：呃，我觉得这是个渐变的过程，当然，我确实观察到年轻一代程序员对于“函数型”编程有更好的认识了。你知道，10年，15年之前，如果你和人们谈起Scheme时，人们会感到不解地看着你，“什么？你在说什么？”。现在，人们听说过了，他们见过“函数型”编程的关键字。而且，通过JavaScript和Python，人们尝试了“函数型”编程，也使得这些东西更加流行。我并不是说已经出现了巨大的变化，我是说逐渐的变化和更多的认知，人们不再象以前那样看到这些东西就害怕了。

 

Erik：也许JavaScript是这个世界上最……（译者注：Brian一阵激动的插嘴，搞得Erik的话听不清了）。我不确定当人们使用JavaScript时，他们是否意识到了这是一种把“函数”当作第一要素的语言。

 

Brian：你可以在运行的时候创造它们（函数）……

 

Charles：所有的东西都是一种类型，所有的东西都是对象，是吧？这是个有趣的语言。随着整个互联网的发展，你认为这种语言也应该有所进化……？

 

Brian：这里的“所有的东西都是对象”，不是面向对象的意义。这里是从“任何东西都是关联链表”的角度来说。现在我听起来像一个老Lisp编程者（译者注：Lisp基于链表），是吧？一个JavaScript的对象不像一个C#对象那样——所有的内存排列都决定了，什么东西都静态地决定了。这意味着所有的东西都可以添加、拿走，可以违反规则，它确实只意味着一个关联链表。

 

Anders：属性包……

 

Brian：是的，属性包的说法更好！

 

Erik：是的，值可以是函数、其他对象，或者是其他属性包。

 

Brian：JavaScript其实就是源自Lisp的Scheme。我又在说Scheme，因为我也许是这个屋子中唯一老到听说过这个词的人，呵呵！但是，Scheme有点类似于“上帝的Lisp”（译者注：不知道是God’s Lisp, Guard’s Lisp还是什么别的，懂得有限，暂时按God’s Lisp处理，达人请指教），所有的噪音都被消除了，只剩下最基本的、最少的东西。JavaScript就是把这些东西带到了前台，披上件不那么可怕的外衣的结果。因为JavaScript看起来有点“C”的味道，你可以使用花括号！呵呵！

 

（一阵乱哄哄）

 

Charles：但是，JavaScript只是一种解释性语言，而且，对开发者来说，用它编程也不是很有效率。JavaScript不像C#或VB，它没有一种真正的面向对象语言所应该具备的IDE，以及你可以工作于其上的框架。

 

Anders：呃，JavaScript是一种弱类型语言，或者说动态编程语言。人们经常把“编译时”与语言的“类型强弱”相提并论。但是，这两个概念其实是相互独立的，是吧？你可以有一种“强类型”，然而在运行期编译的语言，如果你真想要这样的东西的话。但是，对我来说，我以前也讲过，我非常乐于向那些喜欢“动态语言”、“脚本语言”的人指出，正是他们所醉心的那些地方会有问题。经常地，人们都理所当然地认为，如果没有类型碍事，就不用声明什么东西了，可以随手就用，诸如此类。这样干的时候你确实能够更快地写程序，然而，这里有一个陷阱：因为没有类型，我们（编译器）给你提供的帮助就少得多。当你写“X.”时，对不起，“.”之后是什么我们没法告诉你，我们没有足够的智能显示给你，因为我们没有任何办法知道将发生什么。有时我们可以猜，但我们有可能猜错，有时我们根本就一无所知，对吧？X或者其他参数，我们不知道将发生什么。我发现，有趣的是，我们在C#中进行的类型推论的工作，在许多方面都使得C#编程看起来更像动态语言，因为不会随时看到类型，甚至压根看不到。但是，类型在那里，静态地在那里，这也意味着，我们仍然可以给你提供“语句完成”这样的智能帮助。

 

Charles：你是在说“var”关键字啰？

 

Anders：“var”关键字只是个例子。光看这个关键字，似乎这是动态类型，然而，这是静态类型。当你定义“var Blar”时，我们知道“Blar”是什么类型；当你写“Blar.”时，“.”之后我们可以为你显示出东西。

 

Herb：我们（C++）中也在做一样的事情。我有一个“int”类型的vector，我从该vector的头部取出一个元素，我有什么必要再用vector 来声明一个遍历器？编译器知道它是这个类型，编译器能够将类型正确加到变量上。这就是“var”类型干的事，你不必到处都写出类型信息。这带来了很大的好处，你可以书写更好的“范型”代码，以前那些东西是写“范型”代码的障碍。

 

Anders：我想说的是，（如果有类型），我们就能在你写代码的时候给你许多的帮助，尤其在“智能感知”上我说是大实话。当今世界，如果你想把“智能感知”去掉，人们绝对会大叫“不！不！”，呵呵，这工具太有用了。但是，这里还有性能的问题。我是说，当编译器知道类型时，它能够为你生成更好的代码。就是说，你会得到更好的执行效率。

 

Erik：这里有件趣事。几个月前我们有次编译器XX（译者注：没听清），参加者都反映说，“喔，你知道，F#是最好的动态语言！”要我来说的话，F#是拥有最先进的静态类型系统的语言。当然，你不用写任何的类型，因为编译器帮你推断了所有的类型。很有趣的是，人们经常混淆“不用写类型”与“动态类型”。

 

Brian：这些人可都是写编译器的职业程序员！这是在课程结束时，做调查时出的趣事：“你最喜欢的动态语言？”“F#！”

 

Charles：但是（结巴了一阵，可能是震惊了），从开发人员的角度来看，动态类型是设计期的事吧？就我自己而言，如果我不必对任何东西进行强类型处理，我就会假设是动态类型。这是不是错了？我是说，编译器是怎么弄的？

 

Anders：“动态类型”和“隐式类型”是有区别的。一种情况是，靠编译器推断出类型，但编译器在编译期就推断出来了。另一种情况是，编译器在编译时一无所知，它假设这东西可以是任何类型，然后在运行时的适当时机，检查到底是什么类型。后一种情况下，当你分发一个虚函数调用时，也许会使用一个查找表，或是别的什么东西，因为你压根还不知道那是什么东西。前一种情况，根据到底是C#或是C++，你可以预先构造好虚表，准确地知道使用这个虚表的哪个内存地址来找到实际的东西，因为我已经计算好了。这就是预先有效地计算好了所有的东西。但是，人们往往错误理解（静态类型）为，“我，我这个人本身，必须在任何时候亲自手动写出类型”实际上这并不必要，因为类型可以被推断出来，如果你在一个地方知道了类型，你可以跟踪程序逻辑，根据这里发生了什么，类型是如何变化的，从而知道在另一个地方类型是什么。如果你是个足够聪明的编译器，你应该可以做到这些，是吧？我们正开始把这种“聪明”加入到程序语言中。

 

Brian：F#可能是这方面最好的例子。F#甚至欺骗了职业编译器程序员！我认为人们真正喜欢的是快速的反馈。人们喜欢快速看到结果。在他们的意识中，他们把这种喜好和“动态”相混淆了。

 

下面我具体讲讲：你输入了一个函数，然后马上敲入一行代码来测试刚写的函数，如果能够正常工作，你就可以放心地忘掉它们（译者注：指可以投入下面的其他工作），这是人使自己的“大脑堆栈”保持满负荷运作的方式，是人的力量。

 

历史上，“动态语言”在使人以这种方式工作上卓有成效。你打开一个Lisp，你实际上得到的是一个Lisp的监听器，你键入代码，然后在相同的环境中立即测试代码。但是，这实际上是个工具问题，与编译器什么的完全没有关系。你能够使动态语言有一个好的IDE和交互的开发环境，你也能使静态语言，如F#，拥有这样的IDE和交互的开发环境。这就是Sam在F#演示上干的事情。他打开好长一段代码，用鼠标选择它们，用“GO”按钮来执行；然后他打开另外一段代码，再用鼠标选择，再按“GO”来执行。所有的人都以为这是动态解释执行的。实际上，这是静态的，完全编译的。这就是欺骗行家的方法。

 

但这确实是人们喜欢的东西。大家都喜欢能提供“不断反馈”的好工具，或者是“交互式开发环境”，无论你管这叫什么。只要你能够随时写代码并且测试，你就不必写一大堆代码后再测试。你会这样想，“嘿，我写了个叫‘RandomDouble’的函数，让我把它敲进去看看是否能工作”。如果能正常工作，你就可以在进一步的Debugging前把它忘掉（去做别的工作）。