因為lisp給你自己定義你自己操作符的自由，你可以把它鑄造成適合你需求的語言。如果你正在寫乙個文字編輯器，你可以將lisp轉化成乙個寫編輯器的語言。如果你正在寫乙個cad程式，你可以將lisp轉化成寫cad程式的語言。如果你不知道你在寫什麼型別的程式，使用lisp也是安全的嘗試。無論你的程式最終會成為什麼樣子，lisp將在你寫程式的過程中演進到寫那種程式的語言。
如果你還不知道你正在寫什麼型別的程式？他是具有一定模式的：（1) 仔細計畫你將要做什麼，然後（2）做。根據這個模型，如果lisp鼓勵你在決定它應該怎樣工作之前開始寫你的程式，那僅僅是鼓勵草率的思考。
恩，並不是這樣的。計畫-實現模式可能對修建大壩或者發動入侵比較有效，但是經驗並沒有表明這是寫程式的好模式。為什麼？可能是因為計算機是那麼的精確。可能程式之間比大壩或者入侵之間有更多的不同。或者是可能（因為在軟體開發的過程中沒有冗餘舊概念的類似物）舊的方法行不通：如果乙個大壩包含30%太過具體，那是錯誤的邊界，但是如果乙個程式做30%更多的工作，那就是個錯誤。
很難說為什麼舊的方法失敗，但是確實失敗了，任何人都能看到。軟體什麼時候能夠按時交付？有經驗的程式設計師知道，不論你怎麼樣精心計畫乙個程式，當你真正寫程式的時候，你會從許多角度發現計畫的各種不足。一些時候計畫將是錯誤的。然而，幾乎沒有計畫-實現的受害者深究基本的問題。取而代之的是，他們責備人的失敗：如果計畫的制定更有預見性，我們將避免所有的麻煩。既然，即使最優秀的程式設計師也會在實現時遇到問題，可能期待人們有那麼多的先見之明要求有些高了。計畫-實現方法可能替換成其它更適合我們限制的方法。
如果我們有正確的工具，我們可以實現不同方式的程式設計。為什麼我們要在實現之前計畫？突進乙個工程的大威脅是，我們將把我們自己畫到角落麗。如果我們有乙個更加靈活的語言，這種擔心會減少嗎？我們做了，並且確實是這樣子的。lisp的靈活性開創了一種嶄新的程式設計方式。在lisp中，你可以在寫程式的過程中做你的計畫。
為什麼要做事後諸葛亮？正如montaigne所發現的，沒有什麼比寫更能澄清你的想法。一旦你擔心進入死角，你可以利用這點。能夠在寫程式的時候完成計畫有兩個重要的結果：可以用更少的時間來寫程式，因為，當你同時計畫和寫程式的時候，你可以聚焦到乙個真實的程式上；程式會更好，因為最後的設計總是演進的產品。當尋找你程式的終點的時候，你只要你維護某個訓導——只要你隨著問題的明朗化，一直盡可能早地重寫錯誤的部分——最後的產品將是乙個比你花費幾周計畫出來的產品更加優雅。
lisp的靈活性使得這種程式設計方法成為乙個實際的可選項。實際上，lisp的最大危險是，它可能寵壞你。一旦你使用一段時間的lisp，你可能會對語言和應用之間的匹配性變得敏感，那樣你就不能在回到其它語言後，感覺到它沒有給你你需要的靈活性。
Lisp 演進設計
因為lisp給你自己定義你自己操作符的自由，你可以把它鑄造成適合你需求的語言。如果你正在寫乙個文字編輯器，你可以將lisp轉化成乙個寫編輯器的語言。如果你正在寫乙個cad程式，你可以將lisp轉化成寫cad程式的語言。如果你不知道你在寫什麼型別的程式，使用lisp也是安全的嘗試。無論你的程式最終會成...
RBAC 設計演進
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
LISP自底向上設計
長期以來，我們一直遵循這樣乙個程式設計風格方面的原則 乙個程式的功能要素不應該太大。如果程式中的某些部件的規模超出了易於理解的範圍，就會造成大量的複雜性，這些複雜性很容易隱藏錯誤，正如在乙個大城市中很容易隱藏罪惡一樣。這種程式難以理解 難以測試 難以除錯。根據這個原則，乙個大型程式必須要分割成一些小...