从一月从零开始重新开发一个编程语言，到现在已经有五个月了。
目前项目距离发布还有一段时间，那就只能写写最近的感受和领悟吧。
一开始我以为所有的程序员都可以成为这个语言的用户。
但事实并不是这样。
那些上班的程序员不会使用新语言，因为他们不可能随意更改工作中使用的技术栈，那付出的代价远高于收益｡
所以他们给的最多的建议就是“不要再重复造轮子了，没有生态的东西肯定是没人用的。”
既然专业的程序员不用，那给非程序员用总可以吧。
但这个想法也很幼稚。
一个没有学过编程、不是以编程为职业的人，永远不会有自己去开发程序的想法。
所以开发一个面向编程小白，比如以中文为卖点的编程语言，受众会少很多，少到无法支撑项目的开发成本。
然后我沉下心思考：我为什么要做编程语言？
最初的动机是因为我对现有语言的不满，然后想为自己打造一个趁手的“武器”。
所以编程语言的真正用户是我自己。
那有没有必要就因为对现有语言的不满而花费大量的成本去开发一个新语言？
对现有语言的不满主要分为两类，一类是习惯不一样，每次用起来都特别别扭。
比如在 go 里面，变量名后面不需要加冒号，每次都是习惯性输入冒号后再删掉。
这一类问题其实还能接受，因为影响不大，而且在别人眼里可能都不是问题。
而另一类问题就是无法快速实现我想要的业务功能，比如做一个支持企业微信扫码登录的功能，虽然这功能很常见，但真要做完善，不是分分钟就可以。
即使现在有AI，真让你排期完成这个需求的时候，你不会觉得这是一个顺手就能搞定的功能。
现在无论开发一个什么商用系统，都需要好几个程序员、几个月才能开发上线，而且上线初期还满是bug。
我觉得这里有巨大的效率提升空间。
我需要一个非常完善的业务框架，内置所有常见需求，同时又保留充分的定制能力，这样面对任何需求都能轻松上线。
经常做外包的朋友，肯定私藏了不少项目模板，需要的时候就复制一份代码改改，然后就可以上线了。
这种做法非常有效，但每次改代码总会出现很多的错误，还无法做到分分钟就上线的程度。
我以前的主要工作职责就是开发企业内部的框架，在如何设计一个稳定、易用的框架上具有丰富的经验。
很多时候框架的能力都受限于语言本身。
所以我应该从语言底层入手，框架提供既有功能，语言保证定制能力。
这样才能做出比主流框架还要易用的框架。
只要新语言和配套框架确实能帮助开发者提升效率，同时又能保证产出的系统是稳定、美观的大厂质感。那就一定能获得用户的认可。
现在的编程语言大多是科研型人才设计的，他们很少参与过枯燥的一线业务开发，不懂普通程序员的痛点。
很多语言标准库提供的 API 和业务真正需要的功能都相差很远，导致几乎每个项目都存在一个重复的 util 文件夹。
而既知道语言设计背后的权衡，又理解前线人员的需求，则是我的优势。
语言不应该提供太多的配置，大家只想把功能做出来，并不关心代码是怎么写的。
语言要做的，就是帮用户选择一个靠谱的解决方案，这类似于山姆的商业模式。
一个功能对应一个 API 即可，不需要支持一个功能多个写法。
语言的语法并不重要，用户不会因为语法看上去更“优雅”而选择这门语言，反而因为选择了这门语言，而被迫接受所有语法。
当然这不意味着，语言设计者可以为所欲为地设计语法，如果发明了一个和主流习惯不同的语法，就必须先证明这种改动是有价值的，能帮助用户提升效率，而不是徒增用户的学习成本。
现在编程语言已经非常成熟了。
但我觉得现在是合适的时机，去整理一下前辈的成果，抛弃历史包袱，轻装重新上阵。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。