在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
书接上文,至 2018 年 6 月 5 日,RFC#2457刚创建三天,已看到了不少反对声。在非英语母语的参与者中,华人开发者群体尤为突出。形成对比的是其他非英语社区的积极反馈。包括韩语命名的经验之谈,葡萄牙语、德语命名的实例代码(Java,PHP,C++等)。 之前说到 eggrobin 受 Rust 开发组的 @Manishearth 邀请,来谈他使用非英文标识符的经验。开篇自称未写过 Rust,是 Principia 的合作者。【之后至少十余日他一直参与讨论,觉得值得多了解一点,下面的方括号内容都为本人旁白】 地道法国人,2002 年开始学 VB6, 2003 年开始学 VB .NET,2004 开始 Ada95。看着头像很年轻,果然!他 2004 年进入collège,时年 11 岁,开始学英语,到 2006 年可交流。 期间读法语编程书籍(Amazon.fr - Programmer en Ada 95 - 2e édition - John Barnes, Hughes Fauconnier - Livres,不知是否也用了法语命名),同时用他能写能读的语言命名标识符——法语(字母有音调)。2006 年开始,他转为用英文标识符,因为英文关键字+标准库 API 和法语标识符混搭看着乱。接下来十年间,编程,大学读纯数学,成为软件工程师。 下面他开始回应楼上。提到虽然 Ada95 IDE 存在非 ASCII 码的 bug(把非 ASCII 字符后的 ASCII 字符自动大写,形成像TrèS_ÉLéGant),但他那时捏着鼻子忍了【真能忍】。 在同一标识符中混合英文+非英文也有,因为计算机术语在非英文社区往往仍是用英文进行交流,而业务领域相关的概念就像之前 @kimhyunkang 提到的,适合用母语命名。【关于技术 NFKC 和 NFC 的一段略去】 接下来提到一个很喜欢用 unicode 命名的编程领域:数学。【因为是本行,应该挺有发言权】因为如果用英文缩写,经常会有不一致的情况:
更指出在语音学者中也有类似需求:UTF-8 support for identifier names in GCC【GCC,你也是个拖后腿的,不过GCC 10 搞定了】 接下来引用了huangjj27提到的中文输入法切换导致写码效率问题,但是,看他的回应似乎并未领会切换这个问题,而是理解成了非 ASCII 码标识符的阅读难度问题,回应与之前一位类似(用英化的日文命名仍然只有日本人看得懂)。【这倒是个不同文化间英文交流有误解的实例】 【台下各位,已经写了一个钟头了,今天且看看能不能看到华人声影吧】 哦哦,说什么来着。还是来自北京的 3442853561 ,指出导出 crates 会有问题。以及,(自称无偏见的信息)在中文和日语为母语的地区,这个(非 ASCII 标识符)功能极少使用。【还替日本社区发声了居然,大期待后面有日本开发者现身】 whitequark 提到,OCaml 也在考虑从 ISO-8859-1 转到 UTF-8。 mark-i-m 又来了,表示不乐意看到代码中出现 有趣的是,他在三号打的第一枪,下面有 50 ????9踩;而今天的这楼,三赞三踩五困惑。看来喷的实在是捧不起来。 果然立马被数学小子eggrobin怼了,顺带更多NFKC相关内容【也许之后要多了解一下】 clarfon 同意数学公式用非 ASCII 的数学字符能更可读。但建议除非目标用户是非英语社区,否则库的 API 用英文。【听起来有点多余,本身是否使用非 ASCII 码标识符就应该是作者自愿。刻意强调 API 部分的确反映了API 的特殊性】 由于 PR 的 review 和评论排列顺序,跳播一个 7 日的来自 JelteF 的PR review。荷兰人,指出小时候英语不流利时用母语命名标识符更加容易,不用同时学编程和英语。他自己就是实例。紧接着 PR 的创建者 pyfisch 也应声附和表示有类似经历。 下面 10 号来自坐标日本东京的 CAFxX (意大利人)对这两种老生常谈的谬论简直一针见血:
回到 5 日时间线,mark-i-m 附和clarfon的建议 API 用英文。【别告诉我这被最后从技术上限制了!】 又见来自韩国的kimhyunkang, 回应之前有关键盘输入的质疑,听起来就是说韩国和朝鲜的键盘都是标准键盘,可以用韩文输入法。【情况和国内类似】 终于,坐标中国的 liigo 对之前提出 GBK 的那位回应,既然 rustc 只支持 UTF-8 编码,GBK 什么的应该不是问题。【难得的来自华人的中性声音】 5 日接下来的讨论都围绕 NFKC 和 NFC,略过。 【又是一小时,休息片刻继续,好不容易看完了一天的】 6 月 6 日,ssokolow 不知道如何输入π。Rust 组的 eddyb 回应他装了希腊输入法,可以输入λ,π等等【我中文输入法威武,通吃】 lambda 表示基本支持,结尾仍希望不建议 API 使用非 ASCII 字符,并开发相关 lint【编译器的代码检查?】补充说没怎么看到过包含非 ASCII 字符的 API,除了一些数学领域和 APL。 今天就以韩国的 kimhyunkang 的19高赞楼结束吧。
点赞的号中,看到了三位法国人以及来自俄罗斯、德国、意大利、中国、日本、罗马尼亚、阿根廷的开发者。【法国,果然五常】 【个人还比较期待的是来自日本开发者的现身说法,以及最后对于 API 的处理。如有其他特别想了解的方面请留言,否则接下来就走哪算哪了】 2019/11/16 粗搜了一下没发现日本开发者发声,动力下降不少。也看到了更加激烈的碰撞,但是更刺激的早就亲身在国内论坛参与过。虽然觉得看国外不同文化间的交锋相比内战更能使旁观者清,但,现在有点看够了的感觉。更主要的,对Rust本身的知识匮乏也使这个系列注定向说书方向发展,而离技术研讨越来越远。也许哪天有兴致(或者再被某些言论刺激到)再开书吧。下面是写前一篇时就完成了的结尾部分。 Rust 语言初创一锤定音RFC#2457 提出之后,Rust 语言的设计者 Graydon Hoare 一直保持沉默,没有参与讨论与修订。在两个多月后的 8 月17 日,他终于发声,这也是这场论战中他唯一的发言: 他指出,“很多年前,我们(Rust 主创们)就早已确认,将标识符限定于用英文命名是设计上的错误,我们应该改用 unicide 标识符”。并在最后恳请:“这(RFC)本不应再次开启一场围绕标识符命名限于 ASCII 码是否正确的辩论。这绝不正确。不要再纠结于此,拜托。” 最后一句: “从Python到C++都默认支持非 ASCII 码标识符。这是正确的作为。” 后记围绕在英文编程语言中添加对非 ASCII 码命名标识符的支持,类似的论战绝不会是最后一次。就正反双方对立的激烈程度而言,是否前无古人已不重要,只是但愿,再无来者。 因为,这一特性本该成为所有新编程语言的标配,而不需再经过这样的争辩。 |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论