趁此机会试着填一年多前答“标识符中间为什么不能加空格？”时挖的坑吧。之前讨论的主要是标识符，这里讨论语言设计。
注：此部分包含不少“直觉”，限于条件未作细致调研，其中谬误请不吝批评，前人有类似观点也请告知。
越通用的编程语言，生命力越强。越接近自然语言构造，编程语言的通用性越强。
编程语言是一种针对编程领域的人造语言。无论一个编程语言多么“通用”，它仍然是一个“领域专用语言”（Domain-Specific Language）。相对而言，更通用得多的是自然语言。每行代码都可以用自然语言叙述，证明自然语言可以替代编程语言。
如果一个编程语言的语法源自自然语言（注：不一定支持所有自然语言语法），意味着它：
因此，设计接近自然语言语法的编程语言，更可能实现“大一统”。下面通过举例探讨中文相对英文在这个方向上的优势。
当前，不同英文编程语言的同一符号往往意义不同，比如 = == ===。这种情况下自然语言表述就更不易误用。下面选取一种意义作对比：符号表达-英文表达-中文表达
符号表达 | a = 2 | a == 2 | a === 2（1）| a === 2（2） | ------- | ------- | ------- | ------- | ------- | 英文表达 | set the value of a to 2 | a equal to 2 | a equal to 2 in value and type | a strictly equal to 2 中文表达 | 将 a 赋值为 2 | a 等于 2 | a 与 2 值与类型相同 | a 严格等于 2
从视觉效果上（之前讨论标识符时类似），中文表达的密度介于英文表达和符号表达之间。因此，如果为了通用性而牺牲一定信息密度，中文的牺牲更小。这意味着用户接受的阻力会更小。
另外，编程语言往往用符号替代编程领域术语使得代码更简短。相对而言，英文术语的门槛较高（词汇难、长），从而更难以作为编程语言语法的一部分，现在更多出现在报错信息中。下面是python的继承多类出错例子：
class a(str, int):
会报错：TypeError: multiple bases have instance lay-out conflict
如果改为英文自然语言语法表达该行代码：
class a inherits from str and int
或
class a has bases str and int
对应中文表达：
类型 a 继承自 str 和 int
类型 a 的基类为 str 和 int
除简短外，中文术语的较低门槛使得在编程语言语法中使用这些编程术语的阻力更小。
落实到设计，记下一些随想仅作纸上谈兵。如果使用接近自然语言语法设计，可能会遇到一些技术困难（比如无空格语法时的标识符中包含关键词问题）。在寻找解决方案时，不妨也审视一下，是否存在更“自然”的编程方式，试着跳出现有编程语言（尤其是常见的命令式）语法的框框，用自然语言表达语意，也许会有更多灵感。欢迎各位有实战经验的同道一起研究具体问题。
【设想】编程语言设计的 DSL，对编程语言的各方面作描述。spec
自然语言更有生命力，相对英语，术语系统更易入门。 在已形成中文术语系统的领域，DSL入手。
回复评论区：
class a: str,int
(class_a:_str,int)
类 a 继承自 str 和 int
拼音输入法下：("lei_[shift]__a[shift]_jcz2_[shift]_str_[shift]_he__[shift]_int",下划线表示空格的数量)
你确定比英文短？
文中视觉长度是在自然语言表达之间比较，即比较“class a inherits from str and int” 和 “类 a 继承自 str 和 int“。读和写的关系已在前答 标识符中间为什么不能加空格？ 中作过阐述。前答中也有中文标识符补全示例，中文语法也可类似处理。
另外中文术语“较低门槛”？你告诉我"task","thread"和"process"中文的区别？给我讲讲"RESTful API"和"CoAP协议"的中文是什么？中文术语解释不清或者干脆没有中文的术语多了去了。
中文术语低门槛不单指编程领域，详见前文 《编程术语成系统中文化的意义》。
1.你发的文章并没有解决中文术语混乱和不完善的状态
编程领域的中文术语体系当然有改进空间，但各种国内教材发展了几十年，早已覆盖了常用概念。如果术语能成为代码的一部分，将大大提高中文术语在编程行业内的使用频度，可以促进体系完善。
2.中文术语无法改变底层接口和国际通用标准完全被英语霸占的现状
各领域都有术语系统，编程领域只是其中之一。文章中是金融行业使用中文术语命名标识符提高开发效率的实例。假如需要为金融行业设计一套专用编程语言（或者对本答中设想的类自然语言进行扩展），这些中文术语可以自然融入。之前已说过，假如某术语暂找不到合适中文对应，大可暂用英文术语，用的够多时自然有领域专家带头中文化。比如 @老废物千里冰封 对类型论术语的中文化。
3.博大精深是中文在文化方面的优点，但也是在信息化的缺点：同音字，多义词太多，如果想提高开发效率采用拼音首字母提示，重码率更高。之前回答一个关于中文编程话题时，半开玩笑的说过一句“用中文编程做一个时间(time)触发事件(event)，估计程序员能抓狂”，然而这是中文编程必须要面对的问题
个人使用中文命名标识符的实践体会是，九年义务教育达到的语文水平一般足够表达编程中需要的业务语义。如有认为难以用中文表述的业务，不妨结合具体问题具体分析。
4.英语作文字母拼写语言，虽然自然拼写会比中文长，但是一旦用到简写和缩写英语对于术语和关键字的压缩效果也远超符号语言的中文。Uniform Resource Identifier，“统一资源标识符”中文看上去更短一些，那英语简化到“URI”呢？
《编程术语成系统中文化的意义》一文对英文缩写术语已有阐述。此答中设想的类自然语言，理想的情况是可以用于编写所有行业领域的业务代码。URI 除了编程领域，这里可见 还有其他含义，如医学的 Upper Respiratory Infection（上呼吸道感染）。如果代码涉及这些业务领域，同一缩写就有歧义，使用术语全称可以避免此类问题
谢谢解答，不过我举例当然是限定计算机技术范围，如果扩大学术领域，你有没有想过我说的那个“时间事件”会有多少同音词？实践，十件，试件，市检，石剑？这在中文输入法和IDE智能完成上就是一个比英文大的多的挑战。
个人没看出同音词在表达上的问题。在输入方面，在现在一般中文输入法的基础上，IDE辅助还可以根据代码上下文作进一步改进（比如选词范围、排序等）。这样的话，编写中文代码应该不会比写作中文文档效率更低。
“没有中文术语暂时使用英文”，等出现中文术语再改？编程语言作为一种精密的数学语言，怎么可能接受这么不精密的方案？
技术上，编程语言语法可以做到支持多个同样含义的关键词，API 也可同时支持多个名称。
如果所有没有中文术语、无法使用中文术语或者中文术语不方便的部分都使用英文，那么仍然没有摆脱英文编程的桎梏，该学的英文还是要学，没有任何变化
能用中文术语的就尽量用，可以促进中文术语体系的完善，这比起无论是否有对应中文术语都一刀切全用英文术语，个人认为有很大的不同。另外，像“RESTful”这种缩写式术语，且不论它的跨领域歧义性，如果连它的全称也不能基本覆盖它的实际含义，也许就需要重新审视它作为术语的精确性和恰当性。
参观了一下答主的另一篇文章，大体上是在讲英文自然语言翻译成中文自然语言时字符数量的压缩，但是一直忽略这种压缩付出的代价 -- 同音字、多意字，而这是汉字最大的硬伤之一。我为什么一直强调这一点？编程编程，重点在“编”而不是“读”，书写效率的重要性要优于阅读效率【后略】
看的是此答《标识符中间为什么不能加空格？》吗？其中引用 Robert C. Martin 认为读代码所花时间在写代码的十倍以上，写新代码的同时仍在不断阅读之前代码，代码易读可使得代码易写：“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.”
在我看来“暂用英文术语”的方法并不可行 -- 虽然可以“暂用”英文，随后同时兼容英文和中文接口，但是在英文接口出现到中文接口推出之前，这一段时间里所有的程序员仍然必须使用英文接口和文档，只会“中文编程”的人唯有等待中文接口的出现。一旦这样的“暂用”多了，最大的影响是：要么程序员需要兼修中文和英文两套体系，要么在因为“汉化”的等待期而导致技术滞后。
术语体系建设与文档、常见问题解决方法等等都是开发知识库的一部分，详见《一站式 IDE 的构想：从头审视产品研发过程》。即便某些英文术语暂无对应中文，仍有相当数量的开发者使用翻译后的夹杂着这些英文术语的中文文档。国内市场里中文编程会与英文编程共存很长很长时间，就让实践检验吧。
所以你觉得自然语言比编程语言阅读效率高？ 自然英语：the first character of every word whose style is bold 自然中文：每个单词的首个风格为粗体的字符 编程语言: foreach (w in Words) { foreach(c in w) { if(c.Bold){result+=c;break;} } } return result； 你瞧，自然语言在数据结构和算法逻辑结构上并不易读，甚至逻辑上严重的不完备，而编程语言可以清晰的描述了数据结构和逻辑算法（双循环暴力查找）。 如果这个运算逻辑要用自然语言描述： 遍历文章中的所有单词w，遍历w中的所有字符c，若c为加粗则令result追加c并跳出循环，循环结束后，循环结束后，输出结果result [飙泪笑][飙泪笑][飙泪笑][飙泪笑][飙泪笑]你真的确定易读？？真的确定易写？？？
既然用了 前答 这个例子，那么详细探讨一下。首先，自然英文表达有歧义：1）每个风格为粗体的单词的首个字符 2）每个单词的首个风格为粗体的字符。你的代码片段对应的是我当初误以为的第二种语义，而 AppleScript 论文中的 Professional 风格代码 { words | style == bold }.character[1] 实际上对应的是第一种语义。
接下来，用自然语言描述每行英文代码只是编程语言设计的思路之一，但AppleScript已经演示了更接近自然得多的编程语言语法。我回答中已提过：‘是否存在更“自然”的编程方式，试着跳出现有编程语言（尤其是常见的命令式）语法的框框’
所以说“自然语言”在精准描述逻辑过程上的劣势，正是编程语言产生的原因。我们阅读小说的顺序是从左到右顺序阅读就好。而阅读逻辑结构（程序代码）时，需要找到明确的逻辑结构起始点和结束点，然后阅读二者之间的内容，遇到嵌套结构逐层阅读。所以说自然语言和编程语言在阅读和书写顺序上就有本质区别，这才是导致越接近自然语言的编程语言死的越快的真正原因
我没有看出阅读 if {} else {} 和自然语言的 如果 ...，则 ... 有何大区别。
嵌套结构可否举个实例？