ActivePapers Pharo 版本

ActivePapers Pharo 版，作者 Konrad Hinsen，發表於 2019 年 5 月 10 日 ActivePapers 家族迎來了一位新成員：ActivePaper Pharo 版。與主要在兩個不同平台上實現相同理念與概念的 Python 版和 JVM 版不同，Pharo 版追求的是另一個目標：探索可重複、可理解且可驗證的電腦輔助研究中的人機介面。關於 ActivePapers Python 版，我最常被問到的問題之一是：「這能與 Jupyter notebooks 一起使用嗎？」起初我的回答是：「暫時還不行，但我正在努力。」我也確實付諸行動了。然而，這項工作從未帶來令人滿意的結果。原因之一是技術障礙。我曾嘗試將 Jupyter notebooks 納入 ActivePaper 中，但最終發現這不可行，因為 Jupyter 的雙進程設計（核心與 notebook 編輯器是透過通訊協定連接的獨立進程）與 HDF5 函式庫的限制不相容——HDF5 規定任何時刻只能有一個進程寫入檔案。這意味著你無法將 notebook 及其計算結果儲存到同一個 HDF5 檔案中。然而，愈是思考如何整合 ActivePapers 與 Jupyter，我就愈意識到，其線性 notebooks（由程式碼、文件與結果单元格組成的序列）其實並不適合用於記錄科學計算，除非是非常簡單的情況。檢視已發表的各種 ActivePapers，你會發現它們無一例外地包含多個腳本以及一些函式庫模組。表面上看，notebooks 似乎可以取代腳本並同時提供文件說明。然而，優質的文件必須涵蓋整體，而非僅限於部分內容；它必須將多個腳本與來自函式庫模組的程式碼緊密連結。通常，計算方法實作於函式庫模組中，而腳本則將這些方法應用於資料集。如果文件是以腳本為單位逐一編寫，那麼該如何記錄這些方法呢？如今已有大量已發表的 Jupyter notebooks，它們又是如何處理這個問題的呢？當然，我並未檢視所有筆記本，但截至目前為止，我的印象是主要有兩種情況。最常見的情況是 notebooks 用於記錄基於標準且廣為人知的方法（這些方法實作於知名函式庫中）所進行的資料分析。這類 notebooks 的讀者被預期已經熟悉這些方法，或會從其他管道學習它們。另一種情況則是 notebooks 包含了完整的方法實作。除了僅適用於簡單方法之外，這種做法還有一個重大缺點：方法實作無法重複使用。由於我自身的研究主要聚焦於開發與評估新的計算方法，因此我得出结论：notebooks 並不適合我的工作。事實上，早在嘗試過程中我就已得出同樣結論。每當我以 notebook 形式啟動新專案時，很快就會轉回傳統的模組與腳本方式，並將文件另行存放於獨立的文字檔案中。我發現這種技術對於個人使用而言完全足夠，但一堆檔案，即使組織得再好，也難以讓另一位科學家（即使是合作者）願意深入探究。幾個月前，我開始接觸 Pharo，這 largely 出於偶然（我報名參加了 Pharo MOOC，希望從學習者的角度累積一些 MOOC 經驗，以便日後在「可重複研究 MOOC」中擔任講師角色），隨即發現了一種截然不同的互動式運算環境。Smalltalk 家族（Pharo 是其中較年輕的成員之一）長期重視可探索性與可理解性（詳情請參閱這篇部落格文章）。接著，我很快發現了 Glamorous Toolkit——一個建構於 Pharo 之上的新型互動式環境，旨在透過可塑型開發工具達到更高層級的可探索性；其核心理念在於，開發者應能擴充該環境，加入領域專屬的檢視工具。Rafael Luque 曾在一篇部落格文章中精闢總結了這些想法背後的智識背景。與 Pharo 生態系當前及未來的環境相比，計算型 notebooks 顯得極為有限且束縛重重。考慮到它们的起源，這其實並不令人意外。如今的 Jupyter 與 RMarkdown 不過是 1980 年代初由 Mathematica 引入的 notebook 概念的微小變體。而 Mathematica 本身，如同大多數其他電腦代數系統一樣，承襲了 Lisp 的傳統；Lisp 在 1950 年代為運算領域引入了許多革命性功能，其中包括透過「讀取 - 求值 - 輸出」循環（REPL）實現的互動性——在當時使用者介面硬體（即面向行的終端機）的限制下，這是一種自然的互動實現方式。另一方面，Smalltalk 自 1970 年代起步時，便直接採用圖形顯示與指向裝置，代價則是依賴當時極少人能接觸到的硬體。正如 Marshall McLuhan 所教導我們的：我們首先塑造工具，隨後工具塑造我們。1950 年代面向行的終端機已在電腦使用者心中烙印出一種思維模式，即便今日擁有更優越的方法已存在數十年，這種思維仍殘存於現代的計算型 notebooks 之中。而那項更優越的技術不僅僅是 Smalltalk（它始終屬於小眾系統）；非線性的圖形使用者介面（GUI）才是我們所有人用來處理影像或音訊檔案的工具。這類任務幾乎無法以逐行方式完成，因此在 GUI 出現之前，它們根本無法實現。對於計算任務而言，GUI 或許來得太遲：線性思維早已成為文化常規。ActivePapers Pharo 版的目標，是將 GToolkit 環境塑造成一個專用於電腦輔助研究的環境，而非軟體開發環境。這兩項活動雖有區別，卻共享許多共同特徵。主要差異在於：科學聚焦於資料與模型，軟體僅是達成目的的手段。然而，由於此手段至關重要，其他一切皆圍繞其建構。此外，軟體開發同樣涉及資料（關於軟體的資料）與模型（作為規格說明）。歸根結柢，兩者之間的差異是漸進式的，而非根本性的。這段旅程剛剛啟程，我尚不清楚它將通向何方。敬請持續關注更新！與此同時，您可以觀看這段示範影片。留言由 Disqus 提供支持