前言

我目前关注 lively 的 2 个版本:

lively.next 试图成为 LivelyKernel 下一代版本, 但完成度还不高, 目前它们各有优势:

  • LivelyKernel

    • 更丰富的案例和学习资料
    • 更加稳定和完整
    • 更强大的开发环境
      • 函数级别的调试模式
      • 可视化的 connect

  • lively.next

    • 更加模块化和简洁
    • component
    • 生产模式(freezer)

下文分别记录它们的优势.

LivelyKernel

更丰富的案例和学习资料

这点对开发团队至关重要。要是没有可供学习的资料和例子, 就得从源代码学习, 低效且令人生畏。

仅凭这点理由, 就足以让打算使用 lively 的团队, 从 LivelyKernel 开始。从 LivelyKernel 习得的知识和技能, 大多可用于 lively 生态的所有系统。

因此, 即使 LivelyKernel 比较旧, 它也值得你将入门的时间投入在这里。

有大量的真实案例在 LivelyKernel 上边构建, 在 PartsBin 里查看:

我特别喜欢这些基于 LivelyKernel 的项目:

更加稳定和完整

LivelyKernel 提供了稳定和完整的开发环境, 用于支持开发过程。

dynatalk-js 在 LivelyKernel 开发, 过程非常愉快, 很少遇到系统问题。 而在 lively.next 中做一些简单的项目， 也可能出现许多系统性的 bug, 或许因为 lively.next 还在频繁开发。

随手可及的小工具(log等)让开发过程非常愉快。这些小工具的设计, 贴心周到。随着你对编程环境的熟悉, 有时会想"要是有这样一种工具就好了", 在系统里一搜寻, 果然就在哪里! 只有当系统的开发者喜欢"吃自己的狗粮"时, 才会出现这种贴心的设计。

更强大的开发环境

Dan Ingalls 编程的手艺是无与伦比的(Alan Kay 认为世上再也找不到第二个)。LivelyKernel 倾注了 Dan Ingalls 大量心血。 LivelyKernel 是一个 JavaScript 开发环境, 却提供相当丰富的 Smalltalk 编程体验。

lively.next 试图继承这些特质，目前完成度似乎还不够高。

函数级别的调试模式

LivelyKernel 最强能力之一是调试模式, 你可以在代码运行期间, “录制"整个执行过程, 然后进行"时间旅行风格的调试”. 由于是"录制", 所以当你拉动时间轴时, 副作用不会重复触发。

你可以在 Workspace 或 browser 中进入这个模式:

这使得浏览器本身的 debugger 变得不重要。 当然, 如果确实需要, 可以在代码中实时加入 debugger(完全是动态的!), 然后打开浏览器的 devtool 使用它。

目前 lively.next 似乎还不支持这样的调试体验。 lively.next 中的调试, 目前似乎只能借助浏览器的 debugger

可视化的 connect

connect : 以声明方式定义源对象(source object)与目标对象(target object)之间的数据流连接。

LivelyKernel 允许使用 halo 直观地在两个 Morph 对象之间建立 connect.

lively.next 目前还需要使用代码来建立 connect。

lively.next

更加模块化和简洁

lively.next 将 LivelyKernel 的许多功能划分为模块, 更加干净整洁。

代码层面, 更加现代化(ES6)。

给人感觉调整 lively.next 似乎会更容易(暂未验证)。

component

component 功能在 这段演讲中 有提及, 看起来非常强大, 它可以做到:

  • 在浏览代码时实时实例化 component
  • 手动摆弄实例, 会实时地映射到代码

以下是我做的一个小实验:

lively.next 有许多系统级别的 component, 都支持这样的操作!

生产模式(freezer)

Smalltalkers 普遍认可调试模式是唯一模式, 他们将编程环境视为一种学习环境, 将计算视为一种理解世界或特定问题的动态媒介, 软件只是心智成熟的副产品, 甚至不是最重要的副产品。

Smalltalk 分发的软件通常会携带完整的开发环境, 因为它假设用户可能会持续成长, 以至于需要理解和修改它，以服务于自己的新需求。尽管这样的事情不一定会发生, 但当用户需要时， 它应该是"可能的"。

让简单的事情保持简单, 让困难的事情成为可能 – Alan Kay

这使得他们尤其关注可理解性, 他们喜欢触摸运行中的软件/对象，在其生命周期中去探索和理解它(这比主流开源社区要求的更多, 开放源代码只是提供可理解性的最低要求)。

带来的一个问题是, 不容易以主流风格分发软件。

目前的软件行业喜欢分发"软件产品", 通常有以下要求:

  • 它应该尽可能优化(为了用户体验)
  • 它要尽可能安全(用户体验是目标之一, 文末有更多讨论)

而 Smalltalk 社区的软件(它们甚至不喜欢产品这个概念)总是携带完整的开发/调试环境(诸如早期的 Scratch 携带了整个 Squeak 环境), 这通常被认为 “商业不友好”。 这个问题很复杂, 我们留待文末讨论。

在此, 我想简单地抛出这样的看法, Smalltalk 社区的软件在优化层面做得确实不够好, 它应该提供"生产模式"的选项, 这有利于做到 Alan Kay 下述名言的后两项:

Make it work, make it correct, make it fast, make it cheap – Alan Kay

lively.next 提供了 “生产模式”, 称为 freezer. 这部分演讲提到了这点。

freezer 使得我们能够发布更接近主流 Web APP 体验的应用。

如何以"生产模式"发布 lively.next 应用

以下是两个使用 “生产模式” 发布到 Github Pages 的应用:

可以看到, 打开这些 demo, 要比从 lively 开发环境打开快得多。

lively.next 提供了很好的脚手架来支持"生产模式"。 当你在 lively.next 中创建了一个项目, 可以将其配置为提交到 Github 之后自动发布为 “生产模式”。

当然你也可以在 build 为"生产模式":

1
2
3
4
5
6

# 进入项目目录如: lively.next/local_projects/lively-demo`
npm run build
# 预览
cd build
python -m http.server
# 打开: http://127.0.0.1:8000

如何支持用户探索 和 改编(remix)

我们无需在 “生产模式” 与 “调试模式” 之中二选一, 可以将它们视为应用的不同视图(view)。

有很多方式可以做到这点. 一种简单的做法是, 在 “生产模式” 的页头或页脚附上代码仓库地址, 当用户有兴趣探索或改编时, 点击链接，将使用 lively 开发环境打开仓库地址。 目前有许多应用托管平台(如replit, glitch)也提供了类似的机制。

结论

我目前整体上感觉是:

  • LivelyKernel 完整性更高, 似乎更适合作为开发和探索新想法的环境。它有许多历史包袱, 因此更复杂。
  • lively.next 功能更少, 更干净, 将其修改为自己想要的东西似乎更容易。

在一段时间里, 或许可以考虑让两者共存, 如果 LivelyKernel 确实开发效率更高的话，适合用于内部开发。尽量让开发的代码模块化，方便在 lively.next 更加成熟后, 把开发成果迁移过去。 SqueakJS 和 dynatalk-js example 都展示了 LivelyKernel 开发的项目, 可以用于其他 JavaScript 环境。

lively.next 似乎适合用于发布应用, 目前的 freezer(以生产模式发布应用) 功能已经很不错了。

思考

SqueakJS vs lively

SqueakJS 里边有 JSBridge , 如果将其发展得足够易用(如 Caffeine), 是否会与 lively 形成竞争?

数字赋权

前边在讨论"生产模式"时提到:

目前的软件行业喜欢分发"软件产品", 通常有以下要求:

  • 它应该尽可能优化(为了用户体验)
  • 它要尽可能安全(用户体验是目标之一, 文末有更多讨论)

“尽可能安全"通常包含几层含义:

  1. “为了保障用户的安全” 是通常的说辞, 它的确包含事实的碎片
    • 避免用户弄坏软件, 软件最好是冻结的, 它应该像水泥浇筑的一样坚固, 用户不应该可以随意掀开引擎盖。用户只应该在产品经理设计好的区域活动。
      • 移动端软件将这个想法发挥到极致。
  2. 对供应商安全
    • 这通常不会拿到台面上说, 供应商不想自己的工作被对手获取(完全可以理解), 所以希望把软件作为一个黑盒发布, 这也是 SaaS 受到供应商青睐的主要原因之一。

当用户寻求软件只是希望解决手头问题时，用户不会要求更多的权利, 这通常是供应商教育他们的, 比如乔布斯告诉用户"任何问题都有一个适合它的 APP”。他们只是等待供应商的供给，并期待他们是仁慈而全能的上帝.

今天的计算机文化与一个社会在民主化之前的政治文化是很相似的。 拥有权力的人喜欢谈论 “安全” 和 “保护” (然后坐享"保护者"拥有的特权, 柏拉图在《理想国》中把这想法发挥得动听极了), “保护者” 不喜欢谈论与授权相关的概念(如约翰·洛克主张的 agency), 那样的话, 他们就不能为用户"代持"那么多权力了。

怎么看待主流软件行业对 “软件产品” 的这些看法呢?

我的看法是它们并不都是荒谬的, 里边有"真理的碎片", 有些目标是可取的, 诸如追求更好的用户体验, 诸如提供优化和有安全护栏的产品。

但这些不是剥夺用户权利的理由， 完全可以在尊重用户权利的前提下做到这些。

Alan Kay 给出过很好的思考方式:

让简单的事情保持简单, 让困难的事情成为可能

安全护栏是有意义的, 自由有时候是一种负担, 设计者不应该将所有的自由度暴露在用户面前, 强迫用户接受自由度， 也会强迫他们接受复杂性。

通过好的设计, 可以在自由度与复杂性之间取得协调, 日渐强大的 AI 也有助于实现这个目标。

但护栏不该是锁死的, 当用户主动要求跨越护栏时， 应该允许这样做，因为这是用户的权利。

Smalltalk 社区始终珍视用户的这种权利, 我将 Smalltalk 看作计算机领域与主流不同的一种政治诉求, 它主要关于计算的民主化和用户权利。

当 Dan Ingalls 将 Smalltalk 传统带到 Web 平台时, 我们就得到了 lively。

参考