中の人がどう思っているかと，外からどう思われているか
「C# とか C++ とか」って書いてあったので反応してみた．
順調に遅延中
正直、C なんかを書いていると、変数に型があって、いちいちそれをかかされることについて、(LL的な意味で)「重いなぁ」とはあんまり思いません。もう「どっちでもいいじゃん」って感じ。Perl と C を比べたとき、静的型とか動的型とか大して「軽さ」に影響してないよね？、と思います。
が、C# とか C++ とかを使っていると、静的型があるのが苦しくて苦しくて仕方がない。もう、「こんなにも・・！！、こんなにも苦しいのならば型などいらぬ！！」(by *「ふっかつのじゅもんがちがいます。」さん）ってくらい苦しくて苦しくて仕方がありません。
これは単純にポリモーフィズムのお話で、静的型付け というよりは、nominal subtyping が脳のリソースを大きく引っ張っていく割に、作りたいことの本質ではないから。動的型付OOPLとか OCaml のような、structural subtypingのほうが ぜんぜん Lightweight に感じます。
ここら辺は、イルカとサメとイクチオサウルスは、同じような機能を持つけれど系統は全然違う、な、ジレンマと言えば解りやすいかしら？イクチオサウルスは実装継承としてトカゲさん達の仲間という継承木の中にいるけれど、「イルカのように泳ぐ」を必要とする文脈では「イルカのように泳ぐ」型から派生されていなければいけない、というヤツです。（動物ネタで喩えるのはOOP説明の禁則事項だったりしますが、ゆるして(^^; ）
の後に，
……20世紀では、情報は3年遅れでやってくるから……
というフレーズを読んで，そういえば Bjarne Stroustrup 先生がこれ書いたのは 2005 年，つまり 3 年前だな，とか思った．
3.1.3 STLの衝撃
C++を考える上でのSTLの衝撃は測り知れない。STL以前、私はC++が支援するものとして3つの基本的プログラミングスタイル（“パラダイム”）をあげてきた (D&E 4.1) ：
- 手続き的プログラミング
- データ抽象
- オブジェクト指向プログラミング
私はテンプレートをデータ抽象を支援するためのものと考えていた。STLでしばらく遊んだ後、私は4つ目のスタイルを含めた：
- 総称型プログラミング
テンプレートの使用を基礎にして関数型プログラミングの技術に大いに示唆されてきた技術は、伝統的なデータ抽象とは質的に異なっている。人々は明快に型、オブジェクト、資源を今までとは違った風に捉えている。新しいC++ライブラリは――テンプレートを使って――静的に安全で効率的になるように書かれている。資源管理と正確さがキーとなるような埋め込みシステム・プログラミングや高効率数値プログラミングでは、テンプレートは要となる。STLそれ自信は、こうした分野では必ずしも理想というわけではない。たとえば、STLは線形代数を直接支援しないし、未使用記憶領域の利用を禁止されていることが多いがちがちのリアル・タイム・システムで使うには巧妙な手が必要になる。しかしながら、STLはテンプレートを使って何ができるかを説明し効率的な技術の例を与えてくれる。たとえば実メモリ・アクセスを論理メモリ・アクセスから分離するためのイテレータ（とアロケータ）の利用は多くの高効率数値技術のキーとなるし、小さくインライン化しやすいオブジェクトの利用は埋め込みシステム・プログラミングにおけるハードウェアの最適利用例のキーとなっている。こうした技術のいくつかは、標準委員会の効率に関する技術レポート（technical report, TR）として文章になっている [ISO, 2004]。これはかなりの程度、クラス階層や仮想関数へ過度に依存した“オブジェクト指向技術”を使いすぎる傾向に対する反対意見――および建設的代替案――であった。
明らかにSTLは完璧ではない。相対的に完璧であるような“もの”など何一つない。だがそれは新しい地面を打ち破り、巨大なC++コミュニティを超えてさえ衝撃を与えた。C++を使いながら人々は、STLによって開拓された技術を推し進めてSTLを超えようと試みるとき、“テンプレート超プログラミング”について語っている。私たちのうち何人かはまたSTLイテレータの限界について考察している（生成子と範囲を使ったほうが好ましいのはどんな場合か?）、またどうやってC++がこれらの利用をよりよく支援できるかについて考えている（コンセプト、初期設定子、4を参照せよ）。
反対意見――および建設的代替案――は，まだ一部の人にしか届いていないのかな．
ポリモーフィズムのお話
が、C# とか C++ とかを使っていると、静的型があるのが苦しくて苦しくて仕方がない。もう、「こんなにも・・！！、こんなにも苦しいのならば型などいらぬ！！」(by *「ふっかつのじゅもんがちがいます。」さん）ってくらい苦しくて苦しくて仕方がありません。
これは単純にポリモーフィズムのお話で、静的型付け というよりは、nominal subtyping が脳のリソースを大きく引っ張っていく割に、作りたいことの本質ではないから。動的型付OOPLとか OCaml のような、structural subtypingのほうが ぜんぜん Lightweight に感じます。
「いつ」「誰から」 (あるいは「いつ」「どの本で」)“ポリモーフィズム”という言葉に触れたかがみんなあまりにバラバラすぎて，最近気軽に“ポリモーフィズム”と言えない自分ガイル．
多相性，パラメタ多相とSystem F
- 計算機科学一般における多相性(polymorphism)…ひとつの定義・操作・記号を，複数の異なる「種類」(「型」) のものとして使うことを許している，という言語(多くの場合，プログラミング言語) に備わった性質．
- 多相的型システム(polymorphic type system): 多相性を考慮にいれた型システム
- Strachey によるpolymorphism の3 タイプの分類:
- ad-hoc polymorphism(アドホック多相): 対象の適用範囲は複数の「型」に及ぶが，型の種類によって行なわれる実際の操作が異なる．通常，その適用範囲に必然性があまりない(ad-hoc)．(例) C 言語における+ はint の加算演算子であ り，float の加算演算子でもあるが，実際の加算アルゴリズムは全く異なる．
- subtype polymorphism(部分型多相): 操作の対象の複数の「型」の範囲が，型上の順序(部分型関係) に基づいて決定される． (例) Java 言語におけるフィールドアクセス．
- parametric polymorphism(パラメタ多相): 操作の対象の「型」に関わらず，同じ操作を行なう場合に発生する多相性．(例) 数学において，○は，gの値域とfの定義域さえ等しければ，任意の定義域・値域をもつ関数f, g の関数合成f○gを表す．また，ソートアルゴリズムは(要素の比較に用いるアルゴリズムを除いて) その要素の型には依存しないため，一般にパラメタ多相性をもつ．
オブジェクト指向言語においてpolymorphism というと，「あるメソッド呼び出し式において呼び出されるメソッドが，呼び出されるオブジェクトの(静的型ではなく) 実行時の型(クラス) によって決まること」を指すことが多い．これはad-hoc polymorphism とsubtype polymorphism の組み合わせであると考えられる．
id:NyaRuRu:20080326:p2 で紹介した Andrew Kennedy さんのページにある資料を読んでいるときも，「はて，私の知っている polymorphism とは誰に習った (誰の常識だった) ものだったのだろう？」とか思ったり．
何というか，言語の中の人がどう思っているかと，外からどう思われているかの間には，全然高速道路出来てないじゃん，みたいな．がんばれ道路族．
