PLT-Scheme Contracts

一歩一歩讀著「Guide: PLT Scheme」，讀到 PLT Scheme 的 Contracts。我使用 Eiffel 的 Design by Contract 多年。感到 PLT Scheme 的 Contracts 設計過於瑣碎。缺少 Eiffel 的簡單明瞭容易使用。

但是 PLT Scheme 的支持者說 PLT Scheme 的設計是健全的。我不禁好奇又感到懷疑。Behavioral Contracts and Behavioral Subtyping 嘗試說明 Eiffel 的問題。但顯然文章的作者不瞭解 DbC。DbC 的設計，在繼承的子類別處，precondition 可以放寬， postcondition 則必須更緊縮。這文章不同意 DbC 的看法。舉了以下例子：J 繼承 I。J 和 I 都有一個函式 m (x)。m 的引數 x 在 I 中的要求是 x>0。在 J 中的要求是 x > 10。於是 Eiffel 的 DbC 認為使用 J 的 m 時 x 可以為 5。但這篇文章認為不行，使用 J 的 m 時 x 必須大於 10。我同意 DbC 的作法。J 是 I  的繼承者，必須繼承 I 的責任和義務。在 I 中認為只要 x > 0 就有資格使用 m 這個函式時，J 的函式設計就必須滿足這條件，否則，J 不應該繼承 I。J 中的 m 寫著 x > 10。只是說明 J 中的 m 承諾在 x > 10 時可以使用 m。透過繼承 J 還同時承諾了 x > 0 時也可以使用 m。因此，雖然 x > 10 這條件有點多餘，但不表示它是錯的。

這讓我對 PLT scheme 的 contracts 設計感到失望，也許這就是為何 PLT Scheme 一直無法推出 Class 的 contracts 的原因：他們根本想錯了。

風雨將至？Scheme 來援？

出於興趣，工作之餘，我撰寫網路游戲，透過這努力，我吸收新的，工作以外的專業技術。這是必須的，因為，工作的內容常一成不變，以致於人無法單靠工作成長。在技術瞬息萬變的軟體世界，不成長就等著被淘待。在休閒時撰寫網路游戲，使我能任意選擇我想要學習的技術，也沒有工作上必須完成的壓力，能依自己的狀況或快或慢，漸進地成長。

雖說技術瞬息萬變，但值得學習的常常是那些老舊的東西，那些老舊但又能持續推陳出新的東西。在此我指的是一種古老的語言：Scheme。我在前幾天發現 PLT Scheme 提供了 Web Server。

對於 Scheme 這語言，我早充滿好奇。一直沒能派它上用場，只能止於欣賞，無緣深入。我開始撰寫網路游戲時，未曾考慮它。我使用 Javascript，另一個我以為值得學習的語言。我以 Helma NG 為我開發的平台。在這過程中，我停歩了。我發覺自己需要一個 DSL以撰寫游戲的腳本。我考慮自行設計，或直接用 Javascript，前些時決定用 jLINQ+JSON。這組合總算初歩滿足我的需求。不幸，撰寫工作還是一停在停。

「一定是在哪兒有問題，讓游戲的撰寫工作少了一種流暢感。」我心想，「可能游戲複雜度將至的警訊。」

這流暢性的缺乏來自我的游戲中需要有能和資料完美結合的 DSL。但 Javascript 或 jLINQ 或 JSON 並不適合。

這時發現 PLT Scheme 提供了 Web Server 讓我十分開心。我打算以 Scheme 改寫游戲，評估它的實用性。希望這次能讓我進入 Scheme 的領域。