文章讨论Lisp诅咒蔓延至其他编程生态

Lisp 的诅咒常被引用来解释为什么 Lisp 方言的库和可复用组件如此之少。根据这个概念，Lisp 过于强大和灵活，使得开发者能够轻松创建自定义解决方案，从而导致他们长期孤立地工作。这又导致他们经常重复造轮子，因为编写代码解决自己的问题，往往比依赖他人的库（及其思维方式）更容易、更快捷。这就造成了中心化框架和库的缺失，而许多其他语言生态恰恰拥有这些。有时人们还会提到，这种孤立编写的强大而灵活的代码往往缺乏文档，第三方难以理解，于是其他开发者更愿意编写自己的模块——诅咒便如此延续下去。

本周我卷入了好几场讨论，有人认为借助大语言模型的便捷与质量，如今生成代码比使用框架或库这类现有抽象更容易、更便宜。如果我们忽略一个事实——成熟的库极其稳定，经过数十万开发者的测试，被纳入数千条 CI 流水线，并由该领域的专家维护——如果我们接受这个假设：让 LLM 生成功能比学习现有库和框架的接口（或让 LLM 集成这些库或框架）更容易，那么对 Java 这样的语言生态会有什么影响？

过去几十年里，许多人通过协作、集体解决问题以及以攻克难题为目标，为开源生态的成功做出了贡献。

上述情景的第一个效应是：使用开源库的人会减少，从而减少对维护者的反馈。如果我用一两个提示词、20 分钟等待时间和几美元的 token 就能解决我的问题，我为什么还要费心去调研？为什么还要费心去理解别人做出的 API 决策？为什么还要费心去读文档？

第二个效应是：新开源库的创建将停滞。做开源最难的部分是维护。组织代码、托管基础设施、发布到制品仓库。版本管理、向后兼容、保持技术栈更新。如果生成代码如此容易，如果我能如此迅速地解决自己的问题，我为什么还要费心把代码模块化、与世界分享，并完成开源项目所需的一切项目管理？我生成的模块里什么都有，需要时我可以破坏 API，把一切都精确调整到我的用例、我的技术栈。

长期来看，这两个效应甚至可能相互放大。如果用来将新技术、新方法引入语言生态的开源库变少了，人们可能更倾向于直接编写/生成自己的解决方案，然后了事。

你可能已经读出我的言外之意：我并不认同那个假设——我们可以跳过为代码添加库和框架，直接生成一切。我更愿意依赖经过验证、具有明确定义抽象的库，而不是生成数百行代码来解决我的局部问题。“非此处生成”不过是“非此处发明”的另一个版本。尽管如此，我认为大语言模型在编程中的应用已经势不可挡，上述情景会以某种方式到来。也许不像某些思想领袖如今宣称的那样剧烈，而是以一种意外的方式发生。开源协作会在一定程度上衰退，软件开发可能会变得比现在孤独得多。