仓库源文，站点原文

layout: post comments: true title: 戳破针对「木兰」编程语言的拙劣谣言 description: date: 2020-01-23 00:00:00 -0700

categories: 小结

谣言一：「木兰」就是 Python 换了个名字

在各色媒体的含沙射影和误导下，恐怕现在大部分公众都误认为「木兰」编程语言就是完完全全的 Python 语言换个名头而已。一个某问答网站的高赞回答中就有这样的“证言”：

然而，谎言重复千遍也不能成为真理！

这些口诛笔伐和流言中，没有任何一个敢于贴出「木兰」实际的运行截图。为什么？

难道是不会运行 exe 文件？还是因为，只要运行出来就会让大众看到，它和 Python 的明显差别？

万幸的是有一批开发者在第一时间就获得了「木兰」编程语言的可执行文件，包括我自己。

同样功能（连着打印出 5 个数字）的代码，分别在 Python（左）和「木兰」编程环境（右）。

稍加对比可见明显不同，谎言不攻自破！

这还只是我自己尝试了的一小部分功能而已，还有大量的功能和差异限于时间还未探索。

谣言二：没有解决痛点

编程语言技术圈内，已经基本公认了「木兰」绝不是 Python 换名字而已。但还是有所谓大佬，就凭着两者代码视觉上的相似之处，就声称『木兰』编程语言没有解决任何“痛点”，没有任何实质性的改进。

说这话的要么对 Python 或『木兰』完全不了解，要么是睁眼说瞎话。

只要用过 Python 编程的，都应该吃过它非常严格的缩进规则的亏。比如开头的 Python 代码，如果稍不小心，在某些地方把空格多了一个或者少了一个，那就倒大霉了：

 def f(x):
    for i in range(5):
        i = i + x
        print(i)


def f(x):
    for i in range(5):
       i = i + x
        print(i)


def f(x):
    for i in range(5):
        i = i + x
       print(i)

上面的代码全部无法运行！可以试试看，要花多大劲才找得出哪里有问题？

最最坑的是，下面的代码看似对齐了，但仍然无法运行！

就是因为不小心混用了 tab 和空格键。而这种问题对于新手来说，无异于折磨。这也是一个圈内臭名昭著、几乎所有 Python 开发者迟早都会掉进不止一次的大坑。我在学习和使用 Python 时，同样栽过，也抱怨过“怎么这么死板！设计的真二！”

就是这样的一个问题，Python 1991 年问世至今，没有任何人解决过。神奇吧！

但『木兰』就很好地解决了这个问题。即使有开头空格、混合 tab 和空格键都支持：

甚至还支持更自由的写法：

现在说它没有解决“痛点”？到底要多痛的点？切肤之痛、痛彻心扉吗？那样的痛点怎么可能在一个编程语言问世近三十年后还没有解决呢！

这也同样是谣言一的克星。这样的功能差别，还说成是 Python 换个名字，良心不会痛吗？

谣言三：是个本科生就能做

同样在技术圈内，还有人号称，这不过是本科、硕士生毕设水平云云，甚至将它和本科生作业相提并论。

是不是自己把自己忽悠瘸了？还是当所有人都不懂行，会相信「木兰」编程语言当做是像文章抄袭那样简单的文本替换、格式化就能做出来的了？

这个荒唐论调的最致命处在于，为什么之前几乎没有在国内听说过像『木兰』这样的产品？？

不客气地说，在木兰开始研发之前，全中国就算一千万程序员，百分之九十九点九的只把编译器当工具用，其中也包括我自己。就像是开机床的，有几个有兴趣了解机床内部构造的？即使有像上面的缩进规则大坑，也不敢对编译器轻举妄动，而只是捏着鼻子，强行让自己适应继续用。毕竟——“大家都是这么过来的嘛”。

这就只剩下一万人敢于看看编译器的源代码。但看归看，九成的都不会或者没动力把它从源代码编译成可运行的编译器，更不用说修改源代码了。就好比有多少人乐意自己组装一台机床出来的？哪怕给你全套零件和图纸？

在剩下这一千人乐意动动源代码的当中，九成的编译器相关知识背景和实践经历都不足，而即便是像上面演示出的定制语法，也需要顶层设计和将编译器的模块拆分的能力。

就这样，我们只剩下了一百人。那么这其中有多少人有动力、毅力完成它，还要下不亚于做编译器本身的功夫，完成周边配套的辅助工具，最后做成产品，进行推广呢？

「木兰」这样的产品少之又少，正是由于国内编程语言设计、编译器实现、以及相关辅助工具开发领域的极大落后才导致的！

退一万步说，假如现在的计算机本科生教育真的已经到了这个水平，能够轻松完成这样对开源编译器的改造，岂不是国之幸事？岂不是可以在「木兰」的技术基础上，迅速进行进一步的改进和创造，逐步扭转编程语言这一领域长期受制于人的现状了？

要知道，任何工程项目，思路可能是一句话的事情，但实现起来总会有各种各样的问题和难关，正所谓“细节是魔鬼”。是不是至少应该深入研究「木兰」的技术细节，该学习的学习，该推广的推广呢？

过是过，功是功

作为当事人在宣传方面纵然有千错万错，也绝不应该任意诋毁「木兰」编程语言的意义。

无论它前途如何，仅凭至今为止的这次短暂亮相，就已经将国内编程语言研发的整体水平提高了一个层次。

因为它，明确指出了一条经过实践验证、完全可行的定制和改进一个开源编译器的技术路线！对它的逆向分析也已经多方验证了当事人袒露的实现方式（见文末）。

从此之后，上面那些敢于动动编译器源代码但没有明确思路的九百人当中，也都会尝试顺着这个思路对所有编程语言的编译器进行改造；那九千个本来只敢看看源代码的，也会发觉，原来编译器的源代码并不是那么神圣不可触碰，也会有更多的人加入动手修改的行列；更不用说那九千多万原本视编译器为神器不可亵渎的开发者，会有一大批开始对它的实现细节感兴趣，进而投身于编译器研发领域。

从这个意义上说，『木兰』已经创造了历史！

正是因为如此，我们更应该期待『木兰』的更多技术细节，而不是任由它被流言埋没。

在流言大肆其道，事实尚未澄清的现在，正是『木兰』前途命运的关键时刻。

任何一个有良知的人，都应用理性思考，明辨流言蜚语，绝不让『木兰』蒙受不白之冤！

来源于技术论坛的逆向分析

上图源自：https://www.zhihu.com/question/366509495/answer/978966908

源自技术讨论群