perl, and the way we speak

有時候會覺得搞不好自己很適合寫 perl, 儘管我從來就沒真的寫過，
也沒理解過 perl 到底在寫些什麼。但我向來討厭死板板的寫作如
java, 簡直是一字一句都有標準，令人窒息的沉悶似的。
雖然我自己寫起來有時候也會自成一種風格諸如此類的...
主要還是想嫌他的 library 用起來很不方便吧，我想。
不是說 decorator 不好，而是至少要提供幾個簡單的包裝。
也有可能是我覺得好的程式實在應該遵照 UNIX philosophy,
因此程式不應該長大到需要用這麼多龐大的架構，諸如此類。

或許 ruby 找到了一個我最滿意的平衡點，靈活多變的作法，
根據不同的情況，選擇不同的方法，使得程式風格能適應任何情況。
library design 也不是 state based, 可以輕易寫出
one linear. 難懂嗎？不，應該是看情況吧？其實這跟說話
與寫作，我覺得仍然是相似的。根據不同的聽話對象，我們當然
會用不同的方式來說話。如果聽話者對於 context 不夠熟悉，
當然就不能假設太多 context. 反之，大量使用黑話，卻能
有效增進傳達的效率。

程式是寫給人看的，但同時也是寫給機器看的。也有些程式只要給人看，
也有些程式只要給機器看。如果限制了一定要怎麼做，那就很難在
各種情況都做到最好了。當然，完全的 general purpose 也是
不可能的，因此選擇應該用什麼，當然也會是很重要的一個選擇，
而不是進入了什麼世界，就永遠停留在那個世界了...

當然如果永遠總是說 it depends, 那跟放大絕也沒什麼兩樣。
只是我覺得，還是不要太過於強調怎麼樣一定對比較好...
像是廢話似的，但之所以仍然會想說，當然是因為看了不少另一面說法。
我們當然也總是會試著尋找最簡單的答案，把一切都簡化，
於是只要一個答案就能解決所有問題。有時候這樣確實簡單得多，
但有時候這樣卻只會迷失於各種問題之中，或是誤以為這樣就是最好了..
說來說去又回到了程度問題，另一個大絕招。

剛剛翻到語言本能的這段話：

這對聽話的人來說是個恩賜，因為剖析器知道說話的人不可能把任何東西
移開這個片語，所以就不必為他找語跡，省了很多心思。但是聽話人的
恩賜就變成說話人的負擔，因為他必須要為這種片語找個代名詞，就像在
"That's the guy that you heard the rumor that Mary likes him."
中的 him.

也許換成程式看起來會像是這樣：
a = f(x)
b = g(a)
c = h(b)
跟這樣比吧？
c = h(g(f(x)))
很多時候想「代名詞」究竟要叫什麼其實是很頭痛的事。例如：
user = f(x)
user_updated = g(user)
user_updated_again = h(user_updated)
和
user = h(g(f(x)))
的差異吧... 想一堆沒什麼意義的名字，最討厭的是往往沒有真正好的
名字可以用。什麼 updated 和 updated_again, 或是 tmp_ 或是
_tmp 諸如此類的名字，說穿了其實也沒什麼意義。叫 2, 3, 4 也是一樣。

溝通是雙方面的，沒人想說或是沒人想聽的話，溝通就不成立了..
而寫程式，不管怎麼樣，至少電腦或是機器是一定會聽的，
不然就不叫程式了 :D