1. 程式人生 > >漢化了十數個編譯器的前輩的心得體會

漢化了十數個編譯器的前輩的心得體會

@竹閒 的原文在【圖片】回覆:有筒子想用中文寫彙編嗎?_彙編吧_百度貼吧 63樓. 特此轉載, 並向所有勇於探索的前輩們致敬!

他漢化的十餘個編譯器: 竹閒:一般程式語言都是英文的,大家對中文程式設計有什麼樣的看法,中文程式設計有哪些優劣勢?

1)論點:應否「建立新的中文程式語言」,慎思之。

2)理由:

2.1)舊程式語言的優點(代價)。

2.2)新程式語言的立足點。

2.3)舊徑:繞過上述困難,直接沿用舊程式語言。

僅「令其函式名、過程名、變數名均可用漢字」即可。

3)致敬。

2.1)

舊的程式語言,仍在使用當中,未受淘汰。

且擁有龐大的使用者群體,

多年的歷史沉澱、技術支援,

出版的各種入門圖書、文件、豐富詳盡的函式手冊,

繁雜全面的網路幫助與程式碼用例,

以及若干系列的測試工具(微秒級的各函式耗時百分比時間分析、

符號級\原始碼級別偵錯程式、記憶體檢查器、svn程式碼上傳……),

全球多層面、多場合、多語言的產品測試,

完善的售後服務,

不斷的根據使用者反饋或硬體改革而進行軟體升級,

保證20年後該產品\本公司依然存在。

個人的作品與品牌公司在此得到最明顯的對比:

個人\小工作室\普通公司 難以提供上述任何一項,無法與之競爭。

而且即令是完成了上述所有項的大公司,例如寶蘭(borland)公司,

全球320萬用戶,21年(1987~2008)的悠久歷史,無數的測試工具……

仍落得被易博龍收購的下場。所以新的程式語言,一開始就得做好虧本的打算。

2.2)

周思博有云,新技術若都用來解決一些「舊技術能解決的問題」,

則新技術必受詬病。老周此話原是揶揄微軟,但換在程式語言身上,依然適合。

D語言與c–對於c來說,則患此弊。

甚至連ruby等新語言,亦因此被王垠將之與lisp相提並論,被批得爛額焦頭。

所以一旦摒棄舊程式語言,則使用者會循(2.1)為準 來要求新中文程式語言,

間中還夾雜著不少對中文的偏見(中國程式設計員對中文市場的敵視,天下知名。

無論規格書、說明書、函式手冊……能不寫漢字就決不用中文。

漢人學得胡兒語,卻向城頭罵漢人。今古皆然,不足為怪)。因而新語言的崛起,

縱不是一枝獨秀、出類拔萃,也得解決一些「舊技術不能解決的問題」。

即使是記憶體自動回收、網路函式、反射、函數語言程式設計……等等,都是題中

應有之義,而非亮點了。

此事並非苛求,因為既是一門全新的程式語言,眾人當然認為作者是一位

開宗立派的大師,按《春秋》責備賢者的傳統,臧否這位宗匠級別的作品而已。

當然,作者可以把新程式語言拋到網站上,然後撒手遠颺。

通常眾人亦會權當作者交了一趟作業、完成了一趟導師的論文答辯。

例如 Fabrice Bellard 的tiny cc,欠缺維護,現已少人問津了

(順便說一句,把他的 libtcc.c\LIBTCCAPI TCCState *tcc_new(void)內

inline的preprocess_new()改一下,即可支援中文的識別符號。

即令不改原始碼、不重新編譯,只把他的 libtcc.dll 相應改四十個位元組,

也有同樣效果)。

但退一步而言,如(2.1)所說,要作者熬廿年的苦日子,自費出版各種手冊,

牆內牆外都租用伺服器,為各國各族人民提供多語言技術支援,隨時改bug,

不斷推出新版本,而且這廿年很可能顆粒無收。太過強人所難了。

2.3)綜上所述:

另起爐灶後,壓力之大,無以復加;贏利之微,幾乎倒貼。所以大部分人都蠅附驥尾,僅讓

「舊編譯器在吃進中文程式時,能辨認出中文識別符號,從而正常編譯連線,不致報錯」,

就經已心滿意足。

在讀秀或萬方上搜索,可窺見眾前賢的舊跡,謹錄部分於下:

王其巨集《用漢字識別符號的PASCAL編譯程式》,載諸《長春郵電學院學報》1987年02期,

李京 《PASCAL編譯程式的改造》,載諸《計算機工程與應用》1987年09期,

苗慶斌《PASCAL語言漢化的設計與實現》,載諸《計算機工程與設計》1990年03期,

章繼三《中文組合語言程式設計》,載諸《軟體世界》1994年06期,

黃志勇《Foxpro2.5的漢化方法》,載諸《電腦》1995年12期,

闕建軍《在FOXBASE下使用漢字變數名及欄位名》,載諸《中國金融電腦》1996年05期

……

甚至連新人亦沿此舊徑,例如aogo的masmplus,鼎龍的中文C++,竹閒的漢化各編譯器。

藉舊程式語言之勢,讓其函式名、過程名、變數名均可使用漢字(在此強調:均可≠均須!)。

如此則舊的程式文件、程式設計員、程式碼用例……均紋風不動。

此舉雖有狐假虎威之嫌、鵲巢鳩佔之喻,但終究算是把(2.1)的壓力盡數卸開。

然後他山之石,攻我之玉。自此,中文程式設計即可。終於可以不寫

“render_hexagon(last_descending_point)”,改為“_填6邊形(_最近降點)”了。

而且連線lib\跑lua虛擬機器\正常執行python\……效果一切如常,簡直有百利而無一害。

有一害:編譯器每出一趟新版本,上述工作者就須配合一版漢化包,跟遊戲漢化者發行

漢化包毫無區別。我這番話對遊戲漢化者並無半分嘲諷之意:編譯器是程式,遊戲也是程式;

編譯器的使用者(程式設計員)是人,遊戲的使用者(玩家)也是人;而且後者的市場還大些。

而兩廂的漢化者都在免費工作,都追趕在版本號後面而疲於奔命。

「疲於奔命」是巫臣的原話,但漢化者的奔命何止七次,就因為他們的辛勤工作

故意被原編譯器作者所忽視(檯面規則是編譯器得支援unicode,潛規則卻是歐美國家毋需

理睬中文市場,例如以前 go語言組對匯出中文函式名的爭論,

https://groups.google.com/forum/#!msg/golang-china/h_vxbPHaIvw/wFRw1Myrm3AJ

該連結在牆外,不知是否失效了),就因為他們的勞動免費而不足掛齒。

於是,總有人厭倦,就出手打造自己的中文編譯器了。

3)在此,向所有披荊斬棘的中文程式設計員致敬:

例如(以下並非全集,且排名不分先後):O語言的作者,標天軟體的BtAsm團隊,

易語言的吳濤,Python的周蟒,法國的WinDev……

毋論他們在商業上是勝是敗,但始終他們都為中文程式設計作出了自己的貢獻,

默默耕耘,未必收穫。全憑有他們,也才能映照出中文程式設計之路,何等曲折,何等漫長,

雖是一脈如絲,仍是縷縷不斷。

勉之矣,任重而道遠。