錢嘛！夠用就好！名嘛！夠唬就好！最重要的是，在任何情況下，依舊能找出合適的方式保持成長的步調 …
— 良葛格 (@caterpillar) 12月 17, 2012
函數式地思考，命令式地實作！... XD
— 良葛格 (@caterpillar) 11月 21, 2012
相同軟體用第二種以上的語言技術開發時，你就知道何謂開發軟體時的附屬性困難 ... XD
— 良葛格 (@caterpillar) 9月 25, 2012
這個社會太過強調速成，太過看待成功的那一刻，少於傳達學藝之路本應如此漫長 ....
— 良葛格 (@caterpillar) 9月 14, 2012
函數式程式設計的要訣是 ... 關掉你的電腦，然後開始寫程式！
— 良葛格 (@caterpillar) 8月 17, 2012
把你的程式一行一行刪掉，答案就會出來！
— 良葛格 (@caterpillar) 8月 15, 2012
... 使得某些需要這種概念的場合，付出額外的功夫來達到相同目的，像是建立過多的匿名函式，而不是善用 Curried function 來簡單地構造新函式。
— 良葛格 (@caterpillar) 7月 31, 2012
將多參數函式轉換為連續單參數函式的 Currying，以及可對 Curried function 作 Partially applied 的概念反而被淡忘 ...
— 良葛格 (@caterpillar) 7月 31, 2012
由於 Currying 與 Partially applied 概念被分離，有些人亦稱可傳回函式的函式為 Curried function，因此可形成 Function chain；進一步地可傳回物件而形成 Method chain 的設計，都可說是 Currying 概念延伸。
— 良葛格 (@caterpillar) 7月 31, 2012
Currying 與 Partially applied 的概念本是一體的，有些語言因為先天模型的限制，不得以才把 Currying 與 Partially applied 的概念分離了 ... XD
— 良葛格 (@caterpillar) 7月 31, 2012
從命令式語言看 Curried function，容易令人有摸不著邊際的感覺，其實在函數式語言中，Curried function 是很自然的特性。當看不清楚特性的本質時，尋找特性的起源點，往往令人驚訝特性本質如此單純，接下來就會有一連串意想不到的收獲。
— 良葛格 (@caterpillar) 7月 31, 2012
Pattern match 進行的解構動作，與 Algebraic data type 值的建構動作是相反的，也就是取得值的 Component 方式早已定義好了。
— 良葛格 (@caterpillar) 7月 24, 2012
Abstract data type 因為一開始就強調狀態與操作的隱藏，自然無法運用 Pattern match 比對結構與代換值，對於某些共用實作也需自行動手定義。
— 良葛格 (@caterpillar) 7月 24, 2012
Algebraic data type 強調資料的結構與代換定義，就可使用 Pattern match 輕易分析資料，對於 Type classes 的衍生也就無需額外處理。
— 良葛格 (@caterpillar) 7月 24, 2012
Abstract data type 著重資料的狀態與操作封裝，Algebraic data type 強調資料的結構與代換定義。
— 良葛格 (@caterpillar) 7月 24, 2012
函數式的思考，可專注在發掘資料的規律性，而非先受限於程式語法，這有助於將程式設計為語言，而非用語言設計程式。
— 良葛格 (@caterpillar) 7月 14, 2012
那些 JavaScript 的 Wat 只是在傳達一件事，不要依賴 JavaScript（或其他語言）的弱型別行為，曖昧這種事很美，但只限用在連續劇情節中，現實中最好別搞曖昧這種事 ... XD
— 良葛格 (@caterpillar) 6月 17, 2012
抽象用以涵蓋可能的各種細節，如果想暸解的是某個細節，那就不該從抽象下手。
— 良葛格 (@caterpillar) 6月 9, 2012
如果 OO 與 FP 在歷史發展過程中普及程度相反，人們是否會厭倦 FP 的思考模式而回頭歌頌 OO 的典範，然後拚了老命在 FP 語言中實現 OO 的概念？
— 良葛格 (@caterpillar) 5月 16, 2012
JavaScript 真是可憐，先是被當成只能耍猴戲的小丑，後被當成類別功能不全的殘廢，現在又被迫到處演出函數式設計的戲碼…XD
— 良葛格 (@caterpillar) 5月 11, 2012
僅具備一級函式特性的語言，只是提供更多抽象的機會，如果還要考慮效率等可讀性議題，還得有 Lazy、Curry、Partially applied 等特性，要不就有苦命人辛苦實作出來嘉惠他人，要不就祈禱語言未來版本提供底層實作或語法支援讓大家都鬆一口氣，不然就直接用純函數式語言吧！
— 良葛格 (@caterpillar) 5月 11, 2012
以前看過，繼承時應盡可能只重新定義方法，而少定義新方法，最近看到，繼承時重新定義方法可能都不是好的實踐。單看似乎前後矛盾，但前者是指父類別 中的方法盡可能作到抽象，後者是指避免整個重新定義父類別中的具體方法。
— 良葛格 (@caterpillar) 4月 27, 2012
物件導向將真實世界在電腦中作類比，而非真正地抽象為資料。類比可能不正確，而抽象程度不夠，實際世界有了更動，程式類比也會跟著修改。然而好的類 比令人易於理解抽象，也許真正抽象只有數學家辦得到，而大多數開發者從不會是這個角色。選擇物件導向或是函數式，取決於團隊中大多數是凡人或數學家。
— 良葛格 (@caterpillar) 4月 27, 2012
可從多個來源繼承實作，無論是 default method、Trait 或是 Mixin，都會引入複雜度，也容易發生衝突或不自覺破壞某些東西，這畢竟是把雙面刃，真正的問題還是在於，繼承而來的東西往往過於具體而不抽象，即便只有單一繼承也是這 個問題。
— 良葛格 (@caterpillar) 4月 24, 2012
就如 Imperative 需要訓練，FP 也需要訓練，大多數人一開始接受的訓練多是前者，思維一旦定形，要改變就更難，FP 要流行，得從接觸程式設計的源頭開始，至少得是與 Imperative 同等重量的訓練，甚至加上數學能力的培養。
— 良葛格 (@caterpillar) 4月 17, 2012
如果語言中只具備函數式設計的一兩個元素，就應將那些元素善用在可以與原語言適切結合的場合，而不是硬作函數式設計。
— 良葛格 (@caterpillar) 4月 7, 2012
例如 +、-、*、/ 在 Haskell 中確實是函式，但可用中序形式呼叫，且不使用逗號與括號，也就是 - * + 1 2 3 4 可以寫成 (1 + 2) * 3 - 4，實際上這還有 Curried function 的特性在裏頭。函式只是支援函數式設計的一個元素，不是全部！
— 良葛格 (@caterpillar) 4月 7, 2012
在不支援函數式特性的語言過度實現函數式設計原則，只會事倍功半或失去可讀性、執行效率等問題，用不支援函數式特性的語言過度解釋函數式設計原則， 對於推廣反而適得其反。
— 良葛格 (@caterpillar) 4月 7, 2012
函數式設計並不是一定要把程式寫成函數，這是普遍的誤解！你可以寫 (1 + 2) * 3 - 4，幹嘛要寫成 subtract(multiply(add(1,2), 3), 4) ！
— 良葛格 (@caterpillar) 4月 7, 2012
問到函數式程式可讀性如何？就是在問數學定義的可讀性如何？就等於在問自己是否有數學家的閱讀與思考能力？
— 良葛格 (@caterpillar) 4月 4, 2012
在純函數式語言中，程式實作在外觀上幾乎就等於數學定義。
— 良葛格 (@caterpillar) 4月 4, 2012
函數式設計是思考如何以數學形式定義問題，配合函數式特性的語言來撰寫定義，電腦就能根據定義求出解答。
— 良葛格 (@caterpillar) 4月 4, 2012
存起來的錢用掉就沒了，存起來的時間卻可反覆使用。
— 良葛格 (@caterpillar) 3月 18, 2012
只要每日認真投資，有時需要的只是等待。
— 良葛格 (@caterpillar) 3月 17, 2012
新特性加入語言的價值，在於是否可在最小衝擊下，由內而外對該語言生態發生重大改變，而不是由外而內，與其它語言類似特性比較熟優熟劣。
— 良葛格 (@caterpillar) 3月 15, 2012
人生如此漫長，有什麼好急的？人生如此短暫，有什麼好爭的？
— 良葛格 (@caterpillar) 2月 29, 2012
Java的生態是慢慢形成的，Rails則是一開始就是生態集合體，雖然表面上只有Rails一個技術名詞，但實際上包括的是整個開發生態的觀念。
— 良葛格 (@caterpillar) 2月 23, 2012
金錢投資得宜可以贏得更多金錢，時間投資得當可以贏得更多時間，後者遠比前者重要，但前者往往比後者得到更多的關注。
— 良葛格 (@caterpillar) 2月 18, 2012
Rails 是名符其實的［框］架，它透過裁剪它認為不適合的設計來降低開發的複度，用 Rails，你得全面暸解並確定你願意遵守它全套作法，那麼你就會很高興，不然你會很不爽，要嘛上天堂，要嘛下地獄！
— 良葛格 (@caterpillar) 2月 17, 2012
查資料，動手測，想範例，寫文件，我學東西真的很慢就是這樣！...XD
— 良葛格 (@caterpillar) 2月 13, 2012
文件記錄要有自己的流程與架構，如果受到官方文件的風格牽制，只會越寫愈無趣，也沒有意義。
— 良葛格 (@caterpillar) 1月 20, 2012
取得彈性犧性了效能，預設功能換來了一堆選項，隱藏的複雜度將來某處終究會遇到，出來混的總有一天要還的.....XD
— 良葛格 (@caterpillar) 1月 19, 2012
取得資訊的成本越來越低，但過濾資訊的成本越來越高，最終有用資訊的成本存在一個臨界點！
— 良葛格 (@caterpillar) 1月 16, 2012
與其說Rails是一個框架，不如說它是一個語言！
— 良葛格 (@caterpillar) 1月 15, 2012
Rails 的文件不算少，不過感覺都很跳躍，解釋某個主題時，往往讓我有種嘎然終止的感覺，為了填滿這種感覺，得花上另一段時間搜尋另一個文件，不過文件的重複性，以及 Rails 的快速改版都造成不少雜訊，找來頗費工夫 .... XD
— 良葛格 (@caterpillar) 1月 11, 2012
Rails 的 Layout 像是在 JSP 中作 <%@ include %>，Rails 的 Template，像是在 JSP 中使用 Tag File，Rails 的 Helper，像是 JSP 中的自訂 Tag。
— 良葛格 (@caterpillar) 1月 11, 2012