王垠:編輯器與IDE

發表於2013-05-20

來源:王垠的部落格

無謂的編輯器戰爭

很多人都喜歡爭論哪個編輯器是最好的。其中最大的爭論莫過於 Emacs 與 vi 之爭。vi 的支持者喜歡說:“看 vi 打起字來多快,手指完全不離鍵盤,連方向鍵都可以不用。”Emacs 的支持者往往對此不屑一顧,說:“打字再快又有什麼用。我在 Emacs 裡面按一個鍵,等於你在 vi 裡面按幾十個鍵。”

其實還有另外一幫人,這些人喜歡說:“對於 Emacs 與 vi 之爭,我的答案是 {jEdit, Geany, TextMate, Sublime…}”這些人厭倦了 Emacs 的無休止的配置和 bug,也厭倦了 vi 的盲目求快和麻煩的模式切換,所以他們選擇了另外的更加簡單的解決方案。

臨時解決方案 – IDE

那麼我對此的答案是什麼呢?在目前的情況下,我對程式編輯的臨時答案是:IDE。

寫程式的時候,我通常根據語言來選擇最能“理解”那種語言的“IDE”(比如 Visual Studio, Eclipse, IntelliJ IDEA 等),而不是一種通用的“文字編輯器”(比如 Emacs, vi, jEdit, …)。這是因為“文字編輯器”這種東西一般都不真正的理解程式語言。很多 Emacs 和 vi 的使用者以為用 etags 和 ctags 這樣的工具就能讓他們“跳轉到定義”,然而這些 tags 工具其實只是對程式的“文字”做一些愚蠢的正規表示式匹配。它們根本沒有對程式進行 parse,所以其實只是在進行一些“瞎猜”。簡單的函式定義它們也許能猜對位置,但是對於有重名的定義,或者區域性變數的時候,它們就力不從心了。

很多人對 IDE 有偏見,因為他們認為這些工具讓程式設計變得“傻瓜化”了,他們覺得寫程式就是應該“困難”,所以他們眼看著免費的 IDE 也不試一下。有些人寫 Java 都用 Emacs 或者 vi,而不是 Eclipse 或者 IntelliJ。可是這些人錯了。他們沒有意識到 IDE 裡面其實蘊含了比普通文字編輯器高階很多的技術。這些 IDE 會對程式文字進行真正的 parse,之後才開始分析裡面的結構。它們的“跳轉到定義”一般都是很精確的跳轉,而不是像文字編輯器那樣瞎猜。

這種針對程式語言的操作可以大大提高人們的思維效率,它讓程式設計師的頭腦從瑣碎的細節裡面解脫出來,所以他們能夠更加專注於程式本身的語義和演算法,這樣他們能寫出更加優美和可靠的程式。這就是我用 Eclipse 寫 Java 程式的時候相對於 Emacs 的感覺。我感覺到自己的“心靈之眼”能夠“看見”程式背後所表現的“模型”,而不只是看到程式的文字和細節。所以,我經常發現自己的頭腦裡面能夠同時看到整個程式,而不只是它的一部分。我的程式碼比很多人的都要短很多也很有很大部分是這個原因,因為我使用的工具可以讓我在相同的時間之內,對程式碼進行比別人多很多次的結構轉換,所以我往往能夠把程式變成其他人想象不到的樣子。

對於 Lisp 和 Scheme,Emacs 可以算是一個 IDE。Emacs 對於 lisp 當然是最友好的了,它的 Slime 模式用來編輯 Common Lisp 也相當不錯。然而對於任何其它語言,Emacs 基本上都是門外漢。我大部分時間在 Emacs 裡面是在寫一些超級短小的 Scheme 程式碼,我有自己的一個簡單的配置方案。雖然談不上是 IDE,Emacs 編輯 Scheme 確實比其它編輯器方便。R. Kent Dybvig 寫 Chez Scheme 居然用的是 vi,但是我並不覺得他的程式設計效率比我高。我的程式碼很多時候比他的還要乾淨利落,一部分原因就是因為我使用的 ParEdit mode 能讓我非常高效的轉換程式碼的“形狀”。

當要寫 Java 的時候,我一般都用 Eclipse。最近寫 C++ 比較多,C++ 的最好的 IDE 當然是 Visual Studio。可惜的是 VS 沒有 Linux 的版本,所以就拿 Eclipse 湊合用著,感覺還比較順手。個別情況 Eclipse “跳轉定義”到一些完全不相關的地方,對於 C++ 的 refactor 實現也很差,除了最簡單的一些情況(比如區域性變數重新命名),其它時候幾乎完全不可用。當然 Eclipse 遇到的這些困難,其實都來自於 C++ 語言本身的糟糕設計。

終極解決方案 – 結構化編輯器

想要設計一個 IDE,可以支援所有的程式語言,這貌似一個不大可能的事情,但是其實沒有那麼難。有一種叫做“結構化編輯器”的東西,我覺得它可能就是未來程式設計的終極解決方案。

跟普通的 IDE 不同,這種編輯器可以讓你直接編輯程式的 AST 結構,而不是停留於文字。每一個介面上的“操作”,對應的是一個對 AST 結構的轉換,而不是對文字字元的“編輯”。這種 AST 的變化,隨之引起螢幕上顯示的變化,就像是變化後的 AST 被“pretty print”出來一樣。這些編輯器能夠直接把程式語言儲存為結構化的資料(比如 S表示式,XML 或者 JSON),到時候直接通過對 S表示式,XML 或者 JSON 的簡單的“解碼”,而不需要針對不同的程式語言進行不同的 parse。這樣的編輯器,可以很容易的擴充套件到任何語言,並且提供很多人都想象不到的強大功能。這對於程式設計工具來說將是一個革命性的變化。

  • 已經有人設計了這樣一種編輯器的模型,並且設計的相當不錯。你可以參考一下這個結構化編輯器,它包含一些 Visual Studio 和 Eclipse 都沒有的強大功能,卻比它們兩者都要更加容易實現。你可以在這個網頁上下載這個編輯器模型來試用一下。
  • 我之前推薦過的 TeXmacs 其實在本質上就是一個“超豪華”的結構化編輯器。你可能不知道,TeXmacs 不但能排版出 TeX 的效果,而且能夠執行 Scheme 程式碼。
  • IntelliJ IDEA 的製造者 JetBrains 做了一個結構化編輯系統,叫做 MPS。它是開源軟體,並且可以免費下載。
  • 另外,Microsoft Word 的創造者 Charles Simonyi 開了一家叫做 Intentional Software 的公司,也做類似的軟體。

相關文章