把當前各種編程語言的優秀特性集中到一起，設計一種最好的語言，是否可行？

01-03

C — 內存這麼重要的東西，怎麼能讓系統管理呢，必須要程序員來管。

Java — 內存這麼重要的東西，怎麼能讓愚蠢的程序員管理呢，必須要系統自動處理。

(cf. justjavac)

════════════════════════════════════════

Java — 數據類型這麼重要的東西，怎麼可以不管呢？應該讓程序員寫出來然後編譯的時候檢查！

Python — 數據類型這麼重要的東西，怎麼可以不管呢？但是每個都寫太煩人了，運行時檢查下意思意思就行了……

Haskell — SPJ：數據類型這麼重要的東西，怎麼可以不管呢？但是每個都寫太煩人了，所以我們研究一個辦法幫程序員填上吧……

#lang no gc #lang use {} #lang use type check #lang use type infer #lang no lisp style #lang use match #lang use ref count #lang use string #lang use dynamic array #lang no everything class #lang no on jvm #lang use compile


// You can choose you language"s feature

int main (string [] args) { print("hello, world "); }

下文中，將「優秀」一詞等同於「好」一詞，互換後意思一樣。只是「好」讀起來順口些。

這種問題，關鍵在於你如何定義「好」，什麼才叫「好」呢？需要先想清楚怎麼才叫「好」，才能討論這個問題。

針對這個問題，我將「好」定義成，適合於（或適應）。「好」的生物，是指可以適應環境。「好」的語言，是指適合於解決某個領域的問題。你也可以有其它定義，但必須有一個定義，才能繼續討論下去。名字是有歧義的，同一個名字，在你心裡是這種概念，在其它人是另一種概念，就很難討論下去。

這種定義下，語言沒有所謂好壞，只有適合不適合。某種語言特性，對於一個領域的問題很合適，對於另一個領域的可能就是妨礙。同樣沒有最強大的生物，只有適者生存。

下面是舉例：

有一些昆蟲沒有翅膀，不能飛，這在平常的情況下是不好的。但在是風大的海島，有翅膀但翅膀不夠強大的，反而因為能飛而被吹進海里，這時不能飛反而是好的。

在冰天雪地當中，北極熊的白色是好的，黑色太容易暴露。而在非洲，黑色反而會保護皮膚，白色皮膚更容易晒傷。

剛學自行車的時候，後輪有兩個輔助輪是好的，這樣學車不容易摔倒。但學會之後，兩個輔助輪是累贅，應該拆掉。

做一件事情，確定後才做下一件事情，這種性格在不緊急的場合是好的，可以減少犯錯。但在情況緊急時，比如在高考時，反覆確認反而會讓你考砸。

人類看起來比較高級，但當發生災難時，比如彗星撞地球，核爆炸之類。看似低級的蟑螂反而更容易活下去。

再回頭討論語言，

比如指針。在寫高層的代碼時，指針代碼會比較危險，需要封裝起來。但假如在真的需要操作內存（比如解析文件格式，圖片格式，協議）之類，你將指針封裝起來，反而是累贅。

比如 GC。在寫服務端代碼時，GC 使得伺服器更不容易泄露。但在客戶端時，GC 偶然讓人覺得卡一卡。對於客戶端，平穩在中間速度，也比忽快忽慢好。

比如靜態和動態性。靜態類型檢查，可以在編譯時就檢查出某些錯誤，加快運行速度。但某些場合需要一定動態特性，比如寫 UI，C++ 就不太適合寫 UI。

因此沒有絕對的好壞之分。不能說這是好的，這是不好的。只能說，在這種情況下，這是適合的。在另一種情況下，那才是適合的。脫離了具體情景，去討論那種方案好，毫無意義。

情景比結論更為重要。一定需要區分好情景。當情景改變之後，原來合適的會變得不合適，不合適的會變成合適。有時情景之間的區別很微妙，但會導致做法完全不同，外行區分不了情景，反而怪別人做法變來變去。比如不同的病都可以導致發燒，配合其它特徵，醫生可能會叫你回家休息，可能需要做進一步檢查。病人區分不了，統稱為發燒，跟著就說醫生對待發燒一時一個樣。

把各種編程語言的所謂「優秀（好）」的特性，不加選擇，不加節制地集中在一起，反而是四不像，變得不可用。一共結合十種致命武器於一身，而且每一種武器皆可獨當一面，就成為要你命三千。

杜蘭特打球很厲害,身體條件不錯.
斯嘉麗演戲很在行,臉蛋很好看.
把杜蘭特的身體跟斯嘉麗的臉蛋組合,
那杜蘭特就可以直接喝自己的洗澡水了.

這實際上就是說：

「把一群最牛的開發高手圈在一起，就是一個最牛的團隊，就能開發出最牛的軟體……」

「把各種各樣的質量最好的建築材料堆在一起，偉大的建築就會出現了……」

倒是可以這樣，程序在編譯/解析時加參數，例如--memory-garbage-collect auto/manual --type strong/week 什麼之類的，不就好啦。

只是優秀是沒有用的，得逼著程序員去學。rust愛好者。

覺得會因為哪些算優秀特性，哪些不算而打起來

光是GC就

（沒有下文了

編譯型語言中 C / C++ 有優秀的性能和底層操作硬體的特性，Java 有更有好的語法和較為方便的內存管理機制。Android 開發中，一些應用層的事情基本上都可以用 Java 解決，因為它足夠便利，而一些性能敏感的東西（比如說複雜的演算法）或一些底層操作（比如應用層與 Binder 驅動的通訊）就需要用 JNI 來做。

非編譯型語言或者說腳本語言在很多場景下也扮演了重要的角色，比如 Web，你總不能用編譯型語言來開發吧（雖說現在的 Compile-to-JavaScript 的語言也很多，包括 WebAssembly 的完善，但與上述的編譯型語言還是有很大差別的），遊戲中很多邏輯也需要用腳本語言開發來獲得更好的動態性和靈活性，線上應用通過動態下髮腳本語言可以做到簡單的熱修復。

所以強硬把所有語言糅合在一起是完全沒有必要且並不怎麼可行的，當然可以借鑒所有語言中優秀的語法再設計一套語法更好的語言，但語言的精髓往往並不是語法，而是特性和它所推崇的編程範式。

看到有人說 kotlin，我只想說 kotlin 只是 Java 的一個語法糖，它無非就是讓你寫得比 Java 爽一點了而已，如果拿它跟 Swift 比較我覺得沒什麼可比性，Swift 編譯成二進位可以直接運行，速度就不在一條線，另外 Swift 的范型是真范型哦，不是一個簡單的 hint 哦。我之前見過有人問 CSS 不能選擇父元素，那 LESS 可以嗎？當然也不可以了啊，就跟 JavaScript 無法實現的特性，你 TypeScript compile 成的 JS 就能做到了？還不是得 polyfill，較老的瀏覽器中用 Promise 的 shim 都無法做到跟瀏覽器自帶的一樣的行為。

也許，應該就是目前C++的一個超集吧。

於是就有了PHP

個人心目中的理想語言。

0. 以C++為主體

1. 用javascript 或者shell 做C++的宏。這2者是可移植性最好的腳本語言。

2. 編譯期依然允許用javascript 或者shell 來指導SFINAE，或者說乾脆不允許SFINAE，而是用上述腳本語言來拋異常告訴編譯器別選這個函數來做重載抉擇。

3. 鏈接要用C++的relocation 外加JAVA式的包管理。

4. 函數要允許干預函數是如何返回的：有時候我們知道return stack buffer 不合法，我們就是不想用ret指令。相當於結合點彙編。

5. 運行時能夠給點自修改許可權，別把代碼段都設死成防寫了。別說不安全，那個嘛，嘿嘿嘿。

一開始就在「優秀是什麼」上被口水淹死了……

不可行，某些領域根本不需要的特性，加入後就是冗餘，冗餘多了後各種副作用就來了。

肯定是不可行的，因為其實不同編程語言之間的理念很多是矛盾的，但是又都有它們擅長的場合。簡單的舉例子，編譯型語言在編譯期間檢查數據類型，因為這樣可以生成最優的代碼，但是這樣會造成不同類型間瑣碎的轉換問題；解釋型語言在執行期根據上下文自動判斷類型，這樣寫代碼就簡單了，可是效率又不行了。

所有不談應用場景的討論語言優劣都是耍流氓

不是把所有的食材放在一起炒就是世界上最好吃的菜。

香鍋也要有基本法的。

已經有了

PHP啊

如果真的有這樣一種語言，集合了當前所有語言的優秀特性，那麼到時候可能會有人跳出來，抱怨這種語言不能自動進行編寫。