型付けについてのまつもとさんとみずしまさんのやりとり

Yukihiro Matzmotto @yukihiro_matz

@kmizu 静的型のメリットは十分に理解してるけど、動的型よりも「表現力が高い」ってことはないんじゃないかなぁ。スタイルの違いはあっても。Mapの例にしても、型情報を失わないScalaはすごいけど、動的型言語なら型情報なしでそのまま動いちゃうわけで。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz いや、Mapの例だと、動的型言語だとそのまま動かせないのでは？Procが引数と返り値の型情報をメタデータとして保持していない限りは。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz おっしゃるとおり、一般的には動的型言語の方が表現力が高いですが、今回の話では、静的型情報を効果的に使うことで簡潔に書けるケースがあることを示したかったのです。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz 一応繰り返しておくと、さきほどのMapの例では、引数として渡した関数値の引数と返り値の型情報(動的型言語では、この部分の情報は通常は得られない)によって同じ型のMapを返したり、Listを返したりと分岐できるのが肝です。

Yukihiro Matzmotto @yukihiro_matz

@kmizu {1=>"a",2=>"b"}.map{|e| e[0]} と {1=>"a",2=>"b"}.map{|e| [e[1],e[0]]} でしょ。RubyのmapはHashを返さないけど。スタイルの違いなんじゃないかなあ。なんか勘違いしてる？

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz RubyのmapがHashを返せたとして、{}.map{|e| e[0]} と {}.map{|e| [e[1],e[0]} だとどうなります？Procを実際に適用してみることができないので、とりあえずArray返すくらいしか選択肢ないですよね。

Yukihiro Matzmotto @yukihiro_matz

前者はエラーになるでしょ。(k,v)じゃないから。RT @kmizu: @yukihiro_matz RubyのmapがHashを返せたとして、

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz ちょっと行き違いがあるかもしれないので、要求について一応整理しておくと、引数として渡される関数(Rubyだとブロック)の型情報に基づいて、どの種類のコレクション(RubyならArrayかMapか)を返すか、を変えたい、ということです。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz いや、ならないことがあります。空Hashを例に出したのはそのためです。

Yukihiro Matzmotto @yukihiro_matz

@kmizu Rubyならそれぞれ違うメソッドを用意すると思います。同じメソッド(map)が与えられたblockによって全然違うものを返すのは、私の基準ではよくないスタイルですから、メリットに見えません。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz もちろん、良くないスタイルであるという主張は理解できますが、ここで考えているのは、ある要求があったときに、静的型付け言語の方が簡潔で直接的に書けるケースがあるかということなので、良いスタイルかどうかはとりあえず問題にしていないです。

Yukihiro Matzmotto @yukihiro_matz

@kmizu うーん、静的型言語にだけ可能な人工的な(しかも、特にメリットがない)要求を持ち出して、「静的型付け言語の方が簡潔で直接的に書ける」と言われてもなあ、というのが正直な印象です。もうちょっと別の例はないですか。

Yukihiro Matzmotto @yukihiro_matz

@kmizu さらに言うと「簡潔で直接的」というスタイル的なことを取り上げていながら、「良いスタイルかどうかは問題にしていない」というのはダブルスタンダード的な気がします。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz いや、要求を満たすための手順として、より「簡潔で直接的」という話で、その要求自体が「良いスタイルかどうかは問題にしていない」ということです。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz うーん。別に特にメリットが無い、とは言ってないのですが。別の例としては、implicit conversionを使った例とか http://gist.github.com/393880 。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz あと、人工的でメリットが無いと言われても、一応、Scalaの標準ライブラリの機能であって、この例のために人工的に作ったわけでもないんですけど…。

Kota Mizushima (on a diet) @kmizu

あと、勘違いされたくないので、再度強調としておくと、一般論としては、もちろん動的型付け言語の方が簡潔だと思います。ただ、静的な型情報をうまく利用することで場合によっては動的型付け言語よりも簡潔に書けるケースが存在し得るのではないか？、というのが自分の主張です。

Kota Mizushima (on a diet) @kmizu

ただ、静的型情報をうまく活用できるケースがどの程度あるかは正直わからないので、その辺はとりあえず棚上げにして、静的型情報を利用することで、動的型付けよりも簡潔にできるケースが「存在し得る」というのをとりあえず示したかった。

Kota Mizushima (on a diet) @kmizu

というのは、動的型付けVS静的型付け論争で、論点は色々あれど、動的型付けの方が常に簡潔であるというのは暗黙の前提みたいになっているけど、これは常に成り立つのだろうか？と疑問に思っていたわけです。

Yukihiro Matzmotto @yukihiro_matz

@kmizu そうか、Scalaのライブラリからとってきたんでしたっけ。「人工的」は撤回します。ごめんなさい。でも、悪いスタイルであることは事実ですし、「簡潔」とか「直接的」というスタイルと密接に関連のある評価軸を持ちながら、スタイルを無視するのは望ましくないと思います。

Yukihiro Matzmotto @yukihiro_matz

@kmizu そうか、Scalaのライブラリからとってきたんでしたっけ。「人工的」は撤回します。ごめんなさい。でも、悪いスタイルであることは事実ですし、「簡潔」とか「直接的」というスタイルと密接に関連のある評価軸を持ちながら、スタイルを無視するのは望ましくないと思います。

Yukihiro Matzmotto @yukihiro_matz

@kmizu これはコードゴルフにおける長さのような絶対的な評価なら別ですが。 静的型における「簡潔さ」(望ましいプログラミングスタイルのもとでの)を実現するのは implicit conversion 以外では難しいのではないかというのが、私の印象です。

Yukihiro Matzmotto @yukihiro_matz

@kmizu これはコードゴルフにおける長さのような絶対的な評価なら別ですが。 静的型における「簡潔さ」(望ましいプログラミングスタイルのもとでの)を実現するのは implicit conversion 以外では難しいのではないかというのが、私の印象です。

Kota Mizushima (on a diet) @kmizu

@yukihiro_matz 「簡潔」とか「直接的」という言葉の使い方はうかつだったと思います。ただ、悪いスタイルであることが「事実」として語られるのはちょっと納得いかないのですが。少なくとも、議論の余地はおおいにあると思います。

Yukihiro Matzmotto @yukihiro_matz

@kmizu 動的言語では議論の余地なく悪いスタイルです。静的型言語では型チェックが効くのでそこまでではないかもしれません。個人的には賛成しませんが。でも、動的言語との比較という文脈に使うのはフェアじゃないですよね。