好点子的墓地

**摘要：** 好点子有时会因工具链或社区支持不足而失败，但技术进步往往能让它们重获新生——正如理查森的天气预测、阿姆斯特朗的UBF协议以及作者自己的"deft"项目所展现的那样。 # 好点子的墓园 ## 令人着迷却未竟的项目：定义"Deft" 演讲者的热情源自论文《类型系统即宏》，该论文描述了Turnstyle——一个在Racket中通过宏创建类型化语言的系统。这启发了他们在Elixir中构建类似的沙盒环境，并将项目命名为**deft**。 经过一个月高强度且不健康的编码（主要通过直播），他们成功实现了功能原型。该原型支持代数数据类型、与原生Elixir代码的互操作性，以及基于Turnstyle启发式DSL的静态全程序检查。他们甚至实现了模式穷尽性检查规则。 然而项目最终搁浅。初期障碍并非功能问题——其运行良好。真正的阻碍在于：要让这个点子适用于大型真实Phoenix项目，需要投入巨大的工程量。这包括构建**语言服务器**，并与现有Elixir工具（如人性化诊断信息）实现无缝集成。他们意识到，这项工作需要专职团队的资金支持，而非个人在业余时间完成。于是该项目在2022年被搁置，成为了一个"当时技术条件下无法实现的好点子"。 ## 超前时代的远见者：刘易斯·弗莱·理查森 演讲者将此与**刘易斯·弗莱·理查森**相提并论。这位贵格会数学家在第一次世界大战期间构想出了数值天气预测。在法国前线救护队服役时，他利用零散时间研究用七个方程描述大气的系统。 1922年，他在著作《数值天气预报》中发表了自己的构想。虽然备受赞誉，但主流气象学家大多未予理会。批评很实际：他的方法需要数月计算才能得出一个早已过时的预报。理查森本人也承认这一点，称之为"梦想"。 为具象化这个梦想，他设想了一个映射地球的巨大圆形舱室，内有**64,000名人类计算员**。每人负责一个网格单元的大气方程计算，读取相邻单元的结果，由指挥者用彩色光束同步所有人的工作节奏。这个愿景是只有系统架构而无运行硬件的空中楼阁。他将之发表后便暂时搁置。 ## 梦想成真：从ENIAC到现代并发 1950年，**约翰·冯·诺依曼**和**朱尔·查尼**团队使用**ENIAC**计算机运行其方法的改进版本，部分实现了理查森的愿景。24小时预报需要约24小时计算——他们勉强跟上了天气变化速度。瓶颈在于**10万张打孔卡**，而非机器本身。 后来，历史学家彼得·林奇用Fortran重建了理查森的原始计算。演讲者更进一步，利用现代工具实现了理查森关于分布式"天气工厂"的愿景。他们创建了一个高度并发的Elixir/OTP系统，对应理查森设想的64,000名工作者的场景。 为确保正确性，他们采用了**三层验证塔**： 1. 基于林奇代码转换的**Fortran顺序引擎** 2. 独立的**NIF张量引擎** 3. 分布式**"工厂"本体** 工厂的每个计算步骤都与顺序引擎进行比特级校验，验证复杂的消息传递架构是否产生了与原始简单算法相同的结果。这证明现代运行时终于能够执行理查森当年只能勾勒的架构。 ## 无法跨越鸿沟的协议：乔·阿姆斯特朗的UBF 演讲者随后引出另一个杰出构想：**乔·阿姆斯特朗的UBF（通用二进制格式）**，该协议于2002年发表。阿姆斯特朗在论文《与世界对话》中，针对多团队分布式系统中的故障诊断难题提出了解决方案。 UBF是一个三层协议，其核心层**UBF B**是一种用于定义客户端-服务器协议的小型语言，可将协议建模为**状态机**。通过在进程间设置通用"契约检查器"，任何协议违规行为都能立即归因于客户端或服务器。系统实现了自我诊断。 尽管设计精妙，UBF并未获得广泛采用。阿姆斯特朗多年后反思："或许它太超前了。"采用新型数据格式的摩擦成本过高。这个构想是正确的，但从理论到实际系统的转化成本令人望而却步。UBF就这样与理查森的天气工厂一同沉入"墓园"。 ## 通过现代工具链复活 演讲者通过近期技术发展将这些线索串联起来：强大AI编程助手的兴起。这创造了一个**临界点**，极大降低了从优秀构想到可工作系统的转化成本。 正是这种变化，让他们相信2022年的"deft"项目可以重获新生。那些必要的样板工作壁垒——比如语言服务器和诊断工具——不再是难以逾越的障碍，而是可以高效解决的漫长清单。 最终回归个人体验：旧版"deft"原型产生的优雅类型错误虽然美妙，但实现周边工具链使其真正可用，并非他们独处时享受的编程工作。如今有了先进工具处理这些基础架构，这类愿景终于能被构建和分享。好点子的墓园或许终将成为项目复活之地。 来源：《好点子的墓园》（https://www.youtube.com/watch?v=ovlQ81rBc-4）