我和幾乎所有的common lisp和clos(common lisp object system)的設計者都極度深受麻省理工學院/史丹福大學(mit/stanford)設計風格的影響。這種風格的本質可以用「正確的做法(the right thing)」這個短語來概括。對於這樣的設計者，重要的就是要遵循下面的這些設計理念：
「差點的更好(worse is better)」的理念只是稍微有點不同：
然而，我相信，即使在一種假象的情況下，這「差點的更好」理論也要比「正確的做法」理論有更大的生存空間，也就是說，在軟體開發上，紐澤西理論要比麻省理工理論更實用。
讓我來複述乙個故事，向大家展示麻省理工方法和紐澤西方法之間的真實區別，以及為什麼各個理論的支持者都完全的相信他們的理論更好。
兩位著名的人物，一位是來自麻省理工，另一位來自伯克利學院(但是研究unix的)。一次，他們遇到一起討論作業系統問題。來自麻繩理工的人對its(麻省理工學院人工智慧實驗室的作業系統)非常熟悉，並閱讀過unix的源**。他對unix如何解決pc機的loser-ing問題非常有興趣。當乙個使用者程式呼叫系統例程去執行乙個長時間的、幷包含有重要狀態的操作時，例如io緩衝，loser-ing問題就有可能出現。如果在執行這個操作時，發生了中斷，使用者程式的狀態必須被儲存下來。因為對系統例程的呼叫通常是單指令的，執行使用者程式的pc機無法捕捉到例程的過程狀態。系統例程要麼退出，要麼強行繼續執行。「正確的做法」是退出，復原使用者程式呼叫系統例程的指令，讓使用者程式在中斷之後能重新恢復執行，例如，重新進入系統例程。這被叫做「pc
loser-ing」，因為pc機被強制進入一種「弱勢(loser)模式」，其中，「弱勢」者是麻省理工對「使用者」的一種愛稱。
麻省理工的人沒有看到有任何的用來處理這種情況的**，問紐澤西人，unix是如何處理這種問題的。紐澤西人說，unix人清楚這個問題，但提供的解決方式是針對系統例程通常能正常完成的情況的，當系統例程不能成功的完成執行時，它會返回乙個錯誤碼，指示操作執行失敗。乙個正確的使用者程式這時需要去檢查這個錯誤碼來決定是否需要再次呼叫這個系統例程。麻省理工人不喜歡這個解決方案，因為這不是「正確的做法」。
紐澤西人說，unix的解決方案是正確的，因為unix的設計理論是追求簡單，而這「正確的做法」太複雜。除此之外的好處是，程式設計師能容易的新增這種錯誤探測，重複他們的操作。麻省理工人指出，這種實現方案確實簡單，功能性上的介面卻變的複雜。紐澤西人指出，這就是unix在設計上做出的合適的取捨。實現上的簡單比介面上的簡單更重要。
麻省理工人這時嘟囔著說：有時你需要讓乙個強壯的人去變成一種軟弱的小雞。紐澤西人沒明白他是什麼意思(我也不太明白)。
現在，我開始主張「差點的更好」確實是更好。c語言是一種為開發unix而設計的語言，它的設計採用的是紐澤西方法。c語言因此是一種很容易就能寫出漂亮的編譯器的語言，它要求程式設計師編出的**要易於編譯器去解釋。有些人稱c語言為高階組合語言。早期的unix和c編譯器都非常的簡單，易於移植，需要很少的硬體資源來執行，它提供了你從乙個作業系統和程式語言裡想得到50%—80%的功能。
現有的機器有一半在任何方面都低於中等配置水平(更小，更慢)。而unix和c語言在它們上面執行良好。「差點的更好」理論表明實現的簡單性具有最高的優先順序，這意味著unix和c語言很容易在這些機器上進行移植。因此，如果任何一台機器，unix和c能在功能性上提供50%的支援，那它就會無處不在了。unix和c就是這樣，不是嗎？
「差點的更好」理論另外乙個好處是，程式設計師可以有條件的犧牲某些安全性，方便性，全力去獲得優良的效能和較少的資源使用。使用紐澤西方法開發的軟體既能在大機器上執行，也能在小機器上執行，程式具有很好的可移植性，這是因為它們是在乙個病毒程式是寫出來的。
有一點很重要，初始病毒必須基本上好用。病毒的傳播由於它的可遷移性而得到保證。一旦病毒傳播開來，迎來的壓力會促使它進一步改進，促使增加功能至接近90%完備的水平，但使用者此時已經有條件的習慣了這種比「正確的做法」差一點的東西了。所以，「差點的更好」的軟體會首先獲得人們的接受，然後會有限制的讓使用者降低期望，最後進行改進，直至接近「正確的做法」。在實際情況中，2023年的lisp編譯器當時和c編譯器都是非常的優秀，但是很多的編譯器專家仍然努力讓c編譯器做的更好。
2023年的好訊息是我們有了乙個好的作業系統和程式語言；而壞訊息是它們分別是unix和c++。
「差點的更好」還有最後乙個好處。因為紐澤西式的語言和系統不夠真正的強大來開發出複雜巨型的軟體，大型系統必須在設計上進行元件重用。因此，一種整合的傳統就此迅速出現了。
那「正確的做法」的表現如何呢？我們有兩種常見的模式：「複雜的大型系統」模式和「鑽石類珍寶「模式。
「複雜的大型系統「模式通常像這樣：
首先，」正確的做法「需要去設計。然後實現過程需要去設計。最後，進行實現。因為這是」正確的做法「，它會提供100%預期的功能，實現的簡單性從來不是乙個可考慮的因素，所以你要用很長的時間去完成它。它巨大而且複雜。它需要複雜的工具，工具需要能正確的使用。其中20%的功能會花去你80%的精力，所以，」正確的做法「需要很長的時間來完成，它的執行只有在採用先進技術的硬體上才會表現的令人滿意。
「鑽石類珍寶「模式通常表現如下：
」正確的做法「花了大量的時間去設計，但這種方式，在單個功能點上，其實並沒有占多大比重。這種設計的實現，如果想讓它執行的快，要麼是根本不可能，要麼是超出了大多數開發者的能力。
頭一種模式也是經典的人工智慧軟體的開發模式。
」正確的做法「出來的通常是大型的軟體，但除了」正確的做法「會把軟體設計的巨大外，沒有其它的理由造成這種局面。也就是說，大型軟體裡很多功能是偶然會用到的。
從這些事情中我們學到的知識是，人們通常不喜歡按照」正確的做法「做事。但你最好要採納一半的」正確的做法「，讓你的軟體能像病毒一樣流傳。一旦人們被它吸引，花時間去改進它，使它接近90%的」正確的做法「。
乙個錯誤的認識是只理解表面意思，認為c語言是開發ai軟體有力的**。50%正確做法的方案平常是可行的，但ai上不行。
但是，有一點我們可以下結論，lisp社群真的需要認真的反省一下他們在lisp設計上的立場。我會在以後更多的談論這個問題。
設計的理念
今天在閱讀 設計原本 的第一章的時候，看到乙個名詞 設計理念 的時候，十分驚喜。如果只是說設計本身的話，它可以看做是 乙個受造的事物 當設計作為動詞的時候，就是與這個事物相關的設計過程。這個看到這裡其實並沒有讓我感到很驚喜，但是當看到 設計理念 的時候，我覺得今晚的書沒有白看。設計理念是具備設計整體...
Windows UI的設計理念
windows ui的設計理念由最核心的五個原則組成，它們是 簡潔與快速 clean,light,open,fast 注重排版和布局 celebrate typography 內容重於形式 content before chrome 生動而有靈魂 alive in motion 返璞歸真 authe...
Kafka的設計思想 理念
本節主要從整體角度介紹kafka的設計思想，其中的每個理念都可以深入研究，以後我可能會發專題文章做深入介紹，在這裡只做較概括的描述以便大家更好的理解kafka的獨特之處。本節主要涉及到如下主要內容 一 kafka由來 由於對jms日常管理的過度開支和傳統jms可擴充套件性方面的侷限，linkedin...