Lisp系といっても、なんだか読みやすいのである。そして、実案件でも使われていたり。興味を持った方は、まずは、「InfoQ　Jruby　Clojure」あたりでぐぐってみてほしい。
＃追記・寝ぼけていたのかtypo多すぎなので修正orz

私の知る限り、日本語の記述でもっともClojureに好意的な記述をしてくださっているのは、何をかくそう、プログラミング言語Ruby作者Matz氏の「the 0.8 true language」である(ただし、潜在的には、だが)。以下、このMatz氏の長年日記を参考にさせてもらいながら書いていく。
———-(ここからMatzにっきの引用中心)————-

Matz氏は問う、「(これからのプログラミングの)80%の領域をカバーする言語」、名づけて「the 0.8 true language」はいかなるものか、と。そして、Matz氏はいくつかの条件を挙げている。

• オブジェクトとメッセージ(or 動的結合)
• 高階関数(とクロージャ) ※ここのクロージャは当然、言語機能
• 内部DSL
• 並列実装技術
• そして、シンプルな文法

Matz氏は、これらを満たす候補として、第一にLispとRubyをあげつつ、現時点のRubyをthe 0.8 true language候補としては留保している(並列実装技術の導入が遅れているため)。そして、Lispについては、内部DSL向けではない(Lispのマクロは別物の言語を作りやすすぎるから)点を課題として挙げている。

そして、Matz氏の日記は、以下の言をつぶやいて終わる(まぁ、続きはそのうちに、という感じで)。

• 今後Java方面では、ますますのXMLの活用とJVM上のJavaでない言語の台頭が予想される。 というか、もうかなり出てきてるよね。JRubyとかGroovyとかScalaとかClojureとか。

———–(Matzにっきの引用終わり)—————

さて、以上のJRuby～Clojureの４言語の中で、Clojureのみが上記５条件を満たす、と思っている。JRubyとGroovyは並列処理に弱い。そして、Scalaはぜんぜんシンプルではない。

他方、Clojureは、Scheme/CommonLisp等の標準Lispとの互換性を捨て、S式内部にDSLを持つLispである(clojureコミュニティではLess Lispyと呼んでいたりする。Lispっぽくなくも書ける・・)。内部DSLを意識し、並列処理を前面に出した唯一のLisp、それがClojureである。

・・・ということで、本サイトではこれからもClojureに注目していく。Clojureがマイナーであること・おそらくマイナーでありつづけることを知っているので、ややネタ的に。これでいいんだよな、長門Clojure。そう、Clojureはふつうの言語より0.2くらい欠けている(例えば、継承ベースのオブジェクト指向言語機能は、「一切ない」)のだが、それが、逆にシンプルさ・科目さという魅力を出しているのだ。

[追記]継承ベースのオブジェクト指向言語機能が「一切ない」言語といえば、GoogleのGo言語もそのひとつ。 Goにたぶん言語機能としてのクロージャ(closure)はないが、当然実装可能である。Goがclosureを持つ言語(例えば、RubyやClojure)を実装すれば、組み合わせとして上記の５条件をかなり良好に満たすであろうことをいいそえておく。Cの継承者を目指すGoにはそのうちいくつものスクリプト言語系が実装されるであろうことは、想像に難くない。

• [本投稿の背景事情]　小ネタをいろいろおりまぜつつの本サイト、個人的にはScalaとClojureの比較をメインに据えていく予定であったのだが、(自らの発熱に)ついカッとなって、想定外にScala v.s. Goの比較をしたところ、急に本サイトにアクセスが集中してまっている。このままでは、既に全校生徒世界的に注目の集まっているScalaはさとおき、文芸部とコンピ研Lisperの間のみで話題となっているClojureが埋没しかねない。というか、誰も読まないだろうと思って書いたネタに相当のアクセスが流れて、ちょっとまずい状況。ということで、いてもたってもいられず、まじめにClojureの良さを、まずは少しだけ書いておいたと。

Scalaで実サービスをリリースしている著者らのJavaの限界を超えて実用化を目指す新開発言語「Scala」のメリットとは～前編(codezine誌)

今回は、codezine、１位と２位の記事がScalaとGoであること(11/12時点)にちなんで両者を比較しつつ、元記事に一点だけ突っ込む。

[追記@昼間]
以下、熱が下がった直後の明け方に書いたんで、いろいろ記載が粗いので、前提条件・抜け落ち等を補充。
◇プログラミング言語比較の前提はTiobeのランキングのような検索エンジンベースのランキング。
　当然、書籍ベースのランキングや「魂」のランキングは十分に加味されていない・・・のはさておき、そもそも検索エンジンという仕組みへの信頼性が落ちている(少なくとも不況下の幻滅期にある)と思われるので、プログラミング言語の流行り廃りの議論に、こうしたランキングが良いかは、不明(といっても、Tiobeランキングのどの位置にGoがやってくるのか、皆興味あるだろうが)
◇Tiobeベースで話を進めているのに、メジャー言語にPHPが抜けていた。
　これはScala v.s. Goということでミドルから下を主に考えていたから。少なくとも、Goベースのwebサーバは遠からず出てくるだろうし、その上でPHPが動くだろう事も明らかなので、PHPの文字を補っておいた。そもそもこのサイトもWordPress。いや速度面はさておき、良く出来ている。
◇そして、何より、議論のベースに静的片付け言語万歳。C系構文は永遠に不滅です、って言うのがあった(Goはいうまでもなく、ScalaもけっこうC系言語)。
　これは、
　　「真のバカでも使えるものを設計しようとして人々がよくやるミスは、
　　　真のバカのバカさ加減を過小評価することだ」
　　　　　－－Douglas Adams
　(出典　Diomisid Spinellis著　『コード・リーディング』, p65)
　という警句を、コンパイル時に真にバカなミスをしまくっている自分なりに重く受け入れているから。システム系言語はバカの壁に大いに配慮してほしい。ともあれ、Goみたいのがでてくると、下のレイヤの本を読もうという気になる。Goはひょっとしたら泡沫言語になるのかもしれないけれど、少なくとも、Cに近いレイヤに刺激を与える貢献は達成するのでは。
[再度追記
『コード・リーディング』を開いたついでに、監訳者であるMatz氏のにっきを見ると、Goについてのコメントが。やはり、Goには、尊敬するMatz氏も気になる変態言語(というか、大胆な言語)の側面あり。コメントでのやりとりにあるとおり、実装の継承(共有)まわり、プロトタイプ継承っぽいのでは・・・。「半人前の言語」あるいは「小学１年生(ただし神童)くらいの言語」だからこそ、Goと共にプログラミングを学ぶ価値はある。

＜本文＞

JRuby/Jythonなどスクリプト言語由来の言語と異なり、Javaと同様の静的コンパイル言語であるScalaは、Javaバーチャルマシンの主流言語の座をめぐり、本家Javaに挑む挑戦者に位置づけられる。

その試みが成就するのは、早くとも数年後であろうが、Javaの袋小路を打ち破る方向性をScalaは示したといえる。

Javaに対するScalaの利点は、以下の３つであろう。

• 不変性(val)の上手な導入による容易な並列処理プログラミング　※メモリリーク等を防ぐガベージコレクションの仕組みあり
• 簡潔な表記と型を含めたカスタマイズを可能とする言語内言語(DSL)構築能力　※タイプセーフなスタイルを採用
• スクリプトに近い簡潔な記述(関数型言語の型推論などに由来)

-----------

と書いたところで、これらの特性はただいま祭り中のグーグルの新プログラミング言語Goの特性とかぶることに気がつく。

C言語に対するGo言語の利点(私見)

• ・goroutine等による容易な並列処理プログラミング　※メモリリーク等を防ぐガベージコレクションの仕組みあり
• ・interface機能による言語拡張構能力(C++のtemplateに近いもの、か)　※タイプセーフなスタイルを採用

一方、ScalaとGoの明らかな相違点

• ・Scalaの言語仕様は巨大。Goの言語仕様は現時点では小さい　=> コンパイル時間についてはGoの圧勝(実行速度は最適化されたJavaVM上のScalaが速い場合もあろう)

※JVMかネイティブかはさておく。小飼氏ではないが、ネイティブScalaの可能性だってある。

Goの方の利点は２つだけであるが、これはGoがCに近しい低レベルな言語であることによる。RubyがCで実装されたように、Goの上でGoと親和的なスクリプト言語が出てくるのも遠くないことと思われる。

そうなると、2010年代の新主流言語をめぐる争いの中で、注目株のひとつが、

Scala v.s. (Go+(新)スクリプト言語)

というものになる可能性がある(あくまで仮説)。

もしかすると、この２言語の争いは、C,Java,C++(かろうじてC#)といったメジャー言語に割ってはいる最後の新言語をめぐる争いとなるかもしれない

※それ以降(2020年以降？)にくる「新言語」は、もはやアルファベットと記号で表記するプログラミング言語でないのかもしれない。

※個人的には、(新)スクリプト言語の座は、clojureであってほしいと思っているのだが、、実際には、PHPやRuby、あるいはそれらの新種がその位置を占めるのかもしれない。

----------

この仮説はさておき、Goの登場は、本格的な並列処理対応を打ち出した新型の手続き型言語の登場ということで、並列処理対応といえば、関数型言語Erlang,Scala,Clojure・・・という流れを変えるきっかけになるのかもしれない。

これは、かつての総合格闘技をグレーシー一族が関節技・寝技で席巻していた中で、グレーシーを打撃で打ち破った猛者が出たことで、打撃系が一気に見直されたようなもの・・か？(少なくとも、関数型言語には、関節技的なマニアックさがあるのは事実 ^^)

とここで、気がつくのは、数ある関数型言語の中で、唯一Scalaだけが、手続き型プログラミングも普通にかけるハイブリット言語であることを打ち出していることだ。
(実際、codezine記事のパテントビューロ社も手続き型言語の経験者のみが集まり、Scalaで実システムを作り上げている)

すなわち、Goの登場により、新世代の並列処理もやはり手続き型プログラミング・スタイルが主流となったとしても、Scalaは十分生き残っていくポテンシャルがあるのだ。

※言語仕様は巨大だが、現時点でも実行速度は相当速い

再び述べるが、やはり、「現存の言語では最も美少女な Scala」(小飼弾言を日々Scalaを使っている身から一部修正。現時点のScalaは大人の女性ではなく女子高校生レベルの成長途上にある)なのだ。

Scalaと、センセーショナルにデビューしたGo[golangのMLは１日で1000人近い参加者という押すな押すな状態]との関係、今後が楽しみである。

ということで、私は、昼はScala、夜はGoをいじる毎日でいこうと思う(Goについてはgoroutineはさておいて、斬新と思われるinterfaceを押さえたい)。

さて、元Scaka入門記事に一点だけつっこみ

６ページ目「Arrayは直接にAnyをデータ要素として持つことはできないようです(注４)」

少しミスリーディングな記述である(Genericや型パラメータの解説前なので仕方ないが)。Scalaの利点は静的な型づけにある。故に、入門記事であっても型の話は慎重に書かなければならない。

ので、勝手に補充

例えば、mapをもちいたArrayでは、ANY型を持つことができる(持ってしまう)

val anyarr =
   Array.range(1,101).map { n => n match{
            case _ if (n%15 == 0) => " FizzBuzz "
            case _ if (n%3 == 0) =>"Fizz "
            case _ if (n%5 == 0) => "Buzz "
            case _ =>  n
      }
   }

※この例は、以前書いた関数型FizzBuzzのArray版
実行してみる :

scala> val anyarr =
Array.range(1,101).map { n => n match{
            case _ if (n%15 == 0) => " FizzBuzz "
            case _ if (n%3 == 0) =>"Fizz "
            case _ if (n%5 == 0) => "Buzz "
            case _ =>  n
      }
}
anyarr: Array[Any] = Array(1, 2, Fizz , 4, Buzz , Fizz , 7, 8, Fizz , Buzz , 11, Fizz , 13, 14,  FizzBuzz , 16, 17, Fizz
 , 19, Buzz , Fizz , 22, 23, Fizz , Buzz , 26, Fizz , 28, 29,  FizzBuzz , 31, 32, Fizz , 34, Buzz , Fizz , 37, 38, Fizz
, Buzz , 41, Fizz , 43, 44,  FizzBuzz , 46, 47, Fizz , 49, Buzz , Fizz , 52, 53, Fizz , Buzz , 56, Fizz , 58, 59,  FizzB
uzz , 61, 62, Fizz , 64, Bu...

ちなみに、タイプセーフなプログラミングができるScalaではAnyとなったArrayからIntやStringなど任意の型を抜き出すことができる。

scala> anyarr.filter(_.isInstanceOf [Int]).map (_.asInstanceOf[Int]) res51: Array[Int] = Array(1, 2, 4, 7, 8, 11, 13, 14, 16, 17, 19, 22, 23, 26, 28, 29, 31, 32, 34, 37, 38, 41, 43, 44, 46,  47, 49, 52, 53, 56, 58, 59, 61, 62, 64, 67, 68, 71, 73, 74, 76, 77, 79, 82, 83, 86, 88, 89, 91, 92, 94, 97, 98)
scala> anyarr.filter(_.isInstanceOf [String]).map (_.asInstanceOf[String]) res52: Array[String] = Array(Fizz , Buzz , Fizz , Fizz , Buzz , Fizz ,  FizzBuzz , Fizz , Buzz , Fizz , Fizz , Buzz , Fi zz ,  FizzBuzz , Fizz , Buzz , Fizz , Fizz , Buzz , Fizz ,  FizzBuzz , Fizz , Buzz , Fizz , Fizz , Buzz , Fizz ,  FizzBu zz , Fizz , Buzz , Fizz , Fizz , Buzz , Fizz ,  FizzBuzz , Fizz , Buzz , Fizz , Fizz , Buzz , Fizz ,  FizzBuzz , Fizz , Buzz , Fizz , Fizz , Buzz )

===========================

[追記]　Scala以外の関数型言語が好きな方へ(というか、Scalaは関数型言語でないと思っている方へ)。

何を隠そう私は長門clojure萌えである。実際、Scalaのように全方位外交巨大仕様でなく、小さな言語仕様で手になじむ言語・萌える言語ならば、それで良いではないか。

いつの日か、長門clojureと日がな暮らす日が来ることをひそかに私も願っている。

なぜ、clojureが長門かはここを見てほしい・・・。ぁ、真面目にclojureを知りたい方は、RubyのMatz氏のエントリにヒントを得たこちらをどうぞ(はてぶ経由でいろいろな方が訪れてくれているっぽいので、あわてて追記)。

Does Clojure have a function like Haskell’s group?
In Haskell,
Input: group [1,2,2,1,1,1,2,2,2,1]
Output: [[1],[2,2],[1,1,1],[2,2,2],[1]]
Thanks

そのなの、partition-by関数一発だろと、
(use ‘clojure.contrib.seq-utils)
(partition-by identity [1 2 2 1 1 1 2 2 2 1])
=> ((1) (2 2) (1 1 1) (2 2 2) (1))

という突込みが入った後、
そんなgroupメソッドくらい、自分で作ろうぜと、皆で、いろいろとラムダラムダ(clojureにlambdaは出てこないが・・)。さすがLispers。。

Scalaなら・・・こうかな。

def group (L:List[Any]) = {
    def g1 (L:List[Any],temp :List[List[Any]]) : List[List[Any]]= {
        if (L isEmpty) temp
        else {
            if (L.head == temp.head.head) g1 (L.tail,(L.head::temp.head) :: temp.tail)
            else  g1(L.tail, (List(L.head)) ::temp)
        }
    }
    g1(L.tail, List[List[Any]](List(L.head)))
}

scala>  group(List(1,2,2,3,3,3,4))
res1: List[List[Any]] = List(List(4), List(3, 3, 3), List(2, 2), List(1))

Anyにしておいたので、こうもできる。

scala> group(List("A","b","b",1,1,2,2,3,"J"))
res16: List[List[Any]] = List(List(J), List(3), List(2, 2), List(1, 1), List(b, b), List(A))

———————–
[[ 追記 ]]
kmizushima氏から、foldLeftを使ったgroupをつっこんでもらったので、整形表示:

def group[T](list: List[T]): List[List[T]] = {
    list match {
        case Nil => Nil
        case hd::tl =>
        tl.foldLeft(List(List(hd))){(r, b) =>
            val (a::as) = r
            if(b == a.head) (b::a)::as else List(b)::r
        }.reverse
    }
}

Thanks, kmizushimaさん。

Scalaを使っている時、たいていは、便利・快適。なんだけれど、JSONのようにlight-weightなターゲットを扱う時には、「牛刀をもって鶏を割く(古)」・「馬から落ちて落馬した」的な、大げさ感・冗長感を感じることも。

この点、オブジェクト指向言語で「ない」ことを明言しているClojureは、JSONのようなものと相性が良さげ(これは、ClojureがListに限らずさまざまなデータ構造を扱うのを、Scalaに負けないくらい得意であることにもよる）。

ということで、JSON(BSON)ベースの文書指向データベースmongodbのclojure対応の試み、前々から興味深く思っていたんだけれど、githubにプロジェクトを立ててくれたみたい。

昨日立ったばかりのプロジェクトなんだけれど、例がけっこう充実している！

◇１件のデータのインサート 「私はrobbyという名前のロボットです」

(insert! :robots
         {:name "robby"}

◇一括インサート！ 10,000件まとめて・・のはず

(mass-insert!
  :points
  (for [x (range 100) y (range 100)]
    {:x x
     :y y
     :z (* x y)})) 

 =>  nil

(fetch-count :points)
=> 100000

mongodbはScalaからさわったんだけれど、正直clojureからの方が感触よさげ。

後発のClojureの側からScalaを見るのが利にかなっていると思ったので、Scalaから見たClojure、改め、今後は 長門有希が観測する涼宮ハルヒClojureから見たScalaでいこうと思い立つ。ということで、ちょっと前にScalaで見たフィボナッチ数列をClojureで。・・・と思ったら、本家にきれいなメモ化の実装が既に本家に置いてありますね。

atomsでフィボナッチ数列@本家clojureサイト

• clojureでは、mutableなデータを明示的に扱う。メモ化するデータを、(atom {})にいれていくのがポイント。STMを含め、clojureのmutableなデータの扱いはセンスが良い(clojureのSTMの概要については、InfoQ記事)。
• ベンチマークまでつけてくれている。単純な再帰に比べメモ化版の実行速度は10,000倍以上

自分が半分寝ながら書いたScala版メモ化より、ぜんぜんきれい(というか、シンプルな言語系同士の比較ということで、dan氏のJavaScriptでメモ化の実装と見比べるのがいいかも[再び紹介、「フィボナッチ数列にO()を学ぶ」)。もちろん、Scalaだってやればできる子(というか、できすぎる子)なので、ちゃんとしたフィボナッチ実装はいくつも転がっているが。

※ついでに、ScalaでSTM/better Actor実装のプロジェクトも絶賛活動中 => 並列処理に興味ある人は、Scala界最強のハッカーの一人であろう、jboner氏のakka を心して観察せよ。

.NET/mono環境iPhone開発環境への進出・moonlightへの注力(他方でWPFを捨て去る) などmonoコミュニティの十分賢い振る舞いも加味して考えるに、JVMにもCLRにもちゃんともっていけるような言語系は魅力がある(まぁ、その意味では、既にRubyがありますが 。IronRubyは現時点でも相当完成度が高そう)。

ちなみに、Scalaのclrアセンブリへのコンパイル機能というものもあり、そこそこ動作している。が、とても安心して使える漢字ではない(実装が大きいScalaで、ライブラリまで含めたテストをするのは相当骨だろうし)。対して、clojure-clrの実装は、組織だって動いてくれている感じで期待できる。

とにかく、小さな身体(JVM版では1MB強のjarひとつに収まっている)のclojure、やっぱり今後が楽しみだ。

理想の教育・啓蒙用プログラミング言語とは?　ひょっとしたらJavaScript、と私も思い始めた。思い始めた理由を非啓蒙的・大上段から書いて見る。

—

「理念・理想」は実現しない限り、常に新しい。

というわけで、柄谷行人『トランスクリティーク』(大澤真幸氏のプチ書評)を思いおこして書く。

今回の不況で、世界一を目指してきたトヨタが車を作りすぎて、コケてしまったことが示すように、資本主義には過剰生産の病理(あかん。作りすぎてしまうから、売れへんのや。)がつきもの。

で、どうするのか。20世紀末の柄谷氏は、「アソシエーション」というものに希望を託したわけだが、このアソシエーションは、19世紀のKarl Marxの頃にも、21世紀の今にもないもの(Nowhere)。

「association」は、「連合, 合同, 結合; 提携; 関連; 組合, 協会; 連想; 交際, 親密;」などに訳されるらしいのだが、柄谷氏は、相互啓蒙的なものを「アソシエーション」に込めていたのだと思う。同時に、『トランスクリティーク』では、「貨幣」についても考察がなされている(「事後的」にみると珍説の「LETS (‘ω’)」はここから誕生)。

今回はただひとつ、「啓蒙」という観点からだけ述べておこう。

「アイデアの時代・知財の時代」などなど、いわゆる人的資本が脚光をあびる昨今では、 たぶん、「世渡り」と結びついた「啓蒙」が資本主義のドライブとして 不可欠になっているのではないかと。「世渡り上手になるよう啓蒙」された人々には、稼ぐ力とともに「商品」への欲望が内在されるようになる。　#単に、「稼げるようになった当初は、あれもこれも欲しくなる」ということ

「時代に即した啓蒙」は、資本主義だろうが民主党政権だろうがアソシエーションの時代だろうが求められるというわけ。ただ、広い意味の啓蒙とは、単に教科書を教え込むことではない。「差異が利潤を生む」のであり、「何らかの意味で新しい」ものを含むことが啓蒙にあっても必要条件であるためだ。

—-

さて、ここで、理想のプログラミング言語教育の話に入る。

若いプログラマは、最終的には稼がなければならない(稼ぐ手段はプログラミングでなくとも良いが)。資本主義や日本の国際競争力といった大上段から見ると、日本のプログラマが総体として稼がなければならない[チームプレイのプログラミングはそこそこdomesticな産業]。では、生産性が高く今後の世につながるプログラマを、いかに教育・啓蒙すべきか。

現時点での、私の結論は、dankogai氏とほぼ同じで、「JavaScript + Lisp系言語から入る入門コースを作るべき」。小飼氏・岸田氏の議論を見ていてそう思った。
古い人間である私は、BASICを経て、C+アセンブラから入ったので、入門はCからという思いも捨てきれないのだけれども。
(読者想定　中学生～大学教養課程の学生くらい)

ただ、小飼氏と違うところは、たとえ「よっこらセックス」であるとしても、バーチャルマシン環境は早いうちに教育したほうがいいと思っているので、中学生はJavaScript、高校生になったらclojureみたいな啓蒙書を書きたいなと思う今日この頃。もちろん職業人はHaskellScalaで。

けっこうまじめに考えているので、続く。

※「資本主義がもうだめ」とかの本は、啓蒙のことをどう述べているのだろうか・・・指令 : 資本主義の精神棒を少佐に注入せよ。

JVM上の新興言語のツートップ。というか、個人的には、ハルヒと長門な、ScalaとClojure。

Scalaの方は仕事で使っている一方で、長門なClojureは完全に私の片思いで、仕事で使うことは当面なさそう。なので、しばらくは小ネタ集として両言語を比較したい。
Scalaについては日本語ブログだけで既に相当な情報を収集できるようになっている。が、Clojureについては、なかなか日本語情報に乏しい。しかし、そんな中、『逆引きClojure』は、実に期待できそうな存在・・に思えるのだが、更新が滞っている・・・

※　ということで今回は、『逆引きClojure』から適宜引用させてもらっています。

◇Clojureでリスト

Clojureのみならず、Lispでは、プログラムのリストとデータのリストを意識的に区別しなければならない(プログラム自体がリストであるという特性から・・)。なので、Listは以下のようにquoteして生成する :

(quote (1 2 3))

もしくは quoteの略称である「`」バッククオート を使う

'(1 2 3)

リストの長さは、count 関数で調べる :

(count '(1 2 3)) ; 結果は3

◇Scalaでリスト

実にシンプル:

List (1 2 3)

あるいは、演算子「::」を使ってリストを生成する

 1 :: 2 :: 3 :: Nil

試しておこう。

scala> 1 :: 2 :: 3 :: Nil
res42: List[Int] = List(1, 2, 3)

リストの長さは、length 関数で調べる :

scala> (1 :: 2 :: 3 :: Nil).length
res44: Int = 3

・・・この程度なら、clojureである必要はないなぁ。まずは、Lispの標準のひとつであるScheme実装とScalaを先に比較しよう。

[ご利用にあたって]このサイトで掲載されている情報は、「Go towards a Word-Progress」の作成者により運営されています。価格、販売可能情報は、変更される場合があります。購入時に楽天市場店舗（www.rakuten.co.jp）に表示されている価格が、その商品の販売に適用されます。

 [追記]

以下、Lisperな方への小ネタ(小さなエール??)のつもりで書いたもの。近時、Go言語エントリから、こちらに流れてくる方が急増している。Clojureをご存じてない方も多いと思われる。Clojureをご存じてない方・ClojureとClosureって間違い探し？とか思う方とは、まずはこちらの新規投稿にてClojureの良さを知っていただきたい。 あと、ややこしいが、Googleの新JavaScriptフレームワークClosureの方は、Go言語とも大きく関わるであろうProtocolBufferについてちょっと書いたので、こちらをどうぞ。

※楽天が日ハムとのクライマックス・シリーズ第一戦であんなことになって日本シリーズを応援しそびれ、ついカッとなって、長門Clojureへの応援メッセージを書きなぐった。後悔はしていない(久々にこの言葉を使った)。こうして書いてしまったものは書いてしまったものなので、その後もClojureのいい点をひっそりと書き続けるつもりでいた。 まぁ、Clojureが良いLispであることに変わりはないので、間違ってきてしまった方々の人生の時間をさほど無駄にしていないと思う。DnaKogai氏の言うとおり、真の男ならばプログラマならば、一度はLispを実装してみるくらいが良いのだから。

－－－－－

「プログラム言語オタク≒文弱」のオチに、文学はエンターテイメントとしてのみうんぬんを書いたついでに、
「Scala は振り向かずにいるにはあまりに美人だ」とKogaiDan氏が書く前から思っていた小ネタ(?)を。

※以下、あくまでプログラミング・ネタ。
京アニ・ファンかつ非プログラマな方が間違ってきてしまった場合には、
長門ファン限定で情報の伝達に齟齬が発生しない楽しめる可能性があると思われます。

涼宮ハルヒのJVM、もとい、SOS Dan on JVMについての小論。
[perl / cruby/ lua ・・・その他はすべて他に譲る]

JVM上では、Scalaは涼宮ハルヒだ。
なぜならば、長門有希がclojureだから。

若干改良されたS式をしゃべるclojureは、プログラミングが誕生すると間もなく生じた情報統合思念体=LISPの分身。

生み出されてから３年間、ずっと注目されずにすごしてきたclojureだが、Scalaとの対比で世に現れる。

InfoQの「2009年の展望」において、“2009年はScalaよりもClojureの年になるだろう”と予言されながらも、Scalaにばかり全校生徒世間の注目が集まるやや幸薄きclojure。

でも、来年2010年こそはclojureにとって大きなチャンスなのだ。何しろ、
春には涼宮ハルヒが北高から消失するclojure本の日本語訳がGaucheのshiroさん訳で出るのだから。

劇場版『涼宮ハルヒの消失』の観客動員数と同じくらい、日本語Clojure本の部数が出てほしいものだ。長門がつぶやく呪文が実はS式なのだと、映画館を訪れた長門ファンが気がつけば、そんなこともあるかもしれない。

とにかく、英語版を見る限り、clojure本は秀逸だ[STMをはじめ、scalaに取り込まれているアイデアもある]。

・・・でも、2010年にもキョンは、こう心でつぶやくのだろうか「俺はハルヒに会いたかった」。
2010年も、やっぱりツンとデレのハイブリット団長Scalaが来るのかもしれない。

以下、駄文。
残りのSOS Danメンバーon JVM

• Java≒小泉。そつなく全校女子生徒職業プログラマの支持を集めそう。
• jruby≒朝比奈さん。なんといってもその容姿が愛ら(以下、略)
• まだ見果てぬ異世界人≒Ioke。個人的にはもしかしてclojureよりおすすめかも。

せっかくなので佐々木チーム on Monoも

• C#≒佐々木　。Scalaほど美人でないにせよ(以下、略)
• Boo≒橘 京子　。たぶん、付き合ってみても良い言語。Python似の癖にScalaと同じく静的型付け。
• VB≒藤原。根拠なし。
• 周防 九曜≒IronLisp上に実装し直されたFactor、だろうか、、情報統合思念体Lispに対抗できそなのはForth系の言語と思うから。
  IronScheme上ではないうえに、ググってもとても存在感のないFactorこそが周防 九曜的(適当)。

最後に、ここまでネタに付き合ってくれた方に限定した問いかけを :

そう、最大の謎はあなたキョン　ハルヒがScalaで長門がClojureなら、キョンは一体何なのだろうか？