Haskell Foundation 技术领导委员会正式成立并启动运作

Haskell Foundation 的技术领导委员会已经成功组建起来了！

过去几周，我们一直在讨论我们的愿景和策略，现在已全面投入运作。我们将积极制定我们认为需要资金支持和落地执行的倡议与提案。为此，我们需要企业、承包商和志愿者的帮助。每个人都可以参与，无论是非正式地提出想法，还是自己撰写一份具体的提案，或者找到能够支持或资助这些倡议的机构。

我们尽量让社区提案流程保持轻量。不过，我们认为公平和参与至关重要，尤其是在涉及资金的时候，所以任何撰写提案的人都应该知道，我们会开放平台让社区发表意见，甚至提交反提案。随着我们积累经验和获得反馈，这个流程可能会不断演进。

以下是我们的愿景。欢迎随时与我们联系！

我们相信 Haskell 非常出色，它能为大家提供独特的价值，因为它恰好处于人类工匠精神与机器自动化之间一个有趣的交汇点：

也许有更适合形式化验证的语言，也有更适合 vibecoding 的语言，但对于“人在回路”（human in the loop）来说，没有比 Haskell 更好的语言。Haskell 是我们掌控自己的工作、积累机构知识并负责任地交付成果的地方。

我们致力于为所有人改进 Haskell：

想象一下，如果 Haskell 拥有 golang 的迭代速度、C# 的调试能力以及 rust 的上手体验，同时还能提供更强的保证和更好的性能！

现代工作流要求快速的迭代周期：编译、交互式 repl、远程依赖缓存、CI 和测试集成。所有这些都会影响人类和机器的工作流。

Haskell 在代码复杂度方面扩展性很好……但在构建时间方面扩展性不佳。举例来说，GHC 自己的 CI 周转时间长达 6 小时。我们希望将其缩短到 2 小时。

与其无可奈何地把日志和二进制文件一股脑丢进 LLM 对话里，我们设想的是确定性的工具，能够进行精确且符合人体工程学的查询：

而所有这些不仅能在你的编辑器/IDE 中使用，还能通过强大的 CLI 和脚本接口使用，后者既能赋能高级用户，也能支持 LLM 驱动的调试（原生支持，无需任何像 MCP 这样的自定义适配器）。

调试必须重新变得有趣，而不必在你的代码库里到处散落 Debug.Trace.trace。

文档和交互式探索将帮助新手理解惰性求值和 GHC 的所有注意事项，并应清楚地解释如何利用这些工具。

在这个容忍挫折能力极低的时代，我们要打造编程语言生态系统中最好的上手体验，因为这是衡量整体开发者体验的终极基准。

只有我们坚持 unix 原则，才能做到这一点，我们将其总结为：

文档应该读起来是一种享受，由人撰写，为人服务。

安全和信任不会凭空建立。一旦信任失去，往往就无法挽回。

为了保护我们的社区资产和声誉，我们需要：

我们应该进一步支持利用或扩展 Haskell 语言优势的尝试，以推动安全设计和架构的实际应用，例如信息流控制（Information Flow Control）或强制访问控制（Mandatory Access Control）。我们也在关注依赖类型和 liquidhaskell 的进展。

如果我们能用最新的 GHC 编译 10 年前的 Haskell 软件，而无需对源代码做任何修改，那会怎样？

虽然这看起来像是一个不可能实现的目标……但踏上这段旅程无论如何都会让我们更接近一个健壮、稳定且可预测的生态系统。

沿途我们需要回答的问题是：

这不仅需要对 GHC 和核心工具进行投入，还可能需要支持社区努力维护稳定的包集合或协调生态系统升级、让 cabal 在复杂用例下更符合人体工程学、引领并支持稳定性政策，以及收集关于生态系统中哪些部分导致频繁变动的数据。

我们希望 Haskell 不仅成为快速发展的初创公司的选择，也成为不希望其工作流或软件栈被打乱的大型或保守型公司的选择。稳定性将使这两类用户都受益，降低成本与摩擦，并为 Haskell 树立起一种现代语言、拥有可预测生态系统的声誉。

以上所有内容都是为了支持我们所热爱的 Haskell 开源生态系统。我们致力于开源、开源价值观以及其中的社交层面。协作是我们相互交流与启发的方式。

我们希望赋能所有维系这个生态系统存续的维护者和志愿者，他们中的许多人默默无闻，在世界另一端的一个周六晚上做着自己的一份贡献。

我们写代码，是因为我们热爱交付产品。但我们写代码，也是因为想要社交、结识朋友、享受美好时光。我们致力于兼顾这两种价值。

感谢 @hasufell 和 TLC 撰写此文；看到这些目标非常鼓舞人心。我认为这份雄心勃勃的议程将为我们带来很多乐趣和收益。