[[350038]]

在我當(dāng)前所在項(xiàng)目里，其中的某一個(gè)子系統(tǒng)是用 Groovy 中的 Gradle 插件。Groovy 作為一個(gè)運(yùn)行在 JVM 上的腳本語(yǔ)言，天生具有膠水的特性。加之，它支持 DSL 與其程式的簡(jiǎn)潔語(yǔ)法。嗯，如果不考慮性能問(wèn)題，這真的是不一個(gè)不錯(cuò)的語(yǔ)言。

可真的是如此嗎?

開(kāi)始之前，我再次 FBI warning 一下：

• 關(guān)于編程語(yǔ)言的討論，并非能真實(shí)，都存在或多或少的個(gè)人偏愛(ài)因素。因此，文中的某些觀點(diǎn)或許會(huì)有些偏頗。若是不正確又或者是出入較大，也希望大家能指正。
• 這里的場(chǎng)景主要是基于團(tuán)隊(duì)協(xié)作的場(chǎng)景之下討論的，而非個(gè)人項(xiàng)目，又或者是小項(xiàng)目。也就是說(shuō)，只有團(tuán)隊(duì)協(xié)作時(shí)，才會(huì)出現(xiàn)的問(wèn)題，才會(huì)出現(xiàn)各種討論。
• 說(shuō)起這一點(diǎn)我也是有個(gè)人偏好，如業(yè)余開(kāi)發(fā)選各種語(yǔ)言，而真正做項(xiàng)目的時(shí)候，選的語(yǔ)言便是 Java;業(yè)余開(kāi)發(fā)用 React、Stencil.js，在公司做項(xiàng)目的時(shí)候，還是 Angular 大法好。

引子 1 ：編程語(yǔ)言的讀與寫

我們都知道，編程語(yǔ)言是寫給人看的代碼，寫機(jī)器運(yùn)行的機(jī)器碼。所以呢，對(duì)于編程語(yǔ)言而言，我們會(huì)有一個(gè)簡(jiǎn)單的判別標(biāo)準(zhǔn)，即它的讀與寫。從使用體驗(yàn)上呢，我們可以分為：易讀易寫，易讀難寫，易寫難讀，難寫難讀，這么四類的語(yǔ)言。

為了貼合文章的主題，我大概對(duì)我在項(xiàng)目上用過(guò)的 JVM 語(yǔ)言做了一個(gè)分類。(PS：真實(shí)情況下，差異沒(méi)有這么大。)與此同時(shí)，由于每個(gè)語(yǔ)言的使用場(chǎng)景不一樣，我們并不考慮諸如于性能等問(wèn)題。

簡(jiǎn)單說(shuō)明一下 (笑，我們并不討論他們的優(yōu)點(diǎn)。例子中的 Kotlin 不太適合，只是我暫時(shí)沒(méi)有在項(xiàng)目上用過(guò)其它 JVM 語(yǔ)言，也許 JRuby 就不好讀了)：

Java 語(yǔ)言嘛，大家都懂，又好讀又好寫，所以 Java 程序員便宜。

Groovy (Gradle 所采用的 DSL 語(yǔ)言)難寫的地方在于，文檔少、語(yǔ)法糖導(dǎo)致IDE 支持差(相對(duì)而言)。事實(shí)上，它也不是那么好懂，在 IDE 支持的情況下，要用碳基腦做個(gè)類型推斷。

Kotlin，如果已經(jīng)熟悉 Java 或者其它語(yǔ)言的話，寫 Kotlin 并不是一件難事。這件事情難就難在閱讀別人的 Kotlin 代碼，可能會(huì)有點(diǎn)費(fèi)勁，除非你有良好的 IDE 支持——它的親爸爸可能是 Jetbrains。離開(kāi)了 IDEA，找個(gè)擴(kuò)展(extension)都得找半天。所以難度總體上還是不難的，只是相對(duì)難讀一點(diǎn)——因?yàn)檎Z(yǔ)法糖。

Scala，早期的某個(gè)項(xiàng)目，我?guī)讉€(gè)月后看不懂幾個(gè)月前寫的代碼。

而如上所說(shuō)，對(duì)于語(yǔ)言每個(gè)人是有偏好的。所以，這里依舊是我的一些個(gè)人觀點(diǎn)。我也并非這方面的專家，只是從個(gè)人閱讀開(kāi)源代碼和編寫相關(guān)代碼的感受來(lái)說(shuō)的。

引子 2：適用領(lǐng)域與流行應(yīng)用

談及編程語(yǔ)言，我們要討論的是另外的另一特質(zhì)：適用領(lǐng)域。如我們熟悉的：

• Golang 背靠云原生和 Google
• Python 是科學(xué)家們的偏好，畢竟不是以代碼為生。
• JavaScript 是交互方式發(fā)生了變化
• Ruby 是 Rails 框架，所以流行開(kāi)了。
• Java 用于企業(yè)編程，因?yàn)槌绦騿T便宜

而諸如 Rust 這樣的小類語(yǔ)言，還沒(méi)有正式有一個(gè)能發(fā)揚(yáng)光大的場(chǎng)景。

引子 3 ：編程的快樂(lè)，先寫得爽

有一些語(yǔ)言能讓你拾起編程的快樂(lè)，比如 Ruby，但是也能讓你不想去維護(hù)代碼——讓人又愛(ài)又恨的 Method Missing，可以讓你搞起元編程。也能分分鐘讓你看不懂別人寫的代碼。如果沒(méi)有文檔的話，那么我覺(jué)得你不會(huì)再看了。

又比如說(shuō)，操作符重載也是一個(gè)讓人寫的代碼更加直觀。嗯，再重載一下賦值操作符，是不是非常爽。

對(duì)于快樂(lè)來(lái)說(shuō)，維護(hù)性那是以后要考慮的問(wèn)題。

編程語(yǔ)言的被淘汰

在項(xiàng)目上經(jīng)歷了慘痛的 Groovy 開(kāi)發(fā)大型項(xiàng)目的經(jīng)驗(yàn)后，我和我的同事們一致覺(jué)得這是一門可能被淘汰的語(yǔ)言。主要原因有這么幾個(gè)：

1. 可維護(hù)性丟失
2. 缺失更好的 IDE 支持(相比于 Java 之類的)。說(shuō)白了就是開(kāi)發(fā)人員寫起來(lái)不爽。
3. 在最廣泛的場(chǎng)景之下，可遷移語(yǔ)言出現(xiàn)(如 Kotlin Script)

如果你還想把編程語(yǔ)言的一些缺點(diǎn)考慮一下，那也是可以的。

可維護(hù)性丟失

這也并非是語(yǔ)言本身的問(wèn)題，而是語(yǔ)言應(yīng)對(duì)大型項(xiàng)目時(shí)，將會(huì)遇到的一個(gè)挑戰(zhàn)。對(duì)于大型項(xiàng)目而言，自由靈活的語(yǔ)法糖會(huì)帶來(lái)大量的問(wèn)題。而隨著項(xiàng)目的進(jìn)一步擴(kuò)大，保持同一套代碼風(fēng)格容易，而要使用同一套語(yǔ)法越來(lái)越困難。如同樣是聲明類型，有的用具體的類型，有的則是用 def 或者是 var。

缺失更好的 IDE 支持

嗯，如果你習(xí)慣了用 IDEA 對(duì) Java 代碼進(jìn)行快速的重構(gòu)之后。而與此同時(shí)，你并不能使用相似的方式來(lái)對(duì)你的 Groovy 代碼進(jìn)行重構(gòu)。你們就會(huì)慢慢陷入了一個(gè)循環(huán)，既然有一個(gè)更好的語(yǔ)言，為什么我們不去使用它們呢。

退而求其次的，為了使用 IDEA 的高級(jí)功能，如重構(gòu)。我們開(kāi)始將代碼中的 def 轉(zhuǎn)換為具體的類型。

可遷移的語(yǔ)言出現(xiàn)

而其實(shí)上面兩個(gè)問(wèn)題，并不是這個(gè)語(yǔ)言的主要問(wèn)題。畢竟，對(duì)于小的項(xiàng)目來(lái)說(shuō)，IDE 和可維護(hù)性支持都不是問(wèn)題。

過(guò)去，我們根據(jù) Gradle 官方文檔，使用 Groovy 來(lái)編寫 Gradle 插件。而有一天，Gradle 官方文檔同時(shí)提供了 Kotlin Script 的支持。

這就相當(dāng)于是，上帝真的拋了個(gè)橄欖枝給你。你可以同時(shí)擁有更好的 IDE 支持，更好的可維護(hù)性。同時(shí)，還可以快速地遷移過(guò)去。為什么不呢?

其它

與之相似的一個(gè)例子便是 JavaScript 和 TypeScript，但是瀏覽器運(yùn)行的是 JavaScript。所以，JavaScript 并不能這么容易被取代。

結(jié)論

有沒(méi)有可能出現(xiàn)一個(gè)兼容所有語(yǔ)言的語(yǔ)言?

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