matzとkmizuさんを中心としたscalaの複雑性についての話

Yukihiro Matz @yukihiro_matz

レバレッジメモ: Scalaスケーラブルプログラミング - 西尾泰和のはてなダイアリー: http://bit.ly/9QCS0v やっぱScala難しいよな。

Kenji Yoshida @xuwei_k

なにが"やっぱ"なのかよくわからないなぁ・・・　RT @yukihiro_matz レバレッジメモ: Scalaスケーラブルプログラミング - 西尾泰和のはてなダイアリー: http://bit.ly/9QCS0v やっぱScala難しいよな。

Yukihiro Matz @yukihiro_matz

そうですか？ 「以前にも難しいと思ったが、この記事を見て改めてそう思った」という意味の「やっぱ」なんですが。たとえばシンタックスシュガーひとつとっても「簡単」とは言いがたいでしょう。RT @xuwei_k: なにが"やっぱ"なのかよくわからないなぁ・・・

kmizu @kmizu

@yukihiro_matz あえて絡みますが、シンタックスシュガーで「簡単」とは言いがたいってどの部分でしょうか？Scalaが「難しい｣部分を持っている事は否定しませんが、シンタックスシュガーもそんなに複雑ですか？

Yukihiro Matz @yukihiro_matz

@kmizu 繰り返しになりますが「訓練されたScalaプログラマ」には複雑さは見えないんじゃないかと。私だって「訓練されたRubyプログラマ」なのでRubyの複雑さは見えないのでお互い様の点はありますが。

Yukihiro Matz @yukihiro_matz

@kmizu それでも、たとえば「コロンがつくと右オペランドのメソッド」とか、「すべてのメソッドが演算子になる」とかは、ルールとしてはさほど難しくなくても、組み合わせた結果、プログラムのセマンティクスを読み取るのを困難にするという意味で「複雑」だと思いますよ。

kmizu @kmizu

@yukihiro_matz ルール自体が複雑でなくとも、下手に組み合わせると複雑(に見える)な動作をするかもしれない、という意図ですよね？でも、:で終わるメソッドって右結合の演算子が欲しい場合以外では、さほど使われませんし、杞憂かなあと思います。

Yukihiro Matz @yukihiro_matz

@kmizu そういうことになりますね。ただ、私が一番懸念してるのは、右結合ではなくて、演算子としてのメソッドが多重に重なった場合だったりします。っていうか、Scalaのspecで x should not be zero とか言われても、(私の脳が)パーズしきれませんです。

Yuichi Katahira @katahirado

@kmizu 両方やってて主にRubyサイドから来た身としてはscalaは複雑だと思いました。(Rubyと比べて)覚えるべきルールが多い。文法が巨大。でも複雑なのは別に悪いとは思わないのでそれでいいと思いますけど。

kmizu @kmizu

@katahirado Scalaが複雑であろう事は自分も否定はしてないです。ただ、文法の複雑さに関してはどっちもどっちというか、少なくともパーザ書くのはScalaの方が(たぶん)楽です。

kmizu @kmizu

@yukihiro_matz なるほど。ちなみに、これは、(x should not) be zeroとパーズされます。notとzeroが値でshouldとbeがメソッドですね。

kmizu @kmizu

@yukihiro_matz この例の場合、notとかzeroが値なので紛らわしいだけで、パーズそのものは文脈考慮しなくていいので、実はかなり楽なんです。

nishio hirokazu @nishio

「R5RSより言語仕様のでかい言語はみんな複雑」訓練されたPythonista談 @yukihiro_matz @kmizu 「訓練されたScalaプログラマ」には複雑さは見えないんじゃないかと。私だって「訓練されたRubyプログラマ」なのでRubyの複雑さは見えないのでお互い様

小林 悠 @yukoba

「読める言語はみんな複雑」訓練されたWhitespacist談 RT @nishio: 「R5RSより言語仕様のでかい言語はみんな複雑」訓練されたPythonista談 @yukihiro_matz @kmizu 「訓練されたRubyプログラマ」なのでRubyの複雑さは見えない

Yukihiro Matz @yukihiro_matz

「実はかなり楽」といわれても、私には困難である事実は変わらないw RT @kmizu: (x should not) be zeroとパーズされます。notとzeroが値でshouldとbeがメソッドですね。

kmizu @kmizu

@yukihiro_matz これ以上は水掛け論になりそうですが、基本的に、x op yが文脈問わずx.op(y)の構文糖であり、ネストした場合も同様にx op1 y op2 zがx.op1(y).op(z)になるというだけなのですが(優先順位の判定は別とすると)、(続く)

kmizu @kmizu

@yukihiro_matz で、これは少なくとも文法の規模で言えばおそらくRubyのメソッド呼び出し規則に比べて複雑ではないと思います。とすると、どこに困難さを感じられたのだろう、というのが興味があるところです。

kmizu @kmizu

@yukihiro_matz ここで、理由を単に「訓練されたRubyプログラマ/Scalaプログラマだから」という事に求めてしまうのもアリなのですが、もうちょっと踏み込んで、「本当の複雑さ」と「人間(たとえばMatzさん)が感じる複雑さ」の差がどこにあるのかに興味があります。

kmizu @kmizu

問題をもうちょっと明確にしてみる。自分はある特定の文法要素の複雑さを(おおまかに)どうやって考えてるかというと

kmizu @kmizu

該当する文法要素の(形式的 or 非形式的)な定義とそれにマッチする文字列が入力として与えられたきに、自分が人間パーザになるとして、どれだけ高速にパーズできるかという風に考える。

kmizu @kmizu

もちろん、「人間パーザ」なので、特定の言語の文法をよく学習してるかどうかが影響及ぼすのでまあフェアではないのだけど、

kmizu @kmizu

一応自分は、日常のスクリプティングでRubyも使える程度にはRubyの文法を知ってるので、そこまでScalaに極端に偏ってるとも思わないし

kmizu @kmizu

あとまあ、Scalaを学習し始めたときの事を思い返してみても、苦労したのは主に型システム周りの理解であって、演算子周りの文法で苦労した記憶がほとんど無いんだな。ちょっと躓いたことがあるのは、_による無銘関数のシンタックスシュガーくらい。あれは実際にそれなりに複雑なので、

kmizu @kmizu

あれが複雑だというのなら、割と理解できる。

Yukihiro Matz @yukihiro_matz

@kmizu 私が話しているのは文法の複雑さではなくて、理解(人間による意味の把握)の困難さなのだと思います。これを「複雑さ」と呼んだのは私がうかつだったかもしれません。