実際のところは、Google App Engine向けに実装するときに・・・と思ったのだが、Scala2.8ではけっこう、アノテーションが使われるようになるんだね。アノテーションの好き嫌いはあるだろうが、「かゆいところに手が届く」的な用法なのは気に入った。

• Scala 2.8では、@scala.annotaiton.tailrecアノテーションが追加 => 末尾再帰最適化を期待するメソッドにつけとくと、最適化されないパターンだったときにコンパイラがエラーを吐く
• Scala 2.8では、@switch アノテーションが追加 => JVM バイトコードの tableswitch最適化がされないパターンだったときにコンパイラがエラーを吐く

が、Scala2.8、リリースが遅延しているし、リリース直後から実アプリ作りにつかっていいものか、今イチ不安だなぁ・・・(弱気)。。ついでに元ネタにリンクする気力なくすみません。。

@Resource {
  val name = "abc",
  val `type` = classOf[Object],
  val authenticationType = Resource.AuthenticationType.APPLICATION,
  val shareable = true,
  val mappedName = "helloworld",
  val description = "Hello, world type"
}
class HelloWorld {
  def greeting(msg: String): String = msg + ", world!"
}

Scala on Java VM 　≒　(Haskell的言語) on golang

と考えておけば、これから５年くらいは大して外さないのではと思っている。・・・現状のHaskellがHaskell自身で実装されているなど、going my wayな点はさておく。

もちろん、純粋すぎるHaskellがgolangに実装される時には、GoskellとかHaskegolangとか、よくわからない名前の不純ななものになっているかもしれないが(JavaにHaskellを移そうとした人々は、Jaskellと名づけている)。

その点、golang上のrubyならば、gorubyで決まりだろう。ノーベル平和賞受賞者ゴルビーにも配慮十分な覚えやすい名前である。

ともあれ、(Haskell的言語) on golang、ひょっとしたら、５年後にはScalaの強敵になっているのかもしれない。関数脳を働かせる時にはhaskellの側で、手続型コードを書く時にはgolangでというわけ。もちろん、並列処理対応だってばっちりだ。

でも、プログラム言語の普及は常にゆっくりなもの。

ふつうのプログラマが、プログラム言語が手になじませるのには時間がかかる。ここ５年で普通に使われるようになる言語は、Scalaの方だ。
なんてったって、「Javaの限界を超えて実用化を目指す新開発言語「Scala」のメリットとは～後編(codezine誌)」に取り上げられているように、Scalaは、今日からでも、ベターJavaとしてプログラムを書いていけるのだから。

ベターJava。うまい言葉じゃないか。
正直に言うと、Scalaが、HaskellやLispやClojureやF#などと共に属している関数型言語界隈的には、Javaっぽく書いたら負けである。
だが、男には(もちろん、女にも)、とりあえず手っ取り早くすませてしまいたい時がいつでもやってくる。そんなときばかりは、負けとかぬるいとか、言っていられない。

たとえば、

関数型言語のListは、Arrayより遅いらしい、と上司が聞きつけてきたとしよう(上司は「遅い」という言葉に過敏であるとする)。悪いことに、初のScala案件を受託した上司は、Scalaコーディング規約なるものを作ろうとしている。
ScalaプログラミングでList禁止とかいう謎の御触れが出されたらことである。そう、あなたは、忙しいにも関わらず、大急ぎでベンチマーク対決をしなければならなくなった。

そんな時でもScalaなら安心だ。
Java屋であろうとなかろうと、Javaで現在時刻を知る関数がcurrentTimeMillisであることは、ググってみればすぐわかる。

もちろん、Scalaでも、

scala> System.currentTimeMillis
res1: Long = 1258619704810

これを使って、データを付加する時間、データにアクセスする時間計測すればよい。結果は、case classに入れることにしよう。

//ベンチマーク結果の格納クラス
case class Result(
  val AppendTime:Double, //データを付加する時間の結果
  val AccessTime:Double// とデータにアクセスする時間
) {
    val total = AppendTime + AccessTime
}

・・・・ここであなたの手がとまる。ベンチマークって関数型言語的にどう書くんだ・・・・関数渡し・・・をするとして、もArrayとListの双方に対応するには・・・
Scalaなら、とりあえず、こんな風な考えが浮かんできてしまっても大丈夫だ :

    いいや、forループでてきとうに書いて、
　　　　あとはコピペしててきとうに書こう。

えっと・・・・

//入力　ループ回数MAX
def simpleBench (MAX:Int)= {
	println ("Loops : "+MAX)

	//ベンチマークの結果(データを付加する時間とデータにアクセスする時間)
	case class Result(val AppendTime:Double,val AccessTime:Double) {
		val total = AppendTime + AccessTime
	}

	//配列の速度を測定する
	val benchA = {
		val e1 = System.currentTimeMillis
		val a = new Array[Double](MAX)
		//
		for (i <- 1 to MAX)
			a(i-1) = 1.0 * i
		val e2 = System.currentTimeMillis
		var sum = 0.0
		for (i <- 1 to MAX)
			sum += a(i-1)
		print (sum + " = ")
		val e3 = System.currentTimeMillis
		Result ((e2-e1) , (e3-e2))
	}
	//リストの速度を測定する ＃かなりこぴぺ
	val benchL = {
		val e1 = System.currentTimeMillis

		var L = List(0.0)
		for (i <- 1 to MAX)
			L ::= (1.0 * i)
		val e2 = System.currentTimeMillis
		var sum = 0.0
		var LL = L
		for (i <- 1 to MAX) {
 			sum += L.head;	L= L.tail //チェックポイント
 		}
 		println (sum)
 		val e3 = System.currentTimeMillis
 		Result ((e2-e1) , (e3-e2))
 	}
  	println ("Total  -> List : %f     Array : %f".
		format(benchL.total,		benchA.total))
	println ("Append -> List : %f     Array : %f".
		format(benchL.AppendTime,	benchA.AppendTime))
	println ("Access -> List : %f     Array : %f".
		format(benchL.AccessTime,	benchA.AccessTime))
}

関数内関数とかいうテクニックを使ってはいるものの、ただの手続き型プログラミングである。２、３回の試行錯誤の後、あなたはベンチマーク結果を得る。
コンパイル言語であるScalaは十分に高速なので、ミリ秒単位で計測するには、ループ回数も1,000,000回くらいでちょうどいいようだ。

scala> for (j <- 1 to 5) simpleBench(1000000)
Loops : 1000000
5.000005E11 = 5.000005E11
Total  -> List : 234.000000     Array : 62.000000
Append -> List : 172.000000     Array : 31.000000
Access -> List : 62.000000     Array : 31.000000
Loops : 1000000
5.000005E11 = 5.000005E11
Total  -> List : 499.000000     Array : 62.000000
Append -> List : 141.000000     Array : 31.000000
Access -> List : 358.000000     Array : 31.000000
Loops : 1000000
5.000005E11 = 5.000005E11
Total  -> List : 234.000000     Array : 62.000000
Append -> List : 141.000000     Array : 31.000000
Access -> List : 93.000000     Array : 31.000000
Loops : 1000000
5.000005E11 = 5.000005E11
Total  -> List : 234.000000     Array : 62.000000
Append -> List : 188.000000     Array : 31.000000
Access -> List : 46.000000     Array : 31.000000
Loops : 1000000
5.000005E11 = 5.000005E11
Total  -> List : 249.000000     Array : 47.000000
Append -> List : 187.000000     Array : 31.000000
Access -> List : 62.000000     Array : 16.000000

メモリの確保や開放に伴う誤差が考えられるため、とりあえず５回くらい回してみた。

ミドルウェアをScalaで開発をしておられる方(例えば、前回の浅海氏)ならは、やはり、Arrayでいきましょうとなるかもしないが、通常のアプリでは100万回ループを連発なんてことはあんまりないため、ListでもArrayでも大差はない。

ふうっ、これで安心だ。残った時間は、関数脳のトレーニングにあてよう。そうだ、sleepingBeauty関数でも書くか・・・。中途半端な関数脳の持ち主にとって、ベターjavaであるScalaは大いに便利な存在だ。

• 関数脳よりもScalaでの実務的なプログラミングに興味をお持ちならば、「Javaの限界を超えて実用化を目指す新開発言語「Scala」のメリットとは～後編(codezine誌)」でさわりをつかんでおこう。

—————————

最後にひとつだけ。なぜあなたは、忙しい自分の手を動かしてベンチマークを書いたのか。それは、プロマネをしながら、Scala入門もしているらしい上司が、上のプログラムに「チェックポイント」とコメントしておいたようなところで、「sum += L(i-1)」とか書いてしまって走らせることがないようにだ。

ためしに、コメント部分を書き換えてみようと思った方にちょっとアドバイス :

Yuki.N > 当該プログラムにおいてチェックポイント部分をリストの番号による操作に置き換えた場合、現時点のノイマン型アーキテクチャにおける実行においては地球人が１日と呼ぶ時間の枠内では処理が終了しない場合がある。Lispにおける伝統的なcarと同様、ScalaではListは可能な限りheadを介してアクセスするコードを記述すべきである。
・・・じゃ、Java VMでも書き方次第でそんなに遅くなるのか？　正直、リストだってL(i)でアクセスしたいのが人情ってもんだと思うんだが、そこまでの親切はしてくれないものなのか、長門？
Yuki.N > そう。

IT pro誌に連載中の本記事、その前までの回がかなりマニアックであったため、Scalaをはじめたばかりの方があまり読んでいないのではと思われる。しかし、Scalaのコレクション・クラスを知るには、非常に実践的で良い記事なので、少なくともこの回だけは読んでおいてほしい。

で、追記。

Scalaのコレクション・クラスは、データセットの繰り返し関係を扱うIteratorトレイトを内部的に持つと共に、データの取扱い方を抽象化したIterable・Collectionトレイトから派生している。浅海氏が取り上げているListやArrayも例外ではない。こうした裏方を知っておくことコレ大事ということで、特にJavaとの互換性を保つ上で不可欠なIteratorトレイトに少し言及。

※トレイトが何かは省略。はじめての方は、「scala trait」でググッて調べていただきたい。

いわゆるデザインパターンにおいて、繰り返しを扱うiteratorパターンはけっこう有名。その由来通りに、ScalaのIteratorトレイトも、繰り返し関係を取り扱うためのnextメソッド・hasNextメソッドを持っている。

Iteratorを生成し、nextしていってみよう。シングルトンオブジェクトという仕組みで、Scalaでは、以下のようにいきなりイテレータを生成できる。

scala> val i1 = Iterator.range(0,3) //０以上３未満の整数を生成
i1: Iterator[Int] = non-empty iterator
生成されたi1はnextメソッドを持っているはずである。

scala> i1.next
res6: Int = 0
scala> i1.next
res7: Int = 1
scala> i1.next
res8: Int = 2
scala> i1.next //３以上の整数は存在しないためエラーとなる
java.util.NoSuchElementException: next on empty iterator

さて、多少の好き嫌いはあろうものの、Scalaは、基本、万人受けする美少女言語。Scalaのiteratorトレイトは、古のiteratorパターンを軽々とこえていく。いわゆる高階メソッドがばりばり使えるのである。

高階メソッドとは、とりあえず、「ようそひとつひとつをまとめてドンのメソッド」とでもいっておこうか。詳しくは浅海氏の記事を読んでいただくとして、ちょっとだけ。

まずはmkstring。以下のようにタイプすると、

scala> Iterator.range(1,5).mkString("Nagato")
res7: String = 1Nagato2Nagato3Nagato4

数字の間に旧日本軍の戦艦長門が３隻はさみこまれた。これは、Iteratorの要素(1,2,3,4)のコンマの部分が長門におきかわったというわけ。

まぁ、mkStringはあまりおもしろくないので、次はかの大企業IBMとviエディタ日本語パッチ(vij)に高階関数mapを適用してみよう。

scala> Iterator.fromString("IBMVIJ").
　　　　map (x => x - 1).
　　　　foreach { x => print (x.toChar)}
warning: there were deprecation warnings;
HALUHI

おっと、どこかの組織が余計なwarningを出しているが、とりあえず、IBM => HALという古の変換は完了した。この「=>」による変換(関数リテラルという)が、I,B,M,V,I,Jのひとつひとつのアルファベットに適用されているというわけ。

以上、Scalaはiteratorでもけっこう便利、ListやArrayはもっともりもり高階操作ばりばり、なのだよ。何がもりもりか知りたくなった人は、浅海氏の記事を読もう。

——————-

だが、話はここで終わらない。Scalaは萌え要素ばかりではない。美少女がツンデレという例に漏れず、ハルヒScalaに付き合っていくのは、一般人には少々骨なのである。なにしろ、iteratorも，ListもArrayもSeqもMapもTupleもQueueも(以下略)・・・Scalaのコレクションクラスは、みんなみんな高機能。どれがどれだけの萌え要素機能性をもっているかを把握するには３年間くらいかかりそうな勢いである。そして、Scala2.8でコレクション・クラス自体の継承関係にかなりの変更が・・・。Scala、とても便利なのだが、なんだか過剰なのだ。

さて、いよいよgolang。

自分はgolangにさほど萌えていないのだが、それは、golangがライブラリというふくよかな肉がない、いまだスケルトンな存在であるからかもしれない。golangは、基本的なライブラリが欠けていて、それを充実させていただきたく、オープンソースとして公開するから、皆さんどんどんgolang使って便利なライブラリつくってくださいね、というわけ。

ついでに思うに、ギークからすると不足感あるgolangだが、教育用途には意外と向いているのやも。

強引にGoogle golangでコーディングするよう強制されつつ。

・・・だが、その時には、golangにもけっこう萌えているかもしれない。なんといっても、Scalaのライブラリをきちんとマスターするための関門であった、ライブラリの継承関係の把握の手間がgolangにはない。なぜなら、golangには継承自体がないのだから。

継承がないのにgolangがオブジェクト指向って、それ何って話はまたそのうちに。

@ITにて、JavaScriptでストイックにアルゴリズムとデータ構造している連載を見つけた。すばらしい。ということで、KMP法というやつをScalaで書いて見る。

いや、Scalaブログ的には関数型っぽく書くとかっこいいとされているし、実際、関数脳は大事なのだが、better Javaとしてふつうに使えてるよ、という例までに。

//文字列探索のアルゴリズムに KMP (Knuth-Morris-Pratt) 法
// REPL環境での試し方 :、
 //KMP.find("キーワード","検索対象の文字列"で実行

class State(keyword: String) {
    val EOS = keyword.length - 1
    var loc = 0 //文字の位置
    def done = (loc == EOS) // 最後の位置までたどりついたか

    def next(c: Char) =
        if (c == keyword(loc)) {
            println(" => find : [ " + c.toString+ " ]")
            loc += 1
        } else loc = 0
}

object KMP {
    def find(keyword: String, text: String): Boolean = {
        val EOS = text.length - 1
        val state = new State(keyword)
        def next(loc : Int): Boolean =
            if (loc == EOS) {
                false
            } else {
                if (state.done) true else {
                    state.next(text(loc))
                    next(loc + 1)
                }
            }
        next(0)
    }
}

再帰しか使ってないからほぼそのままGoとかにも移植できるだろう・・・書いて見れば、基礎体力を比べるベンチマークにいい、かな？？

関数型言語らしいKMPは、ether氏のこちら(Haskell版からの移植)。

さて、入門者向けにこのJavaScriptのコードを解説するならば・・・はっ、JavaScriptのコード、見るの忘れてた。

－－－

[追記]夕飯を食べて、なんとなく見直してみたところ、一箇所間違っていることに気が付いた。まぁ、さらした後書き換えるのも既にかっこ悪いので、修正は皆様にお任せすることにする(いずれ、ScalaTestとかSpecsとかのテストツールネタで使うということにしておこう。)こうしたロジックのミスは、もちろんコンパイラが見つけてくれることはない。

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

なので、例によって、Scalaにて写経: ※JavaScriptのコードは元サイト側で、例題をちょこちょこ書き換えevalして即実行できるようになっているので、省略。・・この面、たしかにJavaScriptは教育向き。

◇再帰を用いたナイーブな実装　:　「計算量」O(2ⁿ)

実装(ちょっとだけScala風にさせてもらった)　※(たとえ、Scalaであっても)計算効率が悪いアルゴリズムなので遅い

def fibo (n :Int) : Int =
	if (n < 2) n else {fibo(n-2) + fibo(n-1)}

val fiboList = {for (i <-1 to 10) yield fibo(i)}.toList

• 実行例

scala> fiboList foreach println _
1
1
2
3
5
8
13
21
34
55

◇クロージャを活用した実装　:　「計算量」O(n)

うん、良い例題。しかし、JavaScriptも結構簡潔だなぁ。やはり、動的言語の方が教育向きか。

def fib(n:Int) = {
  def f(a:Int, b:Int, c:Int) :Int=
    if (c <= 2)  a else f(a+b, a, c-1)
  f(1, 1, n)
}

• 実行例

scala> for (n <- 1 to 20) print (fib(n)+"\t")
1       1       2       3       5       8       13      21      34      55      89      144     233     377     610
987     1597    2584    4181    6765

◇メモ化(memoization)　:　「計算量」O(1)?

あれれ、そのままでScalaにもっていくと、Scalaの方はちょっとくどいぞ・・・ArrayでなくてListを使おうかと思ったが、簡潔になる方法が簡単に思いつかない。パターンマッチを使ってもきれいに書けないなぁ。

val num = 30 //num番目までの結果を得る

var fibs =new Array[Int](num+1)

def fib(n:Int) :Int = {
	if (fibs(n) > 0) return fibs(n)
	if (n <=  2) return 1
	val f = {fib(n-1) + fib(n-2)}
	fibs(n) = f
	return f
}

• 実行例

scala> for (n <- 1 to num)  println("" + n + "\t" + fib(n))
1       1
2       1
3       2
4       3
5       5
6       8
7       13
8       21
9       34
10      55
11      89
12      144
13      233
14      377
15      610
16      987
17      1597
18      2584
19      4181
20      6765
21      10946
22      17711
23      28657
24      46368
25      75025
26      121393
27      196418
28      317811
29      514229
30      832040

うん、さすがにメモ化は速い。Scalaでもう少しきれいに、と考えたのだが、眠くなってきたので、簡潔な実装をしている方のコードを一部改させてもらう。ほんとは元コードのBigIntの方が良い。

var nums = Map(1->1, 2->1)
def calc(i:Int): Int={
    if(!nums.contains(i)){
      nums += (i -> (calc(i-1) + calc(i-2)))
    }
    nums(i)
  }
  for(i<-1 to 30)
    println("" + i + "\t" + calc(i))

まぁ、要するにArrayの代わりにMapを使う。実行速度面ではMapの方が多少遅いだろうが、プログラムは簡潔。
Actorを使った実装とか、さらにScalaで工夫している人もいたが省略・・・眠る前に今日の振り返り　:　JavaScript、教育用にやっぱり使えそう (いざ、JavaScriptで書けと言われるとF#の#lightモードみたいなのが欲しくなるのだが・・JQueryは・・・以下略 Zzzz…)