背景

這篇文章探討了 Pharo Smalltalk 環境中重寫引擎（Rewrite Engine）的進化。雖然這套由 John Brant 與 Don Roberts 於 1997 年開發的工具在抽象語法樹（AST）層級的匹配與重寫上極具威力，但其特殊的字串語法卻讓開發者難以記憶且無法享受現代 IDE 的程式碼補全與導覽功能。為此，作者推出了 BPatterns，這是一套以 Smalltalk 原生風格封裝的 DSL，允許開發者直接使用閉包（Block）作為模式，將重寫邏輯整合進標準的開發工作流中。

社群觀點

針對 BPatterns 的出現，Hacker News 的討論呈現出技術讚賞與對開發文化反思的兩極反應。支持者高度評價 Smalltalk 在處理閉包（BlockClosure）上的靈活性，認為這項工具展現了該語言最迷人的特質：開發者能輕易地擷取一段程式碼區塊，並透過擴充物件行為來進行深度內省。這種做法巧妙地避開了修改編譯器或開發專用工具的繁瑣過程，且「any」等前綴僅在特定上下文中被視為元變數（metavariable），不會汙染全域語法，這種優雅的處理方式被視為比其他語言更為直觀的語法擴充方案。

然而，社群中也出現了相當尖銳的批評，認為這反映了 Smalltalk 社群長期存在的結構性問題。有評論指出，與其不斷在舊有工具上堆疊新的抽象層，不如回頭完善原始工具的文檔、製作速查表或整理範例。批評者認為，Smalltalk 開發者往往過度依賴 IDE 的強大探索功能，迷信「程式碼即文檔」，導致許多核心工具缺乏正式的 README 或說明文件。這種文化使得新手或偶爾使用的開發者必須耗費大量時間在原始碼中「狩獵」範例，即便有像 GToolkit 這樣現代化的環境，文檔稀缺的問題依然限制了整體的開發效率。

此外，從程式語言理論的角度來看，BPatterns 解決了非 Lisp 系語言在實作語法宏（Syntactic Macros）時常見的「空位」（Hole）標示問題。在 C++ 等語法複雜的語言中，區分型別宣告與一般表達式往往需要複雜的歧義消除機制，而 Smalltalk 憑藉其極度規律的語法結構，僅透過標識符前綴就能達成 AST 匹配，這被認為是處理語法重寫的一種高效路徑。儘管如此，討論也提醒開發者，過度依賴這種「在環境中摸索」的開發模式，在面對缺乏測試或文檔的大型專案時，其生產力可能反而不如 Python 等文檔文化健全的語言。

延伸閱讀

在討論中，參與者提到了幾款現代化的語法重寫與規則撰寫工具，可作為跨語言的參考對象，包括基於語法樹搜尋的 ast-grep，以及廣泛用於靜態分析與安全性檢查的 semgrep。此外，針對 Smalltalk 環境的文檔化嘗試，GToolkit 專案中的 Lepiter 筆記系統也被提及，被視為改善社群文檔文化的一個重要嘗試。