為什麼這麼多人喜歡寫編譯器?

01-12

我主要是為了實踐各種想法，譬如說

實現動態語言（Vczh Free Script）
實現以假亂真的自然語言編程（GitHub - vczh/tinymoe: English-like dynamic typing programming language 而不是易語言那樣一看就只是Basic翻譯成中文）
實現concept mapping（Vczh Library++ 3.0之NativeX語言泛型最終稿）
實現類型推導（腳本技術 - λ-calculus（驚愕到手了歐耶，GetBlogPostIds.aspx））
實現智能提示（開發自己的IDE（十），我終於搞定了智能提示了哇哈哈，寫程序真他媽爽啊）
實現編譯到機器碼（JIT - λ-calculus（驚愕到手了歐耶，GetBlogPostIds.aspx））

各種東西。

現在還有

（100%、完全的）type as a value 還沒做出來
圖資料庫也還沒做出來（github上有個herodb，結果因為我在設計上犯了致命錯誤，已經不開發了，打算重寫，當然那個repo會重用）
從骨子裡分散式的語言（大概就像madlinq的完全版，而不只是一個steamming的框架）也沒做出來

很多技術最終都會合併到GacUI裡面，譬如我的專門針對詞法分析優化過的正則表達式引擎，自帶歧義合併和錯誤恢復的GLR語法分析程序，支持上下文有關代碼著色和智能提示的文本框，這些都已經在裡面了。後面還要挑戰同一份代碼不同的部分使用不同的parser和類型推到程序的智能提示（就像http://ASP.NET MVC的razor模板編輯器那樣，但是我是用來編輯GacUI的XML資源文件的）。

這些也都很難做。在我還得繼續發展GacUI的前提下，估計又可以搞很久了。都指望這些消磨時間了。

如果按產品代碼的要求來看大家的代碼的話，有多少人的代碼大部分不是玩具？一個產品級的實現一個類動不動就上千行。照這個標準看，上學時寫過的80%的代碼其實都是屎。難道因為自己寫的東西都是屎造的輪子都是方的寫完毫無意義，就不寫東西啦？肯定是因為知道自己菜，才要不斷的寫東西啊。明明菜，又不思進取才是最可怕的啊。

當然，各種輪子的實現水平肯定是有高低之分，玩具輪子之間也是有區別的。我也很討厭那些寫了個最簡單的玩具編譯器就到處出來裝逼以為自己很厲害的傢伙，更討厭那些連玩具都沒寫就開始到處貶低別人的傢伙。後來我也發現了，這應該是一個普遍現象。總有很多人以為，後學的東西就比以前學的高級，稀罕的東西就比常見的東西高級。經常能遇到些傢伙，學了點設計模式就到處亂用，到處亂搞，還以為自己寫的東西很高級。同理，因為編譯器不是很常見，總有人寫了個簡單的玩具就到處炫耀。其實是因為寫的東西還不夠多，見過的東西還是太少。

哈哈看到 @李小牧更新的問題描述，感覺應該是針對我之前在他的一個回答下的評論而說的，來稍微說點。

那個評論好像是在這個問題下的：為什麼業內用.net的公司這麼少？ - .NET

（不過您似乎已經刪掉了那個回答…沒辦法在那個回答里直接說了）

您更新的問題描述：

知乎上的人寫的編譯器和GCC有什麼差距，大神為啥不去給gcc提交代碼給開源世界做貢獻而是來這裡裝。

真的非常抱歉。我那個評論實在不是針對您個人，只是您那個回答里有些關於CLR GC與JVM GC的不正確的理解，被別人在評論里點名了就說了兩句而已。還望海量包涵。

我不覺得自己是大神，也不希望給人留下「跳大神」的印象——我離大神什麼的還遠著呢。

我選擇去哪裡工作的目標，一來是要能做有趣的工作，二來就是公司里要能有大神可以讓我拜師學習。幸運的是，現在工作的地方這兩個條件都滿足了。

我目前的主要工作是給HotSpot VM的研發。在淘寶和Oracle做的工作都開源了。在Azul做的工作也有一些反饋到了OpenJDK里。

這個VM里的JIT編譯器當然不能跟GCC相提並論，設計目的、優化程度都大有不同。不過它也算是被廣泛使用的一個項目，而且我不在知乎上冒泡的時候醒著的時間大部分都在做跟它相關的工作。雖然看起來我好像在知乎上泡了很多時間，實際上許多都是在等編譯或者等測試的空隙時間…

另外我也有給V8、JRuby、Nashorn之類的貢獻過少量代碼。接下來應該也會逐步增加參與到LLVM相關的研發中。嗯最後一個總算是跟GCC在一個級別上的了。

為啥不給GCC提交代碼呢？因為愛不足啊。

GCC的「遺留問題」太多，代碼讀起來諸多不爽，已經實現的功能是在那裡杠杠的，但是要修改或者加東西就（相對來說）不那麼方便了。

不過為了知己知彼，GCC的資料和代碼我還是深入學習過的。留作備用，以便跟主攻GCC的大神交流時能搭上話而不會尷尬。

我參與平時維護的HotSpot VM的Server Compiler (C2)確實是個很簡單的編譯器，以至於我可以相當準確的預測它生成的代碼的樣子。高級語言寫代碼時就能夠想到對應的彙編代碼是怎樣一種體驗？ - RednaxelaFX 的回答

如果是更為優化的編譯器，這種事情就做不到那麼高的精度了，例如說我們新的基於LLVM的編譯器生成的代碼就經常在細節上出乎我的意料。

至於我為什麼喜歡寫編譯器，那是因為我喜歡推黃油啊！

請跳傳送門：你對自己玩的遊戲研究到了什麼程度？ - RednaxelaFX 的回答

另外就是，在學校的時候學了不少編程語言，但實在想不出來用它們寫些什麼好。研究它們研究得越深，就越覺得似乎用它們來寫寫編譯器是件能讓我持續感興趣的好玩的事。所以劍走偏鋒掉進了坑了：學習編程語言最好的方法是什麼？ - RednaxelaFX 的回答

其實我多羨慕熱愛用編程語言寫面向用戶的應用程序的人。他們才是找到了許多編程語言的正確用處。

而且因為擁有共同愛好的人比較少，在一個小圈子裡可以認識到不少能知心相交的朋友，這點我也是推動我前進的力量。

在知乎回答JVM、JavaScript引擎、編譯器以及其它編程語言相關的問題，其實最大的私心就是想在這小小的圈子裡多交些志同道合的朋友；另外也想傳播儘可能正確的知識，降低學習門檻，來多少擴大一點這個小圈子。

很高興的是在知乎上確實認識了好幾位很厲害的高手，能跟他們有所交流真是物有所值 ^_^

Cheers.

因為寫遊戲要資源

寫伺服器看不見

編譯器無需任何依賴, 難度還夠一直啃下去

還不斷的可以show出很多有意思的東西

你說為啥不寫?

垃圾回答，刪除

每一個程序員都或多或少有點編譯器情懷，是天然的好奇，就像人類都好奇宇宙之外是什麼一樣。

曾經也付諸實踐過一次。不過只是解釋器，並沒有觸及到編譯環節。不過那次純粹是為了自己方便。

大二時候同時在搞數學建模，和一個圖像分析的項目。經常需要做各種實驗，各種測公式的效果。工具就基本上是Matlab和 C++ 配合OpenCV庫，當時學校的各種上機實踐課佔用了大量的時間。

都是去機房，不能帶自己電腦。一開始我都吧matlab和visua studio這些放到硬碟里拷著過去，等安裝配置完都尼瑪下課了，而且電腦每天都自動格式化 (╯‵□′)╯︵┻━┻。

我就在想有沒輕量級的方案，當時正好在上編譯原理。發現實現基本的詞法分析+遞歸下降的思想，做一個解釋器並不難。我就嘗試先用C++實現了一個C語言的子集的解釋器。支持if for 還有函數func，變數聲明這些基本元素。

然後根據對func的支持，在底層用opencv實現了一整套矩陣運算和基本圖像處理的api，供我的tiny C 語言調用，並且擴充了複雜變數（矩陣，圖像）的支持。

實現了兩種工作模式，一種命令行模式，每次換行就解釋一次結果，一種是正常的代碼模式，可以寫一堆代碼，然後點運行再開始執行。我給取了個名字，叫MiniLab。

於是每次上機課，我只需要拷貝minilab的exe以及opencv的幾個dll 到機房電腦就能用了……從此我在機房也可以愉快的開小差了……實現簡單的演算法毫無鴨梨。不過密集的循環操作基本都得跪。（這塊兒沒優化過）

-----------

後來的後來，編譯原理大作業是做個計算器，我把mini lab交給老師問他這個行不……他看了一下說，這個不錯，考試可以給你加十分（這目測是我整個大二最爽的時刻）

Compiler的工作是cs領域裡在enginnering方面最複雜也最有發揮空間的，相對於os這種主要是coding量大的的東西，compiler在frontend parsing的時候可以靈活設計各種數據結構和演算法來處理，在backend optimizing的時候又會用到其他領域包括os都很少用到的graph等東西，可以說是engineering最有挑戰性的領域（而且不像distributed computing那樣要很多機器大部分時間花在機器配置和同步等無聊事情上，可以專註於一個一個演算法問題解決）。

國內本科現在怎麼樣我不清楚，但是從學生和師資水平可以判斷大部分能寫個簡單parser就到頭了，可能大多還談不上稍微複雜的語義分析和數據結構以及backend optimization, 所以對compiler有點神話（我感覺的，也許不對）。相對來說，我在美國上學的學校雖然很一般，但是compiler課也是完成一個包括支持function/struct和所有c支持的data type以及部分bakckend optimization後直到生成mips asm code的完整mini c compiler. 一個完整的mini comoiler的實現能讓人充分認識到其難度和挑戰，但不至於過度神話。

分兩種情況：

1 寫現有語言的編譯器，或許是為了作業，或許是為了鍛煉自己，或許真的因為現有編譯器的一些缺陷

2 設計自己的語言，只能自己寫了，這樣問題就是，為啥要設計新語言，原因一般就是對老語言不爽嘛

我就日了狗了。

輪子哥有時候回答技術問題，有時候瞎逛。他回答技術問題的時候你們質疑他的能力，他瞎逛的時候你們跟著「輪帶逛」個沒完，你們想把輪子哥引向什麼方向？

往大點說，大V討論正經問題你在那裡吹毛求疵，大V發圖片寫煽情長文你們再去瘋狂點贊去給別人打錢，你們想把知乎引向什麼方向？

你質疑輪子哥就算了，拿出點東西來對著掐啊。你要是覺得輪子哥寫個項目A它難度很低，你寫個水平更高的項目B啊。哦，不行，這問題是在問「為什麼這麼多人喜歡寫編譯器」，所以提問的其實都沒寫過……難怪這裡都是些眼高手低的傢伙在對著輪子哥指指點點，因為自己其實啥都不會啊，我都看不下去了。

輪子哥自己原話很清楚，貼這些自己做過的事情不是為了說自己多牛逼，而是為了說明「自己是為了實踐想法」（換句話說，滿足自己一些業餘開發的需求）而造輪子。在這個問題下，你想反駁，你可以去討論「實踐你的想法到底需不需要寫編譯器」。但是你們選擇了質疑「這個編譯器是不是只是大作業水平」和「這個編譯器既然帶個C# binding，而且編譯出來的代碼也是C#代碼，是不是不配稱作編譯器」，我真不知道說什麼好。

另外，就算你吊打輪子哥了，你意識到你在吊打的是一個微軟員工在他的業餘時間裡出於興趣而造的輪子了嗎？別精神勝利了好不好？

滿足自己當造物主的慾望

另外，強力推薦你們實現 KFFD

因為當前有一種迷信，即「儘可能多地把設計模式/範式轉移到語言的運行時可以產生最清爽、最完美的客戶代碼」

我七年前就給GCC提交代碼了，至今不會寫編譯器，最多就用過peg.js組裝過一個編譯器，還是純標記語言編譯的那種，很簡單的。

修改一個巨大無比的機器，和從頭造一個精巧的小機器，需要的知識是不一樣的。

當然，我相信絕大部分自己寫的編譯器，雖然很小，但精巧程度完全比不上GCC。絕大部分情況下他們存在的意義就僅剩支持的語言了。

就突然想了…

然後開心地翹課不吃不喝不睡覺…

然而問我原因好像真答不上來。

應用領域不同啊。︿(￣︶￣)︿

這周剛寫完了一個……算是interpreter吧，因為backend是把IR轉到了我們自己定義的一個語言裡面，而不是機器語言。（卧槽定義好混亂，被嘴炮同事說的頭都大了，管他呢）

我所在的formal verification領域裡，一項重要的工作是對系統建模。建模過程中經常會需要自己定義語言或者使用工具提供的語言。同時對於很多應用，精確建模是很關鍵的，就是不可以對待驗證的系統進行抽象，需要高度一致的去描述待驗證的系統。最好是一行一行代碼直接對應，這樣才能check出來實踐中有沒有問題，以及是哪裡出了問題。

於是乎我們的代碼轉換工作開始了……

特別是lex和yacc……其實主要是github的強大，下載個類似的程序基本上改一改IR就可以開工幹活兒了……特么追憶我苦逼第一年人肉代碼轉換器的生活。

現在的感覺是，基本上你要寫個tool，涉及到對程序作分析處理和驗證的，編譯器是個繞不開的話題。同時在細分領域，很多低調的實驗室默默寫了牛掰但不好上手的tool或者有針對性的小眾語言，為了填上這些semantic之間的gap，各種語言之間的轉換被越來越頻繁的用到。

我擅自闖入，強答一下。

我剛寫了個有很多BUG的C編譯器，前端自創的，後端用的LLVM，感覺挺有意思。我用C語言很多年了，大學第一門編程語言是 C，工作後也主要是用 C 語言。這次做編譯器的經歷，讓我發現 C 的更多特性和語法規則，對 C 語言的理解更加完備。

再吐槽一下 C11，作為標準，我覺得它應該更規範一些。

你看，寫完一個編譯器，我都能吐槽標準了。

當然應該寫編譯器啊。

學計算機的不寫編譯器難道寫手機App啊？那不是學生物的人寫的嘛（逃

Parser組合子——從玩具到專業工具

因為好奇心。

另外，這個問題的編輯記錄真的很惡意。

因為相比於圖形學和操作系統，編譯器在學習的過程中可以有持續產出，學習曲線也比較平滑。

編譯原理課要實踐啊