Scalaの普及と可読性の議論

tanigon＠ついったー東方部 @tanigon

daiksyの例 maybeValueがゼロのときどうなるんや（どうでもいい）

tanigon＠ついったー東方部 @tanigon

daiksyの例は、scalaの「難読性」みたいな、パズル的な楽しさはあるんだけど、初心者が身構えちゃう部分が如実にあるような気がして、　たぶん、多くの人にとっては hoge.maybeChild!.maybeValue! で取り出せてよ～～ってなるのが普通だと思う

tanigon＠ついったー東方部 @tanigon

たとえば、机上の空論乙とかいわれる覚悟で、こういう書き方のほうが初心者にやさしい val value= try { hoge.maybeChild.maybeValue } catch { だめだったときの値 } まあ、これだとvalueもOptionにするぽか

tanigon＠ついったー東方部 @tanigon

Scalaに慣れてくるとforの例が、とか いう話って、本質的でない部分の理解をいろいろ知ってないとダメで、初心者にはつらいのではっていう。 Optionがイテレータとして使えることとか。(forもfilterの例もそれで動いてる)

tanigon＠ついったー東方部 @tanigon

for {..}yield というものがそもそも Optionであるとか、正直パズルすぎて難読なんじゃないかっていう。　個人的には「そりゃこういうのがエレガントだって思われてる界隈だとしたら　初心者への布教なんて進まない」って思う（導入が遅れるという話しで） disちゃうで

tanigon＠ついったー東方部 @tanigon

scala好きだし xuwei_kさんのfilter式もイイナ！って思うんだけど、やっぱ「こう書くのがScala流」だとしたら、やっぱ普通の人は腰ひけちゃうんじゃないのかとは思うよねｗ

tanigon＠ついったー東方部 @tanigon

(nil許容という前提の表現で) hoge.maybeChild が nilか、実際にChildが入ってるかもしれない、と。で、 child.maybeValueが nil か　数値が入ってるかもしれない、と。

tanigon＠ついったー東方部 @tanigon

そんときに flatMap とか filter とか for とか yield とか 使うのがフツーって、フツーは思わないんじゃないかなっていう。 いや、楽しいけど！！おれは好きですけど！　普及しないよそりゃって思っちゃう！！

がくぞ @gakuzzzz

.@tanigon さんの主張もわからなくはないのだけど、foo?.bar?.baz? という書き方は今回の@daiksyさんの例なら通じるけど、複数のOption値が出てきた時に使えないんだよね。a:Option[Int]とb:Option[Int]を合算したいとか

がくぞ @gakuzzzz

なのでswiftは複数のnilに対応するためにletを拡張するって改修がされたわけなんだけど、for一つ覚えれば全てに適用できるのと、?や!、letまたコレクションでは違う方法と、いっぱい覚えなきゃいけないのとではどちらが果して学習コスト高いのか？

tanigon＠ついったー東方部 @tanigon

@gakuzzzz @daiksy 演算したいとかになるとそうかもですねー。ただ、自然言語的可読性についての問題に鈍感であってはいけないという主張はかわらないです。たとえばその場合 val sum = try { a.maybeValue! + b.maybeValue! }

tanigon＠ついったー東方部 @tanigon

@gakuzzzz @daiksy try {...} catch { intの何か } 的に書ける/書くべき、読みやすい、なんてことを思っています。 あとdaiksyサンプルのケースは実際に割とよくあることかなとも思っていたりします

tanigon＠ついったー東方部 @tanigon

@gakuzzzz @daiksy swiftのunwrap的な話でいくと、実際にはたとえばこう書きたいわけです。 sum = a.maybeValue! + b.maybeValue! ただ、当然、None(swiftのnil)のことがあって、そんときは実行時エラーに。

がくぞ @gakuzzzz

@tanigon @daiksy その記述がしたいのなら可能ですけど、たぶん仰りたい事は別ですよね＾＾；；； val sum = Try(a.get() + b.get()).toOption

tanigon＠ついったー東方部 @tanigon

@gakuzzzz @daiksy かなり簡素で、for yield, flatMap filter などより「読みやすい」と思います！！ toOption のところはまだあれかもですが、素晴らしく読みやすいと思います

tanigon＠ついったー東方部 @tanigon

Try { 演算 }.getOrElse(仕方ねえフォールバック値を返すぜ) 　ケースだと　自然言語的にも読みやすいのかな。getOrElse恐怖症というのも多少あるが...

tanigon＠ついったー東方部 @tanigon

2つのOptionの演算で、「どっちもSomeであることが前提」以外のケース、たとえば片方だけがSomeの場合はこう動く、とか、　そういうことしたいなら getOrElseやTryで、　もっと場合わけしたいならパターンマッチングでいいと思う。それが冗長だとは思わないな。

tanigon＠ついったー東方部 @tanigon

Optionの演算ってわかりにくいな。　例えば Option[Int] のときに　そのIntを使って演算する、みたいなケース

がくぞ @gakuzzzz

単に内包表記に慣れてるか慣れてないかだけな気がするなー

がくぞ @gakuzzzz

Pythonの人とかは内包表記メインで使うし。統一的な表記はそれはそれで読みやすさと学習コスト下げると思うけど、なんだろうこのギャップ？

tanigon＠ついったー東方部 @tanigon

@gakuzzzz 「慣れ」っていっちゃうともうゴールしちゃえるので・・・たとえばScalaでコーディング続けてると、for yield式も flatMap filter式も読解も記述も問題なくできると思います（慣れ）。　考えてたのは、「これが当たり前」だと敷居高い？という。

tanigon＠ついったー東方部 @tanigon

まあ、そういう意味では内包表記に慣れ親しんだ方には親しみやすいScala言語です！　ってことでもいいのだけれど、個人的にはもっと普及してほしいのです...。

がくぞ @gakuzzzz

@tanigon ただ、この書き方だとfilter挟みたいとかの応用が効かなくなるんですよね。ならさっさと統一的な手法を一個覚えて貰う方が結局はいいのでは？と思ってしまいます。

がくぞ @gakuzzzz

@tanigon たしかに「これが当たり前」的な意識をだされると、うっとなる感覚は共感できます。ただ、みんなあんまり当たり前と思って無いから今回のdaiksyさんのようにあちこちで取り上げられるのかなーという気がしております