=============================================================
【悩める相談者による追記】
今回は、少しかたい内容の疑問提起だったので、予想よりも反応が少なかったようです。私の最初からの予定では、ずっと後（来年１月あたり）に投稿する積もりで用意したものだったのですが、実は急遽投稿せねばならぬ事情がありました。
というのは、９月１８日の午後、Ｙ氏から「ＰＡＳＣＡＬのＰ−ｃｏｄｅとＪａｖａはどこが異なるか？」という問題提起が“COMPUTER-ENGINEER ”宛てに発せられたのです。“COMPUTER-ENGINEER ”というのはＹ氏の定めた同報略称なので、どのような方々が対象なのか存じませんが、私めも幸いその中に入れてもらえているのです（ありがたいことに、まだエンジニアと見做されているらしい）。
この問題提起の中でＹ氏は、Ｊａｖａは「ハードウェア非依存」「プラットフォーム非依存」と言われているけれど、どういう仕組みになっているのかと疑問を呈され、続けて、十数年前はやったＰａｓｃａｌ Ｐ−ｃｏｄｅとは仕組みがどう異なるのか、Ｐａｓｃａｌ Ｐ−ｃｏｄｅで実現できなかったことがなぜＪａｖａで可能になったのか、と問うたのでした。
これに対して、私は掲記の「素朴な疑問」の予定稿を返信として送りました。つまり問題の前提となっているＪａｖａの「ハードウェア非依存」「プラットフォーム非依存」という魅力的な前提条件に疑問を呈したのです。同時に、ここで今この議論を始めてしまうと、この【素朴な疑問】を来年１月頃に投稿したとしても二番煎じの内容になってしまうだろうと危惧しました。そこでタイミングを失しないよう、時をおかずにｖｏｘ欄にも載せることにしたのです。
翌日の１９日になると、Ｙ氏の問題提起への反応は凄まじく、話題は次々と広がっていきました。Ｙ氏のところに集まる“COMPUTER-ENGINEER ”からの沢山の意見は、その都度（転送許可を取った上で）再び“COMPUTER-ENGINEER ”に配信されるので、勧進元のＹ氏には大変なご苦労があったことと思います。この１９日だけでも、私のメールボックスへ届いたメールの数は（他のメールも含めてですが）２０通を楽に超えました。
話題は色々な方面に広がりましたが、特に「プラットフォーム非依存」を否定した私の発言に対しては、予想通りＭ氏から反論をいただきました。転載許可を得ていませんので、ここでその全文を公表するのは差し控えますが、その冒頭は次のようになっていました。
『わが尊敬する木下氏が年老いて新技術を信じないのか、
厳密性を欠く素人の私がミーハー族と一緒になって宣伝を鵜呑みにしているのかどちらかでしょうが、‥‥ 』
で始まる厳しい内容（？ もちろんユーモアです）の反論でした。それに対し、もちろん私も反論しました。Ｓさんからもコメントをもらいました。結論はともかくとして、いずれも興味深い議論でありました。
ｖｏｘ欄からの反応はあまりありませんでしたが、私の“プラットフォーム非依存”を否定する発言に異論が出なかったのは、同意する人が多かったと解釈してよいのでしょうか。さすがｖｏｘの読者はよく分かっていると、身勝手に解釈してもよいのでしょうか（分かっていないだけ、という解釈もある）。
ここで、ｖｏｘの読者のためにＪａｖａの“プラットフォーム非依存”がうそであることを再び説明しようと思っていたのですが、気が変わりました。今（９月２２日（日））外は台風の影響で大荒れの天気です。家の中でＢｉｔ誌の８月号のページをぱらぱらとめくっていると（最近Ｂｉｔは購読していないのですが、ある事情で８月号だけ寄贈されたものが手元にあったのです）ここにまさにぴったりの記事を発見しました。
「Ｊａｖａ−キャッチフレーズの真相」青柳龍也（Ｂｉｔ ８月号ｐ１５〜２４）にこのテーマが詳しく説明されています。Ｗｉｎｄｏｗｓ９５とＳｏｌａｒｉｓで同じ結果が得られないことを示す簡単なプログラム例まで載っています。興味のある方は是非これを読んでみてください。そして、どちらの論が正しいか判断してください。
それにしても、世の中で広く喧伝されていることがらの中にはときどき眉唾ものの話しがあるものです。そういう時、これはちょっとおかしいな（笑止千万なり）と思っても、我々はなかなかそれを指摘する勇気が持てません。Ｙ氏のように、直ぐ疑問を提示できるようになりたいものです。私のような未熟者にできることは、精々「素朴な疑問」のような形式でこっそりと意見表明するくらいのことしかできません。
ことのついでに、私が最近「笑止千万」と思ったことをいくつか列挙しておきます。もし間違っていた場合に「年老いて新技術を信じない木下」と思われたくないので、ここだけの話しにしてください。
●笑止千万その１
マイクロソフト社がインターネットへの対応を間違えてＮｅｔｓｃａｐｅに遅れをとったとき、マスコミはビル・ゲイツの失敗としてはやし立て、今にもマイクロソフト社が傾くように書き立てた。
ブラウザーソフトの遅れを取り戻すことくらい、簡単なことではないですか。二番手でスタートし、結局は訴訟合戦の末勝利するのは何時もマイクロソフトなのです。ＣＰ／ＭとＭＳ-ＤＯＳ，ＭａｃとＷｉｎｄｏｗｓのＧＵＩ，表計算ソフト，Ｃコンパイラ，‥‥ いずれもそうでした。Ｋａさんの言うように過去の経験に学ぶべきです（私はマイクロソフトは好きではないが、これは歴史にもとづく事実なのです）。
Ｊａｖａも同じ運命をたどるでしょう（そのうちマイクロソフトはＪ++(?)とかいうコンパイラを出してくるのでは？）。
●笑止千万その２
プログラムを必要な都度ネットワークからダウンロードして実行するから、パッケージソフト（ワープロ、表計算ソフト、コンパイラなどであろう）は不要になる（ＰＣも不要になる）という議論。
こうなる可能性があるのは、２〜３週間休暇で家をあけるときでもコンピュータを通信回線に繋がったままにしておける社会での話だと思います。そういう基盤の整ったアメリカのような社会でなくては、決して出てこない発想ではないでしょうか。回線使用料がただ同然になる可能性のまったくない日本で、事業として成立すると考えるのは愚かなことです。
たとえば貴方は、電話回線を繋ぎっぱなしでワープロで長い時間文章を推敲したり、徹夜でプログラムデバッグしたりできますか。会社ならできる？ そう、会社が電話代を負担してくれますからね。しかしそういう経済感覚の人は東芝グループでは不要でしょう。
もしそういう世界になるとすると、これからはプロジェクトの遅れの言い訳として「ネットが混んでいてワープロが使えなくて‥‥」とか「ネットが混んでいてコンパイラが遅くて‥‥」とか言えることになるので、プログラマにとってはまことに喜ばしいことではありますが。
●笑止千万その３
Ｊａｖａプログラムはバイトコードに翻訳され、インタプリタによって解釈実行されるからセキュリティ上の問題は起こらない。
こんなにお人好しの理解でいいのだろうか。こんな仕掛けを破ることくらい一流のハッカーにとっては造作もないことである。パチンコのプリペイドカードで業界が膨大な損害を被ったのは周知のことであるが、あれを設計したＮＴＴデータ通信やどこかの商社は損害賠償を求められている。将来同じような問題が発生したとき、Ｊａｖａの開発元（サンマイクロ？）は同様に責任を取ってくれるのだろうか。
いや、少し筆が過ぎたようである。ここだけの話にしておこう、ここだけの。本当の意味で“年老いて新技術を信じない”木下と言われたくはないので。 ↑‥‥この表現がすっかり気に入ってしまった。
［Return］
=== Ｔａさんからの私信 ===================================
私信: VOX より 近未来の情報インフラについて
雑誌をななめ読みした程度の知識しか有りませんが、一つだけ私の考えを書かせて下さい。
(笑止千万その２)は、ネットワークコンピュータの批判だと思いましたが、この兆候はすでに実現しつつあると思います。 ただ私もＯＳ自体がネットワーク化されるという発想には、まだついて行けませんが。
例１. マイクロソフト、ネットースケープともに、最新版のＷＷＷブラウザが、ネットワークを通して広く配布されています。 店頭売りを使用していては、時代遅れの感すらあります。
例２． 私などはもうついて行けませんが、通信カラオケの方が、流行に敏感で、曲数も多く、新しいもの好きな人は、絶対通信でないと.. と言います。 私は、絵が無関係なのがイヤですが、動画が配信されるのも時間の問題でしょう。
例３． カラオケも歌っている最中、通信している訳ではないのと同じように、ワープロ作業中回線を占有する必要はありませんね。 NTT? の光ファイバ、あるいは、ケーブルテレビのどちらが主流になるか判りませんが、いずれ、ＰＣのＯＳ程度の転送は、瞬時になると思います。
オンデマンドで映画が見れる時代が実現するなら、ワープロソフトの転送くらい、簡単だと思います。
かなり記憶が曖昧ですが、通信衛星を使って、ゲームソフトを配布する計画または実績があったとも思います。
通信業者の競争で、通信回線は、道路のようにタダになる日も遠くないような気がします。 維持コストは、情報サービス料または、公共投資で賄うようになるのではないでしょうか。
====== Ｔａさんへの木下の返信 =============================
メール、ありがとうございました。
単にネットを通じてソフトウェアを配布するのと、ネットワークコンピュータ（ＮＣ）でパッケージをダウンロード実行するのとで、根本的に異なる点は、ＮＣの場合は回線が繋がりっぱなしになるという点だと思います。私も、ＮＣがどういう形態で使われるのか色々と推測しているだけですが、どう考えても繋ぎっぱなしでなければならないという結論になりました。違うのでしょうか。
一度ダウンロードしたら２度目以降はそれを繰り返し用いるというのでは、今と何ら変わらないではないですか。それを長い時間保存しておくメモリもＨＤもない環境なのです。最初にダウンロードして以後回線を断つ、という方法もあり得ます。そのセションだけの使い捨てということですね。そして特定の機能が必要になったときだけ繋ぐ、ダイナミックリンクのようにするのでしょうか。ただ、繋ぐプロセスが利用者に感知されるようでは使い物にはならないでしょう。ワープロの途中で表計算ソフトを使って、その結果をワープロ文書に埋め込むときなどどうするのでしょう。今の使い方より不便になっても我慢せよとでもいうのでしょうか。
通信カラオケは、ダウンロードしてすぐ回線断とできますからいいでしょう。たとえ動画があって繋がりっぱなしにする必要があるとしても時間的にはたいしたことはありません。しかし長時間思考を要する（我々が今やっているような）仕事の道具としては、繋ぎっぱなしでは使えませんよ。私の経済感覚が古いのでしょうか。
「通信回線が、道路のようにタダになる日も遠くない」と信じてよいのでしょうか。日本では高速道路はいずれ無料になると言われていました。それが実現不可能になってしまっているのはご承知の通りです。ああならなければよいのですが。
古い話で恐縮なのですが、今から２６〜７年前、アメリカのマサチュセッツ州では当時電話は基本料金さえ払えば市内は掛け放題でした。アパートの部屋から端末を使ってＭＩＴのＭｕｌｔｉｃｓが使い放題に使えました。すごい国だなあ、日本もいずれそうなるに違いないと期待しました。そして見事に裏切られました。したがって、私はそれほどお人好しにはなれないのです。
悲しいことですが。
=== Ｔａさんからの返信 ====================================
私信: VOX より 近未来の情報インフラについて（回答）（回答）
ご丁寧な返信たいへん恐縮です。 時間があまりないので申し訳ありませんが、E-MAIL 形式で回答させて下さい。
>> 単にネットを通じてソフトウェアを配布するのと、ネットワークコンピュ
>> ータ（ＮＣ）でパッケージをダウンロード実行するのとで、根本的に異な
>> る点は、ＮＣの場合は回線が繋がりっぱなしになるという点だと思います
>> 。私も、ＮＣがどういう形態で使われるのか色々と推測しているだけです
>> が、どう考えても繋ぎっぱなしでなければならないという結論になりまし
>> た。違うのでしょうか。
電話をかけることに対応する接続確立までの時間がほとんど０であれば、必要なときだけ自動的につながるというイメージになると思います。
しろうと考えですが、ＣＡＴＶなどでは、従量制というより定額料金が中心になるのでは？ あえて従量制とするならば、パケット単位のような、どれだけ通信したかの課金体系。
で、接続時間よりは、どれだけ通信したかが効いてくるかと思います。 (ＮＣからずれてしまいました。)
>> 得ます。そのセションだけの使い捨てということですね。そして特定の機能
>> が必要になったときだけ繋ぐ、ダイナミックリンクのようにするのでしょ
>> うか。ただ、繋ぐプロセスが利用者に感知されるようでは使い物にはなら
>> ないでしょう。ワープロの途中で表計算ソフトを使って、その結果をワー
>> プロ文書に埋め込むとき
プラグインの自動化みたいに、"特定の機能が必要になったときだけ繋ぐ"というか必要な時に、ロードする感じでしょうか。
感知されない位のネットワーク技術が実現しつつあると思います。
>>仕事の道具としては、繋ぎっぱなしでは使えませんよ。私の経済感覚が古い
>> のでしょうか。
例えば、無線ＬＡＮのように、いつもつながってるとも言えるし、必要なときだけ、電波がでているという形態もあり得ますね。
# なんか、あるようでない電子論のようになってしまいました。 (こちらもまったく専門外ですが)
ＮＴＴのテレホーダイとかは、深夜だけですが、定額料金ですね。
# ニーズがあれば、商品が出て来るのが競争社会ですね。
>> 「通信回線が、道路のようにタダになる日も遠くない」と信じてよいので
>> しょうか。日本では高速道路はいずれ無料になると言われていました。そ
>> れが実現不可能になってしまっているのはご承知の通りです。ああならな
>> ければよいのですが。
なるほど、政府がからむとダメってことですね。
>>したがって、私はそれほどお人好しにはなれないのです。
"ＭＩＴのＭｕｌｔｉｃｓが使い放題" のお話は、以前拝見しまして、すごいなと思っていました。
高速道路は無料でなくても、対外競争力は、いまの所問題なさそうですが、情報コストが高いままだと、日本の将来が心配ですね。
あまり内容のない駄文の返信となってしまい申し訳ありません。
それでは、失礼いたします。
=============================================================
木下の独り言：早くこうなるといいなぁ。電話回線の利用を期待するのはやめよう。ＣＡＴＶに期待しよう、ＣＡＴＶに。
［Return］
======= Ｋａさんの投稿にかこつけて、私見を =================
> JavaとP-systemの基本的な違いは、
>
> カバーする範囲の違い(当然Javaの方がカバー範囲が広い)
> JIT(Just In Time)コンパイラの実用化(元々はなかったものですが)
>
> などがあると思います。
Pascal P-system（まあ、UCSD-p system といった方が正確ですね）が敗れたのは、要するに性能競争で他の処理系に敗れたのです（他の高性能なコンパイラ型処理系やＣ言語の出現によるものです）。その意味では Java も同じになるでしょう。Java はインタプリタ方式を特長としていたのに、もうコンパイラの実用化が話題になってきているのですから。早晩、コンパイラ型処理系（J++？）にとって替わられるかもしれません（Javaの仕様は残るでしょうが）。
私は Java と p-system との基本的な違いを次のように理解しています。
Javaの利点は、要するにソースプログラムを手直ししなくても異なるプラットフォーム上で即時に動かすことができるということでしょう。互換上の問題は、個々のプラットフォームが吸収している訳です。決して個々のプラットフォームが何も対策しないで実現されている訳ではありません。
p-system でもそれは同様です。ソースプログラムの手直しなしで様々なＨＷ上で実行できたのです（しかし性能が悪くて、結局は受け入れられませんでした）。
では違いは何かというと、ご指摘のようにプラットフォーム依存部分の差（注１）だと思います。その差を小さくできたことが成功の要因でしょう（プラットフォーム自体は劇的に異なりますが）。それと、その依存部分が見事に切り分けられている（理論的にも物理的にも）点が p-system に比べて格段にアピールするところだと思います。更にもう一つ加えれば、Java は性能問題の洗礼をまだ受けていないということでしょう。それは、これからの課題ですね。
（注１）本当のことを言えば、個々のプラットフォームの構造がよくなったのが成功の直接の原因ではないでしょうか。それで、プラットフォーム依存部分の封じ込めに成功したのです。p-system の時代に Java が出現したとしても当時のＯＳの構造では成功しなかったのでは。
>> 実際にプラットフォーム非依存に動作する「お手本」があることがJavaの要
>> 点ではないでしょうか? その意味では、Javaのプラットフォーム「非」依存
>> はそれほど「外」していないように思います。
だから、非依存に動作する「お手本」に対して、動作しない「例外」のお手本（？）を示したかったのです。“それほど「外」していない”のは確かですが、“完全互換”ではないですよ、 p-system とたいして変わりはないですよ、ということを言いたかったのです。p-system の時代よりは格段に進歩しているのは確かですが。
従来から、p-system や C/C++ のプログラムでも、それなりのエキスパートが書いたプログラムでは、ソースの手直しなしで（再コンパイルのみで）異なるＨＷ上で動かすことができました。Java ではそれが「誰が書いたプログラムでも即座に」となるのでしょう。（性能も含めて）これが本当に実現できれば大変な成果だと思います（私は自ら体験していないので、こんな風にしか書けません）。
Java の将来について心配なことは、バイトコードとかいう命令体系を定めているらしい点です（詳しいことは知りません）。ここで命令を固定してしまっていいのでしょうか。過去の経験に照らして言えば、p-system に限らずこういうものが長続きしたことはありません。技術的な進歩をストップさせるようなものだからです。
もう一つ心配なことは、バージョンアップ対策です（Java はこれで凍結とは考えられません）。インターネットのように全世界規模で動いているシステム上で、全世界一斉バージョンアップなど不可能です。それに、自動的なバージョンアップなどされては迷惑だという人は大勢いるでしょう。どうしても個々にバージョンアップしていく体制が必要です。必ず「私は古いバージョンのソースをダウンロードしたい」という要求が出てきます。そうすると、呼び出すときオプションの指定が必要になります。なら、「私は Wintel オプションを指定したい」と言って直接実行型プログラムをダウンロードするという発想が出てくるでしょう。プラットフォーム依存でもよいから、私は性能のよい方を選びたいという訳です。
こうなると、インタプリタ型 Java は直接実行型 Java コンパイラ（？）にとって替わられ、マイナーな存在になることでしょう。
> 例えば、「駅すぱぁと」とか様々な辞書類とか。つまり、(アップデートを
> 必要とする)コンテンツに(仮の??)手足を付けたようなソフトについては、
> ネットワークから切り離された形態を考えるのは徐々に困難になるのではな
> いでしょうか?
> ワープロや表計算についても、データ共有の観点からコンテンツの形式を定
> めるテンプレートが卓越する(更新に対する自動処理も必要になるでしょう)
> ようになれば、状況は変るかも知れません。これはプログラムの自動アップ
> デートの話でもあります。実際、 MSNのクライアントソフトはホスト側に変
> 更に対応して(半)自動的にダウンロードされます。
> 要するに、コンテンツの共有(をどうやるか)が本質的な論点だと思います。
> それに応じて出てくるのが、処理主体からコンテンツ主体へのパラダイムシ
> フト(地球は大きなホスピタルぢゃなくてデータベース)であり、NCは分散ア
> ップデートのための複雑なプロトコルを実装する代わりに、単純な方式を提
> 案しているのだと思います。
ネットに繋ぐと意味のあるものは、遠慮なく繋げばよいと思います。しかし本来繋ぐ意味のない業務まで繋げて実行するというのはどんなものでしょうか。リソースの無駄遣いです。
> 永遠に事業として成立しないとすると、日本という場所が(世界あるいは東
> 芝グループから見て)不要になるだけのことだと思いますが。
少なくとも今のような高額な料金体系が続く限り私は使う気になりません（しかし使いたいというお客はいるかもしれませんよ、特に海外では。東芝にもＮＣを担当する人達がいるので当然検討していることでしょう）。
それよりも、ＮＣの発想というのはＮＣという箱を開発するハードウェア技術の進歩の方はもうこれでおしまいで、あとは伝送通信技術とかソフトウェア技術の進歩しか必要としないという前提の方がおかしくありませんか。ＮＣを最初に提案した人たちの前提は実はこういうことになると思うのです。ＮＣという「箱」を作るハードウェア技術者はこれから何をするのでしょう。Java chip を開発する人はいいでしょうが、それ以外の人達は５００＄を如何に安くするかしか役割がないのでしょうか。
どんな物でも、それを構成する各部品の技術進歩の集大成として製品が完成するのだと思います。ある特定の分野は技術進歩をストップさせ、それ以外の自分に都合のよい分野のみ技術進歩するという前提で製品構想を立てるというのは、どこかに問題があると考えるのが常識的な判断ではないでしょうか。
私がＮＣ開発の担当者だったら当然「箱」の技術革新をはかります。たとえば、メモリを大幅に増やし、ハードディスクのような大容量二次記憶装置を付加し、Advanced NC とか銘打って売り出します。そして当社のNCは性能がよいから（初期投資は高くつくが）通信回線使用料を大幅に削減できると宣伝します。更に、そのとき主流になっているであろうＯＳ“ Windows 00 ”（注２）を搭載したらもう万全でしょう。これを世に「パソコン」というのです。
（注２）最高機密を教えます。ビル・ゲイツは、自社のソフトウェアの命名規則に関して、西暦２０００年問題があることに全く気が付いていません。
> こういう神話って実際にあるのですか? むしろ、Javaについては、appletと
> いう実行形態を持つことから、セキュリティ上は本質的に危険なので、一生
> 懸命に穴をふさいでいるので、他の naive(脳天気)なシステムに比べれば相
> 対的に安全だという理解になっていると思います。バイトコード云々という
> のは、ランタイムのアクセスコントロールについての誤解から生じた見解だ
> と思います。
是非、「テイクダウン」（下村努 徳間書店）という本を読んでください（もう読まれたかもしれませんが）。若き日本人技術者がＦＢＩと協力して悪名高いクラッカーを追いつめるまでの実話が書いてあります。クラッカーのやっていることの実態が何となく分かりますよ（クラッカーの実力にも日米で１０年の開きがある？）。決して神話ではないことが理解できると思います。
セキュリテイーホールを見つけては潰していくという、今のようなアプローチでいいのでしょうか。対症療法のように思えますが。言語設計の根幹に関わるセキュリティー上の穴が見つかったらどうするのでしょう。私は（不眠症の上に）極度の心配症なのでしょうか。
私は、世の中が騒ぎ出すと途端に冷めてしまい、ちょっと離れて批判的になるという嫌な性分なのです。困ったことですが、一人くらいそういう人間がいてもいいでしょう。
=============================
もう、私の意見を書くのに疲れました。やっぱり「笑止千万」などと大言壮語すべきではありませんでした。反省しています。もう、終りにします。
============================================================
（終り）
［Return］
