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

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

2020-01-23_fake1

然而,谎言重复千遍也不能成为真理!

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

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

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

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

稍加对比可见明显不同,谎言不攻自破!

2020-01-23_compare

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

谣言二:没有解决痛点

编程语言技术圈内,已经基本公认了「木兰」绝不是 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)

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

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

2020-01-23_python_tab_error

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

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

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

2020-01-23_ulang_space_tab

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

2020-01-23_ulang_oneline

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

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

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

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

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

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

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

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

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

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

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

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

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

过是过,功是功

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

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

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

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

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

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

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

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


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

2020-01-23_proof1 上图源自:https://www.zhihu.com/question/366509495/answer/978966908

2020-01-23_proof2 源自技术讨论群