NEO.K / PLDST程式語言設計師風格譜系
編號PLDST-001
版本v1.0
日期2026-07-30
作者Neo.K
狀態公開版／方法論奠基論文

下載 PDF ↓回到論文索引 ↗

程式語言設計師風格譜系：從語言特徵分類到設計決策人格

摘要

現有程式語言分類通常以範式、型別系統、執行模型、語法形式、抽象層級或應用領域為核心。這些分類能回答「一種語言具有哪些特徵」，卻不一定能回答另一個問題：

為何不同程式語言設計者，在面對相似問題時，會反覆選擇不同的取捨方式？

Niklaus Wirth 將設計簡潔視為 Modula-2 與 Oberon 最重要的指導原則；Guido van Rossum 在回顧 Python 時，同時強調可讀性、降低不必要的表達變異、對 Unix／C 生態的開放性，以及針對常見情境的工程調校；Go 的設計文件把大型組織中的建置速度、依賴管理、閱讀、維護與團隊生產力置於語言研究新穎性之前；Ruby 則公開接受「外表自然、內部複雜」的複雜度配置；C++ 的演化長期受相容性、一般化機制、硬體映射與零額外成本原則約束。這些差異不能只由「命令式、函數式、物件導向」等範式標籤解釋。[R1][R2][R4][R5][R6]

本文提出 程式語言設計師風格譜系（Programming Language Designer Style Taxonomy, PLDST）。PLDST 不將設計者進行心理人格診斷，也不把語言成敗簡化為個人天才或缺陷；它把「設計決策人格」定義為：

在特定歷史、技術、使用者與治理條件下，設計者或設計共同體對問題 framing、複雜度配置、責任分配、相容性、抽象、可讀性、安全與演化方式所呈現的可重複決策模式。

本文建立六項方法論核心：

  1. 區分語言特徵、設計哲學、設計者風格、制度風格與生態結果；
  2. 以「設計決策語料」而非單一名言作為分析單位；
  3. 建立原始來源、決策文件、語言構造、治理記錄與回顧結果的證據階層；
  4. 以問題定位、價值優先序、複雜度配置、責任邊界、演化模式與治理方式構成風格描述；
  5. 將風格視為有時間相位、情境依賴與信心區間的向量，而非固定類型；
  6. 提供可轉譯為個案研究、比較研究、AI 分析 SKILL 與書籍章節的標準輸出格式。

本文的核心命題是：

程式語言設計風格≠語言特徵總和\boxed{ \text{程式語言設計風格} \neq \text{語言特徵總和} }

更精確地說：

設計風格=反覆出現的取捨規則+複雜度配置+責任配置+演化偏好\boxed{ \text{設計風格} = \text{反覆出現的取捨規則} + \text{複雜度配置} + \text{責任配置} + \text{演化偏好} }

關鍵詞： 程式語言設計、設計師風格、PLDST、設計決策、複雜度配置、語言史、HOPL、認知維度、語言治理

第一部分　研究問題

一、為何「語言分類」不等於「設計師分類」

程式語言可以依多種方式分類：

這些分類描述的是語言構造或使用模式。它們通常回答：

What does the language provide?\text{What does the language provide?}

PLDST 要回答的是：

Why did the designer repeatedly choose this kind of solution?\text{Why did the designer repeatedly choose this kind of solution?}

兩種語言可能都採靜態型別，但背後理由完全不同：

反之，同一位設計者也可能在不同語言或不同時期採用不同機制，卻維持相似的深層取捨規則。

因此：

Feature Similarity⇏Style Similarity\text{Feature Similarity} \not\Rightarrow \text{Style Similarity}

以及：

Feature Difference⇏Style Difference\text{Feature Difference} \not\Rightarrow \text{Style Difference}

二、從「語言作品」回到「決策者」

語言是設計結果，但設計風格隱藏在下列問題中：

  1. 設計者認為最主要的問題是什麼？
  2. 他把誰視為主要使用者？
  3. 他把複雜度移到哪裡？
  4. 他願意讓使用者承擔多少責任？
  5. 他偏好禁止錯誤、揭露錯誤，還是容許恢復？
  6. 他是否接受多種做法共存？
  7. 他如何理解效能、抽象與硬體？
  8. 他如何處理向後相容？
  9. 他如何處理既有生態？
  10. 他把語言演化視為個人創作、委員會工作，還是社群治理？

這些問題共同構成「設計決策人格」。

三、「人格」不是心理診斷

本文使用「設計決策人格」時，指的是穩定的決策模式，不是：

其英文可更保守地表述為：

Decision-Style Signature

亦即：

Σd=設計者 d 在可觀察決策中的風格簽名\Sigma_d = \text{設計者 }d\text{ 在可觀察決策中的風格簽名}

分析對象是公開決策，而不是設計者不可觀察的內心。

第二部分　相關研究與缺口

四、範式與語言特徵分類

範式分類能揭示計算模型、抽象與程式結構，但它更接近「語言如何表達計算」，不直接描述「設計者如何選擇」。

同一種函數式語言可以：

因此，範式是 PLDST 的輸入，不是最終分類。

五、語言史與 HOPL

ACM SIGPLAN 的 HOPL 傳統重視：

HOPL-IV 的徵稿與寫作指引尤其強調技術準確、歷史完整、設計動機、演化與跨語言脈絡。[R9]

PLDST 接受 HOPL 的歷史方法，但分析焦點不同：

六、認知維度

Green 與 Petre 的 Cognitive Dimensions of Notations 提供一套討論記號系統與使用者關係的詞彙，例如：

該框架明確將這些維度視為討論與權衡工具，而非單一最佳設計清單。[R8]

PLDST 吸收其精神：

設計維度之間通常存在權衡，不能把所有維度同時最大化。

但 Cognitive Dimensions 主要評估記號與使用活動；PLDST 則評估設計者如何反覆配置這些權衡。

七、人本與跨學科語言設計

Coblenz、Aldrich、Myers 與 Sunshine 主張，語言設計應依使用者背景、目標應用與領域需要選擇品質屬性，並結合形式、觀察性與人本方法，而不是假設一組屬性適用所有語言。[R10]

這對 PLDST 有兩個重要限制：

  1. 設計風格不能脫離目標使用者與目標場景；
  2. 某個取捨在一個情境中合理，不代表在所有情境中都合理。

八、目前的研究缺口

目前已有：

但仍缺少一套統一方法，能同時回答：

PLDST 即針對此缺口。

第三部分　基本區分

九、語言特徵

語言特徵是可直接觀察的構造，例如：

特徵回答：

語言具有什麼機制？

十、設計原則

設計原則是對取捨的明確聲明，例如：

原則回答：

設計者公開宣稱什麼重要？

但原則不一定等於實際決策，因為原則可能：

十一、設計決策

設計決策是：

q=(p,c,A,x,r,b,o)q = ( p, c, A, x, r, b, o )

其中：

設計風格必須從多個 qq 中歸納，不能只從單一功能或名言判斷。

十二、個人風格

個人風格是可合理歸因於特定設計者的重複決策模式。

例如：

十三、制度風格

語言進入社群、基金會、委員會或標準組織後，設計風格可能由制度產生。

Rust 的 RFC 流程要求重大改變進入公開設計與共識程序；此時某項決策未必能簡化為某一位創始人的個人偏好。[R7]

制度風格包括：

十四、生態結果

一種語言最後呈現的樣貌，也會受下列因素影響：

因此：

Observed Language=Initial Design+Evolution+Implementation+Ecosystem+Governance\text{Observed Language} = \text{Initial Design} + \text{Evolution} + \text{Implementation} + \text{Ecosystem} + \text{Governance}

不可將今日整個語言的所有特徵都歸於創始設計者。

第四部分　分析單位：設計決策語料

十五、Designer Decision Corpus

PLDST 為每位設計者或設計共同體建立：

Designer Decision Corpus（DDC）

DDC 包含：

  1. 原始語言規格；
  2. 設計論文；
  3. HOPL 回顧；
  4. 設計者文章；
  5. 訪談與演講；
  6. 提案與拒絕記錄；
  7. 郵件列表；
  8. Issue／RFC／PEP；
  9. 實作限制；
  10. 語言演化結果。

十六、最小決策記錄

每一筆決策至少記錄：

decision_id
designer_or_body
language
period
problem
target_users
target_domain
constraints
alternatives
selected_choice
stated_rationale
inferred_rationale
complexity_allocation
responsibility_allocation
compatibility_cost
outcome
sources
attribution_confidence

十七、不能只分析成功功能

只看成功功能會產生倖存者偏差。

DDC 還應包含：

「不加入什麼」往往比「加入什麼」更能揭示風格。

第五部分　證據階層

十八、E1：設計者直接聲明

例如：

優點：

限制：

十九、E2：正式決策文件

例如：

E2 能顯示：

二十、E3：語言與工具構造

實際語言設計可以驗證公開原則是否反覆落實。

例如：

二十一、E4：治理與演化紀錄

用於判斷：

二十二、E5：次級研究與社群解讀

包括：

E5 可以補充結果與影響，但不能取代 E1–E4 來斷言設計者本人動機。

二十三、證據權重

對每項風格推論 hh ，可表示為：

Conf(h)=f(Source,Attribution,Recurrence,Consistency,Context)Conf(h) = f( Source, Attribution, Recurrence, Consistency, Context )

其中：

輸出不應只給分數，還要標示：

高信心
中信心
低信心
證據不足

第六部分　PLDST 六層模型

二十四、第一層：設計情境

任何風格分析先記錄：

Cd=(Era,Hardware,Audience,Domain,Host,Economy,Governance)C_d = ( Era, Hardware, Audience, Domain, Host, Economy, Governance )

包括：

脫離情境的評價容易形成後見之明偏誤。

二十五、第二層：問題定位

設計者主要把問題定位在哪裡？

P1　機器問題

P2　程式問題

P3　使用者問題

P4　組織問題

P5　領域問題

設計者通常同時關注多個問題，但具有主要重心。

二十六、第三層：價值優先序

PLDST 不採單一總分，而使用多軸優先序。

V1　語義經濟

小型核心 ←────────→ 特徵多元

V2　顯式性

顯式宣告 ←────────→ 推導與慣例

V3　安全約束

信任使用者 ←────────→ 系統預防

V4　機器透明度

直接硬體映射 ←────────→ Runtime 中介

V5　可讀一致性

單一／規範方式 ←────────→ 多種表達方式

V6　擴展開放性

封閉正交核心 ←────────→ 巨集／元編程開放

V7　一般性

領域專用 ←────────→ 通用機制

V8　相容性

概念修正優先 ←────────→ 向後相容優先

V9　工具中心性

語言自行承擔 ←────────→ 編譯器／IDE／工具承擔

V10　生態整合

自足系統 ←────────→ 宿主與既有生態整合

二十七、第四層：複雜度配置

語言設計經常不是消除全部複雜度，而是重新配置複雜度。

本文提出啟發式複雜度預算：

BC=(Csurface,Csemantics,Ccompiler,Cruntime,Clibrary,Ctooling,Cuser,Cgovernance)B_C = ( C_{surface}, C_{semantics}, C_{compiler}, C_{runtime}, C_{library}, C_{tooling}, C_{user}, C_{governance} )

分別表示：

這不是嚴格守恆定律。好的設計確實可以透過統一概念降低總複雜度；但在多數具體取捨中，降低某一層的成本會增加另一層的負擔。

例如：

二十八、第五層：責任配置

設計者如何分配責任？

BR=(Rprogrammer,Rcompiler,Rruntime,Rlibrary,Rtool,Rorganization)B_R = ( R_{programmer}, R_{compiler}, R_{runtime}, R_{library}, R_{tool}, R_{organization} )

關鍵問題：

設計風格常常就是責任配置哲學。

二十九、第六層：演化與治理

E1　演化節奏

重新設計 ←────────→ 漸進演化

E2　決策中心

單一設計者 ←────────→ 委員會／社群

E3　實驗方式

先設計後發布 ←────────→ 實驗、回饋、穩定化

E4　相容性政策

允許斷裂 ←────────→ 長期相容

E5　標準化強度

實作主導 ←────────→ 規格／標準主導

第七部分　風格簽名

三十、形式化表示

對設計者 dd 在時期 tt 的設計決策集合：

Qd,t={q1,q2,…,qn}Q_{d,t} = \{q_1,q_2,\ldots,q_n\}

每個決策經特徵映射：

ϕ(qi)=(Pi,Vi,BCi,BRi,Ei)\phi(q_i) = ( P_i, V_i, B_{C_i}, B_{R_i}, E_i )

風格簽名為：

Σd,t=Aggregate⁡({wiϕ(qi)}i=1n)\Sigma_{d,t} = \operatorname{Aggregate} \left( \{ w_i\phi(q_i) \}_{i=1}^{n} \right)

其中 wiw_i 依證據品質、歸因、重複性與情境完整度調整。

三十一、風格不是單一平均值

如果設計者在不同時期發生明顯轉變，應表示為：

Σd={Σd,t1,Σd,t2,…}\Sigma_d = \{ \Sigma_{d,t_1}, \Sigma_{d,t_2}, \ldots \}

例如：

不可將數十年演化壓成單一靜態分數。

三十二、矛盾不是錯誤

設計原則本來可能存在張力：

PLDST 應記錄：

設計者如何排序衝突原則。

真正的風格往往出現在兩個好目標不能同時滿足時。

第八部分　風格原型

三十三、原型不是互斥類別

以下原型是高維空間中的參考點，而不是八個箱子。設計者可以同時接近多個原型。

三十四、語義極簡建築師

主要特徵：

優勢：

風險：

三十五、實用整合者

主要特徵：

優勢：

風險：

三十六、認知工效設計者

主要特徵：

優勢：

風險：

三十七、機器現實主義者

主要特徵：

優勢：

風險：

三十八、安全邊界建築師

主要特徵：

優勢：

風險：

三十九、表達力擴張者

主要特徵：

優勢：

風險：

四十、組織工程設計者

主要特徵：

優勢：

風險：

四十一、制度演化設計者

主要特徵：

優勢：

風險：

第九部分　代表性資料的示範性解讀

四十二、Wirth：簡潔作為生成原則

Wirth 在 Modula-2 與 Oberon 的歷史回顧中，明確將設計簡潔稱為最重要的指導原則，並把概念清晰、特徵經濟、實作效率與可靠性視為其結果。[R1]

PLDST 不應只把他標記為「極簡派」，而應進一步記錄：

初步風格推論：

高語義經濟
高概念一致性
低特徵冗餘
高實作可理解性
教育與工程雙重導向

四十三、Python：可讀性與開放實用的混合

Guido van Rossum 回顧 Python 時指出：

PEP 20 由 Tim Peters 撰寫，是對 Python 設計原則的濃縮性表達；它是 Informational PEP，不是完整、規範性的語言規格。[R3]

這顯示 Python 風格不是單純「簡單」：

可讀一致性
實用性
生態開放
降低不必要變異
接受工程折衷

它同時避免 ABC 的封閉純粹，又保留 ABC 對清晰表達的重視。

四十四、Go：語言設計服務於組織工程

Go 的官方設計回顧明確表示，Go 主要是為了解決 Google 大型軟體工程的生產力、建置、依賴、閱讀、除錯與維護問題，而不是追求程式語言研究上的突破。[R4]

該文也公開說明垃圾回收的複雜度配置：

PLDST 初步推論：

高組織工程導向
高閱讀與維護優先
偏好有限特徵集合
願將複雜度移給實作者
保留部分機器模型透明度

四十五、Ruby：自然性優先於內部簡單

Ruby 官方介紹將其描述為多種語言思想的平衡，並引用 Matsumoto 對「自然而非簡單」的追求，以及「外表簡單、內部複雜」的設計態度。[R5]

這是一個明確的複雜度配置案例：

Csurface↓⇒Cruntime+Csemantics↑C_{surface}\downarrow \quad\Rightarrow\quad C_{runtime}+C_{semantics}\uparrow

初步風格推論：

高使用者自然性
高表達彈性
接受多種寫法
接受內部複雜
偏好程式設計者愉悅與表達

四十六、C++：相容性、一般性與機器模型

Stroustrup 在 C++0x 設計文章中同時強調：

因此 C++ 不能只被分類成「性能派」：

高機器透明度
高一般機制偏好
高向後相容
高社群多樣性壓力
高演化約束

今日 C++ 的風格也不能完全歸於 Stroustrup個人，因為標準委員會與大型既有生態已成為制度性設計者。

四十七、Rust：從創始風格到制度風格

Rust 的 RFC 流程把重大語言變更放入公開設計、討論與共識程序，目標是為成熟平台建立一致且受控制的演化路徑。[R7]

因此研究 Rust 時至少要分開：

早期創始設計
Pre-1.0 社群重構
RFC 制度
Edition 演化
現代團隊治理

若只給 Rust 一個「Graydon Hoare 風格分數」，會錯誤忽略制度演化。

第十部分　優點與缺點的正確寫法

四十八、避免抽象讚美

「簡潔」「安全」「自然」「實用」本身都不是無條件優點。

每個評價必須寫成：

在什麼場景
對什麼使用者
降低什麼成本
增加什麼成本
在什麼條件下失效

四十九、情境化優勢

例如「高安全約束」可能適合：

但可能不適合：

五十、優點與代價成對輸出

PLDST 的標準格式：

風格選擇 主要收益 主要代價
小型核心 規則少、可推理 程式庫／使用者負擔
強推導 表面簡潔 錯誤解釋與編譯器複雜
高相容性 生態穩定 歷史複雜度累積
多種寫法 表達自由 閱讀與工具一致性下降
強靜態約束 提前排錯 表達與學習摩擦
Runtime 自動化 使用便利 隱藏成本與延遲
元編程 領域表達力 工具與理解困難

第十一部分　歸因修正

五十一、創始人偏誤

著名語言容易被敘述為單一天才作品，但真實設計可能涉及：

PLDST 必須列出共同貢獻者與制度。

五十二、成功回寫偏誤

語言成功後，社群可能把後來形成的優點回寫成最初明確目標。

分析時要分開：

original intention
early implementation
later rationalization
ecosystem outcome

五十三、作品等於作者偏誤

一種語言的缺陷可能不是設計者偏好，而是：

不能把所有結果人格化。

五十四、名言偏誤

設計者的名言適合建立假說，不適合單獨完成分類。

最低要求：

名言+至少兩項決策證據+至少一項反例檢查\text{名言} + \text{至少兩項決策證據} + \text{至少一項反例檢查}

第十二部分　PLDST 分析輸出

五十五、標準個案報告

每位設計者的報告包含：

  1. 歷史情境；
  2. 目標使用者；
  3. 主要問題定位；
  4. 核心設計原則；
  5. 關鍵決策；
  6. 被拒絕的替代方案；
  7. 複雜度配置；
  8. 責任配置；
  9. 相容性與演化；
  10. 治理方式；
  11. 優勢場景；
  12. 失效場景；
  13. 反例與矛盾；
  14. 時期差異；
  15. 信心標記；
  16. 來源分級。

五十六、風格摘要卡

設計者：
主要語言：
分析時期：
主要問題：
核心原則：
風格原型：
複雜度移入：
複雜度移出：
使用者責任：
系統責任：
相容性態度：
治理方式：
主要優勢：
主要代價：
歸因信心：

五十七、數值不應假裝客觀

可以使用 1–5 或低／中／高協助比較，但每個分數必須附：

分數是索引，不是真理。

第十三部分　PLDST SKILL 規格雛形

五十八、輸入

SKILL 可接受：

五十九、處理管線

Entity Resolution
→ Web Research
→ Primary Source Collection
→ Decision Extraction
→ Attribution Classification
→ Context Segmentation
→ Style Mapping
→ Trade-off Analysis
→ Contradiction Check
→ Fact-check
→ Report

六十、來源要求

每次分析都必須重新搜尋：

  1. 官方語言網站；
  2. 設計者原始文章；
  3. HOPL 或同級歷史論文；
  4. 正式提案系統；
  5. 可靠學術研究；
  6. 最新治理與語言狀態。

不得只沿用上一位設計師的搜尋結果。

六十一、輸出物

A. 史實層

只陳述可確認資料。

B. 原話層

列出設計者明確主張，避免斷章取義。

C. 決策層

列出實際功能、拒絕與取捨。

D. 推論層

給出 PLDST 風格判定。

E. 反證層

列出不符合初步風格的決策。

F. 應用層

分析該風格適合與不適合的情境。

六十二、SKILL 不應做的事

不得：

第十四部分　書籍轉譯

六十三、書籍定位

暫定書名：

《設計語言的人：程式語言設計師的風格、選擇與代價》

它不是語言教科書，也不是人物傳記，而是：

以設計決策為單位，研究程式語言設計者如何分配複雜度、自由、安全、效能、可讀性、相容性與治理權。

六十四、章節模板

每位設計者章節可使用：

  1. 他看見了什麼問題；
  2. 他不滿意當時的什麼；
  3. 他最相信什麼；
  4. 他把複雜度移到哪裡；
  5. 他把責任交給誰；
  6. 他拒絕了什麼；
  7. 他的設計在哪裡成功；
  8. 他的風格在哪裡產生代價；
  9. 後來的社群如何改變其作品；
  10. AI 能否模擬這種風格。

第十五部分　限制

六十五、公開資料限制

有些設計決策：

因此部分判定只能是中低信心。

六十六、語言與人難以完全分離

設計者會被：

限制。PLDST 不能把設計風格視為全因。

六十七、評估者偏見

分析者本身也有語言偏好。

因此應：

六十八、分數簡化

高維設計思想不可能被完全壓縮成雷達圖。圖表與分數只適合導覽，完整判斷仍需閱讀決策證據。

第十六部分　結論

程式語言設計史經常被描述為：

但更深一層看，程式語言設計史也是：

不同設計者對複雜度應由誰承擔、錯誤應在哪裡阻止、使用者應有多少自由、機器成本應多透明、舊程式應被保護到什麼程度，以及語言應由誰治理的長期爭論。

因此，PLDST 的研究對象不是單一功能，而是反覆出現的決策規則。

本文提出：

Σd,t=(Context,Problem,Values,Complexity,Responsibility,Evolution)\boxed{ \Sigma_{d,t} = ( Context, Problem, Values, Complexity, Responsibility, Evolution ) }

並主張：

  1. 設計者風格不能由範式直接推出；
  2. 風格必須從多筆決策語料中歸納；
  3. 設計者原話、實際決策與生態結果必須分離；
  4. 個人風格與制度風格必須分離；
  5. 風格具有時間相位；
  6. 每個優點都必須同時描述代價與適用條件；
  7. 任何數值分類都必須附上證據與信心；
  8. 「設計決策人格」是一個研究工具，不是心理診斷。

PLDST 最終要建立的，不是一張誰優誰劣的排行榜，而是一套能夠回答下列問題的分析語言：

當一位設計者面對程式語言不可避免的衝突時，他通常保護什麼、犧牲什麼、把成本交給誰，又如何讓這些選擇在多年之後形成一種可辨識的設計風格？

附錄 A　PLDST 核心公式

A.1 決策記錄

q=(problem,context,alternatives,choice,rationale,allocation,outcome)q = ( problem, context, alternatives, choice, rationale, allocation, outcome )

A.2 風格簽名

Σd,t=Aggregate⁡({wiϕ(qi)})\Sigma_{d,t} = \operatorname{Aggregate} \left( \{ w_i\phi(q_i) \} \right)

A.3 複雜度配置

BC=(Csurface,Csemantics,Ccompiler,Cruntime,Clibrary,Ctooling,Cuser,Cgovernance)B_C = ( C_{surface}, C_{semantics}, C_{compiler}, C_{runtime}, C_{library}, C_{tooling}, C_{user}, C_{governance} )

A.4 責任配置

BR=(Rprogrammer,Rcompiler,Rruntime,Rlibrary,Rtool,Rorganization)B_R = ( R_{programmer}, R_{compiler}, R_{runtime}, R_{library}, R_{tool}, R_{organization} )

附錄 B　來源與參考文獻

[R1] Niklaus Wirth, “Modula-2 and Oberon,” manuscript revised 2006; published in the HOPL-III proceedings, 2007.
— Wirth 對 Modula-2 與 Oberon 的歷史回顧，明確說明設計簡潔、概念清晰、特徵經濟、實作效率與可靠性的關係。

[R2] Guido van Rossum, “Foreword for Programming Python, First Edition,” 1996, Python.org.
— Python 起源、ABC 的影響、Unix／C 使用者、開放擴充、常見情境效率、縮排與可讀性。

[R3] Tim Peters, “PEP 20 – The Zen of Python,” Python Enhancement Proposals.
— Informational PEP，濃縮 Python 的部分設計原則；作者為 Tim Peters。

[R4] Rob Pike, “Go at Google: Language Design in the Service of Software Engineering,” 2012, Go project.
— Go 的大型軟體工程目標、組織情境、垃圾回收與複雜度配置。

[R5] Ruby official website, “About Ruby: The Ideals of Ruby’s Creator.”
— Ruby 的混合來源、自然性、外表與內部複雜度、表達彈性。

[R6] Bjarne Stroustrup, “The Design of C++0x,” C/C++ Users Journal, 2005.
— 相容性、一般機制、語言演化、零額外成本與硬體模型。

[R7] Rust RFC 0002, “RFC Process,” 2014.
— Rust 重大變更的公開設計、共識與成熟平台治理流程。

[R8] Thomas R. G. Green and Marian Petre, “Usability Analysis of Visual Programming Environments: A ‘Cognitive Dimensions’ Framework,” Journal of Visual Languages & Computing 7(2), 1996, pp. 131–174, DOI: 10.1006/jvlc.1996.0009.

[R9] ACM SIGPLAN, HOPL-IV Papers and Content Guidelines, 2021.
— 語言歷史、演化、設計主題、技術準確性與歷史完整性的研究要求。

[R10] Michael Coblenz, Jonathan Aldrich, Brad A. Myers, and Joshua Sunshine, “Interdisciplinary Programming Language Design,” PL’18, 2018.
— 目標使用者、應用情境、品質屬性、形式方法、人本方法與跨學科語言設計。

[R11] Michael Kölling, “Principles of Educational Programming Language Design,” Informatics in Education 23(4), 2024, pp. 823–836, DOI: 10.15388/infedu.2024.29.
— 教育語言中的簡潔、模組性、正交性、可讀性及其現代解釋。

附錄 C　事實、原話與推論標記

後續個案論文統一使用：

[F] Fact：可確認史實
[Q] Quote：設計者或正式文件原意
[D] Decision：可辨識設計決策
[I] Interpretation：本文分析推論
[C] Counterevidence：反例或矛盾
[U] Uncertain：證據不足

附錄 D　第二輪事實校對紀錄

本篇完成初稿後，已再次以官方或原始資料核對下列項目：

  1. Wirth 的來源與年代
    《Modula-2 and Oberon》手稿於 2006 年修訂，後收入 2007 年 HOPL-III 論文集；「設計簡潔是最重要指導原則」來自其摘要，不是本文自行替他創造的口號。

  2. Python 與 PEP 20 的歸因
    Python 的起源、ABC 關係、Unix／C 目標讀者、縮排與可讀性主要依 Guido van Rossum 1996 年文章；PEP 20 的作者是 Tim Peters，文件類型是 Informational，因此本文沒有把它寫成 Guido 親筆或規範性語言標準。

  3. Go 的共同設計與文件作者
    Go at Google 是 Rob Pike 於 2012 年發表的官方設計回顧；Go 的核心設計者包括 Robert Griesemer、Rob Pike 與 Ken Thompson。本文將該文作為 Go 設計共同體的原始材料，而不是把 Go 全部歸因於 Pike 個人。

  4. Ruby 的自然性與內部複雜度
    「natural, not simple」以及外表簡單、內部複雜的說法，可在 Ruby 官方介紹頁找到；本文將其用於複雜度配置分析，而沒有推導為 Matsumoto 的一般心理人格。

  5. C++ 的相容性與零額外成本
    相容性、一般機制、語言演化與 zero-overhead 的表述，均可在 Stroustrup 2005 年 C++0x 設計文章中找到；本文同時標示現代 C++ 已具有委員會與社群制度風格，避免全部歸因於個人。

  6. Rust 的制度歸因
    Rust RFC 0002 的起始日期為 2014 年 3 月 11 日，並將重大變更置於公開設計與共識流程。本文只用它說明制度風格，不將現代 Rust 的全部設計歸於單一創始者。

  7. Cognitive Dimensions 的用途
    Green 與 Petre 將 Cognitive Dimensions 定位為討論與權衡工具，而非一組保證最佳設計的規則；本文沿用此限制。

  8. 複雜度預算的理論地位
    本文的 BCB_C 是分析用啟發式模型，不是嚴格的複雜度守恆定律。成稿已明確寫出，良好統一設計有可能真正降低總複雜度。

  9. 史實、原話與推論分層
    代表性人物段落中的「初步風格推論」均屬本文分析，不等同設計者自我描述。後續個案論文將使用 [F]／[Q]／[D]／[I]／[C]／[U] 標記進一步細分。