开发者 John Earnest 谈 Decker 项目与 K 语言的设计

John Earnest（Internet_Janitor）擅长打造富有创意、给人力量的项目。他做的项目“复杂得让它们所运行的平台几乎不可能承受”，比如 dp 和 Octoma；他的项目 Decker 让很多人联想到 HyperCard，并在 Arraycast 上被讨论过。iKe 是 oK 的一个声音与图形平台，右下角有像 Asteroids 这样的示例程序。 在这次访谈中，我们聊了数组语言（K 和 Lil）、语言设计与创造力。 我们从哪儿开始呢？哦！一只鸡刚跳到你腿上，真可爱！她叫什么名字？ Galina，和那种矿物同名。我养过两只，但她的姐妹去世了；这种事难免。 我的大部分职业经验都跟 K 有关，它常被视为 APL 的理念与一些 Lisp 思想成功融合的产物。几乎其他所有 APL 都把严格矩形数组当作数据载体，而在 K 里，嵌套的树状列表完全没问题。K 的语法本质上就是 Lisp 最初设想的那种 m-expr。 你在 K 里怎么架构大型系统？我读过的大的 APL 系统，都是简短优雅的原语淹没在一堆长名字里，甚至每个文件只有一条声明，像最糟糕的 Java 过度设计那样。有办法避免这种情况吗？ 在 Lisp 里，所有东西都刻意看起来像是由同一种材料做成的。Racket 或 Clojure 的语法比单纯的 s-expr 多一些，但宏刻意看起来和函数一样，这既是好事也是坏事，取决于视角。APL 家族语言那种水晶般的质感，在你构建庞大代码库、它开始变得更像常规语言时就被削弱了。 在我参与过的 K 和 Q 代码库里，子系统会拆到各自的文件里，注释很多……局部名字保持简短，但模块级名字往往更长。整体架构看起来和你用任何其他动态语言实现的一样，但业务语言缩小成了小小的结；k 用 2-3 行就能表达另一种语言里一页代码的内容，于是你眼前剩下的就是名字。 APL 和 Lisp 都是非常高层、富有表达力的语言，但在 Lisp 系语言里，你学会构建一套抽象，并让语言朝着你想做的事情的方向生长。在 APL 语言里，理想是无抽象编程。你直接用语言本身来写程序。设计讨论常常集中在什么应该作为原语、什么应该作为惯用法（简单组合）。确实，一些激烈的 APL 拥护者主张不要把库当作导入的代码文件，而是把它们看作一堆代码片段，你可以修改它们来精确实现你需要的功能。 在小说《上帝眼中的微尘》里，工程师阶层绝不会随随便便造一把椅子，而是会造出某个人在此刻精确需要的那把椅子。这是一种不同的代码复用思路：不是想当然地假定封装内部一切正常、接口足够窄，而是把它分解、改造、融入目标系统。有些问题本身具有足够的不可约复杂性，很难采用这种做法；网页浏览器必须应对庞大、复杂且不断演进的标准，而且有实际理由希望代码库与规范的结构相对应。但如果你的任务不是做一个符合标准的浏览器，而是构建一个具备浏览器功能的东西，你就有机会拆掉先入为主的观念、简化问题。这种哲学与 Forth 相当契合，在 Forth 里你同样是无抽象编程。 顺便说一句，高层语言和低层语言是一种错误的二分法。Paul Graham 那篇关于 Lisp 的 Blub 文章提出了一种语言优劣的线性尺度，但它至少是一个格。有些语言在客观设计上确实更好或更差，但一旦你加入一个上下文以及你想用这门语言做的事，就会有多门好语言、多个维度的表达力与刚性、严谨与可塑性，它们能惠及不同的领域。 一个人怎么确定自己的上下文？很快就“不技术”了。 编程的意义就在于此。无论你是艺术家，为自己挑选有趣的约束，还是工程师，接到一组需要满足的约束：它需要快吗，要部署在微小或奇特的设备上吗，要由很多人长期维护吗，还是应该能移植到尚不存在的东西上？有很多维度要考虑。 一个争议性观点：在很多上下文中，静态类型系统被高估了。它们显然在某些上下文中很出色：如果你在做某种不可约复杂、永远装不进一个人脑子里的东西，那么用机器可读的一套模式来表达约束，解决的是协调或社会问题。但在小规模编程时，在事情快速变化时，简洁和即时性大放异彩，而类型不必要地限制了你的思考。 Lil 面向人类规模系统的错误模型在这里完全适用。重新定义你的问题和工具，让你能忽略整类复杂性。 在上下文中澄清一下，Lil 有语法错误但没有运行时错误，所以每个格式良好的 Lil 程序都有定义好的行为，即使它很傻或者不一定符合你的期望。这个想法是，通过添加约束说“这个操作无效或错误”，你让有效程序的空间变得更稀疏、彼此相距更远。如果你的目标是尽可能简洁，你就想把尽可能多的含义塞进去。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）