Avi Press | 2026年7月10日 — 声明 这篇文章写起来非常困难。我几乎没有写这篇文章，因为我更喜欢构建和推广而不是批评。然而，我希望这篇文章能够建设性地为关于Haskell未来的讨论增添一些内容。我必须强调，我并不是在外部批评Haskell。我关心Haskell，真诚地说明Scarf为何在抵触中离开它，希望能让社区中的人认真对待这一反馈。 我在这段时间的经历 在过去的16年里，我一直是Haskell的忠实粉丝。它无疑是我生活中最重要的编程语言。学习它使我成为了一名更优秀的程序员。我为它辩护，建立了一家以它为基础的公司，并在Haskell基金会和Haskell.org委员会任职。我也公开分享了我认为Haskell需要改进的地方。自从Scarf推出以来，我们的后端一直是用Haskell构建的。驱动我们应用的主要API使用了像Servant、Beam之类的库，并在PostgreSQL上。我还直接在WAI之上为Scarf Gateway构建了一个高性能的Haskell服务，它直接位于高流量的开源包流量的下载路径上。这些系统有真正的正常运行时间要求，合同约定的服务水平协议（SLA），我们在生产中成功管理了多年。我们对Haskell进行了严肃的生产测试，许多承诺都得到了验证。代码是可靠的。类型系统捕捉到了真实的错误。语言迫使我们认真考虑如何建模我们的领域。高性能代码通常相对容易实现。但成本也是真实存在的。其中最大的成本是编译时间和生态系统的摩擦。我们花了很多时间优化构建、缓存、Nix、开发环境、CI以及围绕严肃Haskell代码库所需的所有其他机器。很长一段时间，这种方式是可行的。我们的团队对语言和工具的理解很深入。我们知道尖锐的边缘在哪里，通常是带着这些问题生活的。然后AI改变了权衡。大型语言模型（LLMs）现在在写代码方面表现非常出色。显然，它们不是完美的，但它们已经足够好，以至于软件开发的经济学发生了变化。在历史上，我认为错误是发生在两个地方之一：编译时或运行时。现在还出现了第三个地方：代码生成时。模型通常可以在编译器看到代码之前避免错误。而随着模型的改进，在编译时捕捉每一个可能的问题的相对价值也在变化。这并不是说类型安全已经毫无价值。但类型检查的成本如今显得更为重要。如果一个LLM可以在几分钟内生成一个工作实现，而你的编译步骤需要明显更长的时间，那么你的语言和构建系统就成为了开发循环的瓶颈。重要的指标是：整个开发反馈周期需要多长时间，以及这段时间有多少在等待编译器？如果一个人花一个小时编写一些代码，一个冗长的编译周期是恼人的，但可以容忍。如果一个代理在几分钟内能草拟出一个合理的更改，然后再花15分钟等待项目从冷启动构建完成，编译器就从一个小麻烦变成了这个工作线程的主导成本。当你开始同时使用多个编码代理时，这种情况就变得难以忍受。如果你一次只处理一件事情，也许你只需支付一次冷启动成本，然后继续。但是，越来越多的情况下，这不是我想要的工作方式。我希望能够启动多个工作树，分叉出不同的工作方向，让代理尝试各种方法，查看结果，并保留有用的结果。在那个世界里，冷启动时间变得非常重要。如果每个新工作树都需要长时间的Haskell构建，或者需要仔细设置缓存，或者消耗大量内存，那么每个新的工作线程都将开始时带有税费。如果我想要五个代理并行探索五个分支，那么这个税费就会成倍增加。在Haskell中，人们经常讨论缓存、Nix、远程构建器等类似工具。这些工具确实有所帮助。我们也使用它们。但缓存从来不是完美的，为了使其感觉足够好的所需努力本身也是问题的一部分。在实践中，基于AI的并行开发需要廉价、可丢弃的执行上下文。我希望能够说：把这个分叉出来，尝试修改，运行测试，告诉我发生了什么。我们的Haskell环境对于这种工作风格来说并不够便宜。如果所有内容都被缓存并且你进行了一些小更改，你通常可以获得非常快速的编译。有时这个循环是20秒，这感觉很棒。但这是最佳情况，而最佳情况并不是你可以围绕整个系统进行优化的依据。你的更改越深入构建计划的核心部分，这个故事的有效性就越低。在一个以代理为主的工作流程中，你会更加关注冷启动情况、平均情况，以及更深层次的因素。