Duck Typingは大規模プロジェクトでも大丈夫か？ - rubyco（るびこ）の日記
整数として処理したければ、オブジェクトがto_iという振る舞いを持っていることを期待してなんでもとにかくto_iしてしまうのがDuck Typingなのかなと思いました。 Duck Typing? - 18 til i die (another phase) なるほど、そうですね。 そういえば、Duck Typingでは「メソッド名がグローバル」になりますね…。ふと思ったのですが「大規模プロジェクトでメソッド名がコンフリクトしてDuck Typingが破綻する」という可能性はあるでしょうか？ ＞ 識者のみなさま。 # おお、スケーラビリティの話題じゃん。 想定解答： (0) この問いかけ自体が無意味。なぜなら…（誰かがここを埋める） (1) 大規模プロジェクトでもDuck Typingは破綻しない。なぜなら…（誰かがここを埋める） (2) 大規模プロジェクトでDuck Typingは破綻す
「CGIに向く言語がない」について - がるの健忘録
厳密には「業務で」になるんですがね。以下、簡単に理由を。 Perl 5.6まではまだしも、5.8系、重すぎ。厳密にはOOPでないところも激しくマイナス。 インストールで、特にCPANで面倒が多いのも大変に微妙。make installとか「どんな環境でも出来る」とは限らないし。 PHP 最近ほじくり倒してますが、ダメポです。こんな言語業務で使っちゃだめです :-P で、PHP＋PEAR＋Smartyは多分最悪の組み合わせ。ダメポさが３倍どころか３乗くらいに跳ね上がります。 Java(JSP) 言語的に問題はさしてないのですが。基本的にthread挙動なので、threadを理解していない技術者に扱わせると物騒この上ないです。 …でも、ペーペーのプログラマがマトモに理解しているとはとても……… コーディング規約で縛ってどうにかなるんだかならないんだか。 C++/C 個人的にはいっちお気に入りな
Java が使いにくいのは静的だからではない - kwatchの日記
Java が使いにくい言語であるというのは、世界中の LL ファンが皆思っていることだろうから改めていうことでもないけど、使いにくいのは静的言語だからというのは間違っている。Java が使いにくいのは単に Java の設計者のセンスが悪かっただけであり、静的言語のせいではない。 たとえばこんなコード。 public Map<String, List<String>> example() { List<String> list = new ArrayList<String>(); list.add("foo"); list.add("bar"); list.add("baz"); Map<String, List<String>> map = new HashMap<String, List<String>>(); map.put("names", list); return map; }
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://madscientist.jp/~ikegami/diary/20080514.html
