案内とは？/ ディック
[ 22] バベル案内
[引用サイト] http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
|
ひとつには、私はどうも粗野で口汚くなりがちで、オフィシャルな趣のあるAmazonの出版物に載せるのは不適切に思えた。それでかわりに誰も読まない自分のブログに押し込めてしまうことにした。読んでるのはあなたくらいのものだよ。どうも! もうひとつ言うと、これは本当に書きかけのものであり、そこかしこの断片を集めたものでしかない。全然磨き上げられていない。これもブログエントリにする理由になっている。ブログなら別に良質である必要も完全である必要もない。単に私が今日考えたことというだけのものだ。ではお楽しみを! あなたの使ったことのある世界のコンピュータは、実用的な目的のものについていえば、すべてフォン・ノイマン・マシンだ。そしてCというのは、フォン・ノイマン・マシンの機能を記述するための軽量で表現力の高いシンタックスなのだ。 フォン・ノイマン・アーキテクチャというのは、CPUに、RAMに、ディスクに、バスという、あなたが日常で使っている標準的なコンピュータアーキテクチャのことだ。マルチCPUでもこのことは基本的に変わらない。フォン・ノイマン・マシンは、抽象的な計算実行モデルとして有名なチューリングマシンが、使いやすくコスト効率 別な種類のマシンも存在する。たとえばLispマシンというのがある。これはラムダ計算に基づくプログラミング記法であるLispが1950年代に実現されたものだ。ラムダ が、チューリングマシンと違い、ラムダ計算は人間によって読み書きできる。しかし2つのモデルは能力の点では等価だ。どちらもコンピュータに可能なことを正確にモデル化している。 しかしLispマシンというのは、ガレージセールを別にすると、あまり見かけない。フォン・ノイマン・マシンが人気レースで勝利したのだ。ニューラルネットワークやセルオートマトンをうまく現実化したコンピュータというのも存在するが、これもまた人気がない。少なくとも今のところは。 C言語はまた、それがUnixの書かれている言語であるという意味でも知っておく必要のある言語だ。それに偶然ながらWindowsと、そのほか実質的にすべてのオペレーティングシステムがCで書かれている。それというのも、それらのOSはみなフォン・ノイマン・マシンのためのOSだからだ。他に何の言語を使うって言 C言語から大きくかけ離れた言語というのは、ハードウェアの実際の機能とあまりに離れているため、十分なパフォーマンスを出すことができない。少なくともそれらのOSが書かれた20世紀においてはそうだった。 MITとバークレーでは新入生にSchemeを1学期か2学期教えている。学生はなんでそんな奇妙な言語を学んでいるのか見当もつかない。正直なところ、Schemeは最初に学ぶ言語としてはひどいものだ。そしておそらくは2番目としても。あなたはいつかそれを学ぶべきだが、最初と2番目は避けておいた方がいい。 Lispを学ぶのは簡単ではない。大きな飛躍がいるのだ。CみたいなプログラムをLispで書けるというのでは十分でない。そんなのは無意味だ。CとLispはスペクトルの反対の端に位置している。他方が上手く扱えない領域で大きな力を発揮するのだ。 Cがコンピュータがどう動作するかのモデル化に最も適した言語とすると、Lispは計算というものがどう振る舞うかをモデル化するのに最も適した言語だ。ほんとのことを言って、Lispについて多くのことを知る必要はない。一番シンプルでクリーンなSchemeを使い続けることだ。他のLisp方言はライブラリやらツールやらを備え、C++やJavaが持つような大きく複雑なプログラミング環境へと成長している。そういう部分については知っている必要はない。ただSchemeでプログラムを書ける必要がある。The しかし日常のプログラミングに使う言語ということであれば、ライブラリとかドキュメンテーションとかツールサポートとかOSとの親和性とかリソースとか、そのほかたくさんのことに基づいて選ぶ必要がある。それはコンピュータはどう動くのかということとはあまり関係なく、人はどう動くのかということ 今でも多くの人がプログラムを素のCで書いている。たくさんのものをだ。あなたはCを知っている必要があるのだ! C++は地上でもっともバカな言語だ。すごく感覚が鈍いという意味で。C++は自分自身のことがわからない。イントロスペクティブでないのだ。Cも同様だが、Cは別に「オブジェクト指向」なわけではない。そしてオブジェクト指向であるということの小さからぬ部分は、プログラムが自分自身のことをわかるということなのだ。オブジェクトはアクターだ。だからOO言語はランタイムリフレクションとランタイムタイピングを Cについて言うと、Cの上にイントロスペクションのように振る舞うツールを作れるCコンパイラを書くのはとても簡単だ。一方、C++は本質的にパースできない。だからあなたが、たとえば仮想関数のシグネチャを教えてくれたり、コードをリファクタリングしてくれたりするような賢いツールを書こうと思うなら、誰か他の人の書いたツールセットを我慢して使うしかない。あなたはまずパースできないはずだ。そしてC++をパースするツールセットというのはどれも最低だ。 C++はバカであり、バカな言語で賢いシステムを書くことはできない。言語は世界を形作る。バカな言語はバカな世界を作る。 コンピューティングはすべて抽象化に基づいている。低いレベルのものの上に、高いレベルのものが作られる。分子から都市を造ることはできない。あまりに抽象度 Cでまっとうに書くことのできる一番大きなものはオペレーティングシステムだ。そしてそれは実際のところそんなに大きなものではない。それが大きく見えるのはアプリケーションのためであって、カーネルは小さなものだ。 C++で書くことのできる一番大きなものは･･･やはりオペレーティングシステムだ。まあ、幾分大きめの。3倍大きいということにしておこう。あるいは10倍でもいい。しかしオペレーティングシステムのカーネルはせいぜい100万行というところだろうか? だからC++でまっとうに書ける一番大きなシステムは1000万行で、そのあとは崩れていき、コントロールできる見込みはなくなり、「リトル・ショップ・オブ・ホラーズ」の工場みたいなことになる。食わせてくれーー・・・ ここでは何かやるのにいつまでも時間がかかる。以前あるAmazonのエンジニアが、我々のコードベースをこう形容した。「巨大なクソの山で、かつて見たこともないほどでかく、その中心まで潜って それが4年前の話だ。そのエンジニアはもっと快適な場所へと去ってしまった。残念なことだ。彼は本当に優秀な人間だったのだ。 これはすべてC++の問題だ。口答えしない。そうなのだ。私たちは世界でもっともバカな言語を使っている。それはメタ-バカとでもいうたぐいのものだ。そう思わない? とは言え、C++コードでいいものを書くことは明らかに可能だ。それはつまり、ほとんどCのコードに、いくらかのC++の機能が、最低限だけうまく使われているような場合だ。しかしそういうこと には決してならない。C++はすごい遊び場であり、そのすべてを知るとすごく賢くなった気分になる。だからあなたはそのすべてを使おうとすることになる。しかしそれはうまくやるのが本当に難しいのだ。なぜならC++はそもそもにおいてクズ言語だからだ。たとえあなたが優秀であったとしても、結局は台無しになってしまう。 こんなことを言うのが異端であるのはわかっている。固有名詞の異端だ。私だって大学生のときはC++が好きだったのだが、それは私がそれしか知らなかったからだ。私の言語の教授のクレイグ・チェインバーズがC++は大嫌いだと言うのを聞いたとき、「どうして? 私はこんなに気に入ってるのに」と思った。そしてSTLの作者がOOPは嫌いだと言ったという話を聞いたとき、私は彼がどうかしてると思った。OOPを嫌うなんてことがありうるだろうか? 満足を育むのは、多くの場合コンピュータ言語自体ではなく、馴染んでいるということによってだ。慣れ親しんだもので満足してしまう前に、もっといい言語のエキスパートになる必要がある。 だから私がC++について言ったことが気に入らないなら、もっといい言語のエキスパートになることだ(私はLispをおすすめする)。そうすればあなたは私に反論する準備ができたことになる。しかしあなたはそうしないだろう。私はあなたを引っかけたのだ。そのときには、あなたはもうC++のことが好きではなくなっている。そして私が引っ かけて元好きだった言語を嫌いにさせたことに腹を立てるかもしれない。だからあなたはたぶん私が今言ったことは単に忘れてしまった方がいいのだ。C++はすごいよ。本当に。すばらしいとしか言いようがない。私の言ったことは忘れてほしい。問題ないって。 Amazonが始まった当時はすごいエンジニアたちがいた。私は全員知っていたわけではないが、何人かは知っていた。 彼らはみんな、もちろんEmacsを使っていた。エリック・ベンソンはXEmacsの作者の1人だ[1]。世界の最高のエンジニアたちはみんなEmacsを使っている。世界を変えるようなタイプの人たちは、ということだ。あなたの隣のキュービクルにいるすごい彼女のことじゃない。向こうの部屋にいるすごいフレッドのことでもない。我々の分野で最高のソフトウェア開発者たち、業界の様相を変えるような人たちのことを言っている。ジェームズ・ゴスリング、ドナルド・クヌース、ポール・グレアム[2]、ジェイミー・ザウィンスキー、エリック・ベンソン。本物のエンジニアは皆Emacsを使う。Emacsをうまく使えるためには相当頭が良くなければならないが、マスターすれば驚くほど力を与えてくれる。信じないなら、ポール・ノードストロムが仕事しているとき肩越しにのぞき込んでごらん。Visual Hoge.NETみたいなIDEしか使ったことのない人は本当に驚くことになると思う。Emacsは100年のエディタだ。 みんな今でもそれが好きだ。今日でも、非技術系の連中から、Mailmanがなくなってどんなに残念かという話を長々と聞かされる。別に君たちのことをけなしているわけじゃない。去年のクリスマスに、私はAmazonのパーティに出た。ビジネスの連中ばかりのパーティで、なんで私が招待されたのかわからなかった。彼らはみんな、私や、私が一緒に溶鉱炉??Amazonのボラールームで働いている連中より、美しく魅力的だった。若い女性の4人組が、私がカスタマサービス部門にいたことを知って詰め寄ってきて、自分たちがいかにMailmanとEmacsを恋しく思っているかと、そしてArizona(私たちが何年もかけて開発しているJSPによる代替アプリケーション)にはいまだ同じことができないのだと、15分にも渡って言い続けた。 シェルは天才だ。Emacsは天才だ。非技術系の人たちでさえEmacsを愛している。私は今Emacsでタイプしている。私が自主的に別なエディタを使うことは決してない。この惑星上で他には見つけられないタイピングのショートカットやテキスト編集機能が生産性を押し上げてくれるというだけじゃない。私は自由形式の文章であれば、Emacs上で1分間に130から140語を間違いなしでタイプできる。自分で書いたタイピングテスト用のEmacsアプリケーションで計測したのだ。しかしEmacsにはそれ以上のものがある。 Emacs拡張ガイド)の著者のボブ・グリックステインをMailmanのために契約で雇いさえしていた。彼はセキュリティ部門のビルにある小さなオフィスで仕事していた。 カスタマサービスアプリケーション部門はAmazonの最初の「ピザ2枚のチーム」†だった。彼らは完全に自律的だ。当時も今も。誰も彼らと話さないし、誰も彼らを助けない。彼らはすべて自分で作っている。彼らのところにはWeb開発者はおらず、サポートエンジニアはおらず、スワットはおらず、ただ堅実なエンジニアと良き指導文化があった。そしてそれが彼らの必要としたすべてだった。 しかし彼らはMailmanを引退させた。ああ。あああ。私は今でもあれがなくなったのが残念だとみんなが言っているのを聞く。パーティにおいてさえ。 それでもカスタマサービスアプリケーション部門はAmazonの他の部署よりLispハッカーの割合は多いんじゃないかと思う。彼らは別にLispをよく使っているというわけではないが、ただエリック・レイモンドの言うように、たとえそれであまりプログラムを書かないとしても、Lispを学ぶことはすばらしい経験となり、あなたを優れたエンジニアにしてくれるのだ。その後の人生に渡ってずっと。 Javaは一方ではC++コーディングのつまらなくて間違いやすい細部から人々を開放した。境界エラーはなくなり、コアダンプはなくなった。投げられた例外はエラーの起きた正確な行を指し示し、それは99%の場合には正しい。オブジェクトは要求に応じて自身の気の利いた表示を行う。などなど。 他方で、Javaというのは言語、仮想マシン、巨大なクラスライブラリのセット、セキュリティモデル、ポータブルバイトコードフォーマットであるというのに留まらず、宗教なのだ。だからJavaをあまりに愛している人というのは信用することができない。いいJavaプログラマを採用するというのは難しいことなのだ。 C++からJavaへ移行するのは単に構文を変えるということではない。それは衝撃的なほどに大きなパラダイムシフトであり、本当に理解するようになるまでには時間がかかる。それは突然 アシスタントを持つようになったようなものだ。副社長たちがいつでもミーティングに出ていて、それでいながら会社の状況を理解しており、クールなドキュメントを書いたりそのほかのことをしているのを知っているだろう。副社長というのは実際は自分が2人の正社員であるということを忘れがちだ。彼ら自身と、彼らのアシスタントだ。アシスタントを持つことで、解決しなきゃならない問題について考えることから解放される。アシスタントを持たないなら、時間の半分はつまらない作業のためにつぶすことになる。Javaに切り替えることは、2人のプログラマになることだ。1人はあなたがもはや気にかけなくて良くなったことの面倒を見、もう1人が問題領域にフォーカスする。これはびっくりするくらい大きな変化だ。そしてこれはあなたが極めて速やかに慣れる類の変化でもある。 Sucks"で書いている。「最初にいい点を挙げると、Javaはfree()する必要がない。その他のことはすべて大したことではないとためらわずに言える。この一点によって、私は他のほとんどあらゆることを、それがいかにひどかろうが許すことができる。この一点によって、この文章にある他のすべてがほとんど些細なことになってしまうのだ」 ジェイミーのアーティクルは1997年に書かれた。これはJavaの世界では大昔だ。彼がそれを書いてからJavaは大幅に改善された。今では彼が文句を言ったことの一部が修正さえされている。 しかし多くのものは修正されずにいる。Javaはいまだ言語としては最低だ。しかしジェイミーが指摘しているように、「今日における最高の言語というのは、言ってみれば、私たちが現実世界で扱わなければならないまったくへぼな負け犬言語の中にあって Javaは言語自体を別にすれば、あらゆる面で本当にすばらしい。JWZが苦言を呈しているのもほとんど言語自体についてだ。そしてそこには不平を言うべきところがたくさんあるのだ。言語が最低ならライブラリにできることも限られる。本当だ。あなたは多くのことについて私より知っているかもしれないが、ライブラリが最低な言語を本当に救うことはできないことを私は知っている。Geoworksでの5年間のアセンブリ言語の地獄が私にそのことを教えてくれた。 C++と比較すれば、Javaは言語として同程度だ。いや、今のなし。ずっといい。文字列があるもの。文字列のサポートがお粗末な言語なんていったいどうやって使えるんだ? ああ、それに多重継承。私はこの年になってようやくその価値を認めるようになった。私の頑固者のエルフがポリモーフィズムのドグマへのいい反論になると思うなら、多重継承か、少なくともRubyスタイルのミックスイン ゴスリングでさえ、何年か前、すべて始めからやり直すとしたら、インタフェースは使わないだろうと言っていた。 しかしまさにそれがJavaの問題なのだ。ジェームズがそう言ったとき、みんなショックを受けた。私はそのショックウェーブを感じることができた。Sunのマーケティングと法務の連中が作戦行動を起こして彼を黙らせ、否定し、そうじゃないという話にしたのだ。 であって、しかも深刻な問題なのだ。言語はハイプなしに人気になることはないからだ。だから言語デザイナが言語が完璧にデザインされてないかもしれないと無邪気に口にするなら、馬用のトランキライザーを打って言語デザイナを黙らせ、カンファレンスを閉鎖するのだ。言語は生き延びるためにハイプを必要とする。私はただ人々がそれで目が見えなくならないことを願っている。 私はOOP入りのクールエイドを飲んだ。私自身ハイプをオウム返しして言っていた。Amazonで働きはじめたとき、私は学んできたあらゆる決まり文句や賛美歌やブードゥーのまじないをそらんじることができ、それを思考や経験のかわりにしていた。多重継承は悪だ。みんなそう言っているから。オペレータのオーバロードは悪だ。みんなそう言っているから。私はその理由をぼんやりと理解してはいたが、本当にではなかった。それから私は最低なのは多重継承ではないと認識するようになった。最低だったのは私だ。今でもそうだが、年々ましになっている。 先週面接した人が、多重継承は悪で、それは、たとえば人のクラスを、頭と腕と脚と胴体のクラスの多重継承にするというのはひどいからだと言っていた。彼は正しく、同時に間違っていた。その多重継承の状況は、確かに悪だ。しかしそれは全部彼の問題だ。遠くにいればただのバカだが、玄関から入れてやるなら悪になる。 まずい開発者は、これは世界の開発者の多数を占めるわけだが、どんな言語を与えようとまずいコードを書くのだ。 そうは言っても、多重継承は決して楽なものではない。ミックスインの方が良いソリューションであるように思えるが、誰もまだこの問題を完全には解決していない。しかし多重継承がないにしてもJavaは依然C++より優れており、それは私がいかにがんばったところで、私はどこかでコードの書き方のわからない連中に取り巻かれることになり、彼らにはC++よりはJavaを使わせる方がはるかに害が少ないのだ。 加えて、Javaにはコアの言語よりもずっと多くのものがある。そして言語自体も、氷河のようにのろいにせよ進歩していく。だから希望はある。それは私たちがAmazonで使うべきものだ。 ただ注意深くする必要がある。どんな言語でもそうだが、言語環境についてはよく知っているが、テイストやコンピューティングやそのほかの重要なことについてはほとんど知らない人がよくいるからだ。 Perlは10万マイルとか20万マイルとか乗ってきた古い自転車みたいだ。そしていつでもそれには何かしっくり馴染むものがある。たとえ5ポンドの軽さで尻がそんなに痛くならないもっとモダンな自転車に乗り換えていたとしても。 Perlは世界最高のマーケティングを持っている。彼らのマーケティングがいかに優れているかという話で本を書けるくらいだ。Sunは金でJavaのマーケティングをしたが、Perlはラリー・ウォールと仲間たちの純然たるマーケティングの才だけで人気の点でほとんど肩を並べている。ハーバードビジネススクールはPerlのマーケティングを研究すべきだ。あれには驚くべきものがある。 しかしPerlは最近まで他のどの言語も持っていなかったものを持ち、それがはらわたが露出していることを補っていた。破裂したクジラからだっていろんなものが作れるのだ。香水だって作れる。すごく有用なのだ。Perlもそうだ。 そして多くのタスクに対し、これはまったくもって正しいのだ。だからPerlはUnixとの統合と文字列処理においてこの惑星上の(1つを除く)どの言語よりも優れている。そしてその例外となる1つが舞台に登場したのはごく最近のことで、それはゴジラの国でのことだ。これについては後で話そう。 残念ながら、ラリーはUnix統合と文字列処理にあまりにフォーカスしすぎた。そしてリストやオブジェクトについては、ちゃんと実装するのが手遅れになるまでまったく目を向けなかった。実際、いくつかの基本的な誤りが初期におけるPerlの･･･なんていうか、クジラのはらわたに「デザイン」という言葉を使うのはためらわれるのだが、それはPerlの「ライフサイクル」の問題だ。この誤りによってリストやオブジェクトを正しく取り扱うことが非常に難しくなっており、Perlは真性のルーブ・ゴールドバーグ・マシン†へと進化することになった。少なくともリストやオブジェクトを使おうとするなら。 4)に変わってしまう。あなたはこんな風になってほしいと思ったことはないだろう。しかしラリーがある日たまたま何かの問題でそうなるのが都合が良かったため、それ以来Perlのデータ構造はまったくの破裂したクジラとなってしまったのだ。 今では、Perlの本にせよ、チュートリアルにせよ、PowerPointにせよ、少なくとも3分の1の時間は「リファレンス」の勉強に費やすことになる。これはラリーのリスト展開病に対する救いがたい、破綻した、ゴールドバーグ的修正なのだ。しかしPerlのマーケティングは驚くほど優れており、リファレンスはかつて経験した中で最良のものみたいにあなたは感じている。何に対してもリファレンスを取ることができる! Perlでオブジェクトが使えないのは、ラリーが決して本当にオブジェクトを信じたことがないためだ。それはそれでいいのかもしれない。私自身オブジェクトを信じているのかあまり確信がない。しかしそれならなぜオブジェクトを追加したりしたのか? そしてもちろん、Perlにはそのほかにもたくさんデザイン上の奇妙なところがある。たとえば「コンテキスト」を見るといい。それはラリーがシェルスクリプトからコピーしたN変数ネームスペースやシジルによるデリファレンスのようなおかしな決断のぞっとする副産物だ。Perlでは、すべてのオペレータ、すべての関数、すべての操作が、その「コンテキスト」に従い、6つのうちのランダムな1つの仕方で振る舞う。与えられたコンテキストにおいて特定の操作がどう振る舞うかを支配するルールやヒューリスティクスというのは存在しない。あなたは単にすべて暗記しておくしかないのだ。 スカラーコンテキストでハッシュにアクセスすると、分子が割り当てられたキーの数、分母がバケットの数となっている分数を内容とする文字列が得られる。クジラのはらわただ。そう言ったでしょ。 15年かそこらごとに、プログラミング言語はより優れた言語に置き換えられてきた。CはC++で置き換えられた。パフォーマンスが要求されるがデータ型もどうしてもほしいという大規模アプリケーションを開発する人々の間 Perlもまた、間もなくなくなる。それは新しいRubyと呼ばれる言語がついに英語に翻訳されたためだ。そう、それはこともあろうに日本で作られた。これにはあなた同様みんな驚いている。日本はハードウェアと製造業では知られているが、ソフトウェア開発では知られていない。 どうしてなのか誰にもわからないが、私の考えでは、それはタイピングの問題のためだと思う。1万種の文字があるアルファベットを使っていながら彼らが十分速くタイプできるとは、私には想像できなかった。しかしEmacsは多言語サポートを数年前に手にしたので、今では彼 そしてどうにかしてそれらが一緒に動くようにしていて、それがあまりにうまく行われているので、そこにそんなものがあるとは気付かないくらいだ。私はRubyを、私が知る30か40の他の言語のどれよりも早く学ぶことができた。RubyをPerlよりも快適に使えるようになるのに3日しかかからなかった。8年のPerlハッキングの後においてだ。Rubyは非常に一貫性が高く、 じきに物事がどう動くか推測できるようになる。そしてほとんどの場合正しく推測できる。それは美しい。そして楽しい。そして実用的だ。 いつかRubyについてまた書こう。私は最初に霊感を必要とする。ホワイの(感動的)Rubyガイドを読むといい。これは傑出した作品だ。本当に。ぜひ読んで。驚くべきものだ。私にはこのようなものを生み出せる精神を理解することはできないが、しかしこれは可笑しく、感動的で、Rubyのすべてが書かれている。まあ言ってみれば。読めばわかるよ。 ホワイトスペースの件というのは、Pythonがインデントをブロックのネストの定義に使っていることだ。これにより、すべてに対してある仕方でインデントを付けなければならなくなるが、そうしている理由は誰の書いたコードも同じように見えるようにするためなのだ。驚くほど多くのプログラマがこれを忌み嫌っている。自由が侵害されているように感じるのだ。ショットガンフォーメーションや難解なワンライナーを使う基本的人権をPythonが踏みにじっていると感じるのだ。[3] しかし私の意見では、本当にPythonを殺し、メインのスクリプト言語となる望みを、あるいは何であれメインの言語となる望みを絶ったのは、永久凍土の問題なのだ。人々はいまだ埋め込みインタプリタにTclを使っている。どのような面から見てもTclよりPythonの方が遥かに優れているというのに??ただし永久凍土の問題を別にすれば。 私はここですごく品のないことを書いてきたが、しかしPythonを使うのは実際とても快適であり(その欠点を大目に見られるなら)、私はもはやパイソニスタたちを叩くのがそんなに面白いことだとは思わなくなった。「永久凍土の問題」というのは、単に彼らが傾向として、その、冷たかったということだ。なぜか? 私はそれがPythonがPerlのレベルの人気をけっして得られない理由だと考えている。しかし私が単に想像しすぎなだけかもしれない。 私はこれを本当にADJのアーティクルとして書きたいと思っていた。少なくともそういったたぐいのものとして。しかし何かの理由で、私の本当の感覚は午前3時から6時の間の不眠症の発作の間にしか出てこないらしい。さあ、寝る時間だ! 1. エリックは、Lucidでジェイミー・ザウィンスキーと一緒に働いていたときに、ほとんどすべてをジェイミーが書いたのだと言っている。 記録のために言っておくと、私自身はホワイトスペースの問題を全然気にかけていない。そんなことのためにPythonを嫌うのはばかげたことだ。私が言っているのは、驚くほどの割合の*他の*プログラマたちがそれを嫌っているということだ。 |
ディックのサイトです。
