迈向可理解的软件

# 迈向可理解的软件 来源：https://gracefulliberty.com/articles/towards-understandable-software/ 为什么编程很糟糕以及如何修复它 2026\-03\-07· 13 分钟 ·\#计算（https://gracefulliberty.com/articles/tags/computing） 编程很糟糕。代码很糟糕。它难以阅读、难以测试、难以维护。只有少数人能理解任何一个特定的软件项目。这些都是大问题。我来解释我们如何解决它们。 ## 大语言模型不是那个抽象层 大语言模型（LLM）正在成为行业软件开发的重要组成部分。即便是拥有多年经验的专家也在使用LLM代理来测试、调试甚至编写代码。如今许多LLM已经能够与环境集成，它们的一些后勤问题得到了缓解。 非程序员也开始使用LLM。编程本就令人望而却步。许多人不知从何入手，即便知道，也没有兴趣学习任何特定语言的细微语法和库。我经常看到编程知识有限的人用LLM编写从简单的个人脚本到处理科学数据的工具等各种东西。 我不认为这是因为LLM在编程方面出类拔萃。该领域的几乎每个人都见过一次“vibecoding”的结果。即便测试通过了，生成的代码通常也是一团糟。 不，我相信程序员和非程序员转向LLM，是因为编程*很糟糕*。有太多相互冲突的软件栈、无尽的样板代码和烦人的库。普通软件开发者的工作已经退化为拼接库，而不是编写有趣的代码。 但编程很糟糕这一事实并不会让LLM变得更好。它们的主要问题依然存在。它们仍然对环境具有破坏性，从根本上基于盗用的代码，产生不一致的代码，并*灌输依赖*（https://www.media.mit.edu/publications/your-brain-on-chatgpt/）。总的来说，尽管LLM有其承诺，但它们让编程变得比以前更糟。我们值得拥有比当前编程范式更好的东西，但也值得拥有比LLM更好的东西。 ## 我们可以做得更好 如果我们放弃LLM，不必放弃自动化。如果我们放弃LLM，不必放弃高层次的抽象。如果我们放弃LLM，不必放弃人性化的界面。 LLM承诺的好处可能不值得其代价，但我们不必放弃这些好处。我们可以拥有可预测、高层次、可测试的系统，使软件更易于维护。我们甚至不必放弃用自然语言与机器交流。我们只需要采用不同的方法。 我们不应去解决编写代码的问题，而应解决代码底层的软件栈。我们不应让生成海量代码变得更容易，而应彻底消除编写代码的需求。我们应该拥抱那些引领我们走向更高层次语言的抽象层。当自动化某一抽象层的冲动出现时，我们应该将其抽象掉。 LLM在编程中的普及告诉我们，我们需要一种不同的编程方法。自动化编写代码过程的冲动告诉我们，我们需要抽象掉编写代码的需求本身。我们需要另一个抽象层，让我们能够以人类——而非计算机——自然思考的方式来思考软件。 ### 记录这把“牦牛” 让软件可理解的第一步也是最重要的一步是文档。如果我们希望软件能被其他人类理解，至少我们可以向他们解释它。 程序员已经知道文档很重要，但在大多数情况下，我们将其视为事后附加到代码上的东西。我们先写代码，然后可能添加文档注释来解释公开函数的作用。如果用户走运，我们甚至还会写使用示例。 我提议反过来做。不是先写代码再附上文档，而是先写文档再附上代码。我们先告诉人类我们的程序做什么，然后告诉计算机它应该做什么。这就是所谓的“文学编程”（https://en.wikipedia.org/wiki/Literate_programming）。 想象一下：你不再需要阅读别人的代码然后费力解析他们的意图，而是先阅读文档理解他们的意图，然后再阅读代码。你再也不必费力去理解某人为另一个受众（机器）写的东西。他们已经为你解释过了。 据我所知，最好的实现是Entangled（https://entangled.github.io/）双向缠结器。缠结器从你的文档中提取代码并将其分发到适当的源代码文件中。它的双向性意味着你可以用它在文档中嵌入代码，然后正常编辑这些代码，它会将更改传播回文档中的代码块。这允许程序员使用现有的测试、重构和代码格式化工具，而无需为文学编程提供特殊支持。 而且它很快。缠结器对你的构建系统增加的开销很小，尤其是与编译器相比。 我们应该拥抱这种方法，并记录我们整个软件栈，从启动计算机的固件到我们用来连接社区的Web应用程序。这将使软件的每个方面对使用和开发它的人来说都更容易接近。 尽管去*剃这把牦牛*（https://en.wiktionary.org/wiki/yak_shaving），但也要记录它。 这种方法并不能直接解决编程糟糕的问题。它仍然涉及代码及其所有混乱，但它使那些糟糕的代码更容易理解。它在一个方面替代了LLM：理解别人的代码。 ### 废除代码 但我们还可以更进一步。我们不仅能记录代码——我们还能摧毁它。 代码是过去时代的概念。我们被迫使用它，是因为我们过去通过终端与计算机交互。我们用键盘向计算机输入指令，然后计算机解释并运行这些指令。 我们没有理由继续这种模式。坚持用几乎只是一维的晦涩符号和关键词序列与计算机交流，是不愿利用过去40年计算方式变化带来的优势。 拥抱结构。废除代码。 #### 拥抱图形用户界面 我认为替换代码的一个重要方面是拥抱图形用户界面（GUI）。现在大多数人不再仅仅通过文本界面与计算机交互。这是有充分理由的！GUI让我们能够以比文本界面更复杂的方式推理概念，同时通常对新用户也更友好。 我们可以对创建软件做同样的事情。集成开发环境（IDE）可以不仅仅是方便编辑代码的地方。它们可以成为与软件开发交互的全新方式。许多IDE已经提供了一些这样的特性。我们应该更进一步。 可视化编程应该变得如此普遍和简单，以至于任何人都可以在不学习任何代码的情况下创建他们想要的东西。我希望生活在那个未来。 我们甚至不必放弃代码！程序的GUI版本可以只是几种人类可编辑表示形式之一。就像有些人喜欢操作系统的文本界面一样，有些人会继续喜欢基于代码的软件编辑界面。只是它不必再是默认——或唯一——选项。 重要的一点是讨论可访问性。虽然这种*可视化编程*（https://en.wikipedia.org/wiki/Visual_programming_language）专门设计得更易访问，但拥抱视觉环境进行软件开发可能会排除有视觉障碍的人。我想强调确保可视化编程始终对看不见它的人同样可访问的重要性。这可以采取强大的屏幕阅读器集成形式，甚至是一种专门设计用于通过听觉或触觉同样丰富地理解的替代表示形式。 #### 代码是廉价的。给我看“谈话”。 我观察到一些人谈论LLM如何将抽象层级再提升一层。他们谈论LLM如何使人类能够用自然语言与计算机交互，并说我们正在接近一个人工编写的代码成为像现在编写汇编语言一样小众活动的时代。 我不认为这是真的。在我看来，LLM并不代表一个抽象层，而是代表一个自动化层。它没有抽象掉代码层，而是自动化了它。 我这样说是因为抽象层应当是可预测且可靠的。较高抽象层的意图应该在较低抽象层得到准确且一致地表示。而LLM并非如此。相反，LLM随机地解释其提示并预测意图。它们表现得不可预测。它们自动化了随机近似任务输出的过程。如果LLM是一个抽象层，那么充其量也只是非常损耗的一个。 尽管如此，*Torvalds的名言*（https://lkml.org/lkml/2000/8/25/132）仍然可以被颠倒。不再思考代码，我们可以思考“谈话”。因为如果“谈话”和“代码”根本就不是不同的呢？ 人类在存在过程中进化出了极其多样的语言。我们各自的语言代表了丰富的历史，并且非常适应人与人之间的表达。虽然它们为人际交流而优化，但并不适合与计算机进行可预测的交流。这就是为什么我们到目前为止一直使用代码。然而，自然语言处理（NLP）的最新进展可能正是我们创建从自然语言到机器代码的可预测管道所需要的。 这种方法可能无法像可视化编程那样清晰地表达同样的逻辑关系，但它可能是一种对非程序员更易访问的方法。想象一下，你能够像在LLM提示中一样输入指令，并创建完整的程序，但这次是可预测且每次都健壮的。这些程序通过定义直接建立在其他人的工作之上，而不是仅仅从没有作者意图的代码中提炼出的平均结果。 这甚至可以让我们进一步合并文档和代码。我们可以进行文学编程，并用自然语言替换代码，直到只剩下文档。我们用来与其他人谈论程序如何工作的文字，也可以是我们用来与机器交流的文字。 这应该是确定性的。NLP可以用来从语法中解析语义，而不需要Transformer模型的生成能力。解析出的语法可以直接翻译成某种中间表示，然后根据平台要求编译，就像任何其他编程语言一样。 类似于Inform（https://en.wikipedia.org/wiki/Inform）但具有更强的句法意识，并连接到更广泛的定义网络。 这种确定性质量意味着提示变得可靠且一致地成为代码。这与任何LLM都根本不同。它是一个真正的抽象层。 ## 我们以前做过 这些想法都不是新的。以前有过尝试实现它们的项目。我所知道的最佳例子是Eve（https://witheve.com/），一种旨在让编程对人类更易访问的编程语言和IDE。 为此，Eve采用了文学编程方法。它们将特定领域的数据导向编程语言嵌入到描述软件如何对其他人类行为的文档中。代码从属于文档，整个编程环境反映了这一点。 它们进一步探索了这个想法，甚至尝试用NLP查询（https://incidentalcomplexity.com/2016/06/14/nlqp/）替换它们的自定义语言。不幸的是，处理自然语言带来了它们没有准备好的复杂性。它们没有资源将其变为现实。2016年，更高级形式的NLP对于不专注于机器学习的公司来说并不容易获得。*它们甚至尝试了面向GUI的方法！*（https://incidentalcomplexity.com/2017/10/04/September/） 一位前Eve贡献者也在其文章中谈论了该项目的一些复杂性（https://mech-lang.org/post/2025-01-09-programming-chatgpt/）。他们的文章也表达了对LLM局限性的一些担忧，与我的观点相同。 不幸的是，该项目之所以结束，很大程度上是因为它是一个*雄心勃勃的风险投资支持项目，未能将其产品货币化*（https://news.ycombinator.com/item?id=45559031），所以我们从未有机会看到它们的想法结出果实。我相信可以通过更好的财务模式来复制并扩展它。 Inform（https://ganelson.github.io/inform-website/）也广泛地做到了这一点，它是一种用于创建交互式小说的声明式语言，但这一概念可以更广泛地应用。 自然语言可能本质上是一个有泄漏的抽象。但我认为值得再试一次。让普通人直接控制自己的计算机所带来的潜力值得更多关注。它比我们目前给予的关注更多。它值得比LLM更好的东西。 ## 整合起来 编程很糟糕。但这并不意味着我们应该自动化它并让LLM为我们编写一切。相反，我们应该抽象掉代码，在其基础上构建健壮且确定性的系统，让我们能够在更高层次上描述软件。 我们应该拥抱可视化、文学和自然语言编程，以便更好地与机器和彼此交流意图。我们应该追随像Eve这样的项目的脚步，创建专注于向其他人类（而非机器）表达复杂思想的编程环境。软件栈每一层的每一种形式的软件，都应该让程序员和非程序员都能访问。 这个世界是可能的。这个世界是必要的。我们只需要去构建它。 ## 下一步 我相信制作可理解软件的重要性。为此，我正在推进相关项目。 主要是我正在开发ReTangled（https://codeberg.org/liberty/retangled），一个Rust编写的、与Entangled兼容的双向缠结器。它旨在尽可能扩展文学编程，同时合理紧密地集成到现有工具链中。截至撰写本文时，它还处于早期开发阶段。欢迎贡献！ 而对于我在这里浅尝辄止的不同想法（可视化、文学和自然语言编程），我将分别写更完整的文章，并透彻地阐述它们未来的潜力。 但更进一步，我想作为一个社区来探索更多的问题空间。具体而言，我希望我们接过Eve的接力棒，也许采取略微不同的方法。我希望我们创建一个高度文档化且可访问的可视化或自然语言编程环境，无论是新手还是专家程序员都能从中受益。这个愿景虽然遥远，但值得追求。 所以，请加入我！让我们从更好地记录我们的软件开始，以颠覆现状结束。