C++ 為什麼會被設計成現在這個樣子，我一直認為和 Bjarne Stroustrup 的個人背景有很大關系。按照 Stroustrup 自己在 《The Design and Evolution of C++》裡的描述，設計 C++ 的動機來自於他完成博士論文的時候編寫一個模擬器缺乏合適的工具。從這段描述裡，我冒昧地認為 Stroustrup 暴露了他早期的局限性，他意識到必須有更好的工具來管理系統的復雜性，但是眼光僅僅局限在源代碼的層次。他的模擬器是一個單獨的 monolith，在尋求更好設計時，Stroustrup 僅僅追求如何更好的管理這個 monolith 的內部結構，未曾考慮任何更高一級的方法——比如把 monolith 分割成相互協作的更小的模塊——來提高系統的可維護性。
C++ 在 UNIX 上受到的歡迎程度最低，正是因為 UNIX 提供了更多的組織系統的方法，這些方法能夠，而且經常是更好的代替源代碼級別的方式。UNIX 不僅提供了進程和 IPC，讓這些方式成為可能，而且還從一開始就不斷尋求降低這些方法的開銷，讓它們相對於源碼級的管理方式——也就是語言——更加有競爭力。所以，在 UNIX 上 C++ 沒有獲得它在其它一些操作系統中獲得的那種主導地位。
在《The Art of UNIX Programming》的3.1.3節說的很清楚，“如果操作系統讓創建進程的操作過於昂貴，或者讓進程控制的操作過於困難或者過於死板，⋯⋯就會鼓勵 (在一個較大的 monolithic 模塊內部使用) 像 C++ 一類的源代碼級別的內部分層結構，而不是 C 這樣的 (在相互協作的小模塊中) 相對平坦的內部結構。
我常說一句不太准確的玩笑話—— “C++ 就是微軟捧起來的” 。其實也不是全無道理。作為在 PC 發展的黃金時代最廣泛應用的操作系統，Windows 沒有提供太多的系統級機制來管理應用軟件的復雜度，開發者只能著眼於源代碼級別的內部結構，尋求 C++ 之類的語言幫助。
C++ 的興起和 PC 上 anti-UNIX 風格暫時的主導地位有很大關系。Stroustrup 的發明是對 UNIX 上管理系統復雜度的方式的一種不高明的重復。這種重復為那些由於歷史原因或者因為經濟原因 (比如過弱的硬件支持和操作系統支持) 沒有普及 UNIX 文化的領域提供了一種似是而非的，擁有短期效益的替代品，因而受到了歡迎。
UNIX 文化鼓勵通過進程和進程協作來降低單獨模塊的內部復雜度，而不贊成用 C++ 的方式來 “管理” 內部復雜度。事實上，UNIX 文化認為 C++ 的方式在鼓勵過度的內部設計而不是有效的對其進行整體管理。
另一方面，C++ 不光忽略了在單個 monolith 的層次之上的管理方式，還低估了現有手段在單個 monolith 中應對復雜度的能力。做出這種錯誤判斷的不只 Stroustrup 一人，在 90 年代操作系統領域興盛一時的對 micro-kernel 的研究中，研究者和很多業界開發者都認為操作系統內核的復雜度已經到了必需捨棄 monolithic 式的內核設計，由 micro-kernel 加 user-space 進程實現的服務來替代。Linux kernel 的出現及時證明，用 C 這樣的技術也足以很好的管理單個 monolithic kernel 的復雜度。Linux kernel 不光和很多 monolithic 內核同樣穩定，還在性能和設計復雜度上擁有天然的優勢。(比如，對於 Minix 的單線程文件系統的抱怨，其設計者反駁說該 feature 很好實現——但是始終沒有真正實現，而對於 monolithic 內核來說，多線程文件系統幾乎是自然而然的設計。)
今天，如果你把系統中某個組件的復雜度設計的比 Linux kernel 還高，那是一種罪過而不能被認為是必需使用 C++ 的理由。
C++ 的興起，在我看來很大程度上是不是一段普通的歷史，而是反映了整個業界的一個錯誤。正如《The Art of UNIX Programming》所說，上世紀80年代，由於各個 UNIX 廠商的愚蠢，UNIX 文化曾經一度奄奄一息。而 UNIX 社區的開發者們又一再忽略興起的 PC 市場 (而忘記了 UNIX 自己就是在 mainframe 的廠商忽視了 mini-computer 的情形下發展起來的)。在整個世界缺乏 UNIX 文化的情形下，出現了 C++ 這樣畸形的嘗試。
我承認世界並非完美。有些錯誤已經成為文化的一部分被保留下來。但是 UNIX 文化因為它強大的生命力終於逐漸回歸。這顯示出 C++ 不屬於那類可以出於歷史和文化原因而被永遠保留的錯誤。這個錯誤至少應該不被擴大，並且可以被逐漸糾正。
