Realtalk and visual end-user programming

最近看了 Bret Victor 在今年四月底發表的 Communal computing for 21st-century science 這篇報告，內容在介紹他主導的人機互動研究專案 Dynamicland 如何發明新的人機系統來幫助科學家更好地運用計算機做科學研究。這個系統的名字叫 Realtalk，是在致敬 Alan Kay 在 1970 年代打造的 Smalltalk 系統（最早的物件導向程式語言之一）。

這篇報告描述了許多非常有潛力的人機互動想法，例如將 Computing 變成一種溝通和討論科學的語言、將 Computing 變成空間中看得到摸得著的物件、讓每個人都可以自行添加或改動空間中的 Computatinal Object 來完成意圖等等。

在這些想法中，我最感興趣的一直是如何結合人類擅長的視覺能力與計算機擅長的運算能力來研究和理解複雜系統，而 Realtalk 最讓我興奮的地方在於它創造了一種新的 Programming 範式來解決這個問題。雖然我在 2019-20 年就已花了不少時間在研究 Realtalk 的運作原理，但是實際看到 Bret 將他的願景和 Realtalk 的設計哲學清楚且完整地表達出來，著實又讓我被震撼了一次。

關於 Realtalk 的設計哲學，Bret 在他的報告和演講中已經講得相當清楚了，我會在文末附上一些我覺得值得看的文獻和影片。在這篇文章中，我並不打算去談 Realtalk 的 Communal & Physical Computing 層面，而是會把視角聚焦在它的 Programming System 上。我會以軟體從業者的角度去分享我覺得 Realtalk 對我啟發最大的部分 — 我暫且稱之為 Visual end-user Programming — 以及它可以如何讓我們重新思考軟體和 Programming 的本質。

Software & Interface

由於現代軟體的主流範式鼓勵開發者打造可以相互引用的模組化程式碼，因此對於不熟悉 Dynamicland 的人來說，可能會以為我上面講的 Visual Programming 是指將程式碼之間相互引用的關係視覺化。但其實並非如此。

如果要理解 Realtalk 的 Visual Programming 的設計哲學，我們必須先跳脫我們習慣的軟體範式，重新思考：軟體的用途是什麼？介面的用途是什麼？軟體、介面、Programming 之間的關係又是什麼？只有從這些根本性的問題出發，我們才能看到 Realtalk 的 Visual Programming 與傳統軟體開發的關鍵差異。

針對「軟體的用途是什麼」，Bret 在 2006 年寫了一本標題為 Magic Ink: Information Software and The Graphical Interface 的電子書，指出人類使用軟體的三大用途是學習、創造、溝通，而它們對應到的三種軟體類別分別是 Information Software、Manipulation Software 和 Communication Software。

這本書指出，我們在大多數時候使用的軟體都屬於 Information Software，不論是科學家用軟體模擬生化反應、創業者用軟體研究產品數據、工程師用軟體檢視後端負載狀態、普通人用軟體查詢食譜、關注時事、對商品進行比價，這些使用軟體的目的都是為了更新自己對某件事物的認知。所以我們在設計 Information Software 時，不應該以提供各式各樣的互動或按鈕為目的，而是應該以理解用戶所處的問題脈絡、並在該脈絡下幫助用戶更有效地更新認知為目的。

針對「介面的用途是什麼」，Bret 在這次發表的報告中將介面定義成「無形概念的物理型態」（Physical form to invisible concepts）。在這樣的定義下，介面的用途是幫助我們將無形概念具象化，而我們可以透過這些具象化的概念來學習並更新我們對一個系統的認知。我認為這個定義很好地呼應了 Bret 在 Magic Ink 一書中所描述的 Information Software 的「更新認知」的用途。用這個定義去看我們日常使用的軟體，便可以發現所有的軟體介面其實本質上都在做二件事情：將與某個系統相關的無形資料用符合人類思維的方式呈現給用戶（呈現系統狀態）、讓用戶有辦法透過這個介面來操控這些無形的資料（改變系統狀態）。

Distributed Computing & Reactive Programming

在理解 Bret 對軟體和介面的用途的觀點後，我們就可以比較好地理解 Realtalk 系統的特殊之處了。在 Realtalk 裡頭，軟體是由實體空間中的 Computational Objects 組合而成的，每一個 Object 都既是程式，也可以是介面。這些 Objects 會在空間中按照它們內嵌的程式邏輯去交換和處理資料，進而決定它們要怎麼影響這個空間渲染出來的圖像。換句話說，Realtalk 本質上是一個 Distributed Computing System。

關於這些 Objects 如何彼此溝通，可以參考 Dynamicland 的研究員 Omar Rizwan 所寫的 Notes from Dynamicland: programming Raspberry Pis。簡言之，Objects 之間並不是以 Variable 和 Function Call 溝通，而是以 Statement 溝通。所有的 Objects 都可以對這個系統發表 Statement，也可以讀取這個系統當前的 Statements 來更新自己在空間中渲染的內容。舉例來說：

• Object A 可以 Claim 自己是一張地圖，並提供地圖四個角的經緯度值作為內嵌參數。
• Object B 可以用 When 和 Wish 的語法做全局的條件判斷：（When）系統中有 Object Claim 自己是地圖時，（Wish）把這個 Object 的經緯度參數送到 openstreetmap 索取圖片資料，再將索取到的圖片投射到這個 Object 上。
• Object C 可以用 When 和 Wish 的語法做空間的條件判斷：（When）自己上方有 Object 時，（Wish）改變上方的 Object 的背景顏色為藍色。

在這個例子中，假設 Object A 放在 Object C 上方，Object A 的背景色就會變成藍色。此時如果我們把 Object B 也添加到這個空間中，Object A 就會在自己身上渲染出對應經緯度的地圖。

雖然這個例子非常簡化，但基本上已包含 Realtalk 最重要的精神，也就是透過 Claim、When、Wish 等語法來創建 Statement，再讓空間中的所有 Objects 對 Statement 做出反應，跟 Reactive Programming 的原理非常相近。Omar 在 Notes from Dynamicland: Geokit 這篇文章裡面有詳盡的介紹他如何用 Realtalk 的 Object 和語法實作出一個更完整的地圖軟體，有興趣的人歡迎參考。

從 Realtalk 的運作機制我們可以發現一件有趣的事情：當你在一個 Object 上編寫程式時，其實就是在將某種無形概念具象化到這個 Object 裡頭；當你在調整這些 Objects 的空間關係時，其實就是在透過即時操作這些具象化的概念來改變你在研究的系統狀態。換句話說，對於任何一個由空間中的 Objects 組合起來的子集，我們都可以在某種程度上將其視作是一個 Information Software，這個 Information Software 為你正在研究的系統提供了一個動態的表達形式。有了這一層理解後，再回頭看 Bret Victor 在 2013-14 年發表的 Stop Drawing Dead Fish 和 The Humane Representation of Thought 這兩個演講，便會更加清楚 Realtalk 的設計理念。

在 Stop Drawing Dead Fish 中，Bret 提到雖然計算機是一種新的資訊媒介，但我們卻一直在它上面打造用舊的資訊媒介就能乘載的表達形式。舉例來說，我們會在電腦上畫畫、做影片，但是圖畫和影片都是本來就存在紙張和電視上的表達形式。這些表達形式既不會執行運算，也不會與你互動。

在 The Humane Representation of Thought 中，Bret 提到人類的知識在過去兩千年的成長取決於我們不斷地發明新的表達形式，並用這些表達形式來拓展我們思考的邊界。計算機作為一種全新的媒介，應該要能幫助我們製造更加強大、過去不曾出現過的動態表達形式。而要做到這件事，我們就必須善用計算機作為「動態媒介」的三個重要屬性：運算（Computational）、響應（Responsive）、連結（Connected）。

所以在 Realtalk 裡頭，所有的物件都內嵌著程式碼、承載著運算的能力。物件與物件之間可以相互溝通、連結。你可以根據你的目的去改變物件在空間中的位置以及物件內部的參數和程式邏輯，而整個運算空間會即時地響應你對系統所做的每一個改動，將最新的系統狀態渲染出來。

從這裡便可以看出，Realtalk 就是 Bret 在十年前就在嘗試打造的「動態媒介」，而這個動態媒介的用途正是要讓我們可以利用它創造全新的動態表達形式，進而更好地理解我們在研究的系統、更新我們對這個系統的認知。

Direct Manipulation & End-user Programming

講完 Visual Programming 和 Distributed Computing 後，我們可以再來看另一個 Realtalk 系統很重要的特性：End-user Programming。

在傳統軟體開發的過程中，開發軟體和使用軟體是兩個完全不同的階段，軟體的使用者如果想要一個新功能，他需要和開發者提需求，開發者開發完成後，再將軟體打包部署給用戶使用。但是在 Realtalk，開發軟體和使用軟體是耦合在一起的相同階段。當一個軟體的用戶覺得軟體不符合他的需求時，他可以直接修改軟體中的某個 Computational Object 的程式碼，而在他修改完成的當下，他就立即獲得了可以使用的新功能。

換句話說，Realtalk 是一個支持 Direct Manipulation 的 End-user Programming 系統，每一個使用者都可以按照他的意圖去直接修改或添加 Computational Object，進而改變整個 Computational Space 的運作規則。軟體的樣貌不再會只由最一開始的創造者給主導，因為每個使用者都可以是作者。就算你不擅長寫程式，只要你知道 Realtalk 系統中每個 Computational Object 的用途，你依然可以將你認為合適的 Computational Object 組合起來變成你要的軟體。這就有點像你可以使用 Spreadsheet 裡頭的 SUM、DIVIDE 這類高階語言來完成你想要做的計算任務，而不需要知道 Spreadsheet 底層的程式是怎麼寫的。

值得一提的是，我覺得 Realtalk 這種基於 Object 和 Claim、When、Wish 等語法的 Computation System 能讓我們更容易地將運算的邏輯模組化到不同的物件裡頭。舉例來說，一號科學家在 Object A 上寫了一個程式來保存蛋白質結構的資訊。二號科學家看到 Object A 後，在 Object B 寫了可以將 Object A 的蛋白質結構渲染出來的程式。三號科學家在看到 Object A、B 後，在 Object C 寫了一個可以將 Object B 渲染的蛋白質畫面放大縮小的程式。在這個過程中，每個人在為一個 Object 添加程式的當下，想的都是如何去擴充前人的東西，而不是後人會怎麼用他寫的這個 Object。

相較之下，在以 Function Call 和 Variable 為基礎的軟體開發中，將適當的參數和邏輯封裝和模組化是一件非常仰賴經驗和能力的事情。你通常會需要在一開始就想好這個模組未來會如何被其他人使用，要像 Realtalk 的模組那樣自下而上由許多互不認識的人逐步擴充出來，我認為溝通和協調的複雜度會高出不少。

Engineering & Authoring

講完 End-user Programming 後，我想跳出技術細節，回頭討論一下 Realtalk 的設計目的，以及工程師在理解 Realtalk 時容易踏入的誤區。

Bret 在 2014 年給過一個標題為 The Humane Representation of Thought 的演講，並在演講後段提到：Programming 主要的用途有 Engineering 和 Authoring 這兩種。當你的用途是 Engineering 時，你的目標是打造一個可靠的、滿足 Spec 的系統；當你的用途是 Authoring 時，你的目標是以計算機為媒介在別人的大腦中創造印象。

Realtalk 作為一個計算系統當然可以用來做 Engineering，但它更重要的一個特性是人們在 Programming 時可以更專注在 Authoring 上，以計算機為動態媒介去研究一個系統，並且即時的把他們的想法用這個動態媒介能承載的表達形式表達出來。

換句話說，我們不應該過度糾結於「Realtalk 可以打造什麼軟體？」或是「用 Realtalk 打造軟體是不是真的比較有效率？」。以 Omar 在 Realtalk 上實作的地圖程式 Geokit 為例，任何厲害的工程師都應該有能力用 Javascript 在網頁上做出類似的軟體，但這樣的比較容易讓我們忽略 Realtalk 仍是一個非常早期的原型系統，將它的能力與當代已發展數十年的成熟軟體生態系進行直接的比較，就像是要一個嬰兒和成年人賽跑一樣，忽略了嬰兒的龐大的未來發展性。別忘了，我們當代的計算機科技，在 1960 年代時也曾被視作是「看起來很厲害但不知道用途是什麼的玩具」。

正如 Bret Victor 在 A few words on Doug Engelbart 所提的，當我們在嘗試理解像 Realtalk 這樣的新系統時，我們最應該問的問題不是「它做了什麼？」，而是「它想要創造一個什麼樣的世界？」只有在問出這樣的問題時，我們才能把自己置身在創造那個世界的位置上。Realtalk 的設計目的從來都不是要讓我們更快地打造更多的軟體（雖然它確實可能做得到這件事情），而是要創造一個人人都可以以計算機為動態媒介來研究和討論複雜系統、拓展認知能力的世界。

Closing Thoughts

這篇文章探討了 Realtalk 系統中其中幾個我比較感興趣的設計哲學。如果你是相關領域的研究員，我希望這篇文章能啟到一點拋磚引玉的效果；如果你是工程師或學生，我希望這篇文章能讓你在研究計算機時，可以更加重視計算機作為一個知識媒介的潛力，而不是只把目光放在 Engineering 的實作上面。

在 Heptabase，我們的願景是打造一個任何人都可以有效地對任何事物建立深度理解的世界。如果你對於「利用計算機研究和理解複雜系統」這個主題有想法，歡迎透過 alan@heptabase.com 與我聯絡、討論。

如果你想要更深入理解 Realtalk 的運作和設計，以下是我推薦的一些延伸閱讀。

• The Humane Representation of Thought
• Stop Drawing Dead Fish
• Media for Thinking the Unthinkable
• Up and Down the Ladder of Abstraction
• Learnable Programming
• Magic Ink
• Communal computing for 21st-century science
• Dynamicland presentation, Feb 2018
• Bootstrapping Research & Dynamicland, Dec 2019
• Notes from Dynamicland: Geokit
• Notes from Dynamicland: programming Raspberry Pis

雖然 Realtalk 是一個很新的系統，但是它的精神其實可以追溯到 Alan Kay 在 1960 年代的研究。因此在這篇文章的最後，我想以 Alan Kay 寫的 The Early History Of Smalltalk 這篇文章的幾段節錄作結：

It isn't enough to just learn to read and write. There is also a literature that renders ideas. Language is used to read and write about them, but at some point the organization of ideas starts to dominate mere language abilities.

… I think that this is what liberal arts educations is supposed to be about, is to get fluent and deep while building relationships with other fluent deep knowledge.

… Being able to read a warning on a pill bottle or write about a summer vacation is not literacy and our society should not treat it so. Literacy, for example, is being able to fluently read and follow the 50 page argument in Paine's Common Sense and being able (and happy) to fluently write a critique or defense of it.

Another kind of 20th century literacy is being able to hear about a new fatal contagious incurable disease and instantly know that a disastrous exponential relationship holds and early action is of the highest priority. Another kind of literacy would take citizens to their personal computers where they can fluently and without pain build a systems simulation of the disease to use as a comparison against further information.

At the liberal arts level we would expect that connections between each of the fluencies would form truly powerful metaphors for considering ideas in the light of others.

The reason, therefore, that many of us want children to understand computing deeply and fluently is that like literature, mathematics, science, music, and art, it carries special ways of thinking about situations that in contrast with other knowledge and other ways of thinking critically boost our ability to understand our world.