上个月，在社区上发布那篇《Charj —— 代码的代码化语言》时，遇到一系列的相关问题。起初并没有想到会在知乎上有这么多的讨论，所以我并没有详细介绍为什么创造 Charj 的缘由。只是说了说，哦，如果要创造一个语言的语言是这么这么做。由于一直忙着项目，和实现相关的功能。

于是，在完成了 Charj 的 hello, world 之后， 我决定再写一篇文章，介绍一下 Why & Next？

十年以后，编程会怎么发展？

十年，也就是两个五年之后，编程会怎样，这是一个很复杂的问题。而作为一个资深的程序员 & IT 顾问，我年复一年地在考虑这个问题。

2015 年，Google 主导成立了云原生计算基金会（CNCF）。云原生是现在热点话题。

2017 年，我开始研究 Serverless（参见：我写的 https://serverless.ink/ ），即函数即服务。你可以想象一下，2014 年微服务刚流行的时候，人们对于这个观点很惊讶的样子，而在 2020 年，人们已经对微服务习以为常。现在呢，Serverless 已经慢慢进入了技术圈的视野。想必在 3 年以后的 2023 年，人们会对 Serverless 习以为常。

2018 年，我研究地主要内容是如何应对大型的前端应用架构，即微前端一系列相关的内容，详细可以见《微前端的那些事儿》

2019 年，我研究了几个月的低代码开发，随后转向了构建一个理想成熟的理论体系：云研发。（GitHub：https://github.com/phodal/cloud-dev）。

云研发是一种生于云上的闭环 + 代码化的软件开发方式。它可以让业务人员、开发人员、运营人员等在同一个云端共同协作、透明化地完成整个软件的生命周期（需求、设计、编码、构建、部署、运营），而非相互隔离，又或者是借助于多个软件才能完成工作。

而这几年云 IDE 正好开始了它们的蓬勃事业。相信在未来一两年内，云研发这个概率将会越来越多的被提及。然后大概会在 2025 年左右开始被接受。

同样的，去年，我公司的大佬 @大魔头-诺铁，提出了一个更超前的概率：填空式编程。即未来人人都会编程，只需要会填空式的写代码即可。相应的实现是：类型流，GitHub：https://github.com/notyy/TypeFlow 。详细视频见：https://zhuanlan.zhihu.com/p/94522501

2020 年，我上半年主要研究的是研发流程的代码化：『文档代码化』、『需求代码化』、『如何为代码建模？』、『Charj —— 代码的代码化语言』……。它们是走向云研发闭环的关键系内容。

所以，可以遇到的事情是，在未来，编程会变得越来越简单。但是呢，如我在去年那篇《无代码编程》中提到的那样：

复杂度同力一样不会消失，也不会凭空产生，它总是从一个物体转移到另一个物体或一种形式转为另一种形式。

既然，我们在上层实现了接口式的调用，那么我们必然要在下层有对应的实现，也就是编程的基础设施。

简单来说就是：10 年以后，编程会变得越来越简单。位于顶层的应用开发程序员，往往更易受到『人口-红利』的冲突。而通过一系列的封装，底层的通用将会变得越来越复杂。

自动化代码修改 && 自动化重构

与此同时，我研究了另外一个有意思的议题是：自动化重构。这部分的研究，主要是为了帮助我快速完成一个软件开发咨询师的工作。来到客户现场，掏出我开源的工具，自动化地对代码进行评估，而后再一一有针对地解决问题。并且，其中的一些问题便是对于代码进行自动化、半自动化地重构。

而作为这一系列的基础就是编程语言与语法树。

去年，在公司大佬的指导下，我写了重构工具 Coca： https://github.com/phodal/coca 。Coca 是一个用于系统重构、系统迁移和系统分析的瑞士军刀。它可以分析代码中的 badsmell，行数统计，分析调用与依赖，进行 Git 分析，以及自动化重构等。 简单地来说，就是分析各类语言的代码，提取特定的结构，分析内容。

随后，因为 Antlr 对 Go 的支持语言，我改用 Java + Kotlin 来实现其中的语法实现部分，也就是后来的 Chapi：https://github.com/phodal/chapi 。所以，Chapi 被定义为一个通用语言元信息转换器，能将不同语言转换为相同的 AST。而由于使用的是 Kotlin 的实现，我可以自由地转换核心域构建的产品。不过呢，语法解析这种东西，你写了一个语言，你就不想再写第二个了。

上个月和我的同事搞的 CSS 重构工具：Lemonj ，也是基于类似的原理。

系统重写

每隔几年，我们都会发现有大量地系统都在不断也被重写。而除了使用新的框架之外，还有可能使用新的语言。而传统地方式是使用人肉的方式提取这些信息，再一一重写。

这一部分工作，必然可以通过一定地自动完成，那就是代码转换。

编程基础设施的缺失

除此之外，最后的一个考量是基础设施。如你所见，在上一个时代，我们的国家里缺乏一系列的基础设施，从操作系统、数据库、浏览器等等。而在这一个时代，我们缺少原云生相关的基础设施。我们总说开源能解决一部分问题，但是事实上并非如此 —— 开源有着巨大的学习成本。（PS：这个我会在另外一篇文章中介绍）。

我接触过一些国内某大公司，基于开源软件魔改的操作系统、IDE，还有各类的云原生基础设施。不仅仅需要对源码很了解，还需要对系统的设计理念很熟悉。而这些知识则是隐性地藏在源码中，需要经过大量地练习才能掌握。而这个成本，反而远比自己创造一个系统的成本要高得多。

简单来说，就是开源需要巨大的学习成本。

所以，我在 Charj 里打了两个赌：

1. Rust 语言会成为系统编程不可缺少的一部分。
2. 未来编程语言已经不重要了。

如果事实可以如此，那么我们（写 Charj 的人）就可以在 10 年以后不落后，甚至占据先机。