Smalltalk 的简洁性与一致性 vs. 其他语言（2022）[视频]

简洁性、语法与权衡

• Smalltalk 的语法极其精简且统一，但评论者强调，这并不会自动让代码更容易读写，也不会让编译器更容易优化。
• Block 和消息传递把控制结构与普通方法调用统一起来，但为了避免严重性能下降，编译器需要特殊处理（例如对 ifTrue: / whileTrue: 做内联）。
• “一切都是发给接收者的消息”这一模型，会把设计推向在类层次结构/trait 之间分散行为；有人认为这很优雅，也有人认为相比其他语言里的简单函数，这反而增加了复杂度。
• 熟悉程度会强烈影响人们对“简单”的感受；过于极简的语言反而可能让解决方案更复杂。

性能与 VM 优化

• 关于 Smalltalk VM 历史上为何落后于高性能 JS 引擎，讨论非常热烈。
• 一种观点认为，这部分归因于语言/VM 设计本身（例如 block、动态分发）更难被 JIT 很好地优化，并把 Smalltalk 的轨迹与 Python 作比较。
• 另一些人则认为性能差异主要是投入问题：JS 有规模庞大、资金充足的团队；OpenSmalltalk 则由志愿者驱动。把 Squeak/Pharo 当作性能基准被认为具有误导性。
• 讨论中举出了一些高性能的 Smalltalk 风格系统（Self、Strongtalk、基于 Truffle/Graal 的 SOM 变体、TruffleSqueak），它们在某些基准测试中可以追平甚至超过 JS，这挑战了“Smalltalk 很慢”的说法。
• 对于 Python，优化困难的根本原因被描述为不清楚；提到 CPython 与 C 扩展的紧耦合，但未得到解决。

实时编程环境

• 许多人对 Smalltalk 基于 image 的实时环境着迷，在这种环境里，代码、GUI、调试器和工具都集成在一起，并且始终运行。
• 这与主流工作流形成对比，后者通常需要重新构建/重启，被视为一种倒退。
• Emacs 和 Lisp/Interlisp 系统被提到在精神上相似（可扩展、实时、具备 image 历史），但体验并不相同；Smalltalk 被认为更连贯，而 Emacs 更“拼凑”。
• 缺点是：现代 Smalltalk 环境可能很重（例如占用 1GB+ RAM），而且由于必须连同 VM/image 一起发布，部署起来也比较别扭。

实用性、工具链与项目经验

• 轶事描述了 Smalltalk 系统中的惊人生产力和工具能力（OO 数据库、工作流引擎、集成在 IDE 里的自动化）。
• 反面轶事：一个大型保密的 Smalltalk 项目几乎没有产出可演示的成果；语言并不是唯一问题，但保密、缺乏审查，以及 Smalltalk 早期在 SCM/配置管理方面的历史困难都起了作用。
• 现代 Smalltalk 的实用性也引发担忧：人们感觉缺少开箱即用的库、常见 FOSS 实现中的多线程支持薄弱或缺失，以及 UI 比较笨拙（小型编辑器、以鼠标为中心的工作流）。
• 也有人指出，早期的商业 Smalltalk 在其所处年代是“开箱即用”的；实用性的标准会随年代变化。

语言哲学与职业现实

• 一些参与者觉得主流语言（Python、C++、Java）远不如 Smalltalk、Lisp、F#、Elixir 等令人愉悦或富有表现力，但出于职业原因不得不用它们。
• 给出的建议包括：
  • 用你喜欢的语言做原型，并展示显著的生产力/价值，以影响技术栈选择。
  • 如果引入小众语言，要准备好教同事。
  • 或者接受流行工具，但在设计风格和抽象上吸收“更好”语言的思想。
• 这里存在一种张力：是热爱工具，还是专注于解决问题。
  • 一派认为工具美学只是干扰，真正重要的是效果。
  • 另一派则认为高质量工具会“化解”问题，而对工具的掌握至关重要。
  • 还有人建议折中：不要浪漫地迷恋工具，但也不要忽视它们的影响。

与其他语言和系统的比较

• Smalltalk 被反复拿来与以下系统比较：
  • Lisp 以及更早的 Lisp machines/Interlisp 系统（image、GC、交互式开发）。
  • JS、Python、Ruby，以及动态分发模型；基于字典的方法查找被认为既强大，也会拖累性能。
  • Tcl 和 GNU Smalltalk 作为脚本选项；GNU Smalltalk 被描述为更像“带 Smalltalk 风味的脚本”，而不是完整的 Smalltalk 环境，而且维护状态也令人怀疑。
• “同像性（homoiconicity）”也引发争论：
  • 有人声称 Smalltalk 像 Lisp 一样具有同像性；
  • 也有人认为，在编译型 Lisp 和现代环境中，经典的“代码与数据具有相同表示”这一概念其实并不真正适用。

学习、最小化配置与实验

• 有人希望看到更多“实时编码”的 Smalltalk 视频；帖子中分享了 Pharo 教程、游戏/实时编辑演讲，以及入门 Smalltalk 演示的链接。
• Pharo 上的 Glamorous Toolkit 被强调为现代“可塑开发（moldable development）”环境，其中文档本身就是实时、可编辑的代码。
• 有些人想要极简的 Squeak 配置（无图形/声音，仅 REPL，运行在 Raspberry Pi Zero 之类的小设备上）；讨论认为这并不简单，线程里没有现成、文档完善的路径。
• 还有一些想法被提出：
  • 在 Erlang/Elixir 的 BEAM VM 上做一个类似 Smalltalk 的系统，以获得并发和分布式能力。
  • 把 JS VM 作为 Smalltalk 的部署目标（例如 squeak.js）。
  • 把 Objective-C（受 Smalltalk 启发）视为今天更实用的动态替代方案；这一点被提到，但没有得到深入讨论。