一貫性とは別の話で、一貫性と驚き最小の法則は一緒かと思ったけど、そうではない。松本:驚き最小かどうかっていうのは、実は、一貫性より多くのことを含んでいて、一貫していないと驚くのは確かなんだけど、一貫しているからといって、驚かないとは限らない。松本:「驚き最小の法則」のときの驚きって、実は色々な使われ方をしていて、一番多いのは、自分の慣れ親しんだプログラミング言語と違うって驚く、自分の文化との違いに驚くっていう。それは、一貫性があるかどうかってのは関係ないんだよね。先ほどの話が、そのまま適用されるってことですかね。価値をきちんと定義し、それをほかとの影響も合わせて議論して。一貫性が議論の正当化にはならない?松本:ここにある機能が、ここにもあるべきだ、とか、誰も使わないけど、こっちにあるから、こっちにもあるべきだ、みたいなことは、止めようかなと。笹田:似たような機能で、こっちはエラーになるから、こっちでもエラーになるべきだ、みたいな。この間、[ブロックとキーワード引数の話]とかありましたよね。松本:一貫性のために、揃えることは最優先ではなくて、揃ってることで嬉しいなら、それはいいんだけど、揃っていても、誰も使わないし、あってもなくても関係ないような時やむしろデメリットがあるときにまで、揃える必要はないかなという。笹田:先ほどのブロックの話は、まさに揃えるかどうか、って話でした。2.0.0からキーワード引数が導入されたことで、対応しないキーワードをつけてブロックを呼ぶことで、エラーが出るようになりました。あそこは、微妙なところだったと思うんですよね。それまでは、どんなブロック呼び出しでもエラーにならなかったので、驚くかもしれない、と。エラーにならなくてもいいんじゃないかなというのは、ちょっと思ったんですよ。それで、エラーになってもならなくても、たぶん今のところはまだ困らない。導入されたばかりの機能なので。笹田:そこに対して、明確に、誰が嬉しいんですかっていう風に、この間聞かれてましたよね。それで反論を封じた感じだったんですけれども。相手は一貫性しか言ってないから。笹田:そこはもう、ユースケースの方が優先であると。松本:ユースケースもそうだし、あれの場合は、トレードオフが存在したわけだよね。エラーを無視することで、エラーの発見が遅れるっていうことは、デメリットなんだよね。今までのものとの、ほかの部分との、一貫性をとって、デメリットを受けるには、嬉しさがないなという風に思った。笹田:逆に言えば、早めにエラーを出すようにすることも良いと。松本:たとえば、互換性を何も考えずに、もし変更するとすれば、逆に、エラーを早く発見する方法に進みたいと思っているぐらいなのに。