オープンソースについての誤解
2007-05-20
カテゴリー： Books
前の『ウェブ人間論』に比べると、話が噛みあっているだけましだが、中身が薄いのは同じだ。ウェブと脳のネットワーク構造の話など、おもしろい論点はあるのだが、茂木健一郎氏の専門知識が中途半端なので深まらない。気になったのは、梅田望夫氏のオープンソースについての認識だ：オープンソースというのは、誕生してからわずか10年以内です。もともとフリー・ソフトウェアというのはあったけれど、それは一つの研究室の中で作られるなど、物理的制約に縛られていた。(p.33)Richard Stallmanが聞いたら、椅子から転げ落ちるだろう。GNUプロジェクトができたのは1984年、Linuxの開発が始まったのは1991年だ。EmacsもTeXも、インターネットを使ってさまざまなバージョンが共同開発された。たしかに"open source"という言葉をEric Raymondが使い始めたのは1998年だが、それ以前からTCP/IPもHTMLも、すべてオープンだったのだ。オープンとかフリーとか強調していないのは、初期のハッカーにはそれが当たり前だったからである。
梅田氏は、1998年に突然オープンソースが登場して「恐ろしいほどの速度で」発展していると思っているようだが、これは逆だ。本来100％オープンだったインターネットが、著作権や特許に汚染されているのである。最近は、IETFで決まる規格(RFC)も大部分はシスコなどの特許がからんで、「ITU化」したと揶揄されている。W3Cの勧告も、ほとんどマイクロソフトの開発したものだ（特許を認めるかどうかは論争中）。
オープンソースの文化は、原理的に財産権の保護を基盤とする資本主義と矛盾するものであり、それが今まで大目に見られていたのは、サイバースペースで完結していたからだ。それが既存メディアを侵食し始めると、逆襲が始まる。P2PやYouTubeに対する攻撃をみても、私は梅田氏や茂木氏のようにオプティミスティックにはなれない。「本当の大変化がこれから始まる」のは間違いないが、それは彼らの夢見ているようなユートピアの実現ではなく、かつて産業革命とともに起ったような闘いだろう。
編集画面にログイン
梅田さんは、国内ではもっとも最初にUNIXを導入した大学研究室の御出身だから(坂村先生や村井先生も同じ研究室の御出身)、学生時代からオープンソースには接しているはずなのですがね。
「アメリカではyou tubeをダメにしないような文化がある。だからベンチャーが育つ。日本はどうか。winnyを駄目にした。だから日本は駄目なんだ」という議論がありますが、これはとんでもない勘違いだと思います。
アメリカは日本を越えた凄まじい訴訟社会です。これから、権利侵害者（及びその幇助者）に対して訴訟が相次ぐでしょう。
戦いはこれからです。
その本は読んだことはないのですが
（おそらくは今後も読む予定はないですが）
梅田氏が書いたページ
http://www.mochioumeda.com/archive/consensus/981001.html
を読む限り、理解していると思ったんですが…。
ジェフリーサックス氏（コロンビア大学）
藤本隆宏氏（東京大学）
梅田望夫氏
茂木健一郎氏
山形氏（というよりその背後のアメリカの一流経済学者）
といった権威、売れっ子に対する挑戦は凄いと思います。実名を出してる評論でここまでアグレッシブに行けるのはなかなか日本人にはできない芸当です（ネガティブな意味ではありません）
お二人とも大好きなんですけれども、懸念・杞憂はまったく書かないようですね。梅田氏のオプチミストぶりには平野氏はひいている感じが「ウェブ人間論」でありありと出ていました。さらに茂木氏は自分が知らないことをすべて「おおっ〜クオリア」で表現しますので。かみ合っている感は やや一方的に梅田氏の話をクオリア連発で聞く茂木氏というところでしょうね。本書は読んでないですけれど。
「マルチメディアサイコー論」を思い出してしょうがないですね。オープンソースサイコー。先ほども述べましたが、ある程度の枷を誰かがどのように作るか・・・少なくとも梅田氏ではないと思いますが。
ふわふわした楽観論者も必要ではあると思うのです。それが多少の誤解があっても・・・。
http://blogcq.livedoor.biz/archives/50194622.html
それを池田氏に指摘してもらう。バランスはとれてきているのではないかと。
この記述もおかしいですね。
＜このストルマンの流れをくむフリーウェア的世界は、反商業的なため、ソフトウェア産業との親和性があまりにも悪く、思想的な部分が強すぎるきらいもあり、ある一定数以上の信奉者を得ることができなかった。＞
GNUを「フリーウェア」と呼ぶのも粗雑だけど、まぁそれはいいとして、オープンソースのソフトウェアの大部分は、他ならぬLinuxを含めて、GPLで配布されているということを、まさか知らないわけではないでしょうね・・・
全体として、GNUとオープンソースを別のものと考えているように見受けられますが、ソースの公開を義務づけるというのはGPLの理念であり、レイモンドが変更したのはネーミングだけです。ライセンスとしては他にもいろいろあるけど、今でもGPLが多数派です。IBMもGPLで開発しているので、「反商業的」などというのは大きな間違いです。
「カテドラルかバザールか」などというのは、大した違いではない。たとえばEmacsも、オリジナルはストールマンのカテドラル方式で作られましたが、日本語版(Mule)などのバリエーションは、バザール方式で共同開発されています。
評論する人が増えてきてますね・・・（池田氏のことではないのです）
梅田氏の言論には、扇動者としての社会悪を感じます。
インターネットの負の部分を知らない人が、ブログを書き始めて、個人情報を掲載してしまったり、炎上を経験する。
彼は、「ウェブ進化論」で、自らをオプティミストと称して開き直ったようですが、だからといって、インターネットの負の部分を捨象して、ばら色の未来が現実であるかのように言説することが許されるものではないのではないか…。
孤独な呻きがネットで反発され、事件に発展することも珍しくないのですから…。
☆
>それ以前からTCP/IPもHTMLも、すべてオープンだったのだ。(池田先生)
まさに、その通りですね。
日本では、リナックスのメンテや教育に、有料でオラクルなどが乗り出すとか。
リナックスといえども、すべてが無料という訳ではない。
そして、トーマス・フリードマンの「フラット化する世界」によれば、リナックスは、IBMの協力(資金・組織)によって成立したという。
すべてが無料(フリー)で成立しているのではないけれど、オープンか、クローズかといえば、やはりオープンなのだと思う。
自説開陳失礼しました。
そして、ありがとうございました。
「カテドラルかバザールか」は大きな違いだと思います。ストールマンがOSを作り得ず、リーナスがそれを成し遂げたのは、この違いによるものではないですか。
ストールマンがGNU Hurdを完成できなかった原因はいろいろありますが、最大の問題はmicrokernelの設計思想に無理があった（当時のマシンではオーバーヘッドが大きすぎた）ことだといわれています。カテドラルかバザールかには、まったく関係ありません。
オープンソースというメインテーマではなく結びの言葉である「産業革命とともに起ったような闘いだろう。」についてコメントしたい。ラッダイト運動よりも産業革命が成功したために起きた労働者の精神的欠乏感と未来への希望と見えた社会主義が破綻して、その結果として全体主義が興隆し、悲惨な戦争の時代を迎えたというドラッカーの言説を思い出してしまった。でもドラッカーはインターネット革命を楽観的に語っている。未来への悲観と楽観。アジテーションへの警戒を持つ世代。真剣に生きてほしいとのメッセージかな？
> GNUを「フリーウェア」と呼ぶのも粗雑
GNU をオープンソースと呼ぶほうが粗雑では？ （GNU プロジェクトの意思を尊重するなら）
http://www.gnu.org/philosophy/free-software-for-freedom.html
Linux と Hurd の現状の違いは技術面にもあったのでしょうが、それより Torvalds と Stallman の人間性の違いを感じます。
本文をよく読んでください。私はGNUをオープンソースと呼んだことはありません。
気にしたのは（本文ではなく）
> GNUを「フリーウェア」と呼ぶのも粗雑だけど、まぁそれはいいとして、オープンソースのソフトウェアの大部分は、
でしたが、「フリーソフトウェア」と呼ばずに「フリーウェア」と呼ぶのは粗雑、という意味でしたか。失礼しました。
>当時のマシンではオーバーヘッドが大きすぎた
「当時」がいつを指すのか分かりませんが、マイクロカーネルを採用したWindowsNTやNEXTSTEPが十分実用になったわけですから、「設計思想に無理があった」というのは、一般的な見方ではないでしょう。Hurdの開発が遅れたのは、カテドラル方式だからだと考えている人はたくさんいます。
hurd stallman cathedral で検索してみてください。
この手の話題になると思い出すのは、Ｍａｃ利用者がパソコン通信で課金が高かった頃に、オートパイロットで接続時間を短くするため、ComNifty,魔法のナイフ,茄子,ぞーさん,魔法のナイフ,まな板Proなどフリーソフトを利用して頑張ってことなんですよね。インターネットにつながる前からそういう発想はあったでしょ、ってこと。
池田さん、どこの誰がこんなアホなことを言っているのですか？
> 最大の問題はmicrokernelの設計思想に無理があった（当時のマシンではオーバーヘッドが大きすぎた）ことだといわれています。
マイクロカーネルが普及しなかったのは、CPU性能が不足していたからではありません。むしろ逆です。CPU性能が予想以上に向上してしまうため、マイクロカーネルの必要性があまりなかったからです。それはMachの設計思想からもわかります。
マイクロカーネルはマルチプロセッサシステムの利用を容易にします。KMUは今後のコンピュータはマルチプロセッサシステムが主流になるという予想の下でMachの開発に着手しているはずです。ところがCPUがMHzクラスからGHzクラスへと高速化する技術革新があったため、当分モノシリックカーネルでよし、といった考えが支配的になります。コンピュータサイエンスの分野でコンカレントプログラミングのアルゴリズムなんかを研究する人は少数になってしまいました。
マイクロカーネルはこれからです。爆熱インテルプロセッサとDOS/V暖房PCの時代が終わりましたからね。
池田さんはソフトウェアをライセンスという観点で眺めていられるようだけど、オープンソースソフトウェアの起爆力はバザールモデルというソフトウェア開発モデルだと思いますよ、わたしは。
Linuxのすごさはよってたかって作るというラディカルな開発スタイルで、RMSには決してできなかったスタイルです。
RMSはネットの向こう側のプログラマを信用していなかったので、パッチや改良を貰うときにFSFに著作権を譲渡するような書類にサインさせていましたがLinusはそんなことはおかまいなくコードを取り入れた。たったそれだけと言っちゃあなんですが、その違いが本質的な違いにすらなるというのがバザールモデルの「発見」だとわたしは思います。
完全に本題とは離れていますが、マイクロカーネルOSについて少々。1990年代において、マイクロカーネルが普及しなかったのは池田先生の指摘のようにプロセッサの能力不足ではないでしょうか。すくなくてもOS研究コミュニティでも同様に性能不足をあげる人が大勢だと思います。もちろんOS研究コミュニティを「どこのアホ」というならば議論になりませんが。
OS用語乱発で恐縮ですが、カーネルモードとユーザモードの切り替えというコストの大きい処理の回数が、マイクロカーネルOSはUNIXやLinuxなどのモノシリックOSと比較して、多くなるために、結果として遅いOSになってしまいます。ユーザは遅いシステムはその設計思想がよくても嫌うものです。
間宮様の主張されている、CPU性能が予想以上普及したからマイクロカーネルOSが普及しなかった主張される根拠となるような論文などがあれば教えて欲しいです。お願いいたします。
Mach OSを例に挙げられていますが、Mach OSはマルチプロセッサを想定していたかというと、確かにスケジューラの部分を変更しやすいので、さまざまなマルチプロセッサマシンへの対応が容易ということはあると思いますが(まわりで当時Mach OS用のスケジューラを書いていた人を何人かいますが、難易度はモノシリックカーネルOSと大差ないような気がしますけど)、マイクロカーネルOSはマルチプロセッサ向きと断定するのは議論が乱暴すぎではないでしょうか。実際、I/O制御などかえって不利になる点も多いです。実際、マルチプロセッサマシンでマイクロカーネルOSを使っている事例は少ないですし。
間宮様はコンピュータサイエンスに関してどの程度の知識があるのかは存じませんが、コンピュータサイエンスでコンカレントプログラミングの研究は80年代で終わっていたはずで、OSカーネルアーキテクチャとは関係ないと思います。
私は、バザール方式を否定しているわけではありません。レイモンドのいうように、EmacsはカテドラルでLinuxがバザールだという二分法がおかしいと言っているのです。Emacsに多くのバリエーションがあるのは、ネットワーク上でバザール的に改良されたからです。
Hurdについていえば、佐藤さんからも指摘があったように、設計思想が（当時としては）よくなかったことが失敗の最大の原因でしょう。ストールマンは「Hurdはまだ生きている」といってましたけど、もう彼はコーディングをやめたので、完成は不可能だと思います。
もう一つの大きな原因は、hyoshikさんのおっしゃるように、ストールマンの性格でしょうね。彼は天才であるがゆえに、他のプログラマを信用できなかったのでしょう。しかし100年ぐらいたって、20世紀のハッカーとして誰が歴史に残るかといえば、ゲイツでもジョブズでもなくストールマンだと思います。
マイクロカーネルの歴史的なところはあまり知らないのですが、
WindowsNT3.51以前ではユーザモードで動いていたグラフィックスドライバを、NT4.0でカーネルモードに映したことを考えても、やはりそのころは性能不足だったのではないでしょうか（VRAMアクセスのページフォルトが問題だったので、カーネルモードに移したはずです）。
佐藤さんへ。
コンカレントプログラミングをやってる人たちは80年代も今も少ないです。課題が山積みになってます。強力なツールさえありません。マルチプロセッサシステムが当たり前になった今、ようやく作業がはじまるという気がします。
それと、Machがダメだったのはモードの切り替えが多発するからではありません。コンテキストスイッチングに無理があるのです。マイクロカーネルをUNIXプロセスの共有メモリ空間内に配置しないで外在させてしまったのです。DarwinではUNIXプロセスの共有メモリ空間内に配置しています。MacOSが安定しているのはそのためです。
池田さんへ。
Hurdの設計思想に無理があるとしても、それはモードの切り替えのようなものではないでしょう。そもそも、モードの切り替えは設計思想とあまり関係しない。
平宮様へ
コンカレントプログラミングはいつの時代でも難しい問題だとは思います。こちらが伺っているのはコンカレントプログラミングとマイクロカーネルOSが衰退したこととの関連性です。ご説明いただけるたすかります。いちいち説明するのが面倒でしたら、当該の論文などをあげていただくのでも結構です。
平宮様の「(Mach OSは)コンテキストスイッチに無理がある」という主張ですが、残念ですが何度読んでも文意がとれませんでした(いちおうOSの基本的な知識はあるつもりですが)。まずUNIXプロセスの共有メモリ空間というのはMach OSの何をさしていますか？、教えていただけないでしょうか。UNIXプロセスといっているのでUNIXのエミュレーションの話でしょうか。そうするとカーネルの話ではないですよね。文意がとれないので、一般論で議論させてください。カーネルモードとユーザモードの切り替え回数はモノシリックOSとマイクロカーネルOSでは後者は極めて多くなり、そのコストは無視できるものではないはずです。ぷらすさんが指摘されているように、Windows NT系OSが4.0でGUI処理をカーネル側にいれたのもWindowsではGUI処理比率が高く、そのつどモード切替をしていると遅くなるからです。一方、コンテキストスイッチのコストはマルチタスク数に依存するのでモノシリックOSとマイクロカーネルOSで(スケジューラの実装の仕方にはよりますが)決定的な差違があるというわけではないはずです。
Mach OSに話をもどすと、Mach OSは初期の実装ではスケジューリング機構が単純だったのでコストが大きかったのですが、その後はScheme言語のContinuationに類似した機能を使う方法(いわゆるco-routineのような並行実行方法)でコンテキストを切り替える機構を導入したので、コンテキストスイッチのコストを大幅に改善したはずです。
平宮様のいうMach OSの衰退=コンテキストスイッチのコストという主張には無理があると思いますが、ここまで強く主張されるには何らかの根拠があるのだと信じますので、その主張の根拠となっている論文などをご紹介いただけないでしょうか。再度お願いいたします。
追伸：池田先生へ：技術的な話題になってすみません。ただ、モード切替とそのコストというのは民間と役所と間など経済分野でもOSと類似した問題はあるかもしれません。
"W3Cの勧告も、ほとんどマイクロソフトの開発"と言うのは、初耳です。
具体的にどういうものを指しているのでしょうか？
オープンソースのなかでも、javaに関連したものは、microsoftの影はないですし、ここでの表現は、一面的にかんじますね。たぶん、梅田望夫氏などは、オープンソースとして、apache-jakartaなどの周辺の活動を指しているのでしょう。
マイクロカーネルの話は、「モジュール化」が必ずしもうまく行かない例としておもしろいので、拙著（『情報技術と組織のアーキテクチャ』）でも少し取り上げました。理屈の上では、マイクロカーネルの設計思想のほうが合理的ですが、実際にはモジュール間の通信の負荷が高いため、処理速度が（モノリシックに比べて）最大50％ぐらい遅くなるといわれています。
こういう問題は、モジュール化一般にみられるもので、たとえばオブジェクト指向言語でも、粒度をあまり細かくするとメッセージ交換の負荷が大きくなって効率が下がります。Javaのようなインタープリタ型の言語もモジュール化の一種ですが、やはりオーバーヘッドの処理が遅いため、大きなプログラムはできません。
NTも、最初はマイクロカーネルとして出発しましたが、効率が悪いため、4.0以降はモノリシックになりました。マイクロカーネルを採用している大手のOSとしては、MacのOSX（中身はMach）がありますが、やはりパフォーマンスが上がらないため、モノリシックに変えることが検討されているようです。
マイクロカーネルからモノリシックカーネルへの移行が進んだのは、DRAMの価格の下落とも関係があるでしょう。Windows NTの最初のバージョンは16MBのメモリで動いていましたが、当時は4MBのDRAMが1枚1万円以上したのです。この容量でモノリシックなカーネルを動かそうとするとSWAPが多発し、プロセス間通信のオーバーヘッドの方がまだ我慢できるレベルだったのだと思います。
平宮さんへ
自分が専門家でもないのに、他人のコメントを「エセOS論議」だとか「デタラメ」だとか中傷するのはやめてください。あなたの言葉が荒っぽい割には知識がいい加減であることは、当ブログのコメント欄でもたびたび明らかになっています。
あなたのコメントは、非生産的な喧嘩を誘発するだけなので、歓迎しません。もう投稿しないでください。
>Javaのようなインタープリタ型の言語もモジュール化の一種
「ネイティブ・コードを出力しない処理系はインタープリタである」と誤解している人もいますが、Javaは仮装マシンが実行できるバイトコード（マシン語に近いものです）にコンパイルしますから、ソースコードを1行ずつ解釈しながら実行するような、いわゆるインタプリタ型の言語とはだいぶ違います。
「インタプリタ型の言語」がモジュール化の一種なのでしょうか。それともJavaがモジュール化された処理系であるということでしょうか。確かにJavaではオブジェクト生成のオーバーヘッドは大きいです。ただ、メッセージ交換の負荷が大きいという話は聞いたことがありません（Javaにおけるメッセージは、メソッドの呼び出しに相当します）。
「大きなプログラムはできない」と言い切ってしまうと、Javaでサーバーアプリケーションを書いている人達が怒り出すんじゃないでしょうか。
Java は、少なくとも当初は JIT を仕様としては備えていなかったので、インタープリタと呼ぶことを誤解とまでは言いませんが、
> たとえばオブジェクト指向言語でも、粒度をあまり細かくすると
> メッセージ交換の負荷が大きくなって効率が下がります。
> Javaのようなインタープリタ型の言語もモジュール化の一種ですが、
> やはりオーバーヘッドの処理が遅いため、大きなプログラムはできません。
というのは好意的に見ても「粗雑に過ぎる表現」ですね。
どんな言語なら「大きなプログラム」ができるとおっしゃるのか知りたいところです。
当ブログには、コメント欄まで隈なく読んでツッコミを入れてくる人が多いので、油断できないですね。こんな所で厳密な議論はできないので、モジュール化の話も粗雑な一般論です。
Javaがインタープリタじゃない（だから「型」と入れた）ことぐらい知ってますよ。ここでいうモジュール化は、オブジェクト指向などのencapsulationと、階層化という意味の両方を含んでいます。後者の意味では、コンパイラも（マシン語に比べると）モジュール化の一種です。
「大きなプログラムができない」というのも粗雑かもしれないけど、「むずかしい」ならいいですか。一時はMozillaを初め、ウェブ上のアプリケーションをすべてJavaで書き換えてOS中立にしようという話もあったけど、現実にできてるのは小さなアプレットがほとんどですよね。
厳密な議論は拙著を読んでいただくしかありませんが、モジュール化によってソフトウェアの生産性を上げる動きは、フォン=ノイマンのころから始まっています。しかしそれによってパフォーマンスは落ちるので、モジュールをどう最適化するかが問題です。こういう問題を経済学のロジックで説明することは意外にむずかしく、私もうまく行かなかった。
Javaではできない大きなプログラムというのはどのくらい大きなプログラムなのでしょうか？
EclipseやNetBeans、IntelliJなど、最近のJava開発環境はすべてJavaで書かれていますけど、そういったパソコンレベルで動くようなアプリケーションは小さなアプリケーションということでしょうか？
Mozillaがダウンロードサイズ6MBに対して、NetBeansは60MBで、ほぼPure Javaです。また、これらのIDEは、モジュール化されて各モジュールの独立性が高められています。
それとも、こういったJavaで作ったプログラムは起動も遅いしメモリも食うし、現実的ではないという意味でしょうか？
返信をいただいていたことに気付きませんでした。失礼しました。
> 「むずかしい」ならいいですか。
これならいいでしょう。きしださん（↑）のお考えはわかりませんが、大きなプログラムを作るのは普通難しいものです。
あるいは「“Java”こそ、大きなプログラムを作るのは難しい言語だ」と評されるのであれば、私の本業にとって好都合なコメントではあります。
しかし、これを引用して自社技術を宣伝しようとしても、その引用元に、
> ここでいうモジュール化は、オブジェクト指向などのencapsulationと、
> 階層化という意味の両方を含んでいます。後者の意味では、
> コンパイラも（マシン語に比べると）モジュール化の一種です。
とか、
> 一時はMozillaを初め、ウェブ上のアプリケーションを
> すべてJavaで書き換えてOS中立にしようという話もあったけど、
> 現実にできてるのは小さなアプレットがほとんどですよね。
と書いてあるのがバレたら、ストールマンが椅子から転げ落ちるでしょう。技術者でない人への説明なのだと好意的に解釈しても「言葉が荒っぽい割には知識がいい加減」を超えるものではありません。
（カテドラルかバザールかは関係ない、というご意見には同意しています。念のため）
現在、｢大きな」アプリケーションは一般的にJavaで書かれるようになっていますよ。
それどころか、Javaより遥かに遅いRubyで「大きな」アプリケーションを動かせるんじゃないか？ という試みが行われているのが、ここ２年くらいの流れです。
技術的な潮流を追う時間が無いのかもしれませんが、そういった細かな誤認によって、大筋の説得力が失われていくのは惜しいと思います。
プログラミング業界では「モジュール化」というのは別の意味があるようですが、ここで使っているのはBaldwin-Clarkの使っている経営学的な意味です。
それによれば、IBMのシステム/360からモジュール化は始まっており、アプリケーションの命令を必ずOSを通して実行し、ハードウェアに直接さわらない階層化された設計もモジュール化の一種です。同じ意味で、コンパイラのような高級言語で書いてマシン語に翻訳するのもモジュール化です。さらにコードをオブジェクトに分割して再利用するのもモジュール化です。
一般に、モジュール化することはreal optionの役割があり、開発にともなう試行錯誤を容易にしてシステムの柔軟性を高めますが、モジュール間のコーディネーション・コストが増えます。このトレードオフの中で「最適な粒度」を求めようというのがBaldwin-Clarkの議論です。
技術を論じるときに、技術者が使う意味合いを無視して、断りなく経営学的な意味合いで用語を使うことを適切と考えるかどうかは意見の相違ですみますし、粗雑な表現に目をつぶれば、異なる粒度でモジュール化をとらえることは不自然ではありません。また、経営学としての思考については、何も指摘していません。
しかし、
> Javaのようなインタープリタ型の言語もモジュール化の一種ですが、
> やはりオーバーヘッドの処理が遅いため、大きなプログラムはできません。
という表現は、（「できません」→「むずかしい」に置き換えても）滑稽でしかありません。10年以上前から Just In Time コンパイル技術はありましたし（正式採用は Java 2＝1998年）、HotSpot で高速化されたのも 7年前です（wikipedia による）。そもそも速度の制約は、必ずしもプログラム規模の制約にはなりません。実際、旧 Visual Basic による超巨大プロジェクトが実在します。
最後の段落はそれほどおかしな表現とは思いませんが、Java という不適切な例を出してしまったため、技術者に理解を求めることが困難な表現になっているのです。
いまだにJavaについて、あちこちで話が盛り上がっているようですが、どうも私の知識が古かったようですね。多くの人にデバッグしてもらうのはありがたいけれど、たかがコメント欄の一言一句にこれだけツッコミが入るのもやりにくいですね。
私はいつも、記事を書くのに使う時間は1時間以内、ウェブ以外の情報は調べない（コメントを書くときはそれも調べない）という手抜きモードで書いているのですが、月間50万PVともなると、マスメディア並みの品質管理が求められるんでしょうか・・・
こんなところでブログやコメントの質が低い理由を告白されても、とまどう人が多いのではないでしょうか。
しかし、この程度の話にしつこく食い下がるのは私だけかと思っていたので、他でも盛り上がっていたとは意外です。