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

簡單的程式碼有某種特別之處。我指的不是為了對抗複雜度或過度工程而追求的簡潔，而是單純為了簡潔本身、自成目的的簡潔，若真要說有什麼目的，那就是美、易懂與優雅。

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

為什麼動手寫一小段程式碼會這麼過癮？是的，它小而簡單，這就是兩個很好的理由。它可以被徹底理解、完全掌握。你可以耍點小聰明，因為小程式是這個世界上唯一一個寫程式時耍聰明會有回報的地方，畢竟在大型專案裡，長遠來看，直白易懂遠比聰明來得好。然而我相信原因不只如此，而是小程式可以臻於完美。就像一首由寥寥數語構成的十四行詩那樣完美。對大小與範疇的限制，構成了一種智識上的策略，用來避開「或許還能更好」的陷阱——當這種「更好」其實無法被具體衡量、也並不明顯的時候。在這些嚴格的限制之下，程式「做了什麼」遠比它「沒做什麼」來得有趣。事實上，限制反而是激發解法創意最肥沃的土壤，否則那些創意很可能毫無用處：在規模化的世界裡，做任何事永遠都有一種更正確、更被理解、更正統的方法。

在微軟創業初期的某次訪談中，比爾·蓋茲曾描述過他在撰寫著名的 Microsoft BASIC 直譯器時的這種感受。那時的限制，和我們今天為了樂趣、在競賽中、或僅僅為了好玩而自我設下的限制是一樣的。曾有一個世代的程式設計師能夠在自己的作品中體驗到完美，在那個空間與時間都極度匱乏的領域裡，一個改動是否真的讓程式變得更好，是顯而易見、可以被衡量與理解的。那裡沒有容納浪費與不必要複雜度的餘地。

今日的軟體，在某種程度上是軟體另一種現實的勝利：層層堆疊的複雜度，帶給我們不可思議的裝置與基礎設施技術，讓非專業的使用者在手中也能掌握無數的可能性。然而，或許我們仍應從那個軟體得以完美的古老年代保留下一些東西——那種感覺，你所創造的東西是有結構的，而不只是一堆湊合著能跑的程式碼。如果你把視角拉得夠遠，會發現你的大型程式其實又變得很小了，而至少在這個尺度上，它應該要近似於完美，或至少，以此為目標。