Haskell Foundation 技术领导委员会完成组建并启动运作

Haskell Foundation 的技术领导委员会已经成功组建起来了！ 过去几周我们一直在讨论愿景和策略，现在已经全面投入运作。 我们将积极制定我们认为需要资金支持和落地执行的倡议与提案。为此，我们需要公司、承包商和志愿者的帮助。每个人都可以参与，无论是随口提出想法、自己撰写具体提案，还是寻找能够支持或资助这些倡议的机构。 我们尽量把社区提案流程做得轻量。不过，我们认为公平和参与至关重要，尤其是在涉及资金的时候，所以任何撰写提案的人都应该知道，我们会开放平台让社区发表意见，甚至提交反提案。随着我们积累经验和获得反馈，流程可能会不断演进。 以下是我们的愿景。欢迎随时联系我们！ 我们相信 Haskell 非常出色，能够为每个人提供独特的价值，因为它恰好位于人类工匠精神与机器自动化之间的一个有趣交汇点： 也许有更适合形式验证的语言，也有更适合 vibe coding 的语言，但对于“人在回路中”来说，没有更好的语言了。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 撰写这些内容；看到这些目标非常鼓舞人心。我认为这个雄心勃勃的议程将为我们带来很多乐趣和收益。