と打った後、Tabキーを押して数秒後、

となった時点で、MS-IMEから乗り換えていたね、わたくし。

３０秒後には、「な+tab」で「長門有希」が表示されるようになった。ATOK買ってるけどライセンス管理めんどーとか思っていた層にアピールするのでは。

日本人的には、これぞ、Google Chrome OSのキラーアプリなのかもしらん。

どうしたらgolangを速攻マスターできるんだろうって話になって、そりゃぁ、「電車でGo」だろうという話に。まだ、電車でGoを書く実力はないので、まずは、「電波なScala」 の方を。そう、電波なことを語らせるなら長門だ。

—-

朝比奈さんとお近づきになるために、Yコンビネータを分かりやすく説明してあげようと、ちょっとでも思った俺を誰が非難できよう・・・

なぁ、長門。goでも実装されたっていうYコンビネータってなんだ。
Yuki.N > 地球人の通常の言語ではうまく説明できないかもしれない。

そこをなんとかScalaで説明できないものか？
Yuki.N >

 scala >def Y(in:String) = ((
  (in map(_.toInt) toList) zip
     ("cZNSfcXic]gRcos" map(_.toInt) toList)
  ) map (Y => (Y._1 + Y._2-0x63) toChar
) mkString)

長門、Scalaってのは、そんなに括弧ばっかつけるもんじゃないぜ。

Yuki.N > そう？　私の任務はScalaの観測。Scalaのコーディングは対象ではないから。

scala > Y("asahina mukuru")
res1: String = ajLXlnV&moodr?

こ、これがYコンビネータなのか

Yuki.N > 違う。ただの高階操作。でも聞いて。

scala> Y("suzumiya haruhi")
res2: String = sleeping beauty

・・・どうやら、長門流のジョークだったらしい。
clojureで説明してくれ、だったら、長門もちゃんとYコンビネータを説明する気になってくれたのかもな。ま、まずは高階操作について聞いておくか。
このとき、俺はただそう思っただけだった。

だが、事実は俺の想像をはるかに超えていた。このあと、とんでもないYコンビネータが展開されることになるのだ(続く)。

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氏のエントリにヒントを得たこちらをどうぞ(はてぶ経由でいろいろな方が訪れてくれているっぽいので、あわてて追記)。

後発の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 を心して観察せよ。

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なら、キョンは一体何なのだろうか？