若只能用一句話總結，那麼我會說pseudo code要讓電腦讀懂。
pseudo code的興起是因為人類大腦很難一步到位，把心中的想法具體寫出來，於是人類想到中間態，divide and conquer，分成幾步把code完成。這裡的難題是人類的語言非常高階，機器卻只能理解低階的指令，電腦的發展是從邏輯閘、暫存器、加法器、乘法器、比較器...模組化一步步組合起來的，愈組合就愈高階，很可惜距離人類語言還很遠。
解構一個高階指令，舉例來說，求兩點之間距離。"距離"這觀念電腦不懂，第一層解構可以是：座標相減->各自平方->加總->平方根。(座標相減、各自平方)大概需要第二層解構，如此反覆直到所有解構都夠低階到電腦讀得懂。coding至此完成，不同的解構就是各個programmer的功力造化了。
我目前認為clojure語言在這方面是做得最好的：if, when, let, first, last, second, is, some, some?, every? not-any? 這些指令在Clojure裡都有定義，而這些在其他電腦語言卻不完整，雖然說也不難實現，但怎麼沒有明確提供呢？這裡的心得是，指令(應該)是目的性很強、人類一目了然就可以理解的事情，以致於我幾乎不需要知道「求距」是怎麼實作的。我看到「走回原點」，會比看到「上上下下左左右右」要來得清楚；我說「求距」，會比「座標相減->各自平方->加總->平方根」要來得清楚；說排序，大家都知道結果該有什麼特徵，說排序方法，那可有百百種，容易見樹不見林。
前者是目的purpose，後者是方法implementation。對人類來說，給目的是清楚的；對電腦來說，給方法才清楚，在0、1布林運算的世界，加、減、乘等也可以理解成是人類賦與意義(好讓人了解)在各個規則上。解構的過程本身就是在創造"方法"，然而精神是盡量用"目的"來實現。
所謂的friendly language，即是人類可以讀懂、機器也可以讀懂的折衷語言。既然我們軟體工程師的目的是要機器照著我們的意念走，直接跟機器溝通、從機器得到反饋才是正解。waterfall methodology的世界恐怖多了：軟體工程師A寫文件給B讀，由B理解後實現code，執行得到電腦反饋給A。既然A、B兩個人都是軟體工程師，為什麼文件這東西需要存在？試想，B要理解A的文件本身就有容易誤會。不如一切都是code，code就是文件，人類讀得懂的文件。
沒有留言:
張貼留言