[[356459]]

上個(gè)月，在社區(qū)上發(fā)布那篇《Charj —— 代碼的代碼化語言》時(shí)，遇到一系列的相關(guān)問題。起初并沒有想到會(huì)在知乎上有這么多的討論，所以我并沒有詳細(xì)介紹為什么創(chuàng)造 Charj 的緣由。只是說了說，哦，如果要?jiǎng)?chuàng)造一個(gè)語言的語言是這么這么做。由于一直忙著項(xiàng)目，和實(shí)現(xiàn)相關(guān)的功能。

于是，在完成了 Charj 的 hello, world 之后， 我決定再寫一篇文章，介紹一下 Why & Next?

十年以后，編程會(huì)怎么發(fā)展?

十年，也就是兩個(gè)五年之后，編程會(huì)怎樣，這是一個(gè)很復(fù)雜的問題。而作為一個(gè)資深的程序員 & IT 顧問，我年復(fù)一年地在考慮這個(gè)問題。

2015 年，Google 主導(dǎo)成立了云原生計(jì)算基金會(huì)(CNCF)。云原生是現(xiàn)在熱點(diǎn)話題。

2017 年，我開始研究 Serverless(參見：我寫的 https://serverless.ink/ )，即函數(shù)即服務(wù)。你可以想象一下，2014 年微服務(wù)剛流行的時(shí)候，人們對于這個(gè)觀點(diǎn)很驚訝的樣子，而在 2020 年，人們已經(jīng)對微服務(wù)習(xí)以為常。現(xiàn)在呢，Serverless 已經(jīng)慢慢進(jìn)入了技術(shù)圈的視野。想必在 3 年以后的 2023 年，人們會(huì)對 Serverless 習(xí)以為常。

2018 年，我研究地主要內(nèi)容是如何應(yīng)對大型的前端應(yīng)用架構(gòu)，即微前端一系列相關(guān)的內(nèi)容，詳細(xì)可以見《微前端的那些事兒》

2019 年，我研究了幾個(gè)月的低代碼開發(fā)，隨后轉(zhuǎn)向了構(gòu)建一個(gè)理想成熟的理論體系：云研發(fā)。(GitHub：https://github.com/phodal/cloud-dev)。

云研發(fā)是一種生于云上的閉環(huán) + 代碼化的軟件開發(fā)方式。它可以讓業(yè)務(wù)人員、開發(fā)人員、運(yùn)營人員等在同一個(gè)云端共同協(xié)作、透明化地完成整個(gè)軟件的生命周期(需求、設(shè)計(jì)、編碼、構(gòu)建、部署、運(yùn)營)，而非相互隔離，又或者是借助于多個(gè)軟件才能完成工作。

而這幾年云 IDE 正好開始了它們的蓬勃事業(yè)。相信在未來一兩年內(nèi)，云研發(fā)這個(gè)概率將會(huì)越來越多的被提及。然后大概會(huì)在 2025 年左右開始被接受。

同樣的，去年，我公司的大佬 @大魔頭-諾鐵，提出了一個(gè)更超前的概率：填空式編程。即未來人人都會(huì)編程，只需要會(huì)填空式的寫代碼即可。相應(yīng)的實(shí)現(xiàn)是：類型流，GitHub：https://github.com/notyy/TypeFlow 。詳細(xì)視頻見：https://zhuanlan.zhihu.com/p/94522501

2020 年，我上半年主要研究的是研發(fā)流程的代碼化：『文檔代碼化』、『需求代碼化』、『如何為代碼建模?』、『Charj —— 代碼的代碼化語言』……。它們是走向云研發(fā)閉環(huán)的關(guān)鍵系內(nèi)容。

所以，可以遇到的事情是，在未來，編程會(huì)變得越來越簡單。但是呢，如我在去年那篇《無代碼編程》中提到的那樣：

復(fù)雜度同力一樣不會(huì)消失，也不會(huì)憑空產(chǎn)生，它總是從一個(gè)物體轉(zhuǎn)移到另一個(gè)物體或一種形式轉(zhuǎn)為另一種形式。

既然，我們在上層實(shí)現(xiàn)了接口式的調(diào)用，那么我們必然要在下層有對應(yīng)的實(shí)現(xiàn)，也就是編程的基礎(chǔ)設(shè)施。

簡單來說就是：10 年以后，編程會(huì)變得越來越簡單。位于頂層的應(yīng)用開發(fā)程序員，往往更易受到『人口-紅利』的沖突。而通過一系列的封裝，底層的通用將會(huì)變得越來越復(fù)雜。

自動(dòng)化代碼修改 && 自動(dòng)化重構(gòu)

與此同時(shí)，我研究了另外一個(gè)有意思的議題是：自動(dòng)化重構(gòu)。這部分的研究，主要是為了幫助我快速完成一個(gè)軟件開發(fā)咨詢師的工作。來到客戶現(xiàn)場，掏出我開源的工具，自動(dòng)化地對代碼進(jìn)行評(píng)估，而后再一一有針對地解決問題。并且，其中的一些問題便是對于代碼進(jìn)行自動(dòng)化、半自動(dòng)化地重構(gòu)。

而作為這一系列的基礎(chǔ)就是編程語言與語法樹。

去年，在公司大佬的指導(dǎo)下，我寫了重構(gòu)工具 Coca：https://github.com/phodal/coca 。Coca 是一個(gè)用于系統(tǒng)重構(gòu)、系統(tǒng)遷移和系統(tǒng)分析的瑞士軍刀。它可以分析代碼中的 badsmell，行數(shù)統(tǒng)計(jì)，分析調(diào)用與依賴，進(jìn)行 Git 分析，以及自動(dòng)化重構(gòu)等。簡單地來說，就是分析各類語言的代碼，提取特定的結(jié)構(gòu)，分析內(nèi)容。

隨后，因?yàn)?Antlr 對 Go 的支持語言，我改用 Java + Kotlin 來實(shí)現(xiàn)其中的語法實(shí)現(xiàn)部分，也就是后來的 Chapi：https://github.com/phodal/chapi 。所以，Chapi 被定義為一個(gè)通用語言元信息轉(zhuǎn)換器，能將不同語言轉(zhuǎn)換為相同的 AST。而由于使用的是 Kotlin 的實(shí)現(xiàn)，我可以自由地轉(zhuǎn)換核心域構(gòu)建的產(chǎn)品。不過呢，語法解析這種東西，你寫了一個(gè)語言，你就不想再寫第二個(gè)了。

上個(gè)月和我的同事搞的 CSS 重構(gòu)工具：Lemonj ，也是基于類似的原理。

系統(tǒng)重寫

每隔幾年，我們都會(huì)發(fā)現(xiàn)有大量地系統(tǒng)都在不斷也被重寫。而除了使用新的框架之外，還有可能使用新的語言。而傳統(tǒng)地方式是使用人肉的方式提取這些信息，再一一重寫。

這一部分工作，必然可以通過一定地自動(dòng)完成，那就是代碼轉(zhuǎn)換。

編程基礎(chǔ)設(shè)施的缺失

除此之外，最后的一個(gè)考量是基礎(chǔ)設(shè)施。如你所見，在上一個(gè)時(shí)代，我們的國家里缺乏一系列的基礎(chǔ)設(shè)施，從操作系統(tǒng)、數(shù)據(jù)庫、瀏覽器等等。而在這一個(gè)時(shí)代，我們?nèi)鄙僭粕嚓P(guān)的基礎(chǔ)設(shè)施。我們總說開源能解決一部分問題，但是事實(shí)上并非如此 —— 開源有著巨大的學(xué)習(xí)成本。(PS：這個(gè)我會(huì)在另外一篇文章中介紹)。

我接觸過一些國內(nèi)某大公司，基于開源軟件魔改的操作系統(tǒng)、IDE，還有各類的云原生基礎(chǔ)設(shè)施。不僅僅需要對源碼很了解，還需要對系統(tǒng)的設(shè)計(jì)理念很熟悉。而這些知識(shí)則是隱性地藏在源碼中，需要經(jīng)過大量地練習(xí)才能掌握。而這個(gè)成本，反而遠(yuǎn)比自己創(chuàng)造一個(gè)系統(tǒng)的成本要高得多。

簡單來說，就是開源需要巨大的學(xué)習(xí)成本。

所以，我在 Charj 里打了兩個(gè)賭：

Rust 語言會(huì)成為系統(tǒng)編程不可缺少的一部分。

未來編程語言已經(jīng)不重要了。

如果事實(shí)可以如此，那么我們(寫 Charj 的人)就可以在 10 年以后不落后，甚至占據(jù)先機(jī)。

 本文轉(zhuǎn)載自微信公眾號(hào)「phodal」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系phodal公眾號(hào)。