layout: post comments: true title: 汉化了十数个编译器的前辈的心得体会 description: 通过修改编译器, 实现对中文标识符支持的一位前辈的对于中文编程和中文编程语言的心得. View of programming in Chinese from a pioneer who modified a dozen compliers to add support of Chinese identifiers. date: 2017-11-27 12:00:00 -0700
@竹闲 的原文在【图片】回复：有筒子想用中文写汇编吗？_汇编吧_百度贴吧 63楼. 特此转载, 并向所有勇于探索的前辈们致敬!
他汉化的十余个编译器: 竹闲：一般编程语言都是英文的，大家对中文编程有什么样的看法，中文编程有哪些优劣势？
1)论点:应否「建立新的中文编程语言」,慎思之。
2)理由:
2.1)旧编程语言的优点(代价)。
2.2)新编程语言的立足点。
2.3)旧径:绕过上述困难,直接沿用旧编程语言。
仅「令其函数名、过程名、变量名均可用汉字」即可。
3)致敬。
旧的编程语言,仍在使用当中,未受淘汰。
且拥有庞大的用户群体,
多年的历史沉淀、技术支持,
出版的各种入门图书、文档、丰富详尽的函数手册,
繁杂全面的网络帮助与代码用例,
以及若干系列的测试工具(微秒级的各函数耗时百分比时间分析、
符号级\源代码级别调试器、内存检查器、svn代码上传……),
全球多层面、多场合、多语言的产品测试,
完善的售後服务,
不断的根据用户反馈或硬件改革而进行软件升级,
保证20年後该产品\本公司依然存在。
个人的作品与品牌公司在此得到最明显的对比:
个人\小工作室\普通公司 难以提供上述任何一项,无法与之竞争。
而且即令是完成了上述所有项的大公司,例如宝兰(borland)公司,
全球320万用户,21年(1987～2008)的悠久历史,无数的测试工具……
仍落得被易博龙收购的下场。所以新的编程语言,一开始就得做好亏本的打算。
周思博有云,新技术若都用来解决一些「旧技术能解决的问题」,
则新技术必受诟病。老周此话原是揶揄微软,但换在编程语言身上,依然适合。
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,
不断推出新版本,而且这廿年很可能颗粒无收。太过强人所难了。
另起炉灶後,压力之大,无以复加;赢利之微,几乎倒贴。所以大部分人都蝇附骥尾,仅让
「旧编译器在吃进中文程序时,能辨认出中文标识符,从而正常编译连接,不致报错」,
就经已心满意足。
在读秀或万方上搜索,可窥见众前贤的旧迹,谨录部分于下:
王其宏《用汉字标识符的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
该链接在墙外,不知是否失效了),就因为他们的劳动免费而不足挂齿。
于是,总有人厌倦,就出手打造自己的中文编译器了。
例如(以下并非全集,且排名不分先後):O语言的作者,标天软件的BtAsm团队,
易语言的吴涛,Python的周蟒,法国的WinDev……
毋论他们在商业上是胜是败,但始终他们都为中文编程作出了自己的贡献,
默默耕耘,未必收获。全凭有他们,也纔能映照出中文编程之路,何等曲折,何等漫长,
虽是一脉如丝,仍是缕缕不断。
勉之矣,任重而道远。