[[356459]]

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

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

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

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

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

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

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

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

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

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

同樣的，去年，我公司的大佬 @大魔頭-諾鐵，提出了一個更超前的概率：填空式編程。即未來人人都會編程，只需要會填空式的寫代碼即可。相應(yīng)的實現(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)容。

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

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

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

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

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

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

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

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

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

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

系統(tǒng)重寫

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

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

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

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

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

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

所以，我在 Charj 里打了兩個賭：

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

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

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

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