Mojo 自推出以来就吸引了大量关注，社区围绕它展开开发，这股热情让人振奋。随着 Copilot、Ghostwriter 等大型语言模型（LLM）驱动的开发工具不断涌现，很多开发者开始思考编程的未来：如果 AI 能写代码，编程语言本身还重要吗？这个问题问得好，它直击开发流程的核心，也促使我们重新审视编程工具的根本目的，顺便聊聊我们对这项技术长期走向的看法。要回答它，不妨先看看编程语言的三个关键维度。

“人机”规范

学习编码时，一个早期兴趣是理解整个技术栈如何运转。不少学生时代的经历都涵盖编程语言的设计与实现。那时形成的第一个观点是：编程语言是人类向计算机表达意图的抽象工具——源代码就是给编译器或解释器的“配方”，让计算机理解该做什么。

“程序员的心理活动主要是把抽象层次从低级向高级转移。从小处看问题，从大处看问题。”——Donald Knuth

从这个角度看，编程语言应该专注于以易懂的方式展现机器的功能。它需要明确的解释，能精确描述算法或设计，简洁时可以帮熟练开发者快速完成大量工作。这也是为什么像 C++ 这类面向专家的大语言会积累那么多语法糖和核心特性——为了让重要的事情能高效表达。这个观点没问题，但积累更多经验后会意识到，这只是编程语言的一部分。

“人与人”规范

很快会发现，大多数有趣的项目是由团队完成的，规模越来越大，很难把所有代码都装进脑子里。这时软件开发会出现新动态：设计讨论、代码审查、第三方库集成。那些最有成就感、配合最好的项目，总是和一群才华横溢、投入的人一起完成。这种情况下，编程语言的目的逐渐演变成一种抽象——让一个人向另一个人传递关于程序行为的意图。它仍然需要明确规范，但目标变了：语言应该设计给人阅读，而不仅仅是给人编写。计算机相当宽容（尤其有了 LLM 之后），所以我们很多人都受益于清晰的设计模式和易读的代码。大多数代码只被编写一次，却被阅读和迭代无数次。

“程序是供人类阅读的，只是偶尔供计算机执行。”——Harold Abelson 与 Gerald Jay Sussman

结果就是，过于巧妙的语法糖反而违背了语言的核心目标。特化的语法和不常用的功能会让没写过那段代码的人难以理解。LLM 和其他工具虽然能帮忙解码或解释复杂代码，但保留单一、可读的真相来源依然是理想状态。

“计算机到人类”规范

按这种视角看，基于 LLM 的代码生成工具就像一个新团队成员，在项目中贡献、阅读和操作代码。市面上有不少例子，各有特性：比如根据提示生成代码的人工智能、审查代码并提供改进建议的专家、自动生成单元测试的工具，以及不断涌现的新功能。这些工具的共性是由计算机生成并集成到产品中的源代码。虽然能力惊人，但至少在不久的将来，这些代码生成工具还不会取代编程语言现有的功能。事实上，当前对语言模型的主要担忧之一是信任——某些场景下它们输出惊人，另一些场景下却存在微妙的错误，甚至不确定。因此，设计一种可供阅读（而不仅仅供编写）的语言变得更加重要，这样人类才能审查和批准生成的代码。

试想：如果你让 LLM 帮你构建一个处理在线购买的移动应用，你会不审查源代码就发布吗？更极端的例子：你愿意用 LLM 写的代码把人类送上月球吗？这引出了开发者的终极问题——我们愿意接受怎样的错误和成本？LLM 当前的不可靠性意味着，作为代码所有者，我们需要知道提示是否生成了正确行为——生成的代码到底做了什么？这也是为何直接生成低级机器码的 LLM 对一般用例没什么吸引力——很少有人愿意阅读、审查和验证机器码。

展望未来，我们希望 LLM 能增强开发体验，并随时间变得更可靠、更值得信赖。但即便成真，LLM 仍然无法取代对编程语言的需求。它很可能成为高效开发者（“懒人”）的关键扩展——比起从在线资料里复制粘贴，这已经是质的飞跃。此外，虽然 LLM 很可能自动消除编程中的模板和重复部分，但总有一些用例需要人类介入。没人能预测遥远的未来，但可以确定的是，在许多应用中人类将参与相当长一段时间——尤其在错误率要求极低、出错成本极高的场景里。

LLM 最适合输出的编程语言是什么？

深陷软件开发的人会发现身边围绕着各种语言，它们针对不同领域而生：用于 AI 和数据科学的 Python、用于底层编程的 C 和 C++、用于 Web 的 Ja vaScript 或 TypeScript、用于构建移动应用的 Swift 和 Kotlin、用于翻跟斗编程的 CUDA。这些都是有价值的语言，但既然 LLM 降低了我们对语法可写性的焦虑，那么编程语言的哪些品质在这个新时代变得重要？我们认为，在走向 AI 辅助世界的过程中，有三个基本方面能让语言特别有用：一是它在多个领域的可用性和可扩展性，二是现有的训练数据量，三是丰富而充满活力的生态系统。依次来看：

语言的第一个关键部分是实现的可用性和可扩展性。最适合 LLM 的语言是高度可用且易于人类阅读的，但其实现又能扩展到许多不同场景和应用程序。遗憾的是，许多语言实现包含排除某些应用的设计决策。比如，标记/清除垃圾回收不适用于底层系统软件和翻跟斗编程；Python 和其他解释型语言在需要性能、并行性和线程时并不理想；而基于 JVM 或 .NET 的语言不适用于需要小型、低依赖二进制文件的场景。

为了训练能跨多种用例生成高质量程序的 LLM，我们需要一个庞大的训练数据语料库。相比小众或新奇语言（没有现成代码可训练），LLM 在拥有大量开放示例的流行成熟语言（如 Python）上效果要好得多。

最后，LLM 需要一个丰富而充满活力的生态系统。即便是现有的基于 LLM 的解决方案，丰富的社区也已开发出提示库、工具和专业知识，形成了下一代生态。从这个角度看，语言应该设计成能解锁庞大的开发者社区——无论我们在这个新世界中如何定义“开发者”，从传统编程到指令提示，都是如此。

当我们审视大量现有编程语言时，会看到该领域的许多坐标点，但每种都提供了针对不同细分市场优化的权衡。如何推动最先进的技术向前发展？在我们看来，Mojo 是成为 LLM 理想语言的有力竞争者，因为它满足了上述三个基本方面。

我们对 Mojo 的方法

过去二十多年里，我们从构建其他编译器和编程语言系统（比如 Clang/C++、Swift 等）中学到了很多。这些经验让我们构建 Mojo 时明确了几个目标：

成为完全兼容的 Python 超集，继承其易于阅读和理解的语法，让庞大的 Python 开发者社区已经知道如何编写 Mojo！支持系统编程功能和硬件翻跟斗，随着我们进入新的并行计算世界，这些功能和硬件翻跟斗能将 Python 的性能和范围扩展到新领域。与现有 Python 生态系统完全集成，扩展并受益于所有现有软件包。我们还将构建无缝的 C 和 C++ 互操作性，以提升（并受益于）这些社区的工作。最后，提供新的高性能异构编译器和运行时实现，受益于最先进的技术。

因此，我们认为 Mojo 是 LLM 生成和输出高度可扩展代码的最佳选择——因为它结合了 Python 的可读性和可用性，又通过强大的底层系统功能扩展了它，使其能部署到更多硬件上，推动下一组世界级应用和用例。LLM 将继续释放多种语言的创造力和生产力，而 Mojo 也做好了充分准备，将协作软件开发提升到新水平，并把编程带入新领域。Mojo 还很早期——我们发布了 0.1 版本——但长期目标明确，值得关注。

《夸克》非常好用的免费AI浏览器

下载APP查看