只改變IDE是不夠的

互聯網上各種 IDE 新創意不絕于耳，感興趣的朋友可以看看 Bret Victor 的 視頻演示。Chris Granger 在推介 自己 IDE 的相關概念方面相當成功。Josh Marinacci 探討了IDE 改進的一些可能性。（譯注：還有一篇相關文章： 即時C#）我在 IDE 開發領域已經工作了十幾個年頭，對于這些聲音我的感情非常復雜。一方面，為人們展示 IDE 可能提供的新功能并將他們從麻木中喚醒是一件好事。然而另一方面，我也擔心人們會把這些新創意和新功能應用到現有的編程語言上。我不認為“只要給 Java 或 JavaScript 加上一個完美的 IDE 世界就變得更加美好”，我擔心這樣只會帶來失望和悲觀。

代碼同步執行是一個具有啟發性的功能：用實際執行結果作為代碼的注釋，在編輯代碼的同時可以看到語義變化，連調試代碼都不需要了！過去 30 年間，這個超酷的功能被人不斷提起。長久以來，代碼同步執行功能始終沒能擺脫演示階段（包括我自己的工作），很多棘手的基本問題尚未解決。可變狀態要怎么處理？（參考 Circa）I/O 要怎么處理？非確定性和異步要怎么處理？只有階乘函數或之類的代碼可以同步執行，那么這個功能便無法應用到實際編程工作中。一般說來，你還是需要編輯無效代碼并利用傳統的調試器來檢查代碼的執行情況。所以，一個復雜的 IDE 已經提供了你所需要的所有功能。為什么還要畫蛇添足呢？

很多花哨的代碼可視化方案同樣因為折衷而被否決。數以百計研究查詢和可視化代碼的論文被發表。對于精心挑選的示例代碼，它們都表現出色，但還是不能很好地應對現實的代碼。那么，為什么還要設計用途有限卻如此復雜的功能呢？要實現通用的代碼可視化非常難，在不允許修改語言本身以提供幫助的時候時尤其如此。

IDE 最根本的問題在于，它們受制于編程語言的語法和語義。我們的編程語言都是為文本編輯器設計的，也就難怪我們的 IDE 看上去像是濃妝艷抹的寫字板。同樣的，我們的編程語言都被設計成命令式語義，盡管與硬件配合很高效但卻不支持靜態可視化。如果為舊語言直接設計一個全新的 IDE 就可以魔術般地改變語法和語義，這就是一種奇跡。然而我不相信奇跡會發生。

（譯者注：命令式語義：命令式編程語言，例如C#，Java 或C++。語言特征在于，代碼除了體現出想要解決的問題，還要關心機器是如何處理的，例如會在代碼里寫 for 循環，if 語句等等。）

語言和 IDE 彼此息息相關，牽一發而動全身。這也就是我 3 年前開始擱置 IDE 的工作轉而關注語言設計的原因。擺脫命令式語義的束縛是工作的目標之一。另一個目標是去除源代碼文件（同樣也需要擺脫 AST——抽象語法樹，它承載了所有文本編碼信息但不具備可讀性）。這項工作極其困難而且孤獨，甚至沒有人愿意談論這些瘋狂的想法。盡管如此，我始終堅信只要采用匯編語言的后代編程，就不可能擺脫由文本編輯器發展出來的開發工具。

英文原文： Jonathan Edwards  編譯：伯樂在線 – 唐尤華