ろじかるんるんものがたり

病人が特に何も書かない。無駄だからだ。

ScalaMatsuri 2016 に参加しました

Programming Scala

ScalaMatsuri 2016 に参加しました。まだ ScalaMatsuri という名称に変わる前の Scala Conference 以来の参加になります。今回は一般で参加。

一日目。珍しく朝からちゃんと参加してました。偉い。なんかいきなり CoC 説明アニメイシヨンが流れてびびる。CoC というと、最近は Ruby で盛り上がっていますね。OSS における CoC は所謂 CoC とはちょっと質が異なる（と思っている）のでアレですが。ねこみみくまさんって感じがした。

 

Refactoring in Scala

gakuzzzz さんはお仕事で Scala のコードレビューサービス等もやっているので、その辺の経験を元に practical な話をするのかなーと思ったら、案の定タイトル詐欺でした。いきなり Scalaz や shapeless 等のライブラリに存在する Tagged Type の話がでてきたり、比較的新しい機能かつ普通の人は使うことまあほぼない Value Classes の話が出てくる。

個人的には、Value Classes は performance (boxing/unboxing の排除と allocation の低減）のためにあり、必要でない場面では使うべきではないと思っています。必要ない場面で何も考えずに使うと、コードの読み手に「ここはボトルネックなのか」と思わせてしまう。比較的自明にそうならいいのだけれど、どう考えても違うでしょみたいな場所で使われてもただただ読み手を混乱させてしまうだけ。

スライドの例では Model のメンバ id 等に対して使われていました。これは Repository から Model を取得する際に、クエリによっては大量の Model を取得することになるため、allocation の低減という観点で見ると必要になる場合もあるかなと思います。実際には、きちんとプロファイリングした上で使うべきだとは思います。ぶっちゃけ実務では Value Classes 使う前にすべきことが沢山あるはず。

Phantom Types を使って type-indexed な型を定義するのは、Scala に限らず generics 相当を持つ言語では、良い手法だと思います。スライドの例では同じ値表現を持つ異なる型を定義するために使っていましたが type-indexed types は他にも色々と使い道があるのでどんどんやっていきましょう。

次は Play2 の Formatter の定義がだるいという話。だるいので Iso と Prism を使いましょうとかいい始めて、いよいよ本格的に詐欺に。Iso と Prism は数年前から Haskell 界隈で使われだした所謂 Lens ライブラリ等の基盤となるものです。Scala の Lens ライブラリといえば Monocle ですが Shapeless にもあって、ほんとなんでもあるな Shapeless 君って感じ。Lens 抜き、Iso や Prism 単体でも十分に価値のあるものなのでいいと思うのですが、これ Refactoring か…？

前半の話で abstract type members 出てこなかったなーと思って質問したら gakuzzzz さんが path dependent types と type projections 間違えてて（といっても、v.T は v.type#T でしかないわけですが）話が通じてなかったっぽかったのが悲しかったです。二日目に話して解決しました。

 

A deep dive into scalac - ScalaMatsuri 2016 by Chris Birchall

療養中にいつの間にか海外に転職していたクリスさんの発表。Scala World 2015 でもほぼ同様の内容を発表されていて、そっちを既にチェック済みだったのでどうしようかなあと思ったのですが、同時間帯では一番興味がある内容だったので他は動画でいいかということに。

Scala World 2015 の内容とそこまで差はないし、諸々の都合で nsc のコード読んでたりしてるので、個人的にはそんな deep な内容でもない（普通の人は読まないので勿論 deep です…）ので、うむうむと聞きつつ、補足ツイートを適当に投げたししてました。

クリスさんの英語は丁寧で聞き取りやすいので、同時通訳必要ないと思って聞かなかったのですが、同時通訳の質が（翻訳者によるばらつきはどうしてもあったみたいですが）かなり高品質だったらしく、聞いておけばよかった…とちょっと後悔しました。まあぶっちゃけ久しぶりにクリスさんに会いに行くかみたいな感じだったので声が聞けたのだからそれで良い。

スライドにもあるように、nsc って大体 typer があほみたいに遅いんですよね。これは typer というフェーズ名にも関わらず typing 以外にも色々やりまくってるのが原因なのですが、実装の都合的に割りと仕方ない…コード量も他フェーズに比べて圧倒的に多いです。typer と patmat 以外のフェーズは 1 つの scala ファイルで定義される程度には小さい。

発表後にクリスさんと「ソースコードごとに統計出す機能欲しいですね」「でも現状の設計だと無理ですよね」という話をしたりした。まあ、分かったところでコンパイル時間の改善って難しいんですけどね…

 

Thinking in Cats

これまた療養中にいつの間にか Typesafe に転職していた横田さんの発表。Scalaz は、こんなものは Scala way ではない、不要だと主張するために（…）コードをある程度読んだりしてたんですが、Cats についてはコード読む所か、全く知識が無かったので聞くことに。

実際の発表内容は、Cats の作者（だっけ）の Erik Osheim さんが Scala World 2015 で話したのとほぼ同じとのことで、Cats のコードについての具体的な話とかはなくて、期待していた内容と全然違っていて残念。FP （というか Haskell way）でわっしょいわっしょいしている Scala コミュニティとは反対に、FP をやりすぎるなというか Haskell way したいなら Haskell 使え派のおじさんとしては、FP への障害ねえうーんどうでもいいんじゃない寧ろ障害作ってるのってそっちの派閥では…みたいな気持ちで前半は聞いていました。後半もまあ圏論がどうとかモナドがどうとかも、今更聞きたいトピックでもないので、むむーんという感じで終わり。猫画像はかわいかったです。

 

ランチ休憩の時間に横田さんと「lubbing いらなくない？」「OO + FP が Scala の売りだし lubbing なくすわけには」「欲しくない場面はある」「確かにあるけど、OOPL である以上一定は程度は仕方ない、lub を指定できない API が悪い」「-Yno-lub あっていいと思う」「OO + FP の Scala が標準にいれるのは FP に寄りすぎ、バランスが大事」「equals が Any 取るのありえない」「確かに問題になることはある、Java との Interoperability を考えると妥当」「○○も失敗だったと言ってた（ここちょっと正確に覚えてない）」「canEquals 考えたの Odersky 先生だし」「でも～（ここまでと似たようなやりとり）」「lubbing 問題は type system だけでなく library 設計も原因、つまり」「「Scala の Collection Library はクソ」」「そもそも継承とかいらなくない？」「さすがに FP に寄りすぎ。pure OO なのも Scala の売りなんですよ皆忘れてるけど。寧ろ Java よりよくなっているとはいえ OO が蔑ろにされすぎ。self type annotation はあるのに C++ の private 継承のような実装*だけ*を継承する手段がなかったり、Scala の OO はまだ（僕の理想よりも）よくない」「dotty みたく sum type があれば lubbing 問題はある程度ましになる」「それはそう」「SI-2712 問題は」「改善して欲しいけど仕方ないんじゃないですか」みたいな話をしました。話したことちゃんとまとめるとそれだけで一つの記事になるのでこんなところで…発表よりこの時話した内容のほうが有意義だった。

Haskell-like なコードを JVM で動かしたいなら Scala じゃなくて Frege でも使ってあげればいいのに思います。昔からそうでしたけど、最近は観測圏内だと以前にも増して FP = Haskell way みたいになっていて、よくないことだと思います。OO = Java way といってるようなものですからね。バランス、バランスが大事です。

 

この後は発表聞かず暫くスポンサーのブース回ってました。瀬良さんの発表聞きたかったのですが、人多すぎで聞けなかったので結局ずっとうろうろ。クリスさんもいってたけど瀬良さんは typical Japanese developer ではないと思う…

ChatWork のブースに居た人と、何の話題出してもきちんと返してくるなー偉いなーと思いながらフロントエンドの話とかしていたんですが、後で聞いたところフロントエンド界隈で有名な人だったらしく、なるほど失礼しましたという感じだった。実際途中かなり失礼なこと言ってしまった気もする…色々話したんですがここに書くと各位からお叱りを受けそう…書ける範囲だと、React の悪口（React が駄目ということではなく売り文句が詐欺）とか、Web Components 使いたくても実装してないブラウザのサポート期間長くて第二の IE6 問題起きるから使えないとか、「Scala.js 使うことでバックエンド側の人にもフロントエンド開発して欲しい、でもそうすると俺仕事のなくなっちゃうんだよなー HAHAHA」「なるほどー（なんだこの人）」みたいな感じでした。

他にも回ったけれど、書くほどのことはない…と思う…（忘れたわけじゃないよ！）

 

Steps to master the Play source code

jboner さんの発表聞こうかなと最初は思ってたんですが、高橋さんと合流していたので、いかずに発表の準備する高橋さんと補充されたお菓子を即効で食べ尽くすみたいなことをしていた。で発表。

内容は、大体 Play の歴史のお勉強という感じでした。さすがに Play 1.x の話はなくて Play 2.0 から。兎に角実装が酷いとか、API が使いづらいとか、テストがしづらいとか、まともでなかったのが、2.5 にいくに従ってましになっていったよという話。ましにしていく過程で DI 欲しくなったので guice が使われるようになったよとか。あとはちょろっと実際の各モジュールについて説明しておしまい。最終的にはマスターしたいなら読め、とのこと。正しいと思う。

Scala technology supporting the Dwango account system

一次面接で落とされたドワンゴの pab_tech さんの発表。内容は qiita で既に記事になっているので、改めて書くことは特にない。

権限の制限は継承関係でやるより Phantom Types 使ったほうが flexibile じゃないですかとか、継続使う必要性ないと思うんですけどとか質問したりした。

 

その後は懇親会。肉ばっかりだなーと思ってたら、肉から無くなっていった…立食だったのが体に響いて一気にダメージ受けた。病人は辛い。

返り際、運営スタッフの人に余ったお弁当を 6 つ持たされる。2 つで十分ですよ！まだ冷凍庫にあります。ハラール弁当は温めるのが難しかった。

 

で二日目なんですが、書くの疲れたので気が向いたら追記する…