昨天和今天，我花了一些時間在 linenoise（http://github.com/antirez/linenoise）上，這是一個極簡的行編輯函式庫，設計用來作為 readline 簡單而輕量的替代品。
我試著合併幾個 pull request、修復一些問題，同時也做了一些重構。那是一種近乎涅槃的感覺：對一小段完整自足且實用的程式碼擁有完全的掌控。

簡單的程式碼有某種特別之處。我在此指的並非為了對抗複雜度或過度工程而追求的簡潔，而是簡潔本身，是自我指涉的、若非為了美、易懂與優雅便別無目的的簡潔。

畢竟，程式設計的世界向來對小程式著迷。數十年來，程式設計師們在 1k 或 4k 的限制下挑戰自我，從 6502 組合語言到今日的 JavaScript 競賽皆是如此。
甚至連國際 C 語言混淆程式碼競賽，歸根究柢也有很大一部分是在於極簡主義。

為什麼動手鑽研一小段程式碼會如此美妙？是的，它又小又簡單，這就是兩個很好的理由。它可以被完全理解、完全掌握。你可以耍點小聰明，因為只有在小程式碼中，程式設計上的聰明才會有回報，畢竟在大型專案中，長期來看顯而易見遠比耍聰明來得好。然而我相信不止於此，而是小程式可以臻於完美。如同由寥寥數語構成的十四行詩那般完美。對大小與範疇的限制，構成了一種智識上的策略，用以避開「或許可以更好」的陷阱，而這個「更好」實際上既無法衡量也不顯而易見。在這些嚴格的限制之下，程式「做了什麼」遠比它「沒做什麼」來得有趣。事實上，限制反而是讓解法創意得以滋長的最肥沃土壤，否則這些創意很可能毫無用處：在規模化的世界裡，做任何事總有更正確、更被理解、更為正統的方法。

在 Microsoft 創業初期的一次訪談中，Bill Gates（比爾·蓋茲）描述過在撰寫著名的 Microsoft BASIC 直譯器時的這種感受。當時的限制，與我們今日為了樂趣、在競賽中、或僅僅為了好玩而自我施加的限制如出一轍。曾有一整個世代的程式設計師能夠在自己的創作中體驗完美，在那個空間與時間都極度匱乏的領域裡，一項改動是否真正帶來了程式的改進，是顯而易見且可以被衡量與理解的。那裡沒有容納浪費與不必要複雜度的餘地。

今日的軟體在某種程度上是軟體另一種現實的勝利：層層複雜度堆疊出了令人難以置信的裝置，或是在非專家手中也能發揮無數可能性的基礎設施技術。然而，或許我們仍應從那個軟體可以完美的古老年代保留下一些東西，那就是你所創造之物擁有結構、而不只是一堆能跑的程式碼的感覺。只要你把視野拉得夠遠，就會發現你的大型程式其實又變得相當渺小，而至少在這個尺度上，它應該要像完美的樣子，或至少，以此為目標。