可以想見，其它語言只要遵循適當的規範，一樣可以達到 Interactive programming / Live coding，而我認為這方面的先行者是 swank-js (2010) 以及 Christopher Wellons 的 skewer (2012)，使用的語言是 javascript。 其中 swank-js 的影片相當令人印象深刻，但是 skewer 是較多人使用的，到 2018 年仍有維護。其它如 Bret Victor 的演示 (演示2 )，相信也是使用類似的技巧。
記憶所及，2010-2014開始，python 也出現了其互動環境 ipython 的較多討論，及後來的 jupyter 。這兩個環境的糾葛，這篇 IPython Or Jupyter? 寫得很好。如果使用過 jupyter notebook 的話，相信你也能輕易感受到，它其實已經具有 Live coding 的架構，而且只要遵循一些規範，一樣可以達成 reloadable 的要求。另外也有社群寫出 ijavascript 來使用 jupyter 的現成工作流程。而 javascript 由於可以直接使用 browser 內現成的 kernel / REPL ，因此可以在不安裝任何工具的情況下執行，而造就了一些 repl.it 與 codesandbox 等線上 IDE 的興起。clojure 社群也開發出了基於 jupyter 的 clojupyter 及自幹的 gorilla-repl ，這也更加使得 vim / emacs 加速式微，最後我們再來討論。
Live coding 的價值，主要是體現在需要大量使用者互動或人機介面的程式上。由於使用者的互動會改變程式中諸多變數，這些變動在程式重載後若被重寫，表示使用者/測試者必需重新輸入一次，這樣會使得整個撰寫、修改程式的循環時間拉長，讓人一不小心就失神(mind flow)，降低工作效率。一個解決方案是預先寫好測試程式，這某種程度上就是 Test Driven Development (TDD) 的議題。Live coding 是另一種精神的表現，它更自由，不需要事先寫測試，自由發揮的空間更大，但這不見得是當前高度機構化的開發流程所要的。我認為可以這樣說，TDD解決的是程式邏輯的部分，這部分可以經由適當的工作分解，將開發時程平行化，故為產業界所習用；Live coding 較多用在視覺設計(如電玩)，需要即時得到視覺迴饋，無法以事先撰寫的測試程式來評估效果。事實上這個做法非常的炫目，連 Unity 之類的工具都得在停止 rendering 的狀態上變動模型，我相信 Bruce Hauman 的技法也能在 WebGL / WebVR 上得到很好的應用。
最後提一下 emacs 的角色，因為當 browser 都可以拿來寫程式的時候，emacs 的 niche 是更被限縮了。而 browser 拿來寫文件早就不是新聞了，可以想見最後一根稻草會使整個 vim / emacs 的按鍵式操作被 browser 整碗捧去的時候。短期內或許還不用太擔心，因為這還涉及到程式的 focus 的處理部分，現在仍有障礙。但是未來如果再有一波自然語言對話的革命，加上 vr/ar/mr 的引入，寫程式或許就只要說說話、在空中拉拉積木就解決了，到時 vim/emacs 就真的成了時代的眼淚了。vim/emacs 最後一線的優勢就是現存的大量 legacy code ，在對 emacs 本身進行客製化時，有大量的程式碼可參考，儘管這意味著必需要學習一個看來有點奇怪的 lisp。這類工具的偏好問題，永遠夾雜著各種技術之間的競逐、互相領先和落後，不會有一個永遠的王者。但是以一個在視窗系統上存在將近30年的工具而言，emacs 真的是一代拳王無誤。
沒有留言:
張貼留言