6 posts
Literate programming 承諾單一事實來源，但手動的 weave 和 tangle 步驟會破壞 CI/CD 流水線。以下是如何自動化提取和文件生成，使 Markdown 檔案保持規範。
如果你的建置流水線必須等你開啟終端機輸入 才能執行，那你就沒有文學化程式。你有的只是一本綁著編譯器的日記。 文學化程式設計的全部意義在於散文和程式碼共享單一事實來源。Markdown 檔案就是產物。其他一切——可執行原始碼、渲染後的文件、測試檔案——都是衍生的。衍生產物屬於 CI，不屬於你的工作記憶。 問題不是 CI…
我花了30天時間，在向LLM索取程式碼之前先撰寫設計說明。結果改變了我對rubber-ducking的看法。
大多數開發者把LLM用反了。我們用五個詞描述需求，拿回200行程式碼，然後花下一個小時除錯模型做出的假設。 我花了三個月時間執行相反的流程：在索取哪怕一行程式碼之前，先寫一份完整的設計說明。結果程式碼缺陷更少了，但真正的進步在於我自己的理解。 Donald Knuth在1984年提出了「literate…
Literate programming 將 Markdown 檔案作為單一事實來源，使文件、測試和實作保持同步。以下是如何用三十行 Python 實現它。
你的文件、測試和程式碼是三份檔案，講著同一個故事，卻講得都很糟糕。 你在原始碼裡更新了函式簽名，忘了改 README 裡的範例。一週後，新進員工把過時的程式碼片段複製到了生產環境。你的測試檔案仍然把舊的行為編碼為預期結果。現在你有兩個 bug 和一個文件工單。…
LLM 對話包含意圖、被拒絕的替代方案以及可執行的程式碼。這正是文件應該包含的內容。以下是將 ephemeral chat 轉換為持久、可搜尋的文件，同時不遺失敘事的方法。
你花了 45 分鐘和 Claude 設計一個 retry circuit。你解釋了 failure modes，因為 exponential backoff 會掩蓋 cascading pressure 而拒絕了它，確定了 token-bucket rate limiting with…
每個編譯器都將你的程式碼視為樹，但你的編輯器讓你編輯原始文字。以下是結構化編輯的實際樣子、為什麼它沒有佔領市場，以及如何在不更換工具的情況下借用其優勢。
每種程式語言都有形式語法。編譯器讀取它，構建剖析樹，拒絕任何不符合的內容。編輯器完全無視語法，讓你想輸入什麼就輸入什麼。 這種脫節是大量摩擦的驚人來源。自動完成建議的識別碼在上下文中毫無意義。語法突顯在重構中途崩潰。編輯器眼睜睜看著你犯錯，然後報出「Unexpected…
Literate programming承諾程式碼應該首先為人類編寫，其次才是為機器。四十年後，幾乎沒有人這樣寫。以下是軟體文件化中最優雅的理念為何未能改變我們工作方式的原因。
1984年，Donald Knuth發表了一篇提出根本性反轉的論文。程式不應該是為編譯器編寫、為人類添加註解的。它們應該被寫作為人類的文學作品，編譯器從中提取可執行部分。他稱之為literate programming，並以此方式建構了TeX。 這個想法很美。它在現代軟體開發中也幾乎完全缺席。…