商业Smalltalk的兴衰

吉拉德·布拉查(Gilad Bracha)最近发表了一篇名为“历史点滴，忠告之词”的文章，谈到了Smalltalk令人难以置信的影响力，但对此表示遗憾：

…。今天，Smalltalk已经沦为真正信徒的小众。每当两个或更多的Smalltalk人聚在一起喝酒时，人们就会争论这个问题：为什么？

(除非另有说明，否则所有的区块引用都出自吉拉德的文章。)。

实际上，Smalltalk在20世纪90年代上半叶的商业人气激增，但在1996年，这种兴趣几乎瞬间消失了。吉拉德的大部分文章都包含了他对为什么会发生这种情况的猜测。我同意吉拉德在这个问题上的许多观点，但他对Smalltalk的参与和看法在Smalltalk的商业生命周期中开始得相对较晚。我在一开始的时候就在那里，所以添加一些额外的历史和我自己的个人观点似乎是合适的。我将直接回应吉拉德的一些观点，所以在继续之前，你可能应该阅读他的帖子。

Gilad致力于20世纪90年代中期开发的Smalltalk的Strongtalk实现。他的帖子描述了他在那段时间看到的Smalltalk世界。但是，为了更全面地理解，我们将从回顾过去20年发生的事情开始。

从20世纪70年代初开始，早期的Smalltalkers和其他施乐帕洛阿尔托研究所的研究人员发明了个人计算的概念和机制，其中大多数至今仍占主导地位。在艾伦·凯的愿景的指引下，丹·英格斯与泰德·凯勒、阿黛尔·戈德堡、拉里·特斯勒以及帕洛阿尔托研究中心的其他成员一起创建了Smalltalk，作为他们渴望的个人电脑模型Dynabok的软件。Smalltalk不仅仅是一种编程语言--用今天的术语来说，它是在专用个人超级计算机的裸机上运行的完整的软件应用程序平台和开发环境。在此期间，Smalltalk语言和系统至少经历了五个主要版本的演变。

在20世纪70年代，外界只看到了学习研究组内部正在发生的事情的暗示和短暂的一瞥。他们的工作影响了施乐之星(Xerox Star)系列办公机器的设计，史蒂夫·乔布斯(Steve Jobs)拿到Smalltalk演示后，聘请拉里·特斯勒(Larry Tesler)为苹果公司的丽莎(Lisa)工作。但是LRG团队(后来称为SCG for Software Concepts Group)想要直接向全世界公开他们的工作(Smalltalk)。他们开发了他们的软件Smalltalk-80的一个版本，适合在施乐之外分发，并在一系列书籍和被广泛阅读的Byte杂志的特刊中写下了这一点。他们还向几家公司提供了他们的Smalltalk-80实现的内存快照，他们认为这些公司拥有硬件专业知识，可以构建他们认为运行Smalltalk所需的微码定制处理器。当时的希望是，这些公司能够设计和销售基于Smalltalk的电脑，类似于他们在施乐帕洛阿尔托研究中心(Xerox Parc)使用的电脑。

但是没有一个合作者做到了这一点。他们没有构建微编码的Smalltalk处理器，而是使用经济型微型计算机或商用的基于微处理器的系统，编写了本质上是Xerox超级计算机Smalltalk机器的简单软件仿真的代码。最初的结果非常令人失望。他们名义上可以运行施乐提供的Smalltalk内存映像，但运行速度比PARC使用的机器慢10-100倍。这非常令人沮丧，因为它们的实现速度太慢，无法在Smalltalk平台上进行有意义的工作。大多数最初的外部合作者最终放弃了Smalltalk。

但是有几个小组，如我和我在Tektronix的同事，施乐的L Peter Deutsch和Alan Schiffman，以及加州大学伯克利分校的Dave Ungar开发了新技术，使用32位体系结构的商用微处理器大大提高了Smalltalk-80的性能。

与此同时，吉姆·安德森(Jim Anderson)、乔治·博斯沃思(George Bosworth)和他们的同事独立开发了一种新的Smalltalk，可以在配备Intel8088处理器的原始IBM PC上有效地运行。

到1985年，人们可以在负担得起的硬件上实际使用Smalltalk，各种团体开始发布Smalltalk产品。1985年1月，我在Tektronix的团队发货了专为支持Smalltalk-80而设计的一系列“人工智能工作站”中的第一台。几乎在同一时间，安德森和博斯沃思的公司Digitalk推出了他们的第一个IBM PC Smalltalk产品Methods。紧随其后的是他们的Smalltalk/V产品，其名称暗示着与Alan Kay的Vivarium项目的联系。Servio Logic介绍了基于Smalltalk的面向对象数据库系统Gemstone。1987年，在阿黛尔·戈德伯格的领导下，大部分剩余的施乐Parc Smalltalk剥离出来，成立了一家初创公司，ParcPlace Systems。他们最初的重点是销售用于工作站级机器的Smalltalk-80系统。

戴夫·托马斯的对象技术国际公司(OTI)与Digitalk合作创建了Macintosh版本的Smalltalk/V，然后开始开发Smalltalk技术，该技术最终将用于IBM的VisualAge产品。Tektronix与OTI合作，开始开发两个新的示波器系列，它们使用嵌入式Smalltalk来运行其用户界面。OTI和Instantiations(Tektronix的一个分支)都开始使用Smalltalk开发工具来支持团队规模的开发项目。

正如许多软件工具供应商在此期间发现的那样，要支持任何比“生活方式”业务更大的业务，需要99美元的销售额。在1990年，如果你想要建立一个庞大的软件工具业务，你必须找到那些在这类工具上花费了大量资金的客户。大多数继续经营的工具供应商发现，这些客户大多是企业IT部门。这些组织过去是IBM大型机客户，通常拥有数百名内部开发人员，并且愿意为一个有效的应用程序开发平台在每个初始开发人员席位上花费数千美元，外加每年的巨额支持费用。

当时，许多企业IT组织正试图从大型机驱动的“绿屏”应用程序过渡到具有现代Mac/Windows类型GUI界面的“胖客户端”。主要的Smalltalk供应商将他们的产品定位为过渡问题的解决方案。这反映在他们的产品品牌中，ParcPlace Systems的ObjectWorks被重新命名为VisualWorks。Digitalk的Smalltalk/V成为VisualSmalltalk Enterprise，IBM使用OTI的嵌入式Smalltalk技术作为VisualAge的基础。Smalltalk甚至在技术报刊和书籍中被定位为COBOL的潜在继任者：

Dave Thomas 1995年的文章“与Smalltalk一起旅行”是对当时和之前十年商业Smalltalk活动的极好调查。大约在它出版的时候，IBM通过收购Dave的OTI巩固了其Smalltalk技术基础，Digitalk与ParcPlace Systems合并。这次合并的动机是他们共同害怕IBM Smalltalk在企业市场的竞争力。

在1996年的六个多月里，Smalltalk在市场上的位置从企业界最受欢迎的COBOL替代品变成了另一个令人失望的工具，它有一长条需要维护的已部署应用程序的尾巴。

万维网把企业的注意力从胖客户身上转移开，突然之间，网络瘦客户机成了热门的新技术。与此同时，Sun Microsystems针对Java的大规模营销活动让企业相信，Java是Web和独立客户端应用程序的未来。尽管Java从未兑现其客户端承诺，但商业Smalltalk供应商无法对抗Java的炒作周期，基于Smalltalk的新企业应用程序的开发也停止了。合并后的ParcPlace-Digitalk迅速衰落，只存活了几年。IBM迅速将其开发注意力转向Java，并使用从OTI获得的开发环境专业知识来创建Eclipse。

利基公司承担了用已部署的应用程序支持传统企业Smalltalk客户的责任。Cincom获得了对VisualWorks和Visual Smalltalk Enterprise客户的支持，而实例化则接管了对IBM的VisualAge Smalltalk的支持。25年后的今天，仍有数百个已部署的遗留企业Smalltalk应用程序。

1996年，苹果公司的Dan Ingalls使用了一个原始的Smalltalk-80虚拟映像来引导Squeak Smalltalk。丹、艾伦·凯和他们在苹果、迪士尼和一些大学的同事将Squeak用作研究平台，就像他们在施乐公司使用最初的Smalltalk一样。Squeak是作为开源软件发布的，在世界各地拥有一个用户和贡献者社区。2008年，Pharo是从Squeak派生出来的，目的是成为Smalltalk的精简版、工业化程度更高、研究重点更少的版本。此外，在过去的25年里，还创建了其他几个Smalltalk。今天，Smalltalk的用户群仍然很小，而且热情高涨，而且有些零散。

Gilad在他的文章中列出了Smalltalk社区执行失败的四个主要领域，这些领域导致Smalltalk没有得到广泛的长期采用。让我们看一看他们每一个人，看看我同意和不同意的地方。

但是标准是什么呢？这个“Smalltalk”没有标准化的东西是什么？正如Gilad所指出的，至少从1988年开始，在核心语言语法、语义甚至核心类协议上都有相当程度的事实上的一致。但在内核之外，事情就大不相同了。

每个供应商的版本都略有不同--与其说是语言的不同，不如说是平台的不同。

这些平台不只是稍有不同。他们在所有使他们成为平台的方面都有很大的不同。Smalltalk平台之间的差异不像当时存在于GCC和微软的C/C++编译器之间的差异。更贴切的类比是Windows、Solaris、各种Linux发行版和MacOSX等平台之间的差异。使用标准C库的C程序可以很容易地在所有这些平台之间移植，但是移植一个高度交互的基于GUI、C的应用程序通常需要大量重写。

与之竞争的Smalltalk平台产品也大相径庭。将使用公共内核类的基本Smalltalk语言代码“归档”出来并将其转移到另一个Smalltalk产品上非常容易。但就像C实现的平台一样，在Smalltalk平台之间移植高度交互的GUI应用程序需要进行重大重写核心问题不是定义Smalltalk程序的反思方式(尽管我强烈同意Gilad的观点，这是不可取的)。问题在于，构建在核心语言和核心类之上的所有平台服务-使平台成为平台的东西-都是不同的。到1995年，已有三大主要和几个利基Smalltalk平台在客户端应用程序平台领域展开竞争。但到那时，已经有了一个客户端平台的获胜者-它是微软的Windows。

Smalltalk供应商有一种古怪的信念，即“制造一个更好的捕鼠器，世界就会敲出一条路来找你”。因为他们造了一个好得多的捕鼠器，他们想他们可能会为此收费。

…。事实上，一些供应商不是按开发人员席位收费，而是按软件的已部署实例收费。贪婪算法通常是次优的，这种方法比大多数算法更贪婪，更不是最优的。

这可能是对ParcPlace Systems商业模式的准确描述，但对其他Smalltalk供应商来说却不是一个公平的描述。特别值得一提的是，Digitalk以99美元的IBM个人电脑Smalltalk产品起家，在1985至1990年间，它在个人电脑和Mac电脑的Smalltalk产品价格低于500美元的情况下，建立了一家相当不错的小企业。然后，在风险投资的支持下，它过渡到相当标准的企业模式，专注于每个席位2000美元以上，外加专业服务。Digitalk从未收取过部署费用。我也不相信IBM做到了这一点。

企业业务模式对主要的Smalltalk供应商来说运作良好，但却成了陷阱。当你获得这样的客户时，你必须回应他们的需求。他们的当务之急是构建这些胖客户端应用程序。我记得在Digitalk的那一天，当我意识到我们的客户并不真正关心Smalltalk，或基于对象的编程和设计，或实时编程，或Smalltalk带来的任何独特技术时，我感到沮丧。他们只是想用看起来像Windows应用程序的东西来取代那些绿屏。他们购买我们的产品是因为我们(相当成功)的企业销售团队说服他们，Smalltalk是构建此类应用程序所必需的。

支持这些客户期望将工程资源转移到可视化设计人员和可视编程工具上，而不是团队协作开发、版本控制和部署等重要的下游问题。是的，我们知道这些问题并计划解决它们，但大多数资源都用于直接的客户GUI问题。以至于当ParcPlace和Digitalk的领先企业客户转向基于Web的瘦客户机时，它们都措手不及，完全没有准备好与之竞争。

在20世纪80年代，Smalltalk的执行性能一直是一个主要问题。但到了20世纪90年代中期，每个主要的商业Smalltalk都有了基于JIT的虚拟机和多代垃圾收集器。当“Strongtalk将Self的技术应用到Smalltalk”时，它已经很实用了。

虽然我们这些从事Smalltalk VM工作的人喜欢追求C++的性能，但我们的实际竞争对手是PowerBuilder、Visual Basic，偶尔还有Delphi。所有主要的Smalltalk VM的执行性能都比其中任何一个都要好得多。微软甚至曾经出价收购Digitalk，尽管他们对Smalltalk没有兴趣。他们只是想改变Smalltalk/V虚拟机技术的用途，使Visual Basic速度更快。

但正如吉拉德指出的那样，原始速度很少成为问题。特别是对于大多数商业Smalltalk客户关注的胖客户端UI。Smalltalk VM的性能也比其他在20世纪90年代出现并流行起来的动态语言好得多。Perl、Python、Ruby、PHP的执行性能都比在同等硬件上运行的1995年的Smalltalk差得多，据我所知，它们的执行性能仍然很差。

内存使用是一个更大的问题。对于客户来说，要想有效地运行商业Smalltalk，必须将个人电脑的内存增加一倍，这是很昂贵的。但是摩尔定律很快就解决了这个问题。

同样值得深思的是，原始速度通常没有人们想象的那么重要。Java是作为客户端技术引入的(有人还记得applets吗？)。我们的愿景是程序在网页中运行。唉，Java是一种糟糕的客户端技术。相比之下，即使是Squeak解释器，更不用说Strongtalk了，启动时间也比Java好得多，交互响应也更好。它的足迹也要小得多。与Java相比，它是一个更好的性能客户端软件基础。其影响是令人震惊的。

Squeak(或任何90年代中期版本的Smalltalk)在浏览器中的表现真的比Java好吗？您现在可以通过在浏览器中运行1998年版本的Squeak1998来亲自尝试：https://squeak.js.org/demo/simple.html.。这就是当时web开发人员所需要的吗？

Java作为Web客户端的问题在于它想成为自己的平台。Java没有很好地集成到基于HTML的Web浏览器架构中。取而代之的是，Java只是将浏览器当作另一个处理器来托管Sun控制的“一次编写，随处运行”的Java应用程序平台。它的目标不是增强原生浏览器技术--它的目标是取代它们。

由于其平台传统，商业化的Smalltalk产品存在与Java类似的问题。Smalltalk的做事方式与微软Windows等占主导地位的客户端平台之间存在“阻抗不匹配”。非Smalltalk-80衍生平台(Digitalk和OTI/IBM)在消除这种不匹配方面比ParcPlace系统做得更好。

窗口。Smalltalk是窗口技术的发源地。具有讽刺意味的是，Smalltalk继续运行在他们自己独特的窗口系统之上，锁定在一个单一的操作系统窗口中。Strongtalk也解决了这个问题；偶尔，其他人也会这样做，但主要的努力仍然集中在他们自己孤立的世界上，就像其他任何方式一样。

这描述了ParcPlace的VisualWorks，但不是Digitalk的Visual Smalltalk或IBM的VisualAge Smalltalk。为这些Smalltalk编写的应用程序使用原生平台窗口和窗口小部件，就像其他语言一样。每个Smalltalk供应商都提供了他们自己的高级GUI框架。这些框架彼此不同，也不同于其他语言使用的框架。Digitalk针对MSDOS的早期Smalltalk产品提供了自己的窗口系统，但Digitalk的Windows和OS/2产品始终使用本地窗口和图形。

源代码管理。由于缺乏传统语法，Smalltalk代码无法使用传统的源代码控制系统进行管理。取而代之的是定制工具。有些很棒，但它们非常昂贵。

IBM和Digitalk都将源代码控制系统捆绑到他们的企业Smalltalk产品中，这些产品的价格与其他企业开发平台相比具有竞争力。OTI/IBM的Envy源代码控制系统成功地构建在Smalltalk的传统反射语法之上，并将代码存储在多用户对象数据库中。OTI还出售了ParcPlace的VisualWorks的Envy，但缺乏捆绑销售的定价优势。Digitalk的Team/V使用RCS不引人注目地引入了非反射语法和版本化源代码。Team/V可以在运行的虚拟映像中向前和向后迁移Smalltalk“模块”的版本。

部署。SmallTalk使得独立于编程环境部署应用程序变得非常困难。

正如Gilad所描述的，从开发环境中提取应用程序可能很棘手。但是Team/V和Envy都包含了帮助开发人员做到这一点的工具。Team/V支持将应用程序部署为Digitalk Smalltalk链接库(SLL)，它们是可以动态加载的可分离虚拟映像段。Evy最初是为生成基于ROM的嵌入式应用程序而设计的，它拥有丰富的工具，可以从开发映像中摇动可部署的应用程序。

吉拉德还提到，“不受保护的IP”是阻碍Smalltalk被接受的一个部署问题。这大概是因为即使源代码没有与应用程序一起部署，也很容易将Smalltalk字节编码的方法反编译回人类可读的源代码。事实上，潜在的企业客户偶尔会提出这一问题。但是，这通常是一个“怎么办”的问题。在我们与Digitalk打交道的数百家企业客户中，我想不起任何一个不受保护的知识产权导致交易失败的例子。如果是这样的话，我们会对此做些什么，因为我们知道可以用来混淆Smalltalk代码的各种技术。

Smalltalk做了比接管世界更重要的事情-它定义了世界的形状！艾伦·凯(Alan Kay)的戴纳博克的个人计算愿景并没有提供详细的设计文档，描述了它的所有功能以及如何创建它。为了使这一愿景具体化，必须发明真正的文物。

Smalltalk是“发明f”的软件基础。

..