JavaエンジニアにScalaの話を聞いてみたい@ScalaMatsuri2017

on ScalaMatsuri2017, Scala

せっかく座長やったんだったら内容をまとめてくれと @seratch_ja さんに言われたので、書いてみました。

まえがき

私は2016年には学生ボランティアとして、 今年は社会人エンジニアとしてScalaMatsuriに参加させていただきました。

2016年はScalaの今やScalaの開発におけるtipsを学び、Scalaエンジニアと知り合うことができました。ただScalaのフレームワークを用いたサービス、アーキテクチャにあまり興味がなく（研究のために使っていただけなので。。。）、一番研究に近そうな機械学習に関するセッションは「数式は省きます」、のせいもあってセッションの大半はつまらないという感想でした。なんとなくで参加するのはダメですね(笑)

一方2017年はエンジニアとしての価値観を装備し、「streamに関して知見を集めてこい」との上司の司令もあって、目的意識を持って参加してみると実りの多さに興奮しました。 昨年のボランティア参加経験によって私のことを覚えてくださっていた方もチラホラいらっしゃり、積極的に話しかけていくことで寂しい思いをせずに楽しむことができました。

まえがきはこの辺りにして”聞きたい側”として座長を務めさせていただいたセッションでの議論を以下にまとめます。（実はこのタイトルでアンカンファレンス提案したの私ではないんですけどね。）議事録と自分の意見が混在した文章になっていますがご了承を。

JavaエンジニアにScalaの話を聞きたい

このセッションタイトル名からは先生と生徒という確立した立場での議論になるかなりそうなものですが、結果として教える側教わる側という立場を超えた議論ができたのでないかと思います。

議題は主に以下の４つです。

  1. Scalaのメリット

  2. ScalaとJavaの親和性

  3. 言語間の移動が面倒（文法忘れちゃう）

  4. JavaからScalaにチームで移行するには

1.Scalaのメリット

コード量が減って見たいものが一画面に収まる。型で頑健性の高いコードが書ける。nullを避ける書き方は安全。 末尾再帰最適化もある。それでいてJavaの資産が使える。ベターJavaとして使うのでも全然メリットを感じられる。

ベターJavaとは？

（一同）うーむ

ちょっと議論はありましたが、”ベターJavaとして使おう”とは、Scalaっぽい書き方を目指す必要はなく、Scalaのいいとことろを無理なく採用していけばJavaよりも綺麗でいい感じに書けるよ、ぐらいの意図。データ分析系のScala使いは早く書けて早く動作するHigh Productivity Languageとして使用しており、数式を実装に落しこむ時はガリガリindex for書いてます。そっちの方が可読性も高い。とは言ってもコアじゃない部分は関数型的に書いたほうが見通しがいい場面がほとんどです。

nullを返さないのがなぜ推奨されるのか

nullを返すというのはバグの原因の追求が難しく、複雑なシステムを作る上でnullを返さない世界はいいぞとのことです。

2.ScalaとJavaの親和性

Scalaのオブジェクトにはcase classやtrait,ObjectというJavaにはない概念がある。そうしたオブジェクトを呼ぶと問題が起きる。 例えばtraitは実装がなければJavaのinterfaceになるが実装をつけると複数のclassが作成されてしまう。abstract classを噛ませよう。sealed traitは継承することができてしまう。case classやObjectを呼び出すことの具体的な問題点は聞いていないがやってはいけない。

意外に落とし穴なのが設計思想が異なることで、ScalaからJavaの実装を呼ぶとガンガンnullが返ってきたりしてしてビビる。貧弱なJavaの型からScalaの型へはimplicit　conversion, converterでよしなにやってくれる。逆は上記の技術的障壁を越えればScalaエンジニアなら困らないかもしれないがJavaが主役であればJavaの設計思想に合わせたラッパを噛ませる必要があるかも（？）

3.言語間の移動が面倒

Scala書いてJava書いてpython書いて。。。Scala書くとセミコロンつけちゃう。

（一同）わかるー

でもIDEだと間違ってたらすぐ教えてくれるし、すぐ元通りだよ。

（一同）IntelliJ最高！

4.JavaからScalaにチーム移行するには

まずメリットの共有が重要。 PerlからScalaに移行した話、Perl嫌だーってなってて型に守られた安全性の高いScalaの環境にみんな心から満足して移行した。

Javaからの場合、Javaに満足していたら移行するメリットなさそう？

Javaを書ける人ならScalaの仕様に感動する。Javaの面倒臭いところが本当に簡単に書ける。

でもデメリットもあるんでしょう？

Scalaライクなコードを書く、つまり関数型しようとするとオブジェクトの生成というロスがある。これはFinchの話でもでてきたことで90%にスピードが落ちるがそれを上回る型によるの安全性のメリットがある。Java likeなコードはScalaでも書けるのでそこは適材適所。 検証が大事。

おいおいパフォーマンスが落ちたぞー(怒)みたいのがあると思う。

話を聞く限りにおいてScalaのほうが良い場面が多いという意見なので、そこは高いScala技術をもってすればいい着地点に到達できると思う

ライブラリによって独自DSLがあって演算子の意味が違ってややこしい

でも例えばSpringとかヤバいし（わかる）、DSLっていい解なのでは。 DSLを簡単に書けるのはいいことなのでは。 macroが散乱するわけではなく、DSLはあくまで多様な演算子が使えるというだけだし、慣れたScalaエンジニア的にはそんなに問題だとは思わない。IntelliJ使ってれば予測変換候補からScala doc開いて選択ができるしね。 IntelliJ最高！

書き方の多様性やばい。

（一同）わかるー

チームでの移行の最も大きな問題か。

個人で移行する分には自分のペースでScalaライクなコードに成長させていくことができるが、チームでやるには規約を定める必要がある。一人が突っ走ってFree monadがそこら中に転がってみんな読めないことがあった。とは言うものの個人個人がいいものを見つけたら共有してチームのScalaレベルを上げる必要もある。ただそれが無秩序に積み重なるとヤバくなるのでScalaをわかる人がコーディング規約を決めていく必要がある。

結論

JavaからScalaに変えるメリットは → いっぱいあるから触ってみて！習熟することで見えるメリット、気にならなくなるデメリットがある！

ScalaとJavaの親和性 → 高い。だだし技術的な障壁だけでなく文化的な障壁もある

言語間の移動が面倒 → IntelliJ! IntelliJ!

JavaからScalaにチームで移行するには → Scalaエンジニアとしての知見とマネージメントスキル！検証！（大変そうだ、、、）

あとがき

ScalaMatsuri2016に参加した時もアンカンファレンスはあって、折角みんなで議論できる場なのに、声の大きい人が自己満足を満たす場になってしまっているセッションに参加した経験があります。「JavaエンジニアにScalaの話を聞きたい」は”教える側”と”教わる側”がはっきり分かれそうなタイトルのセッションだったため、去年見た残念なセッションになる確率がゼロじゃない、なっては嫌だという思いもあり、今回のセッションはScalaコミュニティの常連っぽい人が来ても会の主導権は渡しませんでした（笑）結果的にいろいろな人が意見を出せるTHE アンカンファレンスになったのではないかと思います。(ただ素敵な方々が集まっていたので誰が座長をしていてもいい会になっていただろうとも思います。)

なんだかまえがき含めて去年のScalaMatsuriに対してちょっと批判的ですが、目的意識を持っていけば短期間でとても多くのことを学べるカンファレンスです。学生のように時間のある身だと、そんなの本読みゃ分かるわ！という感想を抱いてしまうセッションもあるにはあるのですが、Scala言語の今とかScala界隈の有名人をたった２日で知ることができる機会というのは長期的に見ればかなりプラスだと思います。

以上