Joda Timeライブラリの開発者でJSR 310の日時API改善の仕様策定者であるStephen Colebourne氏がScalaの適用しやすさについて示唆に富む記事を書いている。氏はScalaとEJB 2を比較している。氏の考えではEJB 2はJava EE仕様の中で最悪のものだった。
… たくさんの決まりきった書き方やXMLや全体的な複雑さがJavaの世界に持ち込まれました。EJB 2は広く導入されましたが、批判を伴いました。開発者はEJB 2が抽象度の高いAPIを導入することで、企業向けアプリケーション構築の複雑さを緩和しようとしながら、結局、期待した結果を生まずに更なる複雑さをもたらしたということに気づいていたのです。
そして、氏はFantomやKotlin、Groovy、Ceylonのような言語は好きだが、Scalaはこれからの開発に適していないと考えている。
理由のひとつはScalaが適切なモジュールシステムを提供しないからだ。氏はJavaが当初、モジュールシステムを提供せず(そして、必要性が認識されている現在も提供していない)、Maven、Ivy、OSGiのような仕組みが必要だったことを指摘している。しかし、モジュールシステムを無視することはモジュール化が必要な開発者にとっては問題だ。大規模なシステムを構築するとき、モジュール化はメンテナンスを行う上で必要な、重要な仕組みなのだ。
氏は、Javaがモジュールシステムを持っていたら、CORBAをサポートしないJVMを出荷できたと考えている。CORBAは古い技術でJavaの世界では、RMI以外ではほとんど使われていない(一般的にはSOAPやRESTに置き換えられてしまっている)。
実際、2年前にモジュール方式の提案がなされたが、すぐに却下された。(あらゆるモジュールシステムを運用するのに必要な)バージョンやモジュールを提供することに対して強固な抵抗があったのだ。当時、Scalaはまだ企業で利用できる状態ではなかったが、2年経ってもまだ同じ状態のままだ。
氏はScalaの型システムが複雑になりすぎていると指摘している。これは、Steve Yegge氏の見解と同じだ。
Scalaの仕様は、ブログにも書かなければいけないのですが、[型システムについての仕様が]90％を占めます。今まで見てきた中で最大の型システムです。型があり、型の型があり、型の型の型があり、本当に複雑です。
これは複雑さの複雑さ<T>と呼ばれています。単なる複雑さでも複雑さの複雑さでもありません。パラメータ化された複雑さの複雑さなのです。型についての型についての型を持っているということです。恐ろしいことです。
Stephen氏は、当初メソッドが正しくコンパイルされることを示すために使われていた型シグネチャが、Unicodeメソッドのサポートが使われる前に事実上無意味になっていることを強調する。氏はScalaのコアライブラリの下記のメソッドシグネチャを取り上げ、これが何をしようとしているのか説明しようとする。
def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That
氏はScalaの静的型付けは静的型付けの評判を落としていると主張する。
巨大な型システムがあるおかげでコンパイルエラーを避け、事前にコードをチェックできるというのはわかります。しかし、裏を返せば、動的な型システムでできることは何もできないということです。私は、Scalaの型システムは実用を言語の特徴をとしては実用を超えてしまっていると思います。
要するにScalaの型システムは静的型付け全般の評価を下げているのです。
これは新しい見方ではない。Log4JとSLF4Jプロジェクトの創始者であるCeki Gülcü氏はasks if Scalaは信頼に値するのかと問うている。Scalaは進化の過程で何度も後方互換性を破棄しているので(これからも後方互換性が保証されるかどうかわからない)、実用に耐えないのではないかと指摘する。
しかし、Scalaの特徴の中で私がとてもいやなのは、新しいリリースが出るたびにバイナリの互換性がなくなってしまう点です。事前に約束があったにも関わらず、2.7がリリースされたときも、2.8がリリースされたときも互換性がありませんでせした。2.9のときも同じです。Scalaの設計者たちはScalaのライブラリの特質が互換性のないかたちで変更された場合は必ず後方互換性を破棄せざるを得ない、というのが私の理解です。
Ceki氏の指摘は広い意味では、Javaが登場する前にはよくあったことだ。異なるOSや異なるバージョンの間で移植を行うにはソースコードからコンパイルをしなければならなかった。バイナリが使えるようになり、同じOSの異なるバージョンでも使えるようになり、最終的にはDebian、RedHat、Ubuntuのようなディストリビュータが現れるのは、標準C ABIが作られてからだ。このように手間がかかってしまったのは、ABIがLinuxカーネルやOSの初期のリリースに企業の商用製品を乗せなかった(企業側はソースコードを共有したがらなかった)からだ。
さらにCeki氏は"最終的には競合する言語がScalaの開発者とScalaの利用者の間のギャップを埋めるでしょう。そして、そのときScalaは魅力を失います。"という。Scalaは初期には多くのJavaプログラマの想像力を惹きつける機会があった。そして、まだ関数型言語を学び、簡潔なコードを書きたいと思っている開発者を惹きつけている。しかし、言語の安定性を無視して、Javaと同じように肥大化への道を進むのなら、Scalaは企業向けのソフトウエア開発では傍流のままだろう。確かに初期段階ではScalaの利用は成功するかもしれない。しかし、1年も2年もコードベースをメンテナンスすることはできないだろう。
そして、今やFantomからXtend多くのJVMベースの言語があり、どれも同じようなことが実現できる。どの言語も一定の地位を得ようと歩みを進めている。Javaが次のリリースでモジュールとラムダを導入しようと、そしてそのリリースがさらに1年遅れようと、Scalaが安定するよりも早く多くのJava開発者に関数型プログラミングをもたらすだろう。Javaに追い抜かれる前にScalaが体勢を立て直すのはもう遅すぎるかもしれない。