文章目录

原文

prototypes vs classes was: Re: Sun’s HotSpot

译文

(由 ChatGPT 翻译, 种瓜校对和微调)

各位,

温和地提醒一下，我在上一次 OOPSLA 会议上费了些心思, 试图提醒大家, Smalltalk 不仅不是它的语法或类库，甚至不是关于类的。很抱歉我很久以前为这个主题创造了"对象(objects)“这个术语，它让很多人将注意力放在次要的想法上。

重要的想法是"消息传递(messaging)”, 这是 Smalltalk/Squeak 的核心（我们在施乐帕克期间，这个想法从未完全完成）。日语中有一个小词:“ma”, 意思是"介于之间", 或许最接近的英文等价词是 “interstitial”.

要制作出伟大且可扩展的系统, 关键在于设计模块之间如何通信，而不是它们的内部属性和行为应该是什么。想想互联网, 为了存在，它必须做到:

• 允许许多不同种类的想法和实现, 超越任何单一标准。
• 允许这些想法之间有不同程度的安全互操作性。

如果你专注于消息传递, 并意识到一个良好的元系统可以动态绑定对象中使用的各种第二级架构, 那么本质上关于这个主题的语言、用户界面和操作系统的讨论都是无关紧要的。这就是为什么我在上一次 OOPSLA 会议上抱怨的原因, 在施乐帕克，我们经常更改 Smalltalk, 总是将其视为不断进化的工作, 当 Smalltalk 进入更大的世界时，它基本上被看作“只是需要学习的东西”，就像是 Pascal 或 Algol。Smalltalk-80 从未真正进化成 OOP 的下一个更好的版本。鉴于目前编程的普遍低水平，我认为这是一个真正的错误。

我记得我还指出过，不仅要有一个完整的元系统，拥有帮助保护元边界的栅栏也是至关重要的。其中一个最简单的就是我在六十年代末最初探索中的动机之一：意识到赋值是函数的元级别变化，因此不应在同一级别处理, 这是封装这些状态变化的动机之一，不要让它们随意进行。一个允许在普通编程过程中进行其他元事物的系统（比如改变继承的意义，或什么是实例）是一个糟糕的设计。（我相信系统应该允许这些事情发生，但设计应该是这样的，即在进行重大扩展时必须跨越明确的界限。）

我建议，如果聪明而有才华的 Squeak 列表更多地考虑元编程的下一步应该是什么: 我们如何获得强大的力量、简洁性和意义的安全性？

向大家致以问候，

Alan