謠言一：「木蘭」就是 Python 換了個名字
在各色媒體的含沙射影和誤導下，恐怕現在大部分公衆都誤認爲「木蘭」編程語言就是完完全全的 Python 語言換個名頭而已。一個某問答網站的高贊回答中就有這樣的“證言”：
這還只是我自己嘗試了的一小部分功能而已，還有大量的功能和差異限于時間還未探索。
謠言二：沒有解決痛點
編程語言技術圈內，已經基本公認了「木蘭」絕不是 Python 換名字而已。但還是有所謂大佬，就憑著兩者代碼視覺上的相似之處，就聲稱『木蘭』編程語言沒有解決任何“痛點”，沒有任何實質性的改進。
說這話的要麽對 Python 或『木蘭』完全不了解，要麽是睜眼說瞎話。
只要用過 Python 編程的，都應該吃過它非常嚴格的縮進規則的虧。比如開頭的 Python 代碼，如果稍不小心，在某些地方把空格多了一個或者少了一個，那就倒大黴了：
就是因爲不小心混用了 tab 和空格鍵。而這種問題對于新手來說，無異于折磨。這也是一個圈內臭名昭著、幾乎所有 Python 開發者遲早都會掉進不止一次的大坑。我在學習和使用 Python 時，同樣栽過，也抱怨過“怎麽這麽死板！設計的真二！”
就是這樣的一個問題，Python 1991 年問世至今，沒有任何人解決過。神奇吧！
但『木蘭』就很好地解決了這個問題。即使有開頭空格、混合 tab 和空格鍵都支持：
現在說它沒有解決“痛點”？到底要多痛的點？切膚之痛、痛徹心扉嗎？那樣的痛點怎麽可能在一個編程語言問世近三十年後還沒有解決呢！
這也同樣是謠言一的克星。這樣的功能差別，還說成是 Python 換個名字，良心不會痛嗎？
謠言三：是個本科生就能做
同樣在技術圈內，還有人號稱，這不過是本科、碩士生畢設水平雲雲，甚至將它和本科生作業相提並論。
是不是自己把自己忽悠瘸了？還是當所有人都不懂行，會相信「木蘭」編程語言當做是像文章抄襲那樣簡單的文本替換、格式化就能做出來的了？
這個荒唐論調的最致命處在于，爲什麽之前幾乎沒有在國內聽說過像『木蘭』這樣的産品？？
不客氣地說，在木蘭開始研發之前，全中國就算一千萬程序員，百分之九十九點九的只把編譯器當工具用，其中也包括我自己。就像是開機床的，有幾個有興趣了解機床內部構造的？即使有像上面的縮進規則大坑，也不敢對編譯器輕舉妄動，而只是捏著鼻子，強行讓自己適應繼續用。畢竟——“大家都是這麽過來的嘛”。
這就只剩下一萬人敢于看看編譯器的源代碼。但看歸看，九成的都不會或者沒動力把它從源代碼編譯成可運行的編譯器，更不用說修改源代碼了。就好比有多少人樂意自己組裝一台機床出來的？哪怕給你全套零件和圖紙？
在剩下這一千人樂意動動源代碼的當中，九成的編譯器相關知識背景和實踐經曆都不足，而即便是像上面演示出的定制語法，也需要頂層設計和將編譯器的模塊拆分的能力。
就這樣，我們只剩下了一百人。那麽這其中有多少人有動力、毅力完成它，還要下不亞于做編譯器本身的功夫，完成周邊配套的輔助工具，最後做成産品，進行推廣呢？
「木蘭」這樣的産品少之又少，正是由于國內編程語言設計、編譯器實現、以及相關輔助工具開發領域的極大落後才導致的！
退一萬步說，假如現在的計算機本科生教育真的已經到了這個水平，能夠輕松完成這樣對開源編譯器的改造，豈不是國之幸事？豈不是可以在「木蘭」的技術基礎上，迅速進行進一步的改進和創造，逐步扭轉編程語言這一領域長期受制于人的現狀了？
要知道，任何工程項目，思路可能是一句話的事情，但實現起來總會有各種各樣的問題和難關，正所謂“細節是魔鬼”。是不是至少應該深入研究「木蘭」的技術細節，該學習的學習，該推廣的推廣呢？
過是過，功是功
作爲當事人在宣傳方面縱然有千錯萬錯，也絕不應該任意诋毀「木蘭」編程語言的意義。
無論它前途如何，僅憑至今爲止的這次短暫亮相，就已經將國內編程語言研發的整體水平提高了一個層次。
因爲它，明確指出了一條經過實踐驗證、完全可行的定制和改進一個開源編譯器的技術路線！對它的逆向分析也已經多方驗證了當事人袒露的實現方式（見文末）。
從此之後，上面那些敢于動動編譯器源代碼但沒有明確思路的九百人當中，也都會嘗試順著這個思路對所有編程語言的編譯器進行改造；那九千個本來只敢看看源代碼的，也會發覺，原來編譯器的源代碼並不是那麽神聖不可觸碰，也會有更多的人加入動手修改的行列；更不用說那九千多萬原本視編譯器爲神器不可亵渎的開發者，會有一大批開始對它的實現細節感興趣，進而投身于編譯器研發領域。
從這個意義上說，『木蘭』已經創造了曆史！
正是因爲如此，我們更應該期待『木蘭』的更多技術細節，而不是任由它被流言埋沒。
在流言大肆其道，事實尚未澄清的現在，正是『木蘭』前途命運的關鍵時刻。
任何一個有良知的人，都應用理性思考，明辨流言蜚語，絕不讓『木蘭』蒙受不白之冤！
來源于技術論壇的逆向分析
源自技術討論群