編譯器是否有自我託管的實際原因？

Question

如果您的引導程序語言中的編譯器工作正常並且可維護，爲什麼要更改它？例如，Go的編譯器重寫爲1.5版本中的自承載，導致了compile times to become much slower：當Go的目標是快速編譯時，這顯然是不利的。

Answer 1

一個實際原因是社區。用你的語言編程的人可能更喜歡在編譯器中編程，如果它用相同的語言編寫的話。如果我的編譯器位於Fortran/COBOL中，並且它生成Go我不太可能吸引Go開發人員加入編譯器。

另一個是構建鏈，即依賴項。如果你用一種語言編寫編譯器併產生另一種語言，那麼當你可以解決這個問題時，你有兩組測試。這也會導致減少進入門檻，即你不需要開發人員去了解多個工具鏈等。瞭解兩種語言的能力足以成爲一名有能力的編譯器作家，都是艱苦的工作，並縮小了潛在的受衆羣體的幫助範圍。 獲得幫助對於大多數開源項目來說非常重要，任何能夠增加潛在開發人員基礎的東西都具有確定的實際優勢。

您還可以列出測試作爲附加好處。如果你已經編寫了一個自己託管的編譯器，那麼這個語言需要很多東西來使自己的主機（比如文件IO，字符串操作，符號表，樹和列表）變得相對容易（而不是拉扯牙齒）。顯然，你可以在沒有所有這些的情況下生存下來，但它開始使編寫器變得更加困難。這種坐在吃你自己的狗食營。

它被認爲是Rite of Passage但我不認爲這是一個非常實際的理由，除非你能證明它吸引了開發者或其他理由去做，也許對成就感覺良好是一個實際的好處，即你是不太可能放棄它。

有在這裏一個有趣的話題......

https://softwareengineering.stackexchange.com/questions/263651/why-are-self-hosting-compilers-considered-a-rite-of-passage-for-new-languages

對於一些具體原因有羅布派克的讀幻燈片爲什麼他們搬到轉到編譯器Go instead of C。幻燈片中的結論是：

1. 擺脫C是項目的一大進步。
2. 代碼更清潔，可測試，更好，更容易處理。
3. 新的統一工具鏈可以減少代碼大小，提高可維護性。靈活的工具鏈，便攜性仍然至關重要。

根據不同的語言，您從不同的語言中獲益。