在 2026 年使用 1978 年的 DEC VT-100 終端機
nikhiljha.com (Nikhil Jha) · 2026-04-28
Nikhil Jha 在 2026 年 4 月記錄了將一台 1978 年出廠的 DEC VT-100 終端機接入現代計算環境的嘗試，探討近半世紀前的硬體規格與今日軟體的相容性邊界。
硬體規格
VT-100 以 Intel 8080 處理器為核心，配備 3 KB RAM，透過 RS-232 序列埠連接，最高傳輸速率 9600 baud（約每秒 960 個 ASCII 字元）。顯示規格為 80 列 × 24 行，僅支援 ASCII 字元集，不支援 Unicode。
現代使用的技術挑戰
VT-100 是 ANSI 逃脫序列（ANSI escape sequences）的原始定義來源，現代終端機的逃脫序列方言幾乎都追溯自此。然而，直接連接現代程式需要處理幾個問題：
- 流量控制（flow control）：9600 baud 限制了資料傳輸速率，現代程式輸出過快時會溢出硬體緩衝區；需要啟用 XON/XOFF 或 RTS/CTS 流量控制
- 差異渲染（differential rendering）：終端程式需要計算螢幕差異，只傳送變更部分，而非每次重新繪製整個 80×24 畫面
- Unicode 不支援：所有輸出必須限制在 7-bit ASCII 範圍內；emoji 與非 ASCII 字元需要轉換或截斷
ANSI 逃脫序列的來龍去脈
VT-100 實作的 ANSI X3.64 標準定義了游標移動（CSI A/B/C/D）、清除螢幕（CSI 2J）、顏色（CSI 30–37m）等序列。這些序列在近五十年後仍被 xterm、iTerm2、Windows Terminal 等所有現代終端機模擬器支援，構成終端機相容性的基礎事實層。
原始來源：nikhiljha.com — Using a 1978 terminal in 2026 (DEC VT-100)
Zig 禁止 AI 貢獻：貢獻者撲克牌局與開源維護的理性計算
kristoff.it (Loris Cro, Zig Software Foundation) · 2026-04-29
Zig 語言核心貢獻者 Loris Cro 在 2026 年 4 月 29 日以「貢獻者撲克」框架解釋為何 Zig 專案明確禁止 AI 生成的程式碼貢獻，以及這個決策背後的開源經濟學。
貢獻者撲克框架
Cro 將開源維護比喻為撲克牌局：「你押注的是人，而非牌。」維護者接受一個新貢獻者的 PR，表面上是審查一份程式碼，實際上是在押注這個人未來成為核心貢獻者的潛力。即使從效率角度看，自己直接實作某個功能比審查 PR 更快，接受外部 PR 仍可能是理性的——因為在這個過程中建立了關係和信任，為後續更大規模的合作奠基。
Zig 的歷史佐證了這個理論：對 Ryan Liptak（Windows 資源指令碼）和 Frank Denis（密碼學）等人的早期投資，帶來了後續無法替代的深度貢獻。
AI 貢獻破壞模型的機制
LLM 生成的程式碼在這個框架中有三個結構性問題：
- 幻覺與無效提交：浪費維護者的審查週期而無相應回報
- 違反關係建立規範的超大 PR：初次貢獻者提交 10,000+ 行的 LLM 輸出，跳過了建立信任所必需的漸進式互動
- 欺騙性實踐：部分貢獻者聲稱未使用 LLM，但 PR 中出現 AI 典型錯誤模式（hallucination artifacts）
理性計算
Cro 的結論：「從貢獻者撲克的角度，在有人類替代方案的情況下，押注 LLM 使用者根本不理性。」AI 貢獻無法參與需要相互問責與共享問題空間知識的迭代關係。這個限制不是意識形態立場，而是對維護者資源的效用最大化。
函數式程式設計者應該看看 Zig：comptime 作為型別層級程式設計
pure-systems.org · 2026-04-29
一篇寫給 Haskell 與 ML 背景工程師的文章，在 2026 年 4 月 29 日論述 Zig 的 comptime 機制如何提供函數式語言中型別層級程式設計的類似能力，但採用根本不同的方式。
comptime 的核心概念
Zig 沒有泛型語法（generics syntax），而是使用 comptime 讓一般 Zig 程式碼在編譯期執行。函式可以接受 comptime 參數，包括型別本身，在編譯期執行計算並回傳型別：
fn Stack(comptime T: type) type {
return struct {
items: []T,
// ...
};
}這在語義上等同於 Haskell 的型別類別或 ML 的 functor，但沒有獨立的型別層次——同一套程式語言規則在執行期和編譯期都適用。
顯式配置器作為函數式抽象
Zig 要求所有分配記憶體的函式接受明確的 std.mem.Allocator 參數，沒有隱式全域配置器。文章指出這與函數式程式設計中效果系統（effect system）的概念有相通之處：副作用（記憶體分配）透過型別系統明確傳遞，而非隱藏在全域狀態中。
與 Haskell 型別類別的比較
Haskell 的 typeclass 透過 dictionary passing 在執行期傳遞行為；Zig 的 comptime 在編譯期消解多型，不產生執行期分派成本。兩種方法都允許泛型程式設計，但在開銷模型和可表達性邊界上有根本差異。
原始來源：pure-systems.org — Functional Programmers need to take a look at Zig