Loop：緊湊的JVM多核語言
作為一種緊湊簡潔的JVM編程語言，Loop很明顯地受到了Haskell、Scheme、Ruby和Erlang的影響，而且它也同時嘗試著將函數式語言和面向對象語言的優秀特性實用且一致地整合在一起。
程序會在傳輸到JVM中進行編譯，而且會盡可能地優化，這樣在解釋執行的時候就不會產生性能損失；所有的這一切優化都是為了產生高效的可執行代碼。
Loop的源碼文件結構一般如下：
- module declaration
- import declarations
- functions & type definitions
- free expressions
下面是一個Loop程序的例子：
- module mymodule
- require othermod
- require yet.another
- class Pair ->
- left: 0
- right: 0
- main ->
- new Pair() # 注釋可以放在任何地方
- #自由表達式必須放在最后
- print('mymodule is go!')
InfoQ和Loop的創建者Dhanji R. Prasanna進行了一次小型的問答互動，在這之前，有必要對Dhanji做一下介紹，他是前Google工程師，JAX-RS規范的作者之一，“依賴注入：設計模式”的作者，Manning出版社已經將這本書付梓。
InfoQ：Loop相比其他的JVM語言來說有何不同？
Dhanji：我不想做一個面面俱到的特性比較，不過我覺得，若是闡述Loop的設計理念，這將能更好地回答你的這個問題，Loop是為了讓開發者有一個一致、簡單而且快樂的編程經歷。所有的特性都是經過精心設計，并且設計過程中我非常仔細地考慮了特性之間的交互，不僅僅是句法上，而且還包括了語義。在其他的語言中，你可能有很多方法來完成一件事情，這已經幾乎成為一種語言的特性，但是我覺得，多數其他實現都是不需要的。在Loop中，我嘗試著對如何完成一件事情做出種種限制，這樣便能夠保持語言的簡潔和簡單，從而得到一個富有魅力的，感覺舒適的語法。要知道，閱讀和編寫代碼應該是一個簡單愉快的過程。
另外一個區別就是Loop源代碼直接編譯成為JVM字節碼，但是這個編譯過程是在傳送到JVM的過程中完成。也就是說它看起來非常像是一門腳本語言（而且像Lisp一樣是REPL（讀取，求值，打印，循環）式），但是它的性能實際上要比真正的解釋型語言要好。我可以讓其他人做基準測試來驗證，不過現在看來，在我做的簡單測試中，Loop的速度非常快。我也在啟動優化上花費了很多時間和精力，因此它的啟動速度能夠完全達到JVM的極限，我可以毫不夸張的說，啟動速度這個特性通常被大多數JVM語言給忽略了。
Loop也是緊密地和Java結合在一起。在Loop程序中可以很方便地調用Java方法或者使用Java對象。Lists、Sets和Maps都只是java.util的成員，但是做了一些擴展（也簡單地擴展了String）。這和其他的語言有區別，它們是維護了了兩個不同的庫來對Java庫進行擴展。
最后，Loop從一開始就內建了對并發的支持，而且將不可變和狀態的共享作為不可或缺的特性。
InfoQ：你提到了許多Loop的特性都受到了例如Haskell、Scheme和Ruby這樣的語言的影響，你可以簡單介紹一些例子嗎？
Dhanji：當然，不過要知道，當你說“受到影響”的時候，人們總是趨向于認為“直接抄襲”，并且會仔細地檢查你是不是有什么地方抄錯了，應付這種想法是非常艱難的。從我看來，直接受到影響的部分是語法。尤其是Haskell的模式匹配，以及“where”和“do”語句塊，Scheme的類型系統、模塊，TCO（尾調用優化）以及詞法結構（閉包），當然還有Ruby的符號以及自由形式的腳本。
這里有一個句法結構的典型例子，你可以看到Loop是如何受到這些影響的，看看函數調用可以以一種后綴的形式來使用：
- print(36)
- # 可以寫為：
- 36.print()
這看起來的確很像是Ruby的函數調用，但是事實上，這是多態（重載）的函數的簡單使用。我發現這種形式能夠增強某些代碼的可讀性，尤其是“擴展”已經存在的Java對象時候。當然，我們也要權衡這種調用的利弊，不過我相信當Loop成熟之時，這個特性將會得到大量應用。
更進一步地說，Loop也還在函數設計的過程中受到了來自于Haskell和Scheme（尤其是后者）的語義影響。一個典型的例子便是從狀態性，面向封裝的設計轉為一個無狀態，聲明式的設計。像Scheme，Loop在IO的設計上也并不是非常優秀，但是另一方面來看，這也加強了并發程序的不可變性。這個加強之處很明顯地受到了Haskell哲學的影響。
不僅如此，Haskell還影響了如何將聲明式的代碼更易編寫和閱讀上。我非常喜歡這個哲學理念：代碼應該讀起來像是一個解，而不是像一個如何在洗衣房洗衣的說明列表；或者說，我們應該強調程序“做什么”而不是“怎么樣”，Loop毫無疑問地受到了這種理念的影響。
InfoQ：看起來Loop也花費了非常多的精力在并發支持和內建的消息傳遞接口上。你可以跟我們解釋一下和其他流行的并發技術，Loop的并發支持有什么不同嗎？
Dhanji：這是一個非常好的問題。Erlang有許多非常優秀的地方值得借鑒。在Loop中實現并發有兩個主要的方法，它們都是Loop原生支持，而且，如果能夠相互結合使用將會非常強大：
消息驅動通道（對消息傳遞，隊列和線程池的面向事件的抽象）
軟件事務內存（一個用于共享可變狀態的無鎖的，原子性的一致性的模式）
前者將會管理好所有的細節，你所面臨的只是一個抽象的概念。設置好可以并發執行的輕量級的“通道”數目，然后簡單地放入一堆任務即可，當然也可以考慮將這些任務分片然后在各個片內，然后串行執行。這其實提供了一個非常簡單的方法來創建真正地分片事件隊列。因為通道是非常的輕量級，你可以很簡單很容易地創建成千上萬的通道，然后用來分片執行，例如，按照用戶名分片。每個串行通道各自擁有一小塊永久的內存，這將會使得增量式任務處理更加容易。
Loop同樣保證每個線程都是平均分布在這些通道中，這個所謂的公平參數是可以配置的。所有我現在介紹的特性你現在可以馬上在Loop中找到，而且，以后每個串行通道將會有一個可以配置的線程池。
我提到了，串行通道擁有少量的永久私有內存 - 另一方面，事務內存則是一個更強大的選擇，如果你熟悉數據庫的話，Loop如何使用這個技術是和數據庫中的“并發優化”類似。我們再也不需要鎖這個概念，即便是在寫入的時候。這類內存的優化目標便是超高吞吐量的讀操作和無阻塞的寫操作。這個已經成為語法的一部分：
- update(person) in @person ->
- this.name: person.name,
- this.age: person.age
注意“in @person”，Loop將會在@person片中執行這個事務
在這個方法中，我將會更新@person“事務片”中的數據。“this”指針指向當前的事務片。當函數完成的時候，當前事務片將會對其他線程原子可見，或者失敗之后當做完全沒有執行過（類似于回滾）。其他的線程（即使不在這個事務中）都可以看到一個一致的@person片，然后這個片在事務執行的時候會短暫不可見，所有的線程在事務完成之后將會馬上看到一個新的對象，無鎖，無需等待。這最激動人心的事情便是讀和寫線程完全無阻塞。
這個特性仍然還是處于Alpha階段，我嘗試著搞定這個語義問題，但是我真的覺得通道API使得Loop中并行編程變得優美，強大而且容易理解。
你也可以在Github上提交你的代碼為Loop做貢獻。
原文鏈接：http://www.linuxeden.com/html/develop/20120716/127402.html
【編輯推薦】
