Re: [連結] 松本行弘: Code 的世界~成為超級程式設 …

看板Ruby作者ericyu (Eric)時間15年前 (2009/08/09 13:59)推噓14(14推 0噓 0→)

留言14則, 14人參與討論串11/16 (看更多)

拿到書了，片段片段摘譯了前言與第一章的部份內容。歡迎指教有問題的地方。（有些地方也沒辦法看得很懂...） = 前言 = 本書並非深入講述特定技術的書籍，也不是 Ruby 解說書，而是俯瞰程式開發技術的一本書。不是詳細地圖，而是技術的世界地圖。每種技術和考慮都有其目的與歷史，以及發展和進步的經緯。本書嘗試退一步重新思考這些技術。本書 2~14 章是以 2005/5 ~ 2009/4 間在日經 Linux 雜誌連載的專欄為底，添加內容與修正。第一章「我為何要開發 Ruby」則是新寫的。 = 第一章我為何要開發 Ruby = Ruby，在日本誕生的程式語言，近年來特別因為在 Web 方面的高生產力而受到世界注目，應用範圍也廣及企業領域。不過一開始也不是因為要讓世界使用等理由而開發的，只是身為工程師的我為了興趣而開始的。若問我為何要開發 Ruby，最適當的答案應該跟 Linux 開發者 Linus Torvalds 所說的一樣： "Just for fun" 從高中開始學寫程式時，不知怎麼的就被程式語言吸引。周遭喜歡電腦的人通常是「想做遊戲」、「想計算」等「要寫什麼程式」，而我則被「要用什麼程式語言」、「用什麼程式語言會更愉快」這些事情沒來由地吸引。高中時還沒有自己創作程式語言的技術與技術，連自己的電腦也沒有。但是讀了程式語言的文章與書籍，後來大學時研究主題選了程式語言，十年後以 Ruby 的形式實現了夢想。 1993 年開始創作 Ruby 以來雖經過 16 年，中間從沒有討厭或厭煩了 Ruby 的設計過。程式語言真的很有趣。 == 程式語言的重要性 == 因為語言是人類思考的本質。語言會影響說話者的思考。（這裡還提到 Sapir-Whorf 假說，請見 http://tinyurl.com/krz6nv ） 20 年來的名著「人月神話」也提到「程式人員一定時間內能產出的程式碼行數是一定的，不論用什麼語言」。假設這是真的，那麼一天五百行，用組合語言，C，或是 Ruby 都是五百行。但這五百行能做到的事有天壤之別，根據選擇的語言，可能有十倍百倍甚至千倍的差距。沒有軟體的電腦只不過是個箱子，能夠更快速更便宜地開發程式語言是我們所企求的。寫程式不只是為了樂趣，還要為了社會整體變化追求高生產力。程式語言因此成了解決軟體危機的重要工具。 == Ruby 的原則 == Ruby 原來只是我為了興趣而作的，其設計參考了古今東西的語言，這個功能好，那個功能有點... 等，在之間取捨平衡與選擇。什麼都不思考就拿進來的話，會成為扭曲的語言，喪失新語言的存在價值。語言設計困難之處就在這之間的取捨，幸好 Ruby 在這方面做得不錯，許多人都給了不錯的評價。 Ruby 的目標是為了讓我（設計者）能夠快樂地寫程式，並因此提高生產力。因此，有以下三個設計原則： * 簡潔性 * 延展性 * 安定性 == 簡潔性 == Paul Graham 說「簡潔就是力量」。隨著程式語言進步，我們能夠更簡潔地書寫，更抽象化。電腦性能提昇也讓以前程式語言不允許的事情變得可能。譬如物件導向語言，執行時成本較高，但現在是能允許的。為了能提高開發生產力，稍微浪費一些電腦性能，在現在這時代大家也不會生氣。另外像是記憶體管理，現在就交給 garbage collection。變數型別在執行期才檢查。來看看階層計算的例子。圖一 Java class Sample { private static int fib (int n) { if (n<2) { return n; } else { return fib (n-2) + fib (n-1) ; } } public static void main (String[] argv) { System.out.println ("fib (6) ="+fib (6)) ; } } 圖二 Ruby def fib (n) if n<2 n else fib (n-2) + fib (n-1) end end print "fib (6) =", fib (6) , "\n" 演算法相同，但 Ruby 的看起來密度較低。Ruby 不需要明確給定型別，不必要的型別指定可以省略，因此可以較簡潔。演算法教科書使用虛擬程式碼來描述演算法，若要實際使用，就要處理類似指定型別這些非本質的部份，而無法集中在演算法的本質部分。如果能直接執行虛擬程式碼不是很好嗎？像 Ruby 這樣以高生產力為目標的語言就是這種「可執行的虛擬程式碼」。 == 延展性 == 1999 年第一本 Ruby 書寫到 Ruby 不適合的領域是「數值計算為主體的程式」以及「數萬行的程式」。不過在幾年後，已經有數十萬行的程式，連 NOAA 及 NASA 也在使用 Ruby。為了程式語言的延展性，需要「抽象化」 (abstraction)。Ruby 開發當時 (1993) 沒什麼人認為可以在 script 語言裡用物件導向程式，連內建型別都是都以 class library 方式提供的可說是相當稀奇。之後看 Ruby 的成功，我想這個判斷是成功的。 Ruby 的延展性可不只這些。例如像 Lisp 的一樣的高階函式語言內的 block，用程式人員容易理解的方式提供，將控制結構 (control flow) 這種高階函數語言中也能讓使用者自行定義的延展性提供給「普通人」。另外，能夠自由擴充既存 class 的 open class，也提供了更大的彈性（以若干危險性交換）。這些功能的共通點是，對程式語言來說，對程式人員提供最大程度的延展性的這種態度。另外，不是保護程式人員寫錯的安全性，而是重視能自行負責、提供最大程度能力的彈性。身為 Ruby 設計者的我是 Ruby 最初的 target user，因此，比起保護自己，能夠發揮自己最大程度的力量更為重要。關於延展性，還有一個不能不提的是，「沒有先入為主的限制」。例如初期的 Unicode（全世界文字只需 16-bit 即可容納），西元年份兩位就夠引起的 Y2K 問題等。Ruby 整數的表現範圍沒有限制，盡力做到排除這種先入為主的限制。 == 安定性 == 即使是非常重視延展性的 Ruby 也有長年拒絕加入的功能，也就是巨集 (macro)，特別是 Lisp style 的巨集。有了巨集，可以隨意擴充語言。為了 Ruby 拒絕此功能？因為此功能會造成各程式發展到最後就如同不同語言一般，有不同的文法與單字。程式設計除了寫以外，讀也會花許多時間。解讀時的路標就是語言的文法。「這裡是呼叫函式」、「這裡是條件分支」等常識在解讀程式時是很重要的。若導入巨集功能，會引起嚴重的副作用，這裡到底是函式呼叫，控制結構，還是要代入什麼，得再查文件才能知道。嗯，也許世界上也有不會為此所苦的 Lisp 程式人員，不過我認為這只是少數人。要能在世界上普及的程式語言，我相信必須要有「不為風所搖動的核心」的文法。 == 都是為了樂趣 == 程式語言存在目的是為了生產程式，以及盡可能有效率地生產。還有與程式設計的快樂連結在一起。在國外活動等演講後，有許多人跟我交談，其中典型的就是「用了 Ruby 以後又能快樂地寫程式了，謝謝。」寫程式本來就很快樂，是既刺激又富創造性，讓人興奮的知識活動。我想起中學時用 BASIC 這種貧弱的語言寫程式時也很快樂，不過也有因為工作、期限等而造成不快樂的程式撰寫，這是世間常情。即使如此，Ruby 所提供的生產力若能解開程式人員身上的枷鎖，重新找回程式設計的樂趣的話，那就是我開發 Ruby 的理由。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.31.3