冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

ことりんはスカラスキーの愛人になりうるか

これはKotlin Advent Calendar 2013 - Adventarの24日目のエントリです。すから枠です。ScalaとKotlinというと、ことあるごとに「それScalaでできるよ」的な鉄球が一方的に飛んでるイメージがありますが、はたしてそれは本当なのか?スカラスキーの立場からことりんを愛でた感想あたりを書いてみたいと思います。ちなみに、サンドボックス的なプロジェクトを作って書き散らかしてるだけなので、このエントリにコードは出ません。
使い方が浅くて間違った理解をしている所はたろうさんがマサカリ投げてくれると思います。

Kotlinを始める前に

Kotlinを始める場合、とりあえずは以下のどちらかを参照するかと思います。

Docs Home - Kotlin - Confluence
プログラミング言語Kotlin 解説

公式は、割と初期段階であるサンプルのメンテナンス度合いが微妙で、若干どれを信じて良いかわからない。。。Kotlin自体がまだまだ発展途上ということなのでしょう。バージョンアップがあると一気に今までのコードがエラーになるという状況もあるようなので、ある程度の規模の継続的なプロダクトに使うというのは、まだ少し早いようです。

シンタックス・機能

シンタックスの微妙な違いはあるものの、スカラスキーにとって大きな戸惑いはありませんでした。Null安全な機能についてはKotlinほどの機能はScalaにはないので、まだちゃんと使いどころがわかっていません。ただ、JVM上に作られた言語で、nullであることが避けられないケースもあるため、Null安全の機能は嬉しいのですが頼り切ることもできないんじゃないのかなあ、とは思います。場合によっては新たなハマり要素になりかねないのではないかと。適切に使えるようになりたい物です。ScalaのOptionはその辺で丁度良いところを探ってる感じなのかなあ、とは思いました。
後、関数を定義しようとして「def」と打ってしまってIDEAのエディタに赤いマークが出て嘆息するのは、スカラスキーとしては仕方ないでしょう。。。

で、触ってて気になったところを。

  • case classないの?
    • パターンマッチでcase classのフィールド要素への分解とか結構Scalaが好きなポイントだったり。。。
  • パターンマッチの構文はScalaの方が好き
    • 細かい話だけど、各条件に「case」があって強調される方が見た目わかりやすい
  • 「=」で関数定義してブロック使うと関数オブジェクト返すのね。。。
  • アクセッサの仕様がDelphiっぽくて懐かしくなった、ってかこの書き方は好きだったりする
  • extension functionはScalaのimplicit conversionに比べてすっきりするから好き
    • パフォーマンス的にどっちが良いのかは未検証、ラップしてたら変わらん気がする
    • 拡張するメソッドが多い場合はScalaのimplicit classの方がわかりやすいかも
  • オートキャストは使い方が良ければコードがすっきりしそう
  • Tupleないの?

割と細かいところで気になったり気に入ったりしてて、言語全体とおしてどうよ?ってなると「良い言語だと思いますよ?」としか出てこないレベルでしか触れてないです。

開発環境

JetBrainsが作っているだけあって、(無駄に頑張らずに構築できる)開発環境はIntelliJ一択となります。Community Editionでも問題なく使えるので、導入に対して稟議を書かなきゃ、などはないものの、現状eclipseがメインのメンバーが多い環境だと一工夫必要かもしれません。プライベートユースの場合は、個人の信仰の問題以外は特に気にする必要はないと思います。
テキストエディタ+コマンドラインでガリガリと頑張るという方法もありますが、型型しくてimportとかの記載も必要な言語だと、IDEの恩恵を受けない選択肢は個人的にはないです。というわけでIntteliJ IDEA使いましょう。

ビルドツール

公式のドキュメントを見る限り、Javaのビルドでご利用のお好きなものを、というスタンスですね。以下のビルドシステムについては、プラグインが提供されているようです。

  • maven
  • gradle
  • ant
  • griffon

選択肢が多いのは良いことだと思います。今回試すときにgradleを使ってみましたが、特にプラグインも問題なく動いていますし、IDEAとの連携も問題無さげでした。この感じだと、他のビルドツールでもすんなり行けそうな気がします。
本筋とは離れますが、gradleのビルド設定ってsbtよりもDSLが整理されていて読みやすい印象でした。

テストは?

まだKotlinで作られたデファクトとなるようなテストフレームワークはないようです*1。ただ、Kotlinの言語ライブラリの中にテスト支援のための機能は存在しているので、とりあえずビルド設定にJUnitへの依存関係を突っ込んで、以下のたろうさんの記事を読めばJUnitで問題なくテストが書けます。

23日目:JUnitを使う - Kotlin Advent Calendar 2012 (全部俺)

テストフレームワークDSLについてはSpecs2のようなシンタックスが好みなのですが*2JUnitアサーションでは書きたくもない!という訳ではないのでそこはあまり気にしません。

その他ライブラリ回り

今は、バージョンアップがある度に阿鼻叫喚の声が聞こえてくるので、多分依存関係とかライブラリ作者の人とか大変です。先日も @patorash さんが勉強会前日にやられてデモを断念した、とかありましたし。。。
逆に言うと、デファクトとなるライブラリを作ったりするチャンスだとは思うので、余裕と技術がある方は挑戦してみてはいかがでしょうか。KotlinkJDBCとかかっこいいと思います。 > たろうさん

まとめ

光源氏計画推奨です。いざという時の為にキープして、自分好みにしておきましょう。

明日は?

@ayato_p氏です。

*1: 書き始めた後にこんなのがあることを教えてもらった -> JetBrains/spek · GitHub

*2:actual must equalTo(expected)のような記法が個人的にはわかりやすいため