業務システム開発の次の言語としてのKotlinの可能性
いつもながらの、雑感。Javaの次の言語としてのKotlinについて考えてみる。
上記みたいなこと、いろいろ考えていた。
もう、オープン系業務システム(エンタープライズ)の開発言語としては、長い間、UNIX系プラットフォームだとJava,Windows系だと、C#って感じでずーっと続いていたと思う。（Windows系はある種独自の世界なのとよく知らないので、ここでは割愛。）
その間、何度か、新しい言語の波が来ていて、Javaの次が来るって期待があったと思う。
RubyとRuby on Railsの衝撃
自分の記憶にあるのは、Ruby on Rails（以下RoR）の衝撃。
簡単なDBのCRUDアプリを作るのにも、ものすごい金と時間が掛かっていたStruts1全盛の時代。あっという間にWebサイトが作れてしまうのは衝撃的だった。『JavaからRubyへ』みたいな本が書かれた。
楽天市場のサイトがRubyで開発されたのって、象徴的と思う。
SIの世界でも、一部でRuby/RoRが使われるようになったし、Javaの過去資産を活用できるJRuby、そして、Javaとの連携を強く意識したgroovy/grailsが出てきて、動的言語が注目を浴びていた。
ただ、主流はやはりJavaで、言語よりフレームワークでRoRを強く意識して、同程度の生産性を出そうと頑張っていたと思う。
Javaも5になって、ジェネリクスやアノテーションが出来て、いいフレームワークを作れるようになってきていた。
Springは、RailsLikeな開発ができるSpring Rooをリリースしていたし、日本では、SAStrutsが色んな企業の業務アプリ開発に使われるようになった。
この動きっていうのは、Webアプリケーション開発/アーキテクチャのベストプラクティスが確立され、Webアプリ開発がボイラープレート的なコードの記述になっていったことを示しているんだと思う。
RoRはボイラープレート的なコードをほとんど0にしたし、それに刺激を受けたJavaフレームワークもその方向で進化した。
言語の動的性質っていうのは、インパクトの小さな部分だったのではないかな、と振り返ってみると思える。
ただ、多くの人がRubyやGroovyに触れることでそこに表現されていた関数型プログラミングの概念が業務アプリのエンジニアたちに広まったのは結構大きいと思う。
Scalaの台頭
動的言語とそのフレームワークが注目されている中、やっぱりコンパイル時のチェック、そして、何より静的言語のパフォーマンスいいよね、でもJavaいけてないよねってことで、Scalaが台頭してきた。
頻繁にクジラの画面を表示させていたTwitterがバックエンドをRoRからScalaに切り替えた、というのがその象徴的事件。
Webアプリとしてのフロント側だけでなく、Hadoopなどのパフォーマンスが必要とされるバックエンドでの大量データ処理の必要性が出てきたのも背景にあると思う。
ただ、技術的なチャレンジとしてScalaが注目、方々で採用されている中、Javaもしぶとく生き残っている状況がある。
Scalaの膨大な言語仕様や、コンパイル時間の長さ、バージョンアップ時の互換性の軽視あたりは、採用に二の足を踏むチームも多かったんじゃないかなー。
個人として、最初かなりScala面白そう、と思ったのだけど、実際書いてみると色々辛い。。。年寄り文系の自分には難しすぎるんだよね。Scalaは。。。
下記みたいな話もある。まあ、パフォーマンス問題は過去の話と思うけどねー。
今の言語の進化の方向は、静的型付けがある中で、どれだけ手軽にプログラミングできるか、を模索していると思う。Go言語とかもね。
（ざっくり言い過ぎと思うが。。。）
Kotlinの位置付け
KotlinはIDEベンダであるJetBrainsが開発したJVM上で動作する静的言語。（JavaScriptにコンパルすることもできる。）
まだ、リリース前のベータ版だけど、もうすぐリリースとのこと。Android開発ではもう結構使われているっぽい。
基本的に、KotlinはAltJavaであるC#,Groovy,Scalaあたりの良いところ取り。そして、Javaプログラマが多く従事している業務アプリの現場での課題解決を強く意識していると思う。
下記は自分がいいな、と思ったところ。
- 静的言語であり、コンパイル時チェックが効く
- 文法がJavaプログラマにとってとても学びやすい
- Null Safety/Optionalが言語レベルでサポートされて、Java8のOptionalより分かりやすい
- 関数型プログラミングが言語レベルでサポートされ、Java8より分かりやすい
- 演算子オーバーロードや拡張メソッド（Scalaのtrait）などDDDに都合の良い機能が豊富
- 困った時はJavaで書ける
- 返り値を複数とるような感じで、書ける
Java8への移行との比較
個人的には、Java8のラムダやメソッド参照、Optionalなどは、かなり無理矢理詰め込んだ感があり、相当使いにくい。
複雑なロジックになった時、StreamAPIを下手に使うと、可読性が低下する気がするし、Optionalの使い方も徹底できる気がしない。そこら辺、どうしてもプログラマの規律に依存しなくてはならないと思う。
ある程度の規模のプロジェクトになると、これらを全面的に導入して、学習コストに見合うメリットが出るとは思えない。
（技術自慢のプログラマー集団なら、新しいチャレンジにもなるし、ありかと思うけど。）
個人的にそこにコストをかけるんなら、ValueObjectとか、仕様クラスみたいなDDDのやりやすい所をやっていった方がプロジェクトに対してはメリットが大きいと思う。
対して、KotlinはJava8の新機能がやろうとしていたことを遥かに効果的に実現していると思う。とにかく分かりやすくて、Javaプログラマには学習コストが低い。
ちゃんとした研修コンテンツを作って動画配信してあげれば、プロジェクト全体に導入することも大したコストなくできると思う。
@masatsugumatsus 結局、技術的に苦労するのってフレームワーク側だから、機能開発に限っちゃえばkotlin導入のリスクって殆どない気がするなあ。SIのプロジェクトなんて、どうせJavaもよく分からず使っている人ばかり、って場合も多いし。。。
— 松下正嗣 (@masatsugumatsus) 2015, 11月 23