【CSDN编者按】“我们有这么多珍贵、优雅、给了我许多快乐的语法，为什么你们还在使用那些劣质的语法？你们怎么能这么盲目、这么愚蠢？”这类争论永远没有胜者，建议不要尝试。

—— Alan Perlis，1978年

作者 | Gilad Bracha

译者 | 弯月，责编 | 夕颜

头图 | CSDN付费下载自视觉中国

出品 | CSDN（ID:CSDNnews）

以下为译文：

上世纪七十年代末，施乐帕罗奥多研究中心（PARC）的研究人员发明了现代计算。当然，发明者也包括其他地方的人，但绝大部分的贡献来自PARC。

其中很大一部分成果建立在Smalltalk编程语言之上。

四十年前，Smalltalk的动态更新和反射功能就已经领先于如今的许多主流语言。Smalltalk利用这些功能建立的IDE，至今让许多徒有其表的IDE依然望尘莫及。而且Smalltalk image的功能也远胜于Docker。

Smalltalk及其使用者不仅发明了IDE，还发明了窗口系统以及相关的概念（弹出式菜单、滚动条以及这一切背后的bit-blt原语），还建立了GUI构建器、单元测试、重构甚至敏捷开发等概念（好吧，人无完人）。

然而，如今Smalltalk的地位一落千丈，只有少数坚定的支持者。无论何时只要两个Smalltalk使用者坐到一起，他们就必然会争论起一个问题：为什么Smalltalk会衰落？

没人知道为什么，因为又没办法造出一个平行宇宙来探其究竟。

不管怎样，我觉得可以从这个问题中吸取教训。我来说说我知道的一段相关的历史。以下的描述可能并不太准确。肯定有人比我更了解这段历史，希望他们的评论能帮忙纠正我记错的地方。

下面我们开始。

缺乏标准

Smallktalk有（到现在依然有）多种实现，其实现的数量甚至超过了曾经广泛使用的编程语言。在传统行业，一项技术有多个来源是优势。但对于Smalltalk而言，情况则截然不同。

每个供应商的版本都略有不同，并不是不同的语言，而更像是不同的平台。例如，Smalltalk的类并没有公认的语法，而是通过反射方法调用来定义。不同供应商的反射API差异导致了程序定义本身就不可移植，不论程序使用的其他API如何。

当然，人们为了解决这个问题付出了许多努力。从八十年代末，人们就致力于Smalltalk的标准化，在九十年代人们进一步为之努力。但是，他们的努力几乎没有取得任何效果。

当然，我们与其他人合作开发的Newspeak语言完全解决了这个问题。但在2008年金融危机之后我们就陷入了资金的困境，而且Smalltalk社区对此也不感兴趣。社区对于解决Smalltalk-80模型的缺点毫无兴趣，这一点将在本文中反复提及。

商业模型

Smalltalk的供应商们一直有一个很奇怪的想法，那就是“酒香不怕巷子深”。他们认为他们的酒足够香，所以应该可以卖上好价钱。

这种想法在开源出现之前就有了，尽管Smalltalk的编译器、工具和库都是以源代码形式提供的，只有虚拟机是闭源的。

但是，绝大部分软件开发者宁可自己在石板上刻程序，也不愿意购买工具，不论这些工具多么精妙。有些供应商甚至不是按照开发者席位收费，而是按照软件的部署数量来收费。贪婪算法通常不是最优，而这种收费模式比其他模式更贪婪，效果也更差。后来的事实证明了一切。

有一件特别过分的悲剧，ParcPlace拒绝了Sun微系统公司在Sun的工作站上安装ParcPlace Smalltalk的橄榄枝。Sun给出的条件是按照每台机器支付版权费用，但远远不及ParcPlace通常开出的价钱。

最终，Sun自己开发了另一种语言，貌似是跟咖啡豆有关的，好像叫Fava吧？同样，我们也不知道在另一个宇宙里会发生什么事情。

性能

Smalltalk比C慢很多，直到现在都是如此，而且需要耗费更多内存。在八十年代末、九十年代初，这个问题很严重。到了九十年代中期，我们开始开发Strongtalk，当时最有潜力的客户之一就是瑞士银行。他们已经部署了许多Smalltalk应用程序。他们能承受Smalltalk，而别的客户不行。例如，他们愿意给柜员配备强大的电脑，那些电脑都是带有32M内存的IBM个人电脑，其成本让绝大多数公司望而却步！

实现总要花很长时间才能跟上技术的进步，即使追上以后，也只有很少的语言能够享受到这些进步。这一点也非常讽刺。JIT源于APL，但Smalltalk也是这个领域的先行者（Deutsch-Schiffman的研究成果），更不用说Self语言（适应性JIT的发明者）了。

Strongtalk将Self的技术应用到了Smalltalk上，于是它有了实际应用。

例如：Self需要64M，最好是96M内存，而且只能运行在Sun工作站上。Strongtalk可以在8M内存的个人电脑上运行。这一点非常重要。而且Strongtalk还有FFI，见下文。

然后Java出现了。1997年的时候Strongtalk比Java快，但Strongtalk被Sun收购了，然后其虚拟机技术被用来提高Java的速度。

Strongtalk中的Smalltalk部分早早地被埋葬了。等到它开源时，代码都腐烂了，支持它的系统也早就消失了，整个世界早已时过境迁。但是，Smalltalk社区依然对这个项目毫无兴趣。

想象一下，如果把投入到JVM的所有努力都投入到Smalltalk虚拟机中会怎样。

还有一点值得考虑的是，原始速度通常并没有人们想象得那么重要。Java最初是一种客户端技术（还记得applets吗？），程序是在网页上运行的。但是，Java作为一项客户端技术实在是太差了。相反，不用说Strongtalk，哪怕是随便一个解释器的启动时间都要比Java更短，而且交互性也更好。而且，Strongtalk需要的资源更少，从性能上来看，它比Java更适合作为客户端软件。但结果却出人意料。

另一方面，Netscape为浏览器开发了一门脚本语言，因为Java实在是不争气。Sun给了Netscape使用Java这个名字的许可。这个脚本语言的名字你一定听说过，它就是JavaScript。

最终，人们找到了一种让JavaScript更快的方法。谁找到的？正是那群让Strongtalk更快的人之一（Lars Bak），使用了同样的原理。

想像一下如果Sun当时有一种还过得去的客户端技术，那么Hot Java浏览器会一直活到今天。

另外，Java在客户端的失败成就了Java服务器端的成功。当时似乎这个主意不错，但Sun产品的商业化最终直接导致了Sun的灭亡。Sun的Strongtalk非常适合客户端技术，但公司的管理层无法采纳这一点。

他们肯定不会采纳的！几年前他们就结束了Self项目来专心开发Java。两年后，他们花了比开发Java多一个数量级的钱来开发Self，来购买同一项技术，以提高Java的性能。

与外界的交互

Smalltalk的做事方法很独特。通常（尽管并不绝对），这些方法都比主流的实践好。尽管如此，它与外界的软件环境的交互却很困难。例如：

FFI。Smalltalk的FFI很别扭、限制很多，而且非常低效。毕竟，谁愿意从那个美丽、梦幻的肥皂泡中出来，走向肮脏危险的世界呢？

我们在九十年代中期的Strongtalk和后来的Newspeak语言中完全解决了这个问题。

窗口。Smalltalk是窗口的诞生地。讽刺的是，Smalltalk依然在自己特殊的窗口系统上运行，锁在了单一的OS窗口中。

Strongtalk也解决了这个问题；其他人也解决了这个问题，但那些努力主要集中在他们自己孤立的世界中。后来，我们的Newspeak也有了原生的UI。

源代码控制。缺乏统一的语法意味着Smalltalk无法使用常见的源代码控制系统来管理，需要专用的工具。一些工具很不错，但非常昂贵。

一般而言，把一段Smalltalk代码直接保存成文件会出问题。Smalltalk使用一种名为file-out的格式，可以说它是一系列反射式API调用，还有一系列的元数据，如代码创建的时间、日期等。这种组合很难用源代码管理工具管理。

部署。Smalltalk很难将应用程序与编程环境独立部署。原因在于，Smalltalk并不是一种通常意义上的编程语言。它是一个整体的编程系统。具体来说，Smalltalk认为计算发生在互相通信的对象之间，而所有对象都存在于同一个宇宙中，可以认为是“对象的海洋”。一些对象知道如何创建新的对象，我们称之为“类”（这就是前面说过的没有专门定义类语法的原因）。

如果把一些对象从它们创建时所在的海洋（即IDE）中取出来会怎样？这是个很需要技巧的序列化问题。分解对象图谱是非常困难的。

而把一个应用程序从IDE中分离出来（以减少资源占用，或者保护知识产权，或者避免为每个部署支付IDE的授权费用）是非常困难的。

Self transporter用一种聪明的方式解决了这个问题。Newspeak从更基础的层面上更简单地解决了这个问题，一是意识到传统的语言观点无需与Smalltalk模型对立，二是将语言严格地模块化。

知识产权暴露的问题在今天已不那么重要。不论是基于服务器的应用程序，还是开源软件，知识产权都不那么重要。浪费资源依然需要考虑，但在多数情况下还能忍受。Avi Bryant又一次解释了他为后来的Dabble DB组织服务器的方式。其方法意想不到的简单，使用Squeak image就能非常轻易地解决。另一个人们经常错误关注的问题就是性能。

那么，为什么Smalltalk没能占领世界呢？

虽然是马后炮，但是从老板们的角度来看，Smalltalk的价值是：

花很多钱，被绑定在一种又慢、又暴露知识产权的技术上，画面看起来很奇怪，交互也不是太好，唯一的好处就是开发和维护非常容易！

除此之外，就是各种霉运

尽管如此，那些看透了这一切的人，今天依然在运行Smalltalk的系统，依然获得了不菲的成果；而用现代语言替换Smalltalk的成本极其昂贵。

所有我提出的这些问题都曾有过解决方案。那些尝试过解决这些问题的人发现，这个世界并不愿意接受。这不仅因为公司领导层的目光短浅，也是Smalltalk社区自身的问题。

我在Smalltalk社区的好友就完全无视了Strongtalk和Newspeak。从自己的舒适区走出来，需要极大的勇气和决心。

我相信，社区自己选择了那些对于Smalltalk自身局限无所谓的人，所以他们没有动力解决这些问题，也不愿意支持那些想要解决问题的人。实际上，他们甚至在面对面的时候都看不到这些问题，这导致他们采用了完全不切实际的商业策略，进而对他们造成了更多的伤害。

也许，Smalltalk更深层的问题是，它吸引的都是太富有创造力和想象力的人，而将这些人组织到一起就像赶一群猫一样困难。

不论如何，至今仍有人在使用Smalltalk，而且比大多数人想象的还要多。勇敢的人们依然在Smalltalk系统上付出，有商业系统，也有开源系统。我说过的一些问题已经在某种程度上解决了，尽管我认为它们还没有得到完全解决，实际效果也并没有那么好。同样，我们依然在努力让Newspeak更稳定。真正的进展并非来自迂腐和平凡的人，而是那些认为自己能做得更好的梦想家。

原文链接：

https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-advice.html

本文为CSDN翻译文章，转载请注明出处。

更多精彩推荐
☞国产数据库技术全面破冰，金融核心系统打破国外巨头垄断指日可待
☞Linux 之父怒删工程师提交的补丁，称“太蠢了”网友：怼得好！
☞Mybatis 逆向工程使用姿势不对文档全被清空，一怒之下写了个插件……
☞趣谈程序员真香定律：源码即设计
☞干货 | 大白话彻底搞懂 HBase RowKey 详细设计
☞热评 | 警惕新基建热潮中的区块链项目烂尾