make it as simple as you can, but no simpler
（私訳）出来るだけシンプルにせよ、しかし、それ以上シンプルにするな

Topic: c++ in linux kernel
Name: Linus Torvalds 6/5/10 8:07 PM

Heath Provost on 6/5/10 wrote:
>
>C++の「例外」についても、同様なことが当てはまる。
>彼等は明確なコードを書くことに努めている。「例外」は、
>暗黙的なマジックの見本だ…

そうとも、「例外」は良い例だ。Linuxカーネルは実際に独自の例外メカニズムを行っている。そのようにして、何が行われているのか（そして、問題の実際のニーズへ更に的を絞る一方で、良いパフォーマンスを与え、馬鹿げた巻き戻し問題を避けながら）コントロールするからだ。

私は実にC++が嫌いである。私の見解では実に悪い言語だ。見当違いな問題をすべて解決しようと頑張っているが、当を得た問題には取組まない。C++が"解決する"ことは、トリビアルなことであり、本当に深刻な問題をフィックスするというよりも、Cへのほぼ純粋に構文的拡張だ。

（C++のオブジェクト、テンプレート、関数オーバロードは全く構文糖だ。更に、総じて悪い構文である。更に、C++は実際、Cの型システムを積極的に悪くしている。）

非システムプログラミングにおいては、ほぼ確実にガーベジコレクションを提供する言語を使った方がいい。アプリケーションの複雑性で真の違いを見せるだろう。C++のフィーチャー？ 大いに役立たずだし、貴殿の顔が歪むだけだ。

システムプログラミングにおいては、全くCを用いるのが幸せだ。そこらの既存のコードとライブラリを使って（C++コードの再利用？ 幸運を祈る）、ある意味で安らかな時間を持てるだろう。設計を台無しにし、ある不安定なテンプレートライブラリを選ぶ機会が少ないほど、頭痛は少ない。

従って、どちらの場合においても、C++が正しい選択になりそうにない。

Topic: c++ in linux kernel
Name: Linus Torvalds 6/6/10 9:35 PM

? (0xe2.0x9a.0x9b@gmail.com) on 6/6/10 wrote:
---------------------------
>Linus Torvalds on 6/5/10 wrote:
>---------------------------
>>[cut]
>>私は実にC++が嫌いである。私の見解では実に悪い言語だ。
>>見当違いな問題をすべて解決しようと頑張っているが、当を
>>得た問題には取組まない。C++が"解決す>>る"ことは、トリ
>>ビアルなことであり、本当に深い問題をフィックスするという
>>よりも、Cへのほぼ純粋に構文的拡張だ。
>
>深い問題のはっきりした例を書いてほしい。
>（ガーベジコレクションについて既に貴殿は言及しているから、
>メモリ管理を除いて）

例えば、コンカレンシーだ。

私の意見では、C++は何ら興味のあることを追加していない。

>よろしい。それでは何故、貴殿はCが構造（struct {...}）を
>サポートすべきと考えるのか？

まさしく阿呆だ。

Cは良い言語である。この上なく役立つ程にまで完璧（そして、そうだ、如何なるマトモな言語でも、構造データを処理する能力は非常に要求される）であると同時に、全くシンプルだ。

構造データ型を持たない言語はCほどパワフルではないであろう。データ構造とポインタ（データとコードにとって）を兎も角興味深くする必要がある。

しかし、どこにその線引きをするか？

一人のC++擁護者である貴殿は、おそらく、この簡単な議論を本当には"分からない"だろうが、（ANSI版の）CについてK&R本を読み、悟るべく努めよ。

一つのかなり薄い本で、いかに言語が記述されるか注目せよ。読んで面白い。

Cが見事にこなしていることは、全く"出来るだけシンプルにせよ、しかし、それ以上シンプルにするな"をしていることだ。そして、そのことがCを素晴らしいものにしている。言語はパワフルでありながら、ほぼ最小である。

深刻な影響無しにC言語から削除出来るであろうフィーチャーは多くない。確かに3つの異なるループ構築があり、トリビアルな構文変更を出来るであろうが、それは深刻な問題ではない。C言語はシンプルだが、過度にシンプルではない。

ところが、そのことがいつも欲するものではない。より多くのビルトイン機能を持ち、よりシステム指向でない言語を人々が欲しがる理由を、私はよく理解している。言及した通り、ガーベジコレクションとコンカレンシーのサポートは本当に重要な問題であり、それら両方共Cで出来るが、ライブラリインターフェイス（通常、C上で拡張する方法）を用いてうまく出来ない。

ガーベジコレクションとコンカレンシーは、たんに構文的な拡張より以上の隔たりがある。なおも非常に不味く、それらを出来るだろうが、勿論受入れられる簡単な方針ではない。一言語が、ただ次から次へとサポートすることによって"良く"はならないと、私は言っている。

だが、繰り返す。Cは見事にやっているし、C++には徹底に欠いている、考え方と設計の明晰性を持つ。

そう、私は考え方と設計の明晰性をたまたま思い着いた。私が最初に入門したのは他のもの（わっ、VMS）だったけれども、UNIXが好きだった理由がそれだ。

C++は汚い。設計が無い。まさに"Cの上に汚物を追加している"。その汚物は全く意味がなく、ましてや設計もない。完全完璧なランダムだ。

ランダムから出発して、今や標準委員会によって追加されるランダムさだ。

>例えば名前空間と関数オーバロードは役立たずではない。
>それらは、Cが出来ない本当の問題を解決する。

貴殿の言うことは嘘八百だ。

>例えば、ソースコード内に"connect"という関数を定義し、
>"sys/socket.h"もインクルードしたいなら、Cでは出来ない。

つまりは、いかにただ構文的フィーチャーでないことを示すために、貴殿は構文について話し始めているのかい？

何の薬を服用しているのだ？

オーバロードというものは完全に構文的フィーチャーだ。Cにおいて、問題をフィックスする方法は全くトリビアルな構文変更による。つまり、関数"my_connect()"を呼ぶ。

うわぁ。マジックのようだ。私は3つのキャラクタを追加し、そのくだらなさのため、C++よあっちへ行けという完全な理由を作った。

実のところ上述のことは、いかにC++が実にひどく、Cが実にシンプルである理由の格好な例である。

そう、Cの解法は実にシンプルだ。余りにもシンプル過ぎて、全く阿呆に見える。だが、率直に言って、同じ関数の名前がオーバロードのために全く異なる時、C++コード内に混乱が生じ易いのであるから、実際にはスマートなほどに非常にシンプルなのだ。

勿論、貴殿はオーバロードに混乱しないだろうが、オーバロードのしていることは、実際はまさにCがやっていること、すなわち、関数の名前をユニークにすることである。それは左程難しいことでなく、オーバロードの雑多性を避けることにより、検索（いいかい、よく聞け！ "grep -w my_connect"がまさに動くよ！）が簡単になり、曖昧さを回避する。

（同じことが貴殿の他の例にも適用される。すなわち、たんにモジュールプレフィックスの追加、又は関数の区別のために別のトリビアルなネーミングルールを持つことで、幸せになれる）

Topic: c++ productivity
Name: Linus Torvalds 6/8/10 9:49 AM

anon2 on 6/8/10 wrote:
>
>だが、カーネルコードの場合、生産性は異なる事項だ。
>Linuxデベロッパーは実際に無料で働いている。
>それ故に、その同等の金額は、完全な作物を与えるだろう。

実際、これは間違いだ。

人が無料でも働くことが、作物をより工夫するためには結構なことだとは意味しない。つまり、人は他の埋め合せのために働くのであり、ツール（言語も含めて）に過度な不満を持たず、生産物を得ることが大きな争点なのだ。

もし、言語変更が人をより生産的にするのであれば、いかに報われるかにかかわらず、良いことだろう。それは金額云々では全くない。

だが、実のところ"コードの行数"のような事柄が生産性の尺度に少しもならないし、ボトルネックすらならない。大きなプロジェクトのボトルネックは、(a) トップの人を得ることと(b) コミュニケーションがすべてである。

カーネルにおいて、ざっと1000人が個別及びすべてのカーネルリリース（約3ヶ月おきに）に関係している。ところが、一つのロングテールがあり、百人（又は50人だけで）のトップ貢献者は巨大仕事の大部分をするが、その時でさえ、私が心配する最も大きな問題はコードではなく、コードと開発の"フロー"だ。

例えば、私は個人的に多くはコードをもう書かないし、数年の間書いたことがない。私は主としてマージ（そして、大きな程度までマージしない。すなわち、私がしている大部分は、"いや、xyzのため、私はこれを取らない"と人に話すことだ。たとえ拒絶が珍しいケースであっても、私が存在する主な理由は、それなのである。誰もが"イエス"と言えるが、誰かが"ノー"と言う必要がある）する。

物事を働かすための一番の方法はコミュニケーションする必要が全く無いことである。それは正に並行プログラミングでの同じ問題であるが、当然のことながらコミュニケーションは主なボトルネックだ。

コミュニケーションを避けるための一番の方法は、ある"文化"を持つことだ。それは別の言い方で、"人は知っているので、書下ろしたり、話す必要の無いルールのコレクション"とも言える。確かに、どのように事が為されるかについて多くのドキュメンテーションがあるが、通常の人の文化と同様に、ドキュメンテーションは2次的な類のものだ。

（言い換えれば、文化について多くの本があり、人類学で学位を得られ、人生をそれの研究で過ごすが、多くの人の99%は文化についての本を読まず、コミュニティの一員として学ぶ。）

C（もっとはっきり言えば、UNIXと）に非常に強い"文化"がある。これはまた、言語がシンプルで曖昧さが無いことがとても重要な処でもある。C++の最も悪いフィーチャーの一つは、いかに物事の多くをコンテクスト依存にし、それは、コードを見る時、何が行われているか知るため、単純に局所的一瞥が滅多に十分なコンテクストを与えない。

それはコミュニケーションに対しても大きい問題だ。より大きいコンテクストを与えなければならないのであるから、直に事柄を記述するのがより難しくなる。それは、私がオーバロードのようなことを忌嫌う大きな理由だ。すなわち、grep出来ないのみならず、コードの小片が実際していることを見るのが困難になる。

言い換えれば、破片（"パッチ"を考えてみよ）内でコミュニケーションする時、目に見えないコンテクストがコンパイラにsctpモジュール内に"connect()"があると知らせるような場所に"connect()"を見るよりも、"sctp_connect()"を見る方がいつも良い。

効率良くコミュニケーションするために、破片内でコミュニケーション出来なければならない。私は、ネットワークのバンド幅にあるような"効率良く"を意図していない。一般的なことを意図している。全プロジェクト（又は、いくつかの全ファイルすら）を送る代わりにパッチを使う理由は、電子メールでは詰め込み過ぎだからではなく、問題となるただ一つの事柄が修正であり、最終結果ではないからだ。

開発が曖昧さとコンテクストを避けるのは、それが根本的な理由である。ところで、それは"カーネルプログラミング"とは特に関係がない。どんなソフトウェア開発においても当てはまるが、実生活においても当てはまる。曖昧に喋る又は書くことが通常の人のコミュニケーションでも良いことではない。

従って、シンプルで明快な言語は良い事柄なのである。不必要に冗長（意味のない構文的しくじりはいつでも悪い）でない方がいいが、同時にずっと多いコンテクストも要求しない方がいい。

［皆がそのテーマのエキスパートであれば、暗黙のコンテクストの大部分は結構である。これが、エキスパートでなければ深遠な科学的文学が読むに耐えない理由だ。すなわち、完全に筋が通るためには多くのコンテクストを要求する。だが、多くの分野を持つ大きなプロジェクトでは全く不可能だ。

例えば、私はVMとコアカーネルを実際によく知っているが、様々なファイルシステムとネットワーキングのコードを読める必要がある。だから、私のような誰かに対してさえ、隠れたコンテクスト無しに、コードは書かれていなければならぬ。］

Cはほぼコンテクスト自由な言語だ。Cの式を見る時、それが何をするか分かる。関数呼出しは一つのこと、且つ一つのことのみ行う。つまり、"どのバージョン"の関数を呼ぶか微妙な問題が無い。

勿論、関数呼出しのため、プリプロセッサとインライン関数を利用出来るが、その時でさえ、完全に明示的でなければならぬ。つまり、そのプリプロセッサシンボルに対して尚もgrep出来、完全に"直接的"だ。

さて、他のシチュエーションでは、貴方はもっと言語サポートが欲しい、言語にメモリアロケーション等（すなわち、ガーベジコレクション。C++でのバカバカしい"new"キーワード又は他の戯言を言っているのではない）をして欲しい。カーネルにおいては、少なくともしないであろう。同様に、非常に特殊化されたロッキングとメモリ予約上のコントロール等を要求する。従って、あるモデルのコンカレンシーを晒す言語は、そのコンカレンシーにおいても、ほぼ確実に強く制限されるであろう。

だから、OSカーネルの特殊なケース又は、特にシステムプログラミングに対して、Cは"出来るだけシンプルにせよ、しかし、それ以上シンプルにするな"だと私が考える特別な理由がある。すべてのプロジェクトでCを使用すべきだと私が言っていない理由は、それである。

だが、C++は？ その"良いフィーチャー"は全然良くないと私は本当に思う。Cを追い越すならば、適切に実行し、問題となる実際のフィーチャーを得よ。つまりは、ガーベジコレクション、あるコンカレンシーのサポート、ダイナミックなコード生成や、何かそういったものだ。

Topic: c++ productivity
Name: Linus Torvalds 6/11/10 12:17 PM

Oh Come On Dept on 6/11/10 wrote:
>
>デバッギングの目的のためには、デバッガーは既にどの関数が
>呼出されるか知っているし、正確に語れる。

私は、メッセージ全体を理解出来ない、この能力に呆れている。コミュニケーションがすべてだった。私はそれが全く明白だと思っていたし、いつも語っていることだった。

コミュニケーションに"デバッガー"は無い。何が行われているか理解を支援するIDEは無い。シンタックスハイライト等は無い。

外に出て行く、パッチと提案を持つ電子メールだけがある。特別なツールの余地は無い。すなわち、人間として修正からコードが何をするのか理解出来なければ、問題だ。通常、コード周辺で約3行のコンテクストを見る。

だから、型又は、すぐには判明しない別のコンテクストに依存するコードは悪いのだ。

まあ、Cでも悪いことは出来る。マクロへの引数の一部でない（グローバル又はローカル）変数を使うマクロを使える、等々。だが、Cでは、悪いことを取組まなければならないか又は、正規なC"文化"にひどく逆らったことをしなければならない。人がそれをする（そして、たまたま発生するなら、私は禁止しないだろう）時、すべての人はお粗末なハックだと知っている。

誤解しないでほしい。3行のコンテクストを使って、Cでコードが何をするのか貴殿がいつも語れるとは限らない。コードが実際に正しく動くために必要なロッキングルール等を簡単に見落とす。しかし、同時にCは少なくとも、何が発生するか見ることを困難にする事類の余地はより少ない。

C++では、目に見えないコンテクストを使用するために設計されたフィーチャーを持つので、散らかった状態にするのはずっと簡単だ。

"目に見えない"コンテクストは、C言語のC++拡張の内に至る所にある。暗黙的オブジェクトの生成、コンストラクタ、デストラクタのすべてにある。デフォルト引数にあり、型に基づくポリモーフィズムにある。むかつく、下らない"参照による渡し"にある。

そうだ、馬鹿げた言語からのダメージを制限するためにC++のサブセットを使用出来る。しかし、問題は"道理に適ったC++文化"すら無いことだ。いい仕事をしているプロジェクトはあるが、一部の人は参照（"ポインタよりも安全"だと。何と低能な議論だ）を使うことを愛し、他の人はほぼすべてをテンプレートを使って為されるべきだと考える。

ある程度信頼の置ける人が賛同する、道理の適った標準サブセットが無いのだから、"ただサブセットを使え"は実現可能なモデルではない。大き過ぎるC++のフィーチャーが個人として忌まわしいということは、他者も同様である。

そして、得られたのは"CであるところのC++のサブセットを使え"。私達は全面的にそれに賛同し、Cコンパイラを使うことにより当り前に強制出来る。問題は解決した。下らないものすべてが窓から消える。

Topic: c++ productivity
Name: Linus Torvalds 6/11/10 5:35 PM

Mark Christiansen on 6/11/10 wrote:
---------------------------
>Linus Torvalds on 6/11/10 wrote:
>
>>C++ vs. Cのコンテクストについては十分。
>
>コンパイラと言語が手伝えることがあるのか？
>言語が緩和出来るかも知れない何かの問題
>に貴殿は立ち向かっているのか？

実のところ、私達が言語自体について問題を抱えることは滅多に無い。Cは、それを知っている人々から成る大きな基盤を持ち、非常に大多数である。Cを知っている人は低レベルの事を知っている傾向の人々の類であり、良い支持者でもある。

言語の詳細について気にする人々は、完全に間違った事についてよく心配する。言語が充分に表現力豊かで、不必要な苦痛を引き起こさない限り、主要な問題はいつも別のことだろうと、私個人は思う。

例えば、私達にとって大きな問題はコンパイラの安定性だ。カーネルだからかも知れないが、実のところ、コンパイラのバグは本当に苦痛だ。

同様に、カーネルに対し、生成されるコードについて私達は結局非常に厳しい条件を持つに至る。私達は非常に制限されたスタックを持っており、よってコンパイラがでまかせにスタック上のテンポラリ構造を生成し回るはずがない。

もっとはっきり言えば、カーネルにおいてCの使用さえも、私達は制限する傾向にある。ほぼ他の誰もがしない事（呼出し手法、インラインアセンブリ等をいじるような）私達はするかも知れない。しかし、同時に、構造（従って、大量のスタックのスペースを潜在的に使用するが、ソースでもっと見える必要がある）であるローカル変数を持つという理由で、構造の'typedef'のような事柄を慎んでいる。

>私が最も願うことは、データの良い記述だ。

最初にデータ構造を設計すべきであり、データ構造の良い設計はコードよりもずっと重要であるという意味で、激しく同意だ。データ構造とロッキングを正しくすれば、コードは働く（又は、働かなくても、少なくともフィックス可能だ）。

良いコード設計は、いかにデータが移動するか、いかにデータを秩序立てるか、いかにデータを見つけ、他のデータと関連付けるか、について考えが次々と思い浮かぶ。

だが、OO言語は、オブジェクトが重要であり、オブジェクトに関連付けられたメソッドを持つべきだという手段を考える傾向にある。まさに馬鹿げた話だ。一つのオブジェクト（又は、ある型のオブジェクトの当り前なコレクション）が本当の関心事ではない。

関心すべきは、異なる型の異なるオブジェクトが相互作用し、ロッキングルールを持つ等々の時なのである。その時点で、重要なのは一つのオブジェクトではもうないのだから、"オブジェクトインターフェイス"を隠蔽しようとするのは絶対に間違っている。

だから、私は、OOの標本は問題にならないトリビアルなコードのためであると考える。異なる型の演算子オーバロードを持つことは非常に綺麗だし、言語に独自の型を追加（しかも良い構文で）する必要無しに、ベクターや複素数代数のような事柄を容易にする。

だが、同時に、それはトリビアルで全く面白み無い問題だ。その類の道具（型に基づくポリモーフィズム[関数/演算子の]を持つOO言語がする傾向にある）は全く何の複雑なデータ関係とは関連しない。

だから、私はデータの記述が重要であることに賛成であるが、同時に、最も記述が本当に重要である事柄は、いかにデータが矛盾無いか、一貫性の必要条件があること、ロッキングルールがあること（そして、一つのデータオブジェクトのためでないことも）等々である。

私は、それらを本当に容易にコンパイラへは書けないと思う。結局、どうしても自分でそのコードを書かざるを得ない。

いいかい、私がそう思うのは、私が低レベルプログラミングだけをしているからかも知れない。先に言った通り、私が仕事しているコードの大部分が、殆のソフトウェアプロジェクトが考えすらしていない事柄に非常に注意を払っている。すなわち、スタックの深さ、メモリアクセス順序、決め細やかなロッキング、直接的なハードウェアアクセスだ。

Cはそれが得意だ。私はプリプロセッサは最低だと思うし、私達は無慈悲にも悪用しているが、"コンパイラが背後で自動的に事を容易にする"がカーネルのために支援するだろうとは考えていない。

もっとはっきり言えば、私達は、コンパイラが背後でより少なく動くことを確認する事柄を追加して来た。暗黙且つ静寂な整数型変換は多くの問題の原因となり、私達は専ら醜くも、あるC/プリプロセッサのコードに私達の"min()/max()"マクロ（一方が他方と異なる型又は異なる符号を持てば、単純にエラーとする）を持たせている。

デフォルトによって、Cは私達にとって充分に厳しくはない。私が最もほしくないものは、更に黙って"支援"するコンパイラだ。

（繰り返すが、セキュリティ問題は大変重要だ。殆のプログラマは、"信頼の置けない誰かが、2つの大きな整数を渡し、それらの加算がオーバフローすればどうなるか？"について懸念しない傾向が強くなっている。カーネルでは、そのような事柄が多くあるので、以下のようなコードを見るだろう。

    if (a + b < a)
       return -EINVAL;

それはオーバフローをプロテクトする。"符号付き整数オーバフローは不定である"は、実に私達には困惑だ。そのような不定は何でも良くない。たまたま不定であるという理由で、事を転居させられるコンパイラは、私達にとってはバグである。

例：私達はセキュリティ問題を抱えたことがあった。あるコードが、様々なインライン等の後に以下のことする。

   var = ptr->xyz
    if (!ptr)
       return -EFAULT;
    use var

コンパイラは、ptrがNULLになるはずがない[もし、そうなら命令違反となっていただろうという理由で]ということを"知っていた"ので、単純にそのifを削除した。だが、実は、ユーザはアドレスをゼロへマップ出来、そのifは重要だった。私達は今、上記のことに対して、様々な自動チェッカーを持っている。しかし、実際はカーネルにとって、静寂的にコンパイラに"支援"させ、無意味なコードを削除させるよりも、これについて警告を出す方が良かっただろう。）

結局以下のことに纏められる。

>C++は、異なるコードにはその違いを指示するためにメソッドを持つ。
>ジェネリックベースクラスに関する階層的改善の問題を私は左程持
>っていないので、私が継承を本当に好きだとは言えない。

正しい。それはトリビアルな事柄であり、結局左程一般的な事柄ではない。複雑な問題は、厳密に単純な階層的データ構造を持たない。

そうは言っても、簡単なケースではCでも出来る。相互に埋め込んでいる構造は、ロケット科学ではない。カーネルはいくらかのケースで非常にうまくやっている。すなわち、他の構造に埋め込める、ジェネリックリスト構造を持つことによって、いかに私達がリストのような事柄をしているか見たまえ。今回だけじゃない。そうして、これらの事柄の"多重継承"を私達は持っている。

だが、そうだ、貴殿はポインタを理解する必要があるだろう。そして、ポインタへのポインタも。いくつか"面白い"マクロラッパーを一度書こう。それでも、それらを何らかのイテレータであると考え、ジェネリックイテレータベースのソートルーチンに渡せる程には洗練されていないだろう。

しかし、トリビアルなケースでは、それ程悪いばかりではない。もっと複雑なケースでは、ロッキングが単一でなく多重のオペレーションをカバーし、個別のデータ構造を記述することによっては、それを記述出来ないので、兎も角も特別にコードを書く必要があった。

>更に、異なるコードに違いを指示するには、そのフィーチャーは良い。

確かに。カーネルでは、私達はそれを明示的に操作せざるを得ない。関数ポインタをそのデータに関連付けるか、又は、貴殿が言及したようにし、すべてのケースを操作する共通ルーチンを持つかだ。どちらも存在する。

そして時には、私達はプリプロセッサとインライン化を使って実に不快なことをし、死んでいるコードを追いやる最適化をするコンパイラに頼る。"サイズに基づくポリモーフィズム"をするいくらかのケースがある。そのケースでは、異なるサイズの整数引数を取れて、それらに対して異なる事柄をする、文字通り一つの関数（つまり、やっかいなマクロ）を持つ。それは信じられない程醜いが、C++でも左程美しくはならなかっただろう。

だから、厳密な言語サポートが無くても、ポリモーフィズムすら出来るのである。

>C++とオブジェクト指向分野は、注文コードモデルに集中している。
>C++で、Stroustrupは特にパラメータ手法を貶している。

私は一般的にパラメータ手法を避ける試みに賛同する。C++がその答えだと決して思わない。又は、オブジェクト指向アプローチすらも。

私達は出来る限り静的型（そして、コードパスをパラメータ化でなく、静的にする）をするように努めている。型の中の"フラグ"を避けよう。

それが働かない時は、OO的事柄をするが、明示的な関数ポインタを使って、それをしよう。実際にやっていることを隠蔽する以外に、C++構文の有利な点は何なのか？

>データの良い記述があれば、私は構造上の有用な事柄をするライブラリ
>又は、好めばクラス（ライブラリのコンパイルが済んだ後に時間をかけ
>て作られるであろう）を作れる。

実際の問題が特別なデータ記述で関連付けられるとは私は考えない。貴殿はその類のデータのためのライブラリルーチンを欲しくない。つまり、貴殿はデータとその他の種類のデータ両間で相互作用するコードを欲しいのだ。

論より証拠として、C++コードの再利用に関してほぼ総合的に不足していることを私は示す。又は、たんに何らかの"オブジェクト指向"ライブラリに関して。それは存在しない。C++の全体と一部分のみがBoost + STLだろう。そして、それらは左程興味深く興奮させる問題ではないよね？

単にリスト上をイテレートするために何故全く新しい言語を必要とするのか？