寻找唯一语言的探索：为何编程的 “Holy Grail” 并不存在
Source: Dev.to
请提供您希望翻译的完整文本（除代码块和 URL 之外的内容），我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。谢谢！
Introduction
在过去的十年里，我一直在 IT 行业的变幻潮流中航行。我的旅程并未从云原生的象牙塔开始；它始于 Desktop Support 的前线。那时，我的主要武器是 Visual Basic 和 VBA，我用它们来自动化那些占据我一天时间的重复手工任务。
我的技术演进
| 阶段 | 角色 | 主要语言 | 关键洞见 |
|---|---|---|---|
| 桌面支持 | 终端用户自动化 | Visual Basic, VBA | 自动化繁琐任务 |
| Wintel 管理 | 服务器管理 | PowerShell | 将一整批服务器视为单一可脚本化对象 |
| DevOps / 云计算 | 编排云基础设施 | Python | 用于庞大云基础设施的“胶水”语言 |
| ServiceNow 目录 | 自助云功能 | JavaScript | 现代企业对响应式前端的需求 |
| API 开发 | 高性能服务 | Go (Golang) | 构建云的“连接组织” |
| 早期教育 | 基础 | Java, C++ | 早期接触编译语言 |
在这段旅程中——从大学时期使用 Java 和 C++ 到我目前在 Go 的工作——我一直在寻找 可以在任何地方使用的唯一真语言。
现代架构师的巴别塔
对于现代系统架构师而言，今天的技术格局常常感觉像一个 数字巴别塔。构建单一产品需要不断进行上下文切换：
- Python 用于数据工作负载
- JavaScript 用于前端
- C++ / Rust 用于性能关键系统
这种切换会产生 认知负担，并悄然侵蚀生产力。
为什么业界从未统一使用一种通用编程语言？
寻求通用语言
4.1. 理论可能性
- Church–Turing 假设：任何图灵完备的语言都能计算其他任何图灵完备语言能够计算的所有内容。
- 数学上的通用性 已经存在。
4.2. 硬件作为最低层“语言”
- 所有计算都可以由逻辑门构建。
- 单个 NAND 门就足以表达所有布尔逻辑。
- 实践中： 在门级别编程极其缓慢且容易出错——对人类毫无用处。
4.3. UNCOL 实验
-
问题（1950年代）： 有 M 种编程语言和 N 种处理器架构时，需要 M × N 个编译器。
-
解决方案： UNCOL（通用计算机面向语言）——先把每种语言编译成 UNCOL，再把 UNCOL 编译到各个机器上。
-
结果： 尽管有机构支持，UNCOL 仍然失败，因为它需要：
- 数百个全新的数学符号
- 正式的机器无关语义
- 在该领域尚未成熟时进行编译器自举
-
遗产： UNCOL 的失败启发了后来的成功：
- 中间表示（IR）
- 可移植的虚拟机（如 JVM、.NET CLR）
- Niklaus Wirth 对通用编译策略的研究
API vs. ABI：真实的障碍
一个常见的误解是 软件独立于其运行环境。实际上，编译后的二进制文件是 操作系统的囚徒。
| 概念 | 描述 |
|---|---|
| API（应用程序编程接口） | 面向人类的合同，用于源代码 |
| ABI（应用二进制接口） | 机器层面的合同，使二进制文件能够与内核和 CPU 通信 |
- 内核依赖性： Windows、Linux、macOS 各自以不同方式实现系统调用。
- 结果： 相同的源代码会生成本质上不同的二进制文件。
- 标准化尝试 往往趋向于最低公共分母，牺牲平台特有的能力。
工具箱悖论
即使我们解决了内核/ABI 问题，仍然会面临 工具箱悖论：
- 编程语言 ≠ 仅仅是语法。
- 它们是针对特定思维模型（即 范式）的 优化。
- 范式是一种思考方式，帮助开发者推理某类特定问题。
6.1. 范式示例
| 范式 | 优化目标 |
|---|---|
| Excel | 数据表示与响应式逻辑 |
| C | 直接硬件控制与确定性性能 |
| Mathematica | 符号与数学推理 |
| PowerShell | 基于对象的管理管道 |
- 当开发者被迫逆势而为时，会产生 摩擦。
- 示例：在 C 中构建复杂的数据可视化系统是可能的，但缺乏高级 UI 抽象会把原本几天的项目拖成多年的工作。
Cognitive Load & System Reliability
- Cognitive load: 切换范式迫使大脑同时保持多个心理模型。
- System reliability: 将一种语言强行用于其未设计的角色会产生不匹配，导致 performance 降低，错误增多，交付变慢。
结论
单一通用编程语言的梦想在数学上可行但在实践中不可能，原因如下：
- 硬件多样性（不同的 ABI）
- 人类认知（不同的范式和思维模型）
- 历史尝试（例如 UNCOL）揭示了通用编译的复杂性
编码的未来不在于发明新语言，而在于降低语法摩擦——创建工具、运行时和抽象，使我们能够关注意图而非语法。
语法的终结，而非新语言的诞生，将定义软件开发的下一个时代。
通用性、WebAssembly 与 “唯一真语言” 的终结
通用语言的梦想
最有前景的现代通用性尝试是 WebAssembly (Wasm) 及其 Component Model。该架构将软件模块视为与语言无关的 LEGO 积木。
在历史上，语言之间无法交互，除非使用脆弱的胶水代码。Wasm 通过 WebAssembly Interface Types (WIT) 改变了这一点，它允许组件交换高级数据——如字符串和结构化记录——而不受原始语言的限制。
“在很多方面，这实现了最初的 UNCOL 梦想。”
多语言平台的实践
- Spin 3.0 – Rust 开发者可以构建高性能模块，并无缝部署到 JavaScript 应用中。
- 其他新兴运行时也在采用相同的组件优先方法，使跨语言集成成为常规而非例外。
成长的痛点
当前的 Wasm 运行时（例如 Wasmtime）仍然表现出可衡量的性能差距：
- 在某些基准测试中，文件 I/O 的速度可能比本地执行慢十倍。
- 这种慢速 并不是语言本身的失败，而是架构导致的后果：
- 安全沙箱引入系统调用开销和频繁的上下文切换。
- 像 Tokio 这样的异步运行时进一步放大了这一成本。
- 对本地多线程支持的限制仍然是高性能服务器端工作负载的阻碍。
削弱技术通用性的人为因素
- 商业竞争 – Sun Microsystems 与 Microsoft 围绕 Java 的法律争斗著名地破坏了 “一次编写，随处运行” 的承诺。
- Blub 悖论（Paul Graham） – 程序员往往用已知语言的视角来评估更强大的语言，把表达能力误认为是不必要的复杂性。
- 碎片化风险 – 正如 Matt Butcher 警告的那样，生态系统在开始统一时，可能会因不兼容的扩展而被拆散。
从翻译者到 AI 驱动的架构师
“我整个职业生涯都在充当翻译者。我把业务意图翻译成 PowerShell，把用户工作流翻译成 JavaScript，把基础设施翻译成 Go。”
现在翻译者 不再是人类架构师——而是 AI。
- 这一转变常被称为 Software 3.0，与 Andrej Karpathy 关联的术语。
- 在这种范式下，自然语言成为主要接口。架构师用英文描述意图，大型语言模型根据上下文生成相应的方言——Python、SQL、Rust 或其他语言。
新的价值主张
| 过去 | 现在 |
|---|---|
| 人类必须像机器一样思考 | 人类描述意图，机器处理复杂性 |
- 架构师 并未过时；他们被提升了。
- 他们的价值从记忆语法转向掌握 系统设计、约束和意图。
- 我们正从 砌砖工转变为指挥家，通过单一的自然语言接口编排专用工具。
更大的图景
我在 IT 行业的十年经验告诉我，巴别塔并不是缺陷——它是现实。复杂的问题需要多样的工具。
改变的不是 语言的多样性，而是 强大桥梁 的出现：
- WebAssembly Component Model – 连接运行时。
- AI – 连接人类思维与机器执行。
整个行业正迈向 即插即用的未来。
对唯一真语言的追寻已经结束——不是因为我们找到了它，而是因为我们已经不再需要它。
桥梁才是圣杯。