仓库源文，站点原文

源自 如果要全新设计一款中文编程语言&编译器&集成开发环境，大家有没有什么好的建议? 写着写着成了文章, 干脆整理下发在这里.

看到这个知乎问题时非常兴奋, 因为两年前开始过非常相似的讨论: 讨论: 适合中文用户的编程语言和IDE, 侧重于现有语言/IDE不具备的特性 · Issue #11 · program-in-chinese/overview​

两年来看到不少对中文编程语言的尝试, 如中文版TypeScript和另一个实现, 还有最近看到的几个中文版Python的实现等等, 觉得中文API对于中文编程语言的成败几乎是决定性的. 因此最好优先考虑如何建立或利用现有生态.

看到题主的工作背景后, 想起之前一位游戏领域开发者实现的一个相关项目(详见 游戏设计领域对中文编程(语言)的需求). 个人认为一种渐进, 风险相对较小(投入产出比)的方式是:

  1. 先开发一些自身领域相关的中文API的库. 优势是工作量较可控, 社区用户集中, 而且不依赖于2和3即可发挥作用, 即在现有编程语言开发中使用. 而2/3不可能缺少1而成功. (详见: 用中文命名API的意义和途径). 最近的一个不成熟设想, 主要因为我个人暂时没有一个特定背景和圈子以便开发专业库, 只得从为现有API建立中文索引入手.
  2. 在1的基础上开发中文DSL与相关IDE辅助功能(比如上面的那个Groovy引擎). 这一步实现的IDE辅助功能比如中文输入和自动补全的集成(如这里演示), 稍加改动就可以用于辅助其他/现有编程语言中使用中文标识符, 同样也不依赖于3.
  3. 在2的基础上(可能经过几次迭代), 发展出一套通用型的语言设计.

这个顺序的好处是, 在每一步都有直接实用性, 可以从第一步开始积累用户, 在此基础上改进相关辅助工具. 简而言之, 就是从用户的实际用例出发, 每一步都做到"足够好"即可.

如果反向, 从通用语言设计开始, 很容易成为无根之水. 因为离实用阶段相当远. 在达到内测阶段之前, 大多数情况要么纠结于各种语言特性取舍而止步于一个不完整的原型, 要么完成语言后无力进行实用性的API开发导致仍然无法实用.

设计中文API时, 还有一个从自身领域相关入手的理由, 就是选取命名时的术语一致性问题. 通用API往往牵涉到不少难以取舍的翻译(如之前对JDK的翻译尝试). 如果是自身熟悉的专业领域, 不仅熟悉API的功能内涵便于找到对应中文, 也方便在相对较小的专业社区中打磨出一套为同行认可的术语词典. 在这基础上, 同时也会发展出一些易用易懂的短语句式(比方说英文API常见的getXXByYY对应的中文), 而这些句式多半可以在第三步适用于更广泛领域的中文API命名. 当然, 现有的中文编程工具的API命名风格也可用于参考.

关于IDE, 除了上面帖子的几点, 中文例程的积累对于推广非常重要. 有几个方面:

  1. 编程语言自身的测试代码. 一方面是项目必需, 更可以作为面向用户的例程.
  2. 类似于上面的5分钟入门, 以及一些常用的代码片段. 最好是集成在IDE中. 比如这里的演示: 通过IDE扩展提供常用功能的例程/片段 · Issue #133 · program-in-chinese/overview
  3. IDE最好与库管理集成, 便于共享开源代码. 详见从立创EDA，Gratipay看中文编程开发环境和推广运营的一个趋势的第一部分.

这里就要说到题目的第二部分. 实际上, 编程语言/API的详细设计, 可以在实现之前就落实在文档上. 包括覆盖所有语言特性的例程, 以及API的类/方法设计等等. 一旦这些文档得以打磨成熟(可以从社区获取反馈), 整个项目几乎就成功了至少一半, 因为目标将会非常明确, 而且能够确保大方向没有问题. 即使因为种种原因不能实现, 后人也可以依照这个文档进行改进/实现, 仍然会省力很多.

鉴于今后希望进行一些中文DSL的开发, 此文也为自己提个醒, 在写第一行代码之前, 文档先行.

看到其他回答提到图形化编程. 因为个人工作中用过内部开发的一套图形化开发工具, 有些体会想分享下. 几个问题会直接影响团队开发和复杂度较高的开发.

  1. 不同版本间的比较. 我们上代图形化开发工具至少可以导出为xml文件. 不同版本间好歹可以比较修改的细节, 虽然xml的diff结果也很难阅读. 这代的虽然改成了在线web工具, 但diff功能一直没跟上. 导致只能倚靠版本的注释和手动记录修改内容, 这使得用惯了版本控制的开发者非常不适应也很抵触.
  2. 支持多人同时开发. 其实和1一样也是版本控制的一部分. 我们的工具有一个草稿模式, 比如新建立的工程有个0.0版本, 同时建立了一个0.0.xuanwu草稿, 我可以在这个草稿版本中作改动, 并提交0.1版本, 但是如果另一个开发者同时在ta的草稿0.0.someone中作了修改, 而在我的0.1版本提交后做提交的话, 会被要求提交到0.2版本, 因为0.1已被占了, 关键是, 不能合并我做的0.0到0.1的改动. 这几乎就决定了只能由一个开发者开发通过图形界面开发的部分, 而另一个/几个进行通过代码定制的部分.
  3. 也许是最重要的, 自动测试框架. 常用英文编程语言都有对应的自动测试框架. 而图形开发如何编写自动测试和维护测试用例呢? 没有自动测试意味着测试人员的工作量更加不可控(想象一下自动测试出现前的年代, 所有修改都必须人工测试). 又有个不成熟的想法, 在语言/DSL设计时, 可不可以将TDD的思想融合进去, 使测试框架成为一种语言特性?

因此如果要走图形化, 首要也许要考虑如何实现一套版本控制系统和自动测试框架(除非针对单人开发和短平快项目), 而两者都不是易事. 个人认为, 如果是想为通用型语言做准备, 最好从文本型设计开始, 而将图形化作为锦上添花的功能.

有一点虽然与设计无关, 但仍建议一下: 实现时用中文命名标识符. 因为是面向中文开发者的工具, 潜在合作/贡献者也都会中文. 详见:

想到再补充.