如何反駁「JVM、PVM是C寫的，語言不就是對C的封裝嗎！把C學精通了看我多厲害！」？

01-13

假定題主不是來釣魚。其實簡短的答案就是：不必反駁。

首先：

把C學精通了看我多厲害！

真的把C學精通了那確實厲害。確實有大量重要的、偏底層的軟體是用C語言寫的。要真的「精通C語言」那其實不只要精通C自身的語法和語義，常常還要涉及很多平台相關的知識，需要紮實的功底。

其次：

JVM、PVM是C寫的

（這裡的PVM是說Parallel VM么？）

我就緊著JVM說，「JVM」是用C寫的么？

傳送門：Java 平台中的 JVM 和 .Net 平台下的 CLR 分別是用什麼語言寫的？

嗯確實有一些JVM是用C實現的。

但桌面和伺服器上最主流的倆JVM實現，Oracle HotSpot VM和IBM J9 VM的主體都是用C++實現的。（J9以前解釋器核心曾經是用Smalltalk實現然後生成出C的，現在已經被重寫）。特別是用HotSpot VM的各位，這個VM里可是一點C代碼都沒有，除了極其少量的內聯彙編之外都是C++。（如果遇到非要說C和C++是一回事的大大的話，就別跟他爭論啦，浪費自己時間又是何苦）

同時也要強調，有諸如Maxine VM和Jikes RVM這些用純Java實現、能自舉的JVM實現，並不依賴於C語言來實現其主體功能。

所以嗯…「JVM是用C寫的」這個表述是對是錯，取決於是希拉里還是川普說的吧。

然後：

語言不就是對C的封裝嗎！

這個表述是對是錯也取決於是希還是川說的…（逃

其實非要認這個死理，覺得編程語言就是對C語言的封裝，這樣的大大就不要跟他爭辯啦。

一來確實想要從這個角度切入也未嘗不可，二來已經陷入這死理的大大通常也不會聽別的角度的理解，三是有些大大對編程語言的理解還停留在解釋器的思路上止步不前。

所以放棄吧同學，反駁的收益太低了。

為什麼說從這個角度切入未嘗不可。例如說CPython的實現，一個用C寫的解釋器，它在解釋執行Python代碼的時候確實就像是把Python代碼應對到一個個C寫的函數那樣。要說CPython實現「就是對C的封裝」也不算過分——用C實現了豐富的運行時功能，然後為這些功能賦予一個語法。CRuby（MRI）也可以這樣看。Lua的官方實現也是。例子可以舉很多。

但是反過來說，實現Python一定要用C語言么？不，還有好幾個不是用C語言實現的Python。實現Python一定要用解釋器的思路么？也不。可以先編譯到機器碼再執行之，執行這編譯後的代碼未必要調用任何C語言寫的函數。

這就暴露出了從「語言是對C的封裝」角度切入的缺點：這個角度雖然可以用來解釋某些情況，但角度實在太狹隘，還有很多別的情況解釋不了。

嘆氣。

話說我想起以前我在淘寶的JVM組的時候面試過的一位大大。他想過來面試專家職位，號稱自己熟知JVM的設計與實現細節，想來參與我們對OpenJDK的HotSpot VM的定製改進工作。

於是我就問了他幾個簡單的問題，他全部都胡扯，面試後還用很難聽的話向我老闆的老闆投訴面試他的人資質太差。例如說，一個很簡單的問題就是HotSpot VM中，Java線程的mixed-mode stack是什麼，解釋器、JIT編譯後的代碼與native代碼是如何交互的——要說熟知JVM的實現細節的話，這種基礎中的基礎、天天都要打交道的東西，總得知道吧。然而他根本不知道我在說什麼。最後只能支支吾吾出一個「JNI」。

最有趣的是，他堅稱HotSpot VM的高性能的主要來源全部都是靠JNI來實現的。

JVM的性能…全部都靠JNI…

嘆氣。

這位大大肯定不知道為什麼會有諸如PureJavaCrc32這樣的東西的存在吧。他肯定無法相信這個純Java的實現會在許多情況下比通過JNI調用的native實現更快：http://www.mail-archive.com/core-dev@hadoop.apache.org/msg42685.html

他既無法理解JIT編譯器所能做的事情，也無法理解一個高性能的JVM常常會伴隨著相對較高的JNI調用開銷（參數marshalling、優化邊界受限等）。

然而我需要逐條反駁他么？不需要，只要不跟他在一組幹活就好了。最終我們組並沒有招他進來。世界還是很清凈的 ^_^

問他：同學，你聽過彙編嗎？

哦，那你寫的JVM呢？

CPU不都是二氧化硅造的嗎？把沙子玩精通了，看我多厲害

語言當然不是對C語言的封裝。參考C++的第一個（翻譯成C語言的）編譯器cfront為什麼做不下去的歷史，有很多概念就是C語言難以有效表達的，把代碼寫得再亂也沒辦法。

為什麼不精通圖靈機呢……

之所以有這麼多不同的語言，就是為了讓程序員可以不斷提高自己的編程效率，不需要實現，編程語言自己就是對數學的一種抽象，抽象的好壞直接影響到使用效率，而解釋器用什麼方法實現完全是另一回事。

而且也不想想為什麼那些精通（？）了C、C++的人要去寫JVM、PVM，不就是因為希望有一個更順手的編程語言嗎。

還有，要寫出JVM來，不光需要懂語言，還需要對編譯原理、數據結構與演算法等知識有很深入的理解，這跟用什麼語言基本無關。

C語言是對彙編語言的封裝

彙編語言是對機器語言的封裝

而機器語言運行在硬體之上

硬體由二極體等基本元器件組成

二極體的主要原材料是硅

硅這種單質由硅原子組成

原子由原子核(質子+中子)和電子組成

綜上所述，建議你同學去學習質子、中子和電子這些知識，這才是真正的底層，這才是宇宙的真知。把質子、中子和電子研究透了，就掌握了宇宙的真理，那個時候就可以涅槃了。

我想到一句話，雖然有點跑題：

&> 任何 C 或 Fortran 程序複雜到一定程度之後，都會包含一個臨時開發的、不合規範的、充滿錯誤的、運行速度很慢的、只有一半功能的 Common Lisp 實現。

https://zh.m.wikipedia.org/wiki/%E6%A0%BC%E6%9E%97%E6%96%AF%E6%BD%98%E7%AC%AC%E5%8D%81%E5%AE%9A%E5%BE%8B

真正能用C語言寫JVM的人，已經對編譯原理融會貫通，什麼語言對他來說都沒本質區別。你以為他用JAVA寫不出一個C編譯器？

打個簡單的比方就像開車手動擋和自動擋。

就算會證明了微積分，也不代表你是牛頓萊布尼茨，重複前人的勞動，不僅證明不了你牛逼，反而容易證明你比較沒有眼光，因為你不是向前走，而是往後看

歷史發展到今天，不再需要重複前人的發明創造了，就像牛頓發明了微積分，你再發明一次就成牛頓了？不會的，人家只會嘲笑你欺世盜名，而且用的是這麼low的手段，讓人一眼就看穿了

不過最近感覺c和c++都下降得很快，流行程度上

英文小說是由26個字母寫成的，把26個字母寫的再熟，能寫出英文小說來嗎。

苟富貴勿相忘

不要和他爭

我會寫0和1耶，我是不是要得圖靈獎了？

無需反駁，他們是對的。

只要向精通勢力低頭就好了。

關鍵是什麼叫「學精了」？

幹嘛要反駁呢，多無聊

不必反駁，因為這麼說的人，有一部分可能本身就缺乏認同感。你再一反駁。他就更惱羞成怒了。他這麼說可能只是簡單的讓你讚美他一下而已。就像我們在知乎寫答案一樣，為了被點贊。

真要反駁的話。可以這麼說嘛。。

暖心流：

你精通了c確實蠻厲害的。很多高級語言什麼的也確實是用c寫的。不過如果每次解決問題都要用c重複造輪子的話，你可能身體受不鳥啊。會很累的，多讓人心疼，別人既然都有造好的輪子。你就直接用唄。節約的時間，我們去擼串喝酒好不好？我覺著你人很有范，和你在一起很開心的哈。然後，你就多了一個基友哈哈。。

技術流：

咱們編程的都知道一句話，編程思想要比語言語法本身重要的多。那麼什麼是編程思想呢？既然是思想，一個尤為重要的問題可能就是我們為什麼要編程？當然是為了更高效解決現實中的問題嘛。很顯然學習編程不是為了證明自己很牛逼。因為證明自己很牛逼的方法很多。

具體到這個問題上，其實也是一種解決問題的思想問題。比如我們只要解一個二元一次方程，那麼我們根本不需要發明一個二元一次方程的一般公式。直接算就行了。同樣的，如果我們編程的世界裡，如果只有一個需求，那麼用c去實現它就行了。但是如果我們有千千萬萬個類似的問題呢？當然是找出這些問題的一般解（公式，更高級的語言等），更高效一些。

1. JVM 和DVM 都不是C 的封裝。

2. 語言並不決定成品功能性上的上下限。

3. 在各種實現自舉後的語言說成自己是自己的封裝在語義上是循環引用，邏輯矛盾。錯誤是出自「封裝」的定義和這個語境不乎。

要麼是他不懂自舉要麼就是他不舉

精通C啊，來來來，要不我粘幾行我們組的Linux VFS的代碼你看看