動的型言語の一番の問題点

自分の考える動的型言語の一番の問題点は、
log_puts(out, msg)
ここのoutに何を入れられるのか、何を入れたらいいのか簡単に調べる方法がないという点です。

これは全く以ってその通りだなぁ。現時点で動的に使われているメソッドを割り出すエディタや IDE はない(はず)ので欠点と言ってもいいのではないだろうか?(静的型言語愛好者支援)


ぼぉっと考えてたんだけどインターフェイス縛りっていうのはどうなんだろう。
現状の、

class Log
   ...
   def puts(obj)
      ...
   end
   ...
end

を、

class Log
   ...
   def puts([:to_s] obj)
      ...
   end
   ...
end

メソッド縛り。アノテーションみたいな?とか。

module Outable
   def to_s
      ...
   end
end

class Log
   ...
   def puts(Outputable obj)
      ...
   end
   ...
end

モジュール縛りとか。


宣言部で、型が合わない・モジュール・メソッドを備えていないオブジェクトを弾くことできると嬉しいって要望は昔からあったような、なかったような。安易に使われそうだし(型・メソッド制限の是非とかスレッドがたつの。オープンソースなら云々かもしれないけどプロダクション環境なら云々とか意見が分かれそう)、あんまり良い案が浮かばないのであった。


エディタが動的に検索するようになれば解決!という方策を採るなら、構文解析というかコンパイルまでを外から扱うのが楽にならないといけないのかなぁ?


追記
arton さんからトラックバック来た。けど、よくわからない。


ここでの「問題」は、人の作ったメソッドを使う時・使い方を調べる時に、引数として突っ込めるのか突っ込めないのかパッと見わからん、というのが「問題」だと思うのですが違うんでしょうか? ドキュメントは当てにできないから宣言部ですぐわかったらなぁ、という願い。


追記2
あ、続きのエントリできてる。


「覚えたつもり」で間違って書いてしまった場合、動かす前からダメって言われた方が良いと思うんですけど。こんなミスは私だけかな……。型がどうこうとか、動的だからどうこうとか、IDE がどうこうとかは割りとどうでもいいです。ヒントは多い方が人間系でも間違いに気付きやすいので良いと思うんですけど。基本的に私も含め人間のことをあんまり信用してないんで。信用してないというか、間違うこと前提というか。ドキュメントが英語でも定義にあればその部分は間違えないし。


頻度が多いかというとそんなにないような気もする。


追記3
3つ目できてるな。


んー、私の場合、やっぱり型とか動的とかどうでもよくて、「変な名前つけるな」とかいった低レベルな問題なんですけど。メソッドが必須ならそれは重要なことなんだから、パッと見わかった方がいいじゃないか、という。時刻的に追記2はまだ読んでないかな?


今度はトラックバック


追記4
DbC は期待しちゃうけど、とりあえずそこまで大きな話ではない。あー、でも DbC っちゃ DbC かな。