-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
汉化了十数个编译器的前辈的心得体会 #13
Comments
@buyouyuan 请在这里继续讨论. #2 主要进行迎接新人,自我介绍和社区运行规范方面的讨论. |
没记错的话nasm是十几年前成型的项目. 之前看到过一个源码阅读笔记, 猜想preproc的部分修改后可以支持中文指令.
汇编和C都是编程语言演变的一个阶段, 而且有先后关系, 说父/母感觉有点牵强.
如果你对创建新的中文编程语言有兴趣, 请在#11 讨论.
正如英文编程语言还在继续演进, 新的编程语言还在发明, "完美"的中文编程语言也不可能一蹴而就. 前辈们暂时没有惊世之作不意味着不在坚持, 创建这个讨论组的目的之一是要充分利用前辈们的经验教训, 为更广范围和广义的中文编程实践汇聚人气, 交流以促进步. |
现在多数语言本身已经支持unicode的标识符, 可以认为用中文编程的第一个障碍基本消除了. 不过为继往开来, 还需要不懈努力. 接下去的方向至少有:
|
原址在此, 63楼
他汉化了的编译器列表: https://www.zhihu.com/question/20184664/answer/21045030
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……
毋论他们在商业上是胜是败,但始终他们都为中文编程作出了自己的贡献,
默默耕耘,未必收获。全凭有他们,也纔能映照出中文编程之路,何等曲折,何等漫长,
虽是一脉如丝,仍是缕缕不断。
勉之矣,任重而道远。
The text was updated successfully, but these errors were encountered: