背景

這篇討論源於一位開發者在 Hacker News 分享他在一週內用 Emacs Lisp 打造的《模擬城市》（SimCity/Micropolis）克隆版。這款名為 ElCity 的作品不僅是為了趣味，作者更希望藉此實踐「功能核心與命令式外殼」（Functional Core / Imperative Shell）的架構模式，並開發出一套用於定義地圖圖塊及其效果的領域特定語言（DSL），以提升遊戲的可擴展性。

社群觀點

社群對這項實驗性計畫展現了高度興趣，討論焦點首先集中在 Emacs 作為遊戲平台的潛力與限制。許多資深用戶回憶起 Emacs 內建的遊戲傳統，如 Tetris 或 Zone 模式，並建議作者參考這些既有的圖形庫來優化視覺效果。有趣的是，原版《模擬城市》的開發者 Don Hopkins 也現身評論區，分享了他過去將遊戲移植到 Unix 系統時，如何透過分離模擬引擎與使用者介面來達成跨平台目標。他指出，這種架構與作者採用的「功能核心」理念不謀而合，並鼓勵作者將此作品打磨後提交給 GNU 計畫，甚至開玩笑地提到理查·斯托曼（RMS）或許會對在 Emacs 裡玩模擬城市感興趣。

關於技術架構的討論尤為深入。部分留言者探討了「功能核心與命令式外殼」（FCIS）是否為程式設計的未來。支持者認為，將業務邏輯寫成純粹、同步且無副作用的函數，能極大化程式碼的可測試性與可並行性，而將副作用限制在邊緣的命令式外殼中。這種模式在處理遊戲狀態的儲存、還原與除錯時具有顯著優勢。然而，也有人質疑這種架構在現有主流語言中的實踐難度，認為大多數語言在處理副作用時往往會引入過高的認知負擔。

此外，社群也針對「脫離 Emacs 運行」的可能性展開辯論。有觀點建議將核心邏輯與 Emacs 解耦，以便在其他 Common Lisp 環境中執行。但資深 Lisp 開發者指出，不同方言之間的移植並非易事，Emacs Lisp 提供的環境與標準 Lisp 存在顯著差異，強行解耦可能會失去 Emacs 賦予的便利性。另一派意見則認為，既然目標是 Emacs 插件，就應該擁抱其生態特性，而非追求無謂的通用性。

最後，討論也觸及了 AI 在現代開發中的角色。作者坦承在開發過程中諮詢了 LLM 並使用相關工具輔助，這引發了關於「AI 生成代碼是否值得展示」的省思。雖然有開發者對此感到羞怯，但多數人持鼓勵態度，認為 AI 是強大的輔助工具，能幫助開發者快速驗證想法，重點在於最終產出的創意與結構，而非是否每一行程式碼都由人工敲定。

延伸閱讀

• MicropolisWeb: 由 Don Hopkins 維護的原版模擬城市開源版本與相關歷史文件。
• Boundaries: Gary Bernhardt 關於「功能核心與命令式外殼」架構模式的經典演講。
• Mastering Emacs - Fun and Games: 介紹 Emacs 內建遊戲及其背後技術原理的文章。
• gptel: 一款用於 Emacs 的 LLM 客戶端工具，作者在開發過程中所使用的輔助工具。
• Doom on Emacs: 另一個在 Emacs 中實現複雜圖形遊戲（Doom）的知名專案。