Neal Ford谈编程语言和平台

个人简介 Neal Ford就职于ThoughtWorks，是一名软件构架师，职称为Meme Wrangler。ThoughtWorks是一家全球化IT资讯公司，提供end-to-end软件开发和交付。他设计、开发软件，撰写教材，编写杂志文章，制作课件，录制video／DVD演讲，出版过5本书。

   

1. 这是来自在三藩市举行的QCon大会上的采访，今天接受我们采访的是Neal Ford。Neal，首先能否向大家简单介绍一下您自己和您的工作？

我在ThoughtWorks工作。我们公司是一个国际化的咨询公司。我在公司的职称是软件构架师，但在美国，很多时候，职称意味着post- useful，或者只能说我十年前曾用COBOL写过些当时超赞的代码。在TW工作其中一个好处是可以选择自己喜欢的职称，所以我给自己的头衔是Meme Wrangler。Meme指的是思考单位——这是思考单位在数学上的表示，也指代信息单位，而Wrangler则是因为很多问题往往都会引发争辩。因此，我在TW的正式头衔是ThoughtWorker和Meme Wrangler，但我的日常工作是负责项目上的软件构架，担当其技术领队。我负责过Java项目，有时候也做.NET项目，而目前大部分都是Ruby项目。

   

2. 听说您对转换语言和JVM很感兴趣，您能否跟我们大家讲一下您在这方面的看法呢？

这是目前Java世界里非常有意思的一个方向。Java实际上包括两个元素：语言和平台。单看语言，Java这门语言已经很老了，我说它老是因为它存在已经有12年了。在过去的十二年里，我们对这门语言有相当的研究，它曾尝试回头去兼容C、C++来吸引C、C++程序员，这反而给它本身带来了很多负累。

回头去兼容C、C++带来的问题是，在发展到一定程度的时候，它定当停止这样的兼容，之前为此所做的投入则突然成为累赘，Java有很多这样的包袱。在 Java诞生最初，它需要这些兼容功能来吸引C、C++用户，否则它可能没法成为一门成功的语言。但总有一天会达到这样一个转折点，曾经的优点转变为缺点。如今，无论是Java核心还是简单到从0开始计数，我们对其中的缺点都了如指掌。

从0开始计数在一门没有指针的语言里实在有点不知所谓，但在C那样使用指针的语言中却非常必要。数组在C语言中实际上是指向某块内存的指针，如果把index数乘以数组元素的个数，得到值就是内存中对应的偏移量，以这样的方式创建数组效率就非常高。但在Java没有指针这个概念，从0开始计数没有任何意思，应该选择从1开始，但就是为了要兼容C语言，所以遗留到现在反而成了包袱。但幸好，Java是由两样东西组成的：语言和平台。

现在，我们可以好好利用Java平台，把Java语言看作是Java平台上的汇编语言，选择Groovy这样更容易表达的语言来编写应用，打个比方说，Groovy好似是Java的新兴方言。Groovy是Java向Ruby方向发展的结果，但它仍然保留了Java世界的一些惯用特性。再来看JRuby，JRuby是目前非常漂亮、非常强大的语言，它在JVM上运行，可以编译成Java字节码。无论是Java，还是Groovy，其表达力都远远不如Ruby。

实际上，Java可能仍然是当前最强大的主流语言，Java开发员完全能够抓住这个优势，因为JRuby现在可以在Java平台上运行。这在Ruby世界里不是什么特别的事情，从字面上就可以看出JRuby只是Ruby在另一个平台的表示，就好像你有Windows下的Ruby跟Mac下用的Ruby一样，JRuby就是Java版的Ruby。Ruby这门语言实在是很强大，所以诞生这样一个Java版的Ruby意义非常重大。Paul Graham有一篇比较各种语言的博文，这篇博文写得非常好，甚至可以说是一篇很好的评论，他选择用来比较各门语言的准绳非常确切。按照他的比较准则，以 9分为满分计，Java、C#以及现代静态强类型语言只获得4分。

按同样的准则，Ruby则获得了8分，可见它是门十分强大的语言，尤其是Ruby on Rails蕴含了Ruby的许多超强特性。TW在Ruby开发方面很有经验，我们手头正在开发很多Ruby项目，还有源源不断的客户来委托我们开发 Ruby项目。我们不久前刚刚发布我们有史以来第一个商业软件——Mingle，这是一款Agile项目管理工具，因为我们希望能够尽快把它推向市场，所以选择Ruby on Rails来开发，但这款软件最后部署环境是JRuby，主要是考虑到JRuby的部署比标准Ruby on Rails方式要简单很多。

因此，我们结合了两者的长处，利用了Ruby的高效和Ruby on Rails强大的功能，同时也利用了Java平台上部署的便利。我相信这种情况在今后会越来越频繁。大概一年前，我提出了一个新词——polyglot programming(多语言编程)，polyglot指的是那些会说多种语言的人。有人认为这个世界存在着一门完美的语言，但我觉得完全不可能，因为每一门带有特殊目的语言的诞生都是为了以更简单的方式解决某些问题。实际上，我们一直在做这样的事情。其实，你写的每个软件都会采用像Java这样的基础语言，但软件还需要和数据库交互，这时候你就会采用SQL，然后你的软件还需要一个web UI,也就意味着要用到Javascript。当然由于每个XML文档都有自身的语法，XML有它自己的语言，因而，这又是另一门语言。

我们一直以来都是以这样的方式在开发，但鉴于Java平台的工作方式以及JVM上可以运行Java以外的其它语言，我们可以把这种开发方式更进一步向前推进。我相信，在将来，大家会更多地利用那些出于特殊目的而设计的语言来解决对应的问题。根据摩尔定律，增加晶体管不再提升处理器的功能，因而目前选择的突破方式是增加芯片，也就是说我们编写的代码要能更好的处理多线程。目前，关于这个问题，我们不需要有太多顾虑，但三年前我们也没有去担心 Javascript，当时大家都以为用户已经习惯了静态网页,直到Google跳出来说web应用其实可以不那么烂，我们才开始注意 Javascript。

他们之后又推出了Gmail，然后，突然之间，我们必须要为Ajax提供支持。我觉得并发世界（concurrency world）会发生相同情况。目前不需要对此太担心，但总有那么一天，会有那么个人跳出来宣布说所开发的软件能够真正地利用所有的处理器。到那个时候，我们就突然又要开始担心自己的软件是不是很烂了。编写好的多线程代码不是件容易的活，尤其是要用Java编写。如果不相信，你可以去翻阅一下Brian Goetz编写的《Java Concurrency in Practice》，这本书里囊括了所有在用Java编写多线程代码时会遇到的难题。

但光明的一面是，我们没有必要用Java来编写多线程。在polyglot programming概念的引导下，你完全可以用另外一种语言独立编写多线程部分。用Java太难，所以你可以选择用Scala来写，Scala是一种函数式语言，它的代码能够转换生成对应的java代码。你也可以用Jaskell，它实际上是Java在Haskell上的“方言”。这些函数式语言都继承了线程安全的特性，所以你没有必要编写同步的日志，也没有必要去担心contentious，你只要写你的代码，并发问题交由语言来处理就好了。

当然，用这些语言来编写整个应用软件很难，其实没有关系，因为你只是用它们来实现可恶的多线程部分，而UI部分你可以类似Rub on Rails的东西来实现，与主框架的交互部分你又可以用Java来写，毕竟Java在这方面提供很多类库，而且最后的软件也可以在同一个JVM上部署。实际上，这个解决方案比运用对象关系映射那类东西要简单得多。后面那种情况，不仅仅要多语言编程，还牵涉到跨机器的问题，非常棘手。但如果只是牵涉到同一个 JVM的话，所有的开发都可以在同一个JVM上完成，失配就不再是什么大问题。对于格式可能需要关心一下，但鉴于这些语言中大部分是运行在JVM上，支持、遵守Java变量的格式，所以与其底层Java部件的交互就非常得轻松自如。

实际上，在JRuby中，你可以运行或者编写Java类库，你还可以编写map之类的东西，Ruby可以混入(mix)Java的接口。研究人员已经做了相当多的工作，成功地开发了这样一种从基础上就和Java完全不同的语言——Ruby。Ruby和JVM的结合非常好，你现在完全可以充分利用Ruby的所有优点，最后仍然在JVM上部署软件，那些基础设施运维人员也就不会因为你说要转换开发语言而突然“被吓死”了。

   

3. 您前面提到Groovy，为什么您认为元编程（meta-programming）非常重要呢？

Groovy和JRuby两者比Java更强的一点在于元编程，而元编程实际上对你的代码直接产生影响。“元（meta）”意味着“外部的”或者是指“关于”，正如元数据（metadata）指的是描述你的数据的数据，元编程（meta-programming）就是针对你的程序的编程。这听起来好像是计算机科学领域深奥的话题，其实不然。这也是Groovy和JRuby胜过Java的其中一个方面，因为Java在元编程的支持方面非常有限。Java中，你可以来注释方法并通过反射得到注释，但值得以这种方式来工作的地方不是很多，其中一个用途是创建私有方法的测试。

JUnit 有一个第三方类库叫做JUnitX，它是你代码中私有类型函数的反射,从而使得你可以测试这些私有函数。在元编程方面Java有很大的局限。比方说，你不能在Java中凭空合成新方法，因为Java语言本身不允许这样的操作。你需要的是能够在不手动编写所有代码的前提下实现功能强大的应用程序。这很重要，但也不是说Ruby下能做的事情很多在Java中就根本没办法做到，只是实现过程实在麻烦到没有人愿意去做。

例如，Java中你可以往一个类里面添加函数，但最后你往往都需要借助另一种语言来实现这项操作，而这恰恰是Groovy开发员所实现的功能。他们站在 Java上层编写并生成Java bytecode，但他们用的完全是另一种语法，所以最后生成的bytecode也和一般由Java生成的不同。这些代码可以帮助你打开类，进而打开 java.lang.String类或者往其中添加新方法，对于Java开发员来说这很重要，因为几乎每个项目都脱离不了String utils类。

Java 是一种面向对象的语言，而运用面向对象语言的方式则是创建子类，但string这样的基本类型是没有子类的，因为在Java中，这些基本类型都被定义为 final。我不知道这出于什么原因。在你期望从String上创建子类，并打开String类修改该类的时候，Java的局限性让你不得不转移到过程式编程来创建String utils类。Groovy团队帮助你实现了这一功能，JRuby团队也不例外，他们所用的方式都是为java.lang.String提供一个代理类（proxy class）。这样，当你调用java.lang.String类的时候，实际调用的是代理类，而你则可以在这个代理类中添加新函数。这个功能是必须要具备的，因而非常重要。

在实现每个项目时，String所包含的方法其实远远不够。所以，Groovy把元编程推进到另一个高度，Java编程因此更加简单。但Ruby的这一动作却做的有点过了头。Ruby中，你不仅可以打开类，而且还能在运行时做一些非常复杂的操作，并且Ruby处理运行时的方式是Groovy或者Java中永远都不可能实现的。由于Ruby的设计目的是成为超强的元编程语言，所以Ruby中允许的一些操作在Groovy或者Java中可能很难实现或者根本就不可能实现。其中包括非常轻便的eval操作，这可以将代码以string的类型返回后再执行。

Groovy中也可以这样做，但你必须特别创建一个Groovy builder来完成这个任务。Ruby中有几种方式可以选择，这些方式都控制eval代码的范围。你也可以强制Groovy以类似的方式来实现。但 Ruby背后有相当多复杂的东西，Java开发员对此非常头痛。Ruby中，你能做的操作之一是把类似ArrayList的类打开，然后向 ArrayList中添加新方法。这个可能听上去很恐怖，你也可能不需要向ArrayList中的每个实例都添加新方法，这时候，你可以选择向 ArrayList的一个实例添加新方法。

这意味着新添加的方法只对ArrayList的那个实例有效，这种方式非常新颖，而且效果很不错，很有用。因为Ruby中有一个影子元类（shadow meta-class）的概念，，所有对象的背后其实都有一个特殊的类，而你可以在影子类中向这个类的实例添加新方法。Ruby on Rails中很多地方你都可以运用到这项特性，这种做法在你添加新方法之前就已经限制了打开类的范围。你因此可以以动态的方式添加新方法，而这种方式对于 Java开发员来说是想都不敢想的，因为这在Java或Groovy中根本不存在。

拥有一门强大的元编程语言非常重要，有这样一些原因：在最近十年左右，在软件开发领域，我们试图通过创建这些有约束的（locked down）开发环境来提高开发效率，比如说Java和C＃就是其中的例子。这些开发环境中都有这样一个念头，那就是防止编程能力较差的开发员写太多对软件本身有害的代码，这也是为什么大家使用强类型语言，使用静态类型系统，而且还设置一些类似于不能从String、Object类以及一些重要的内部类型创建子类等限制。因为他们担心那些技能交差的开发员在这几个方面犯一些令人悚然的错误。Glen Vandenberg——我一个朋友，曾经说着这样一句话：“糟糕的程序员会想方设法出错”。

然而他说的是对的，我的经验也证实了这一点。你可以严格设置开发环境，限制那些糟糕的程序员可能带来的麻烦，但这些限制的开发环境同时也影响了优秀的程序员的开发效率。基本上，你不但没法让那些糟糕的程序员因此而提高效率，而且还减缓了优秀的程序员的效率，得不偿失。这也是为什么目前我们无法提高软件开发效率的原因。但大家的态度在逐渐的改变。Ruby on Rails就是一个很好的体现。借助于ROR，我们因此不再创建极具限制的开发环境，不再需要像扩展Java那样来通过开发框架来添加功能。比如 AspectJ，aspect就是一个完美的例子，编程语言本身就应该包含这个概念，但他们没有，所以大家不得不另外开发一个框架把代码“编织”到字节码中去。

但在Ruby中，你不需要这样的第三方框架。因为Ruby本身就内嵌这项功能。像Aspect这些第三方扩展的问题很复杂。因为它的语法和编译方式和Java完全不同，而且它本身就相当复杂。Ruby中你不需要这些东西，因为语言本身已经支持这些概念。所以，大家不再需要创建极具限制的开发环境，也不需要通过开发框架来做扩展，取而代之的恰恰是完全相反的做法：选取一门超强的语言，在这之上编写一些简单的抽象，这就是Ruby on Rails。Ruby on Rails是Ruby上的领域特定语言，它简化了在Ruby中创建web应用程序的过程，你因此不再需要去理解什么是元编程，也不需要去知道Ruby背后那些复杂的东西。当然如果你对这些概念都有所了解的话，在必要的时候也是相当有用的。

所以，你可以把抽象降低一层到Ruby中去实现，充分利用Ruby的特长，你就不用再大费周章。我可以给大家举一个很实在的例子。在我最近工作的一个项目中，很多人都不喜欢花很多时间在测试上，所以他们尽量加快测试的速度。而且他们在做单元测试的时候不喜欢访问数据库，因为访问数据库往往减缓了整个测试的速度，于是他们开始添加一些元编程代码，一旦发现测试试图访问数据库，就直接把这个测试设为失败。即使是偶然间无意识地访问数据库，这个测试也会被立马设为失败。

后来在功能测试中，他们又觉得需要测试真实的东西，而不能总是用模拟来替代，因此他们开始添加这样一个功能：在进行功能测试时，即使是偶然间试图测试模拟对象，这个测试也立刻被设为失败。实现这个功能只需要几行代码，因为这几行代码的背后其实是超强的元编程以及更为简单的Rails抽象。不是每个参与这个项目的人都必须理解这背后的机理，但每个人都能够使用它们并且从中受益。几个曾经实现这个功能的人——Jay Fields和Dan Manges最终将它以RubyGem的形式发布方便大家的使用。

这也是ThoughtWorks在Ruby社区方面做的一些工作，和我们在Java社区中做的完全一样。我们动手用Java的时候，缺少很多重要的基础结构，也没有什么好的方式去实现持续集成，也没有大量的有关测试的东西，针对这些情况，ThoughtWorks进行了开发并且将成果以开源形式发布。现在，我们在Ruby社区中做的事情跟之前一模一样。比方说针对Ruby的持续集成——CruiseControl.rb，这就是ThoughtWorks创建的开源项目之一。再比如我们项目中的很多信息结构代码段，比方说我刚刚提到的关于测试那些功能，最后都以 Dust gem开源的方式发布。假如你这会儿运行“gem install dust”命令的话，就能马上在你自己项目中得到我们的源代码。

我们的项目团队创建了一个名为 “somethingnimble.com”的网站，这个网站实际上是汇总他们在项目开发中发现或者开发的一些极有价值的东西的blog。最近，他们在这个网站上发布的很有意思的一个东西叫做“mixology”。Ruby机制的类似于接口的形式，尽管两者不是同一回事，是一个混入（mix in）。你可以把行为混入到类，但是偶尔你会希望能够动态的混入一些东西。这就是mixology的意义所在，在安装mixology之后，你可以在运行时设定混入或者不混入的标准。这好比是说“我想要这个Java类实现这个接口，但仅在满足这个特殊条件的情况实现。但若是符合另外一个条件的话，就实现另外一个接口。”

Java中完全无法实现这样的做法，因为Java语言本身的设计不允许这个层次的访问，但在 Ruby中却是允许的，因为Ruby能够很好地支持元编程。这恰好又是一个例子证明一些在Ruby中非常容易的东西在Groovy中几乎不可能实现，因为 Groovy中从来没有为语言本身设计类似的功能。这种方式的好处是，不需要放弃你的开发平台，你完全可以借助JRuby来实现，这部分实现在Java平台上运行地很好，不用因为要试图说服负责开发基础设施的工作人员说你要换平台运用另一种开发语言而把他们给吓着了。你可以在最后给他们一个war文件让他们去部署，他们甚至根本不需要知道你其实没有用Java代码来实现，而是用的其它效率更高的语言。

   

4. 您提到了在JVM上实现的语言，但还没有讲到.NET，请问您是否再谈一下这个问题？

我真的觉得这个polyglot编程概念真的很不错，在.NET上的还要更好，因为毕竟CLR是专门为多语言设计的，而JVM在这个方面只是沾到一点边而已，JVM从没有得到任何扩展去支持多语言，但由于它的设计相当灵活，所以还是可以支持多种语言。CLR和.NET语言世界中也不断涌现出很多很有意思的成果。Microsoft就启动了IronRuby项目来实现CLR对Ruby的支持，就好比Java中的JVM支持JRuby一样。另外我遇到的很有意思的是Python，创建Python的人名叫Jim Hugunin。

他开发了很多非常意思的东西。他曾经参与开发过一些Aspects的东西，还创建了Jython，就是JVM上的Python。之后，他又决定看看CLR支持Python的话能得到怎样的效果，于是他又在CLR上做相应的开发，出乎意料之外的是，Python在CLR上比在C运行时或者Java运行时上运行得更快。这让他感到非常惊讶，在他去微软工作的时候，他不仅参与了IronPython的开发，而且还参与到一个建立在常规虚拟机之上的叫做动态语言运行时（Dynamic Language Runtime）的项目。他们所做的是在VM上层建立一个框架来支持多种动态语言的一些共性。可以预想到的是，IronRuby在CLR上的开发会比 JVM上的容易，因为在CLR上支持动态语言的很多必需的东西他们已经抽取出来在动态语言运行时中实现了。

我认为polyglot编程这个概念会在各种开发环境中普及开来，围绕这个概念也会有越来越多的开发，在然后就不存在任何单一的语言环境，各种开发平台则被当成管理运行时的工具。在下一个十年中，大家谈论的最重要的两个平台将会是JVM和CLR。操作系统中的机器平台如何运作都不是问题。只要你有这样一个管理运行时，你可以把应用部署到管理运行时上，没人在乎系统究竟是如何去操作的。最后我们上升到虚拟化的高度，因为像JVM和CLR平台的开发非常成熟，我们都没有必要再去关心物理的操作系统，因为我们可以直接在管理的运行时上部署。我认为这是件非常好的事情，大家在开发的时候又可以少关心一项细节。

Ruby拥有的另一项优点是动态语言即将可以在任何平台上运行。Python已经实现了，Ruby也很快能够实现，就目前来说，Ruby已经可以在各种操作系统上运行，可以在JVM上运信，很快也能在CLR上运行。

   

5. 您提到了很多语言，您不觉得要开发人员去学习所有这些语言会很困难吗？

这个实际上也是人们抱怨领域特定语言的原因。大家常常抱怨语言不协调的问题，抱怨要学习这么多不同的语言还要成为其中的专家。的确，这是个问题。但如果你仔细看各种Java框架，其实每个框架都以XML文档的形式内嵌了它自身的语法。尽管每个XML文档都用了同样的语法，但它们用的仍然是不同的语言，因为每个文档定义的语法都不同。就比如你下载Struts，但在了解Struts配置语言之前，你根本不可能立刻就应用Struts，而它的配置语言用的就是它自身的语法。

这也好比使用同样的符号集的不同语言，比如说英语和法语，但两者完全是不同的语言，甚至是拼写相同的词汇都可能有不同的意思。我们在Java世界中已经为这样的问题努力过，因为每个框架你都得读懂一个或者多个XML文档，而这些文档用的却又都是他们自身的语言。我们其实还能减少需要讨论的语言，因为我们可以减少实际开发所需要的框架的数量。有一个为Ruby on Rails做的很好玩、几乎是动画片类型的广告，广告中说：“要学作Java web开发，你需要大概15本书，因为你需要JVM，需要Struts、Hbernate、String的书，它们每没一样都有自己的语言。”

对于Ruby on Rails，你只需要两本书：一本Ruby，一本Rails。即便是你想应用混入的方式，比方说结合Scala，这也都是你所需要的全部书籍了。 Scala并不是用XML语句来表示的语言，而是种相对独立的语言。这时候，我觉得我们需要的不是书，而是对这门语言精通的专门的开发人员。我们需要专门的人员来编写Scala代码，而不是说项目中的每个人都必须去编写。就像你现在用别人开发的jar文件那样，你也可以以同样的方式应用别人写的 Scala。这其实跟我要在这里——这个大会上讲的领域特定语言非常相近，而且很有关联。

很久以前我就开始对这个问题感兴趣了，这实在是编写软件的一个非常强大的方式，因为它所做的是在已有的语言上层作更简单的抽象。其实我们一直在做这样的事情，每当我们所做的抽象开始变得复杂起来的时候，我们就开始在已有抽象的基础上做更简单的抽象，这也是DSL“运动”的目的：创建更简单的语言抽象。这项技术在Ruby世界中非常通用，因为Ruby on Rails中有很多方面都是领域特定语言。如果你再看一下像RSpec等有趣的行为驱动测试框架的话，你会发现它实际上就是在Ruby的基础上用领域特定语言所编写的。

你可以再看一下Rake——Ruby中的make功用，它也是在Ruby上的领域特定语言，非常强大的基础语言，而且你还可以在它上端继续编写更简单的抽象。这也就意味着你可以主要处理那些更简单的抽象，然后再退到下面一层得到更加强大的语言功能。我对这个课题很感兴趣的其中一个原因是我的一些同事和我自己目前正在为Pragmatic Press撰写一本关于创建内部DSL以及Ruby的书，我们正在研究Ruby世界中非常常用的一些技术，因为这些技术是用Ruby编写软件的通用方式。其实，在Ruby世界，你可以选择的DSL驱动方式跟你能选的开发框架一样多，但在Java世界中，99％都是开发框架，而此外的所有扩展只占1％。

我觉得这个课题真的很有意思。Martin Fowler和我一起编写过DSL相关的指导手册，他也在领域特定语言这个课题上做了很多的研究，汇总了很多相关知识。在我看来，这也是近年来大家谈论较多的话题，在接下来的年月里，你会发现越来越多的人讨论它，因为它实在是在复杂的代码块上创建更简单的抽象的非常便利的机制。可以肯定的是，目前在软件开发中有很多很多复杂的构造模块。在这些模块上编写更简单的抽象所能采用的技术变得越来越出色，然后你都不需要去了解所有那些复杂的构造模块，也不需要再去研究怎样把他们结合起来使用。

   

6. 您能够给大家列举一下您最喜欢的三本IT书籍么？

这个问题还真的很难回答。对我来说，排第一位的是可能是Pragmatic Programmers。这本书尽管已经出了10年了，但每页内容仍然包含着很多很有价值的东西，可以说它是本经典的、经久不衰的书籍。 Refactoring Book也是本很不错的书，书中总结了很多你平常可能会想到以及会去实现的东西。这本书在出版时具有革命性的意义，它列出了很多专有名词，很多优秀的开发人员早已将这些名词引入到他们的代码中，而这之后这些词汇也被添加到大家编写代码时采用的标准词汇表中。我要说的第三本书，可以说是个很有意思的选择，但它确实是让人爱不释手。

那就是Kent Beck的Smalltalk Best Practice Patterns。即使你不知道什么是Smalltalk，但在另一种语言世界里“游览”一下也是很有意思的。我们以为自己在Java中不断地发现些新东西，但Smalltalk的开发员们其实在20年前就已经发现了这些，只是Smalltalk和Java社区之间互相传递的知识太少，所以我们只能一次又一次的重复开发同样的东西。如果你读过跟Smalltalk Best Practice Patterns类似的书，那你肯定会发现里面有很多你如今可以在开发Java或C#或者其它开发的时候汲取的非常好的建议，因为Smalltalk的开发员曾经遇到过同样的问题，并且已经找到了漂亮的解决方案。

我觉得软件开发还有个问题就是对历史不了解，不清楚以前的开发中所发生的事情。每个人都认为“老的技术就是过时的技术，我们不需要再关注这些技术”，但即使是过时的技术，开发员也曾发现过很酷的东西，我们其实应该好好利用他们曾经的发现，多关注一些相关的历史，了解技术发展的进程，了解他们曾经很酷的点子，这样我们也可以避免在每次诞生一门新语言或者新技术的时候还要重新开发曾经实现过的东西。