Scala関西Summitで発表してきたよ

summit.md

Scala関西Summitで発表してきたよ

2016/10/08 大阪産業創造館にてScala関西Summitが開催されました。

弊社、ゴールドスポンサーとして協賛もしてましたが、スポンサーセッションとは別に普通にCFPにも応募しました。

そんな訳で「Implicit 再入門」というタイトルで登壇してきました。

テーマの動機

しばしば「ImplicitがあるからScalaは可読性が低い、怖い」という主張を見かけていたので、いやいやそれは機能を誤解しているか使い方を間違えてるだけで、本来は可読性を高めるためにあるんだよっていう話がしたかったのが一つ。

また「Java8やKotlinがあるからScala必要ないでしょ」みたいな言説に対して、現状Java8やKotlinには存在しないScalaのアドバンテージついて紹介したかったというのがもう一つの動機でした。

最終的に「Implicit怖くない」と思って貰えればいいなという感じでしたが如何だったでしょうか？

補足

Howを隠蔽してWhatを明確に、という話はDDDの基本でもあるよね。またパフォーマンスチューニングではHowが最重要なのでHowとWhatを分離しておけばドメインのコード(What)を変更せずに性能改善ができる(場合がある)

— がくぞ (@gakuzzzz) 2016年10月9日

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

HowよりWhatというのは宣言的プログラミングのアプローチですが、DDDも基本はこれをどう実現するかという話ですね。

また、Implicitな値が自明な事が大事と述べましたが、なかなか自明な定義って難しいですよね。そういう場合に抽象化が役立つ場合があります。

例えば「StringとIntを受け取って(String, Int)を返す処理」を考えた場合、実装はいくらでも考えられます。

val f: String => Int => (String, Int) = s => i => s -> i
val g: String => Int => (String, Int) = s => i => i.toString -> s.toInt
val h: String => Int => (String, Int) = s => i => (s * i) -> (s.length * i)

しかしこれが「AとBを受け取って(A, B)を返す処理」だとしたらどうでしょう？副作用が無い前提だとすると実装は一つしか書けませんね。

def f[A, B]: A => B => (A, B) = a => b => a -> b

抽象化を行う事によって型から実装が導かれました。この定義は自明と言えるものですね。これも抽象化の力の一つです。

Implicitな値を定義する際にはこの辺も意識してみるといいかもしれません。

他の発表について

Scala Matsuri の運営として焦りを覚えるぐらいｗ面白いセッションが多かったです。

特に Akka 周りのセッションは、単に導入してみましただけで留まらず、生きた実例としてナレッジが共有されているように思えました。

まとめ

きのこさんをはじめとしたスタッフ皆さんの働きと参加者の皆さんのおかげで大変素晴らしい体験を得られました。

改めてありがとうございました。

今度はぜひScala Matsuri 2017で盛り上がりましょう！！