意圖

忽然間想到 lukhnos 的這篇〈意圖〉，所以就留了個言：

忽然想起來這一篇，因為我正在寫最笨的版本，
打算再慢慢調整把程式整理到漂亮

那麼，一開始最笨的版本就會留在 git 裡，
只剩下精簡漂亮的程式呈現

不自覺就想到 program derivation 哩

而昨天也在 twitter 上 murmur 了：

source code seldom explains why but explains how. how to improve this without documents?
12:21 PM Jul 6th from web

總覺得我還沒辦法很精確地描繪出 source code 的世界，
但無論如何，邊寫就會想到一些東西。上面提到的狀況是，
我用了兩個整數分別代表 region 和 direct, 前者是 index offset,
後者是一個 0~3 的方向 enum. 現在想想，應該把這部份做出來，
而不是只用整數表達。因為我現在碰到了...

9 個 case, 分別是左上、右上、左下、右下、
左側、上側、右側、下側、和其他所有的狀況。

這個用 if 寫出來實在太複雜了，但我一時想不到什麼好算法。
於是，我仍然先笨笨地列舉所有狀況，然後想辦法把所以運算
收斂到一個可用公式裡。例如：

region = direct = 0

事實上也是可以寫成：

region = x + y * region_width
direct = 0

因為會到這一個 branch 時，表示 x y 都會是 0.
那麼這邊就可以跟其他地方合併了，不用寫特例。
但是特例不寫出來時，我不太好想像是否有一個 general rule 在那。
可能有，也可能沒有，不知道...

這又讓我想到之前在 slashdot 上看到有人在說，
其實 programming 是界於 science 和 engineering 之間。
因為並沒有 science 那麼純粹，但也沒有 engineering 那麼明確。
在 programming 的時候，事實上我們仍然需要找到「問題」

亦即，其實是很難照著 spec 去走，因為 programming 本身
就是一件在尋找 spec 的事情。這恐怕也是為什麼有些 bug
到最後只能變成一種 spec, 有時候並不是不想修或不能修，
而是我們原本所期望的事情，有時候根本就是矛盾而不可能存在的。

我們會希望東西又便宜又好又快又 blah blah 各種優點都有。
但事實上很明顯這種事當然是不存在的。而 programming 時
則會逐漸找出這種根本就不可能發生的事，或是意外找到一些，
意想不到的好處。

因此，design 和 implement 有時候是同時發生的。
因此，OOA/OOD/OOP 有時候是一起進行的。
因此，有 extreme programming 這種說法出現。
因此，有 test driven, behavior driven 等等說法出現。

不過，有時候也會覺得 testing 是一種 over kill,
真的需要 100% test coverage 嗎？
我們需要測試所有的細節嗎？

但像 Agda2 那種什麼東西都要給個 prove,
這樣寫起來又真的是太累了... 而且無奈我太笨學不大起來 @@
更何況，不是 Turing complete 的語言/工具，
應該是沒辦法做所有 practical 的事吧？
termination check 也是讓我感到相當困惑的事...

同時，documentation 也是個疑問。
and, what about literal programming?