原问题的题目比较宽泛, 先引用原问题的描述:
不要说什么中文难打, 难记, 难读之类的荒谬话语.
也不要说关键字只有几十个. 我一点不觉得那些 for,if,+,= 有什么价值. 阅读代码的时候我希望尽量不要看到哪怕一个运算符和关键字, 尽量全封装起来才好.(愿世界再没有长段代码块)
编程百分之九十九的工作是面向 API 编程.
而 java 的标准库接近上千吧, 安卓的 API 有几千? ssm 框架呢. dom 和相关 vue,react 框架呢. CSS 的几十个属性, 上百属性值也不那么容易理解吧. 底层开发人员还要大量用系统调用和内核 API 呢, 这也是大坑. 其他三方库, 开源项目的 API 不用说了.
这些类名, 方法名, 属性名, 常量名的记忆要多久呢? 不记忆查询的话消耗的中间成本是多少呢? 那些错误提示, 那些看原版资料的时间, 那些上谷歌, Stack Overflow 的成本怎么算呢.
在公司工作的时候, API 的设计和阅读是否是痛点之一呢? 为了几十万行的程序要分多少层, 多少模块, 要设计多少个类, 多少属性, 多少变量常量, 多少对象名, 多少 CSS 类名. 为此写多少文档, 多少注释, 死多少脑细胞?
在工程化, 标准化, 框架化的现代, 在越来越重视软件工程规范, 分层, 封装, 模块化的现代. 在代码几十万上百万行的现代. 在越来越讲究代码可读性, 讲究代码自解释的现代.
中文化真的没意义吗?
我的回答如下:
很高兴看到针对 API 和可读性的问题, 也是中文编程相关话题中相对较少讨论的部分.
毫无疑问, 在中文是唯一官方语言的地区, 在编程中更多地使用中文是必然趋势.
标识符母语化可以提高代码可维护性, 详见:《对在代码中使用中文命名的质疑与回应》. 如题主所言, 业界对代码可读性意义的认识提高是中文编程的一个助力. 详见《中文编程兴起的必然性》.
API 是标识符中的重要部分, 但也是一个短板, 亟需补上. 个人认为, 随着自定义标识符使用中文的逐渐推广, API 中文化也会逐渐推进, 从专业领域到通用领域是比较可能的方向.
中文编程专栏之前有过一些探索. 比如将英文 API 汉化后的对比:《用中文命名 API 的意义和途径》
英文版:
使用了中文 API 的版本:
(第一个?)在常用包管理平台发布的中文 API:《在 Maven Central 发布中文 API 的 Java 库》.
因为库本身就是针对中文处理的, 因此中文 API 自然而然. 当然绝不是只能在中文相关项目中使用中文 API. 即使保留英文 API, 中文 API 也可以在所有已有的开源项目中积累, 详见《在国内原创开源项目中使用中文命名的意义与方式》. 再之前也有尝试:《FriceEngine 试用与 API 中文化》
API 中文化虽然看起来技术门槛不高, 但很大的一部分工作量在于补完测试和术语一致. 发现的对现有编程语言和常用库进行汉化的开源项目, 还没有看到完备的测试集, 而这是库的质量的最直观体现. 常用 API 中英文词汇的对应中文术语, 也尚未形成完备的对应表. 这和标准 / 常用库往往有成百上千个 API 有关, 也和 IT 术语尚未标准化有关.
因此,(传统)专业领域也许更容易进行中文 API 的实践, 因为领域本身就已经有完备的中文术语系统. 游戏领域自不用说, 工业领域更是如此. 举个例子:
自研 API 需要实践积累, 因为 API 设计一方面是个软件问题, 更需要对业务需求相当熟悉. 另外, 中文 API 也和少儿编程息息相关, 尤其是如果要将编程应用于传统学科 (如数理, 语文等等) 的教学, 就必须开发一套母语的领域 API, 比如日本的《小学编程教育指导》中, 就有这样的母语 API 的例子:
最近也看到不少中文 Scrach 的类似环境, 但似乎尚未看到和传统学科结合的例子.
总之, 路在脚下. 希望多多交流, 一同努力.
来源: http://developer.51cto.com/art/201908/601238.htm