历史的点滴,忠告的话语(新话)

2020-05-25 16:47:06

为什么你们这些蠢货要用这些低劣的语言载体,而我们这里却有这样的东西。

珍贵,如此优雅,让我如此愉悦?你怎么能这么瞎这么傻?

那场辩论你永远赢不了,我认为你也不应该尝试。

在20世纪70年代末,施乐帕洛阿尔托研究中心的研究人员发明了现代计算机。当然,还有其他人。

其中很大一部分是用Smalltalk编程语言完成的,并且基于Smalltalk编程语言。四十年。

主流语言就是今天。该语言利用这些功能提供了一个IDE,它在。

许多方法仍然把目前日食、黑洞、红矮星和其他悲剧。

令人羞愧的是,在那个术语下伪装。Smalltalk的形象提供了一个比Docker好得多的Docker

(弹出菜单、滚动条、使它们成为可能的Bit-BLT原语)以及GUI构建器,

然而,今天的Smalltalk被降级到了真正的信徒中的一小部分。

答案是不可知的,因为我们不能运行平行宇宙并调整事物来看哪一个。

我在2016年的一次演讲中确实描述了这样一个另一个宇宙;这可能是我做过的最好的演讲。

然而,我认为我们可以从这个问题中学到一些东西。我将讲述历史的一部分。

据我所知,我认为是相关的。我敢肯定下面的账目有误。

当然还有比我更接近历史的人。我希望他们能扩大我的研究范围。

如果需要,请评论并更正我。我相信我会因为这件事被骂的。看我是否在乎。

缺乏标准。SmallTalk曾经(现在仍然拥有)多个实现--远远不止如此。

会被认为是一种优势。然而,在Smalltalk的案例中,事实证明情况截然不同。

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

特别是,Smalltalk类没有常规语法;相反,它们是通过。

程序定义本身是不可移植的,不管。

当然,有努力来补救这一点。Smalltalk标准化的努力可以追溯到80年代末,

但在90年代被推得更远。唉,在实践中,它们的影响微乎其微。

当然,新说法彻底解决了这个问题,以及许多其他问题。但是我们的资金很少

社区对解决Smalltalk-80模型中的弱点缺乏兴趣,这将是一个。

商业模式。Smalltalk商贩对建造更好的捕鼠器的想法有一种古怪的信念。

这个世界会敲出一条路到你的门口。既然他们造了一个好得多的捕鼠器,他们。

这甚至是在开源概念提出之前;尽管Smalltalk编译器、工具。

唉,大多数软件开发人员宁愿用打火石工具把他们的程序刻在石板上。

夹在牙缝里也比花钱买工具好,不管多么精致。事实上,一些供应商对此提出了指控。

次优,而且这种方法比大多数方法更贪婪、更不理想。它的明显成功说明了。

在一个特别恶劣和悲惨的案例中,我告诉ParcPlace拒绝了Sun的报价

允许在Sun工作站上分发ParcPlace Smalltalk的微系统。Sun会为每个人支付。

Smalltalk过去和现在都比C慢得多,对内存的要求也更高。在20世纪80年代,

20世纪90年代初,这些都是一个真正令人担忧的问题。在20世纪90年代中期,当我们致力于Strongtalk时,瑞士。

在战场上。他们可以在其他人做不到的地方这样做。例如,他们愿意装备。

他们的出纳员拥有大多数公司认为成本过高的强大计算机-IBM PCS。

实现技术花了很长时间才赶上,当它赶上时,它被应用到较小的。

语言。这也是一个残酷的讽刺。JIT起源于APL,但Smalltalk也是这方面的先驱。

示例:自己需要64MB,最好是96 MB,并且只能在Sun工作站上运行。StrongTalk运行速度为8Mb

然后,Java出现了,1997年StrongTalk比Java还快,但StrongTalk被Sun收购了;

Smalltalk系统被活埋了,直到为时已晚。当我最终把它开源的时候,

比特已经腐烂或消失,系统没有支持,世界已经向前看了。然而,

Smalltalk社区对该项目几乎没有兴趣,这一事实仍然很能说明问题。

想象一下,如果JVM投入的所有工程工作都集中在Smalltalk VM上。

同样值得深思的是,原始速度往往没有人们想象的那么重要。

在网页中运行。唉,Java是一种糟糕的客户端技术。在祝贺中,即使是Squeak。

解释器(更不用说Strongtalk了)的启动时间比Java好得多,交互性也更好

也会有回应。它的足迹也要小得多。这对表现出色的客户来说是一个更好的基础。

一方面,网景为浏览器开发了一种脚本语言。毕竟Java不会被砍掉。

它。Sun允许他们使用Java名称作为他们的语言。“你可能听说过这件事。

最终,人们找到了一种让Javascript变得更快的方法。哪些人?从字面上看,有些是相同的。

想象一下,如果Sun拥有一种可行的客户端技术。也许热Java Web浏览器还会是。

另一方面,客户端Java的失败导致了对服务器端Java的强调。

这在当时看起来是个好主意,但最终将Sun的产品商品化并做出了贡献。

直接导致太阳公司的垮台。Sun在Strongtalk中拥有一流的客户端技术,但该公司的

当然,他们为什么要这么做呢?几年前,为了专注于Java,他们关闭了Self项目。

两年后,他们花了比发展自我的成本多一个数量级的钱,买回了自己的股票。

Smalltalk有其独特的做事方式。通常情况下,虽然不总是这样,但这些方法要好得多。

FFIS。Smalltalk FFI笨拙、受限且效率低下。毕竟,你为什么要。

我们早在90年代中期的Strongtalk中就提到了这个问题,很久以后,我们又在Newtalk中谈到了这个问题。

Strongtalk也解决了这个问题;偶尔,其他人也会解决这个问题,但主要工作仍然集中在。

他们自己与世隔绝的世界,就像所有其他方式一样。后来,我们有了NewSpeech的原生UI,如下所示。

源代码管理。缺少常规语法意味着无法管理Smalltalk代码

使用传统的源代码控制系统。取而代之的是定制工具。有些很棒-但是。

通常,将Smalltalk代码保存在像文件这样普通的文件中是有问题的。使用的Smalltalk。

一种称为文件输出格式(file-out format)的东西,它被善意地描述为一系列反射API调用,以及。

使用元数据,其中包括代码被归档时的时间和日期。这是一种复合。

环境。原因是Smalltalk从来都不是传统的。

理智。这是一个整体构思的编程系统。具体地说,这个想法就是计算。

发生在沟通的对象之间,这些对象都存在于某个宇宙中,就像对象的海洋一样。一些。

这些对象中的大多数知道如何创建新的对象;我们称它们为类(这就是为什么没有

当您尝试将某些对象从创建它们的环境(IDE)中取出时,会发生什么情况?

如果您希望通过将应用程序与IDE分离来部署该应用程序(为了减少占用空间或保护您的IP,

或者避免在每个部署的副本上支付IDE的许可费),事实证明这是非常困难的。

自助车以一种聪明的方式解决了这个问题。纽派克对此的论述要多得多。

如今,知识产权曝光问题已不再是一个令人担忧的问题。对于基于服务器的服务器来说,这无关紧要。

应用程序,或用于开放源码软件。尽管在许多情况下,浪费的内存占用仍然是一个令人担忧的问题。

可以做得很好。Avi Bryant曾经向我解释过他是如何为已故的、伟大的。

涉猎DB。这是如此简单,你只需要哭,它的表现就像一个符咒使用Squeak图像。

通过20/20的后见之明,我们可以看到,从尖头老板的角度来看,Smalltalk的价值。

花很多钱被锁定在速度慢的软件上,这些软件会暴露你的IP,在屏幕上看起来很奇怪,而且。

不能与其他任何东西很好地交互;但是维护和开发要容易得多!

然而,那些看到过去的人,今天仍然在运行Smalltalk系统,取得了巨大的成果;努力。

我们这些试图解决这些问题的人发现,更广泛的世界不想听-。

即使这是为了它自己的最大利益。这不仅适用于目光短浅的企业领导层,

我相信,这个社区是由那些不受Smalltalk困扰的人自己挑选出来的。

最初的限制,因此没有动力去解决这些问题或支持那些这样做的人。事实上,他们经常

我甚至看不到这些限制正摆在他们面前,导致他们采用不切实际的。

也许Smalltalk的一个更深层次的问题是,它吸引了一些有点太有创造力的人,

然而,Smalltalk仍然在使用,比大多数人意识到的要多得多。勇敢的灵魂继续。

在Smalltalk系统上工作,既有商业的,也有开源的。我提到的一些问题是。

在一定程度上解决了问题,即使我觉得他们没有得到彻底和有效的处理。

尽他们所能。给他们更多的权力。同样,我们仍在花时间试图将新话带回。

更可用的状态。真正的进步不是由学究和平凡的人取得的,而是由梦想家取得的,他们意识到我们可以做得更好。