这是我们在工作中使用有趣的编程语言的最后机会吗？

Source: Dev.to

冲突

从主流 vs. 小众编程语言的角度来看，这是一种不同的视角。

• 如果你对某种编程语言痴迷，那么你很可能痴迷于某种小众、深奥的语言。
• 如果你并不痴迷，你可能在使用或多或少标准的语言——老话说“没有人因为选择 Oracle 而被解雇”。

这两者并不相同，但请耐心听我说。我并不是在为任何一方辩护；我只是想说明这里存在冲突：

在一个团队、公司或更广阔的行业中，存在价值观和兴趣不同的人。

一个全新的冲突是使用大型语言模型（LLMs）。同样，有些人全情投入，有些人拒绝使用，而许多人则介于两者之间。

如果我们将这些维度叠加，就会得到冲突象限。这只是一个简单的示例——冲突很少是二维的。

冲突并不好玩。诚然，有些人喜欢并在冲突中茁壮成长，但对大多数人而言，持续的冲突会让人疲惫。如果我团队的大多数人位于一个象限，而我在另一个象限，我就必须：

• 压抑自己的需求，
• 争论，
• 换公司，
• 或做其他事情。

可能的解决方案

在工作中审视一个项目时，我恍然大悟：我们既可以拥有蛋糕，又能吃掉它——一个团队可以使用特定的工具，另一个团队可以使用别的东西。我们可以在多个象限中组建成功且低冲突的团队。

下面是那个小项目的故事。也许它能在黑暗动荡的时刻给你带来希望或灵感。

Source:

项目概述：将内部仪表盘迁移到 PureScript

背景

• 大约两年前，我想把现有的内部仪表盘迁移到 PureScript。
• 该仪表盘是一个没人想动甚至不想扩展的遗留系统的一部分——门槛相当低。

目标

1. 快速迁移基本功能，以解除困扰我的大型遗留系统迁移的瓶颈。
2. 实现可组合、可扩展，尽可能降低摩擦：可复制的组件以及轻松集成 TypeScript/JavaScript 组件。
3. 展示 PureScript，激发大家的兴趣（剧透：并未取得成效）。

从未把推广 PureScript 作为目标；与团队和技术领导的约定是先尝试几周，然后再考虑或计划重写为 TypeScript。

我在 业余时间 完成了 MVP（包括核心功能的迁移），因为工作时间没有空余。作为额外收获，我还制作了一个关于 PureScript + shadcn/ui 的视频和一个模板。

为什么不引入不可维护的技术？

我认为最糟糕、最不专业的做法之一，就是引入没人能维护的东西。这会永久玷污该技术的声誉。

我曾见过一个用 Haskell 构建的项目，从一开始就因糟糕的管理和不切实际的计划而注定失败。团队成员离职，最终没有人能够或愿意维护它。多年后，甚至连 Haskell 长什么样都不知道的人都把所有问题归咎于这门语言（以及开发团队）。

Source: …

执行

在我部署第一个版本后，只有我们两个人在贡献。

• 我的合作者 没有任何 PureScript 经验，最初 非常讨厌它——主要是因为工具链和编译错误。
• 尽管如此，他贡献的 代码和功能比我多。
• 几周后我们把项目做到了相当大的规模，尽管这并不在我们团队的优先事项中；我们在晚上以及其他任务之间进行开发。

LLM 辅助时代

事情进展顺利，项目在成长，随后我们进入了 LLM 辅助编码时代。

• 许多过去需要手动管理的恼人事务现在都有了漂亮的 UI：客户支持工具、开发工具、产品配置、分析以及探索工具。
• 其中大量代码并非人类编写。结果是？相当成功。

它之所以能够如此良好且可扩展的主要原因是它是一个 无状态应用（除了持久化用户的暗/亮模式偏好），并且由简单的流程组成。当我们让 LLM 介入时，已经拥有了一个充满可复制代码片段的坚实代码库。

每个工具都是 隔离的；它不会影响其他工具。唯一的问题是如何组织所有内容并避免 UI 混乱，但这更像是一个有趣的拼图，而不是实际的难题。在这种情况下，我并不担心潜在的糟糕或缓慢的更改会影响其他工具——无需进行大规模的冒烟测试或 QA 循环。

真实案例

“有个人想要添加一个新的防欺诈工具。他不是我们团队的一员，也从未接触过 PureScript。”

我们进行了一次五分钟的聊天，我分享了仓库，并说：

“看，只要有安全的端点，基本上没有其他需要担心的了。”

项目的 README 只有：

npm install
npm start

没有复杂的设置。贡献者第二天就打开了一个 pull request；代码看起来很好，保持了一致性，UI 也友好且易于使用。

经验教训

• 陡峭的学习曲线不再是阻碍。
  由于良好的文档、可复制的模式以及 LLM 的帮助，贡献的入门门槛现在相当低。

• 不要一概而论。
  我并不是说每一次贡献都相同，也不是说这种方法可以取代深度技能的获取。它只是降低了入门的门槛。

• 无状态、隔离的组件 使得实验和快速迭代变得安全。

• LLM 可以加速开发，而不会牺牲可维护性——前提是底层架构简单且结构良好。

结论

语言选择、工具链以及 LLM 采用方面的冲突是不可避免的。但它们不一定要具有破坏性。通过：

1. 选择低摩擦、可组合的架构，
2. 保持组件隔离且无状态，
3. 利用 LLM 处理样板和重复代码，

你可以构建一个欢迎任何象限贡献者的系统——无论他们热爱 PureScript、讨厌它，还是从未听说过它。

因此，下次当你思考是否需要在意所使用的编程语言时，请记住，你所创建的过程和环境往往比语言本身更为重要。

开源、LLM 与函数式代码

在工作环境中，现在有机会拥有 良好的人类代码（我甚至可以说是良好的函数式代码），并向各种贡献者敞开大门。如果你的标准高于 LLM 能够提供的水平，你随时可以对代码进行重构和打磨。

作为额外好处，我们可以降低对可维护性和“公交车因子”的担忧。微软表示他们将使用 LLM 将所有代码重写为 Rust，所以如果有人敢于声称这样做，我们同样可以在更小的规模上大胆引入新技术。

如果有人在工作中讨厌你的 Haskell 工具，是什么阻止他们在周末把它重写？
这从未如此容易。

我只在将 Ruby、JavaScript 和 Python 代码迁移到函数式语言方面有经验，但我相当确定反向操作同样可行。

这同样可以延伸到制作库。如果有人说：

“哦，不！没有针对某个新热技术的 Haskell SDK！”

我们可以直接笑他，然后把他送回 2025 年！（抱歉，这是我最喜欢的内部笑话之一。）

PureScript 与 FFI 生成

以 PureScript 为例，我们甚至不需要重写库——可以为现有的 JS/TS 库生成 FFI（PureScript 友好的绑定）。我们还可以生成使用这些库的 TypeScript 代码，然后再为该代码生成 PureScript 绑定。

示例：
我们使用 shadcn/ui，已经集成了几个图表，但并不是全部。几个月前，我想调查一下某处的数据长什么样（以改进缓存），只做一次。LLM 在快速绘图方面相当不错——它们不想使用 shadcn/ui，而更倾向于直接使用 Radix charts。但我不需要维护它，所以无所谓。

（也许下次我还会需要它，而我仍未学会它，但那是另一个问题。）

工具与错误

我不想在一堆抱怨和神话中纠缠；我想提到的最后两件事是 工具 和 错误。

我没有精确的维恩图，但很多抱怨 Haskell 工具的人现在已经把聊天当作代码的接口了。所以……嗯……自行得出结论吧。

编译错误的情况更有趣。这些错误——在 Haskell、PureScript 等语言中——是许多缺乏经验和有经验的开发者的痛点。讨论这个话题已经在我的待办列表上很久了。

长话短说： 90 % 甚至更多情况下，编译错误实际上 非常好且精准。问题在于它们往往 过于 精准。编译器会用你不懂的词汇和概念准确指出问题所在。如果你真的懂，你根本就不会犯这个错误。

firstLetter :: String -> String
firstLetter xs = head xs

• Couldn't match type ‘Char’ with ‘[Char]’
  Expected: [String]
    Actual: String
• In the first argument of ‘head’, namely ‘xs’
  In the expression: head xs
  In an equation for ‘firstLetter’: firstLetter xs = head xs

0 || True

• No instance for ‘Num Bool’ arising from the literal ‘0’

顺便说一下，我并不是在为这些错误辩护。它们对人类仍然很糟糕。但你猜怎么着？它们对机器 非常有用。把这些“糟糕”的错误喂给 LLM。完全不必害怕编译错误。

一个真实的 LLM 生成模块

在这个项目中，我们对 LLM 生成的代码保持谨慎，但最终还是得到了一些只有 Claudius 会阅读和编辑的模块。一次我出于好奇想看看我们到底写了什么。

我们为不同的飞行状态准备了 10 种状态——这是一种常见模式：当某个动作正在进行时，我们不希望允许其他动作。每个动作/按钮都有自己的标志/状态，并检查所有其他 9 项（共 9 次检查）来决定是否应该被禁用。糟透了。

• 如果你查看一次更改或 PR，…

ime，没关系——每个状态只会添加一个普通状态，没有什么特别的。

• 如果退后一步看全局——hell。从 10 个状态快速简便地降到 1 是个捷径。

重构和处理技术债务非常重要，但也可能让人害怕。这正是支持 fearless refactoring 的语言（如 PureScript）的优势。例如，我无法想象 JavaScript 开发者如何长期生存下去。

这就是我现在在某个特定项目中的情况。这 不是 对仅使用函数式编程的未来的论证。

给你的问题

1. 你在意使用什么编程语言吗？
2. 你为此做了什么？
3. 大型语言模型会在意它们使用的编程语言吗？
4. 语言选择如何影响你在乎的事物？
5. 它将如何影响未来？

这是 2026 年 2 月；无论你的观点和经验如何，编程语言因新抽象层而变得不那么重要的可能性（并非 0%）是存在的。但它们也可能变得更重要。这会是我们最后一次选择并关心编程语言的机会吗？

我本想在这里漫谈、推测并进一步展开，但大概只能留到以后再说。

支线任务：PureScript 采纳

对于那个项目，我的支线任务是让人们对 PureScript 产生兴趣，甚至教几个人。结果失败了。 没有人真的想参与，而且目前也没有太多激励。