再论中文编程

说实话，关于中文编程的讨论，这几年一直没断过。核心出发点其实很简单：用母语写代码，这事儿应该成为潮流——不仅仅是中国人的愿望，外国人搞不好也希望能用英语来编程呢。现有的编程语言，绝大多数都是“像英语但不是英语”的存在，这种接近但并不完全等同于自然语言的状态，本身就说明了一个深层次的需求。

早些年，出于对这种类似英文编程语言的无奈，也带着一股民族热情，国内涌现了易语言、习语言这样的中文编程方案。坦白说，它们的发展都不太理想。问题出在哪里？一方面，理论根基不够扎实，在编译原理上没有真正意义上的突破，结果被戴上了“中文版VB”或“汉化版C语言”的帽子。另一方面，实践层面也跟不上，提供的库函数不够强大，生态没建起来，自然就败给了那些非国产的成熟语言。尤其让人惋惜的是，易语言后来还和杀毒软件杠上了，这对一个成长中的语言来说，几乎是致命的打击。

实际上，用母语编程，往大了说就是接近自然语言编程。国外也在搞这个方向，只不过他们走的路线更偏人工智能。如果这条路走通了，我们首先能享受到的可能是“接近英语的编程语言”。但中文编程什么时候能真正落地？恐怕还得等相当长一段时间。

关键在于编译原理本身需要突破。举个例子，文法的产生式数量不能太大，这是现有编译原理一个很现实的局限。要是我们想给每一个句子都分配一个产生式，语言确实能接近自然语言了，但LR分析法的状态数会急剧膨胀。为什么？因为状态数大致是M×N的复杂度——M是句子长度，N是句子数量。句子一长、一多，计算量就直接爆炸了。

那有没有解法？有的。一种思路是换用解释型分析法，就像现在很多编译/解释型计算机语言做的那样。传统编译原理是编译型的，新的思路则可以转向解释型——解释器直接看着文法的产生式和句子来解释，以此完成分析任务。

另一种解法是引入“公共命名空间”，这东西主要是为了防止命名空间混乱。它本质上是一张二维表：每一行代表一个句子，每一列代表一种方言，每个单元格里存放的是“同位素”，此外还有冗余项。稍微整理一下，公共命名空间的公式可以写成：公共命名空间 = (句子, 方言, 同位素, 冗余项)。

要我说，这条路虽然不好走，但方向是对的。编译理论的突破，加上真正实用的工具链支撑，才是中文编程破局的关键。这不仅仅是情怀问题，更是一个技术命题。