核心的JRuby開發者及書籍Practical JRuby on Rails Projects的作者Ola Bini為JVM開發了一種名為Ioke的新語言這種強類型動態基於原型的面向對象語言的目標在於給予開發者Lisp與Ruby的力量同時其擁有優雅小巧及規則的語法
Ola解釋了Ioke的基本特性
Ioke是一個強類型動態基於原型的面向對象語言它很容易理解並且內置了對幾種宏的支持對Ioke產生重要影響的語言有IoSmalltalkSelfRuby及Lisp（尤其是Common Lisp）
Ioke目前構建在JVM上但我現在正考慮將其編譯為JavaScript並在V上運行它
對於Ioke我有幾個目標但最明確的一個是創建一種能將Ruby和Lisp中我所喜歡的那些特性組合起來的語言結果我發現Io已經實現了我所期望的大多數特性但有些地方實現的還不完美我還需要一種適合表達內部DSLs的語言我想要一種不會妨礙我反而會助我完成工作的語言根據以上幾點我設計出了一個宏系統有些人可能會覺得這個系統很差勁
就Ioke的設計向Ola Bini提出了幾個問題
看起來Ioke的關鍵特性之一就是它使用了基於原型的繼承相比於占主導地位的基於類的繼承你認為這種繼承方式更強大麼？
是的這是Ioke的一個特性但我不確定它是否是一個關鍵特性它在很大程度上改變了一些東西的設計我對此感到很滿意我認為它實際上比基於類的系統要好既然開發Ioke的主要目的是為了我自己的使用那麼我的感覺當然就很重要了
在Ruby中你可以使用單例類實現基於原型的OO同時我發現可以用這種方式清晰地對一些算法建模從功能上來說這沒有什麼明顯的問題只要你想你總可以根據規約實現基於類的OO
Ioke的一個主要指導原則是我所采取的決定並不是為了獲得大家的認可僅僅因為基於類的OO占據著主導地位我就要使用它麼？ 不一定吧確實有很多原因要求我們使用基於類的OO然而歷史已經證明對很多應用來說這樣做的意義並不大因此在Ioke的開發過程中我嘗試了各種可能
因為在主流的語言中只有JavaScript采取了基於原型的繼承你認為這種形式會被大家所理解並應用到實踐中麼？
實際上我認為基於原型的OO要比基於類的OO更自然也更容易理解我覺得基於類的OO是需要學習的而大多數人都會發現基於原型的OO更加直觀前提是他們並沒有被人灌輸基於類的OO的所謂優點當然JavaScript可能並不是最好的參照物因為語言的基於原型的本質很容易被掩蓋在該語言模型的邊邊角角之下這意味著大多數開發者實際上並不知道如何以正確的方式使用語言的這些特性
看起來Ioke從一開始就被設計成一種JVM語言你認為在最近一段時期內這會成為新語言的必經之路麼？
我現在的想法是沒必要從頭構建一個新的虛擬機例如大多數新語言都帶垃圾回收但我不理解為什麼創建這些新語言的人要編寫自己的GC呢這需要花費數月的時間而它只是一項重復的工作而已看看Ruby GC的那些問題吧顯然這種想法對很多其他的事情也適用——尤其是庫因此Ioke是一個JVM語言（但是Ioke的大部分內容是不依賴於JVM的你可以在另一個平台上重新實現這些內容這很簡單核心內容非常小）我認為面向JVMCLRParrott及LLVM的語言都應該這樣從頭構建一個新的虛擬機幾乎沒有任何意義
你為Ioke實現的條件（Condition）系統看起來與Java的異常處理系統很相似但更靈活你能否提供幾個例子來更好的說明其價值呢？
你可以認為異常所具有的功能是條件系統的一個子集有兩點區別其一是從協議和抽象的角度來看異常所處理的東西不見得非得是異常或是錯誤警告也行大多數動態語言都有基於adhoc日志的警告系統但是如果你想做其他事情呢？在Ruby中你可以改變warn方法以拋出一個異常然而這仍然表示警告和異常的處理方式存在著分歧要麼采取系統攔截要麼采取線程攔截所有這一切僅僅是表面上的不同而已本質上是一回事
條件可以將這一切統一起來他們為上面提到的那些事情提供了一致的協議
條件所提供的功能是雙重的首先就是restart它實際上幾乎是完全獨立的
所謂restart就是可以注冊到塊中的一些東西它基本上就是調用restart時所執行的一些代碼塊然後有一些方法會去調用命名的restart找到所有活動的restartrestart幾乎可以看作是一種異常機制從范圍上來說它是動態的
憑借條件我們可以為某些可能發生的事情注冊處理器當條件發生時處理器可以選擇去處理它或是把它交給下一個處理器處理然而這並不是堆棧展開（unwinding the stack）（至少現在不是）如果某個處理器想去處理某個條件（處理器也是一塊代碼）處理器上下文中相應的代碼就會被執行執行的位置是動態的就在條件第一次發生的地方這意味著幾個方法從某個條件發生的地方所調用的處理器實際上可以在相應的上下文中進行疊加
這沒什麼好奇怪的你可以在純Ruby環境下完成這件事但如果標准庫沒有提供相應的支持那效果就要大打折扣了
在Common Lisp中這非常強大當你以交互的方式使用Common Lisp時條件的默認處理器會將你帶到調試器中該調試器運行在錯誤發生的上下文中同時它可以完成處理器所能完成的事情——包括為變量提供新的值等等該調試器無需做任何特別的事情實際上它只是條件系統一個具體的用例而已
這實在是太強大了
你認為Ioke符合維護和重構的標准麼？它是動態的又具有強類型你是怎麼看的？
這很難說既然它很簡潔同時又為這種簡潔性提供了強大的特性那麼它應該很容易維護同樣的原因自動化的重構現在還不完善
就像Lisp一樣Ioke提供了語法抽象有兩種形式第一種是宏它就像是具有延遲參數的方法調用一樣這些參數可用特殊的方式計算出來另一種是語法它與Common Lisp的defmacro差不多這兩種方式為創建新的控制結構和定義新的抽象提供了可能語言本身是足夠強大的你可以用其創建自己的方法類型如果你不喜歡關鍵字參數你可以定義一種新的不包含關鍵字參數的方法類型當前Ioke中的DefaultMethod可以用純Ioke實現出來使用宏就行
對於Ioke的語法來說你遵循了Lisp和Smalltalk的方式例如space的使用一些人可能會覺得這麼做會令那些熟悉C語言代碼風格的開發者敬而遠之你覺得是這樣的麼？
很早以前我就已經是一個CC++及Java開發者了我並沒有覺得哪裡不舒服Ioke的語法確實很麻煩之前有很多人都覺得這對於強大的抽象來說是個絆腳石當你有一個像以上那些語言的AST時你會發現要想實現語法宏是多麼的不方便語法占很大的比重因為他們很不統一
因此大家可能在一開始會覺得它不那麼自然但我真的很喜歡它我相信你也會的比如我發現Ioke的可讀性就非常好而Java就不行了Ioke中沒有太多的標點字符妨礙我們閱讀下面對JavaRuby及Ioke進行了一下比較
ArraysasList(foo bar quux)
map(new Function<String Pair<String Int>>(){
public Pair<String Int> call(String str){
return new Pair<String Int>(str strlength());
}})select // this gets too long ok?
[foo bar quux]map {|str| [str strlength]}select {|n| n[] > }
[foo bar quux] map(str [str str length]) select(second > )
在這個例子中
Ruby的區別不那麼明顯
但它實際上也有很大的差別
我發現當方法用空格分隔開時閱讀起來會更方便
使用圓點來終止表達式同樣會造成很大的差別
因此
作為Lisp的使用者
這麼說有點另類
但語法真的是很重要
我為Ioke設定的目標就是讓其擁有Lisp和Ruby的力量
同時保持其語法優雅
小巧及規則
From:http://tw.wingwit.com/Article/program/Java/hx/201311/27061.html
