この前行われた電脳王戦（コンピュータ対人間）を特集したNHKの科学番組を見た。
まず、面白かったのは、コンピュータを開発した人は、ほとんど将棋を知らない人だった。
では、この人は何を開発したのか、
それは、データ検索方法だった。
そのデータ検索は滅茶苦茶ユニークで、対戦戦局の盤から勝利の比率（数字）を導きだものだった。
・・・
将棋盤は碁盤の目になっている。要は将棋盤はx軸とY軸で出来ている、つまり2Dだ。
ここから、ある特定の駒を結びつけポリゴン化し、その面積で勝利の手を導きだす。
>
・・・
この方法を聞いていた将棋関係者のコメントが面白かった。
「もしかすると、プロ棋士もこの方法を無意識に行っているのでしょう」
・・・
私は30年前、エキパートシステムに携わっていたとき、人間の無意識つまり人間の深層心理を見出せれば、最高の人口知能ができると確信していた。
そして、人間の深層心理は、ビッグデータの中に隠されているはずだ。
'96年日経パソコン（夏合併号）に「Netscape ブラウザーがOSに変わる」という記事があります。
当時、OS製造を手がけたことがある私は、「Windod95でも凄いのに、Windod95上で動くブラウザーがOSになるわけがない」、と苦笑したことを記憶しています。（記事ではJavaScriptよりJava Appletを重視している）
あれから約18年、「ブラウザーはOSである」と言っても、誰も笑う人はいません。当時、ブラウザーがここまで発展するとは私は想像も出来ませんでした。
NetscapeはマイクロソフトのIEに敗れ去りましたが、技術はFierFoxに引き継がれました。そして、スマートホーンのOSとして再び表舞台に登場しようとしています。
もし、Netscapeが日本で誕生し、IEに敗れ去っていたらここまでブラウザーは発展しなかったでしょう。本当の資本主義とは、捨てる神あり、拾う神ありの世界であり、将来を見越した資本家が存在する社会だ、と思いました。
反面、日本の資本主義は単なる西洋のコピー（仏作り魂入れず）でしかない、とブラウザーの発展を見てきた私は思います。
日本も早く、目先の利益だけでなく、本当に消費者が欲する製品を作ってほしい。
タスクは死語?
私がプログラマーになったとき一番最初に教わったのがタスクだった。だが、タスクの概念を理解すまでに数年かかった。新人にも一応タスクの説明をするが、納得することはなく、首をかしげるだけだ。そんな時いつも「タスク人だ。いつか理解できる」と言ってお茶を濁した。
メインフレームが無くなったと同時にタスクも無くなった。小型のコンピュータでは、タスクに変わりシェルもしくプロセスとなった。だが、タスクとシェル，プロセスは構造が違う。Linuxで初めてプロセスに出会ったとき、目が点になった。fork,exec実にユニークだ。
私が関わったタスクは以下のような構造になっている。メインフレームでは、基本的なメモリーはどのタスクからも参照できた。ただし、リングレベルが7つあり、メモリーは完全に保護されていた。
仕事をしてもらうタスクにはイベントを渡し、目的の仕事を実現してもらう。完了通知はスリープで待つか、イベントで待つかタスクにより違った。
Javaが普及してきて、マルチスレッド が普通に使えるようになった。私はこのスレッドをタスク代わりによく使う。
デフォルトモードネットワーク
デフォルトモードネットワークはコンピュータ用語ではない。脳科学の言葉だ。ここでは、デフォルトモードネットワークを話題にしていない。
上記脳の構造に私の知っていタスクにかってに置き換えてみる。
タスクディスパッチャーはアイドルループ中に、イベント通意及びMakeUpを行う。赤矢印は、その際タスクをサーチする為のリスト構造だ。
たぶん、人間の脳の構造をシェル，プロセスでは、説明できないだろう。イベントをターゲットに動くタスクだからこそ、人間の脳の構造を説明できるはずだ。（私は脳科学者でないでの、単なる憶測でしかない）
ないとは思うが、もし誰かが私にタスクのことを聞いてきたら、人間の脳をモデルに説明しようと思う。
データを構築するオブジェクト指向は簡単
「アルゴリズムとデータ構造」によると基本的なデータ構造は、配列、連結リスト、木構造がある。このデータ構造を操作することを、アルゴリズムと言っている。オブジェクト指向が一般化する以前は、データ構造をプログラマーが好きなアルゴリズムを使用し、操作していた。でも、これでは、冗長処理いたるところに発生し、この冗長にバグが多数組み込まれ、苦労していた。
しかし、オブジェクト指向では、このアルゴリズムをテンプレート(Javaはフレームワークコレクション)として前もって準備してある。だから、データ構造の基本的な操作は誰でも行える。逆にアルゴリズムが、言語の奥底に隠れたため、言語が変わるとアルゴリズムが使えなくなる恐れがある。だから、アルゴリズムを示した図書を手元に置いておくと便利だ。
VMを操作するオブジェクト指向は難しい
'80年代終わりころから'90年代始めに、通信制御プログラムを引き継ぎ、中途半端だったプログラムを完成させた経験がる。通信制御プログラムは、割り込みコンテキストから成り立っている。だが、引き継いだプログラムは、逐次処理感覚で作ってありびっくりした。
VMを操作するオブジェクト指向の難しいところは、この割り込みコンテキストだ。コンテキストにはテンプレートは存在しない。だから、シーケンス図などで、相互関係を明確にし、ロック制御、排他制御を行う。もし、メモリー共用などが発生すると、問題解決まで多くの時間を費やすことになる。経験上、相互関係を全て読みきることは不可能だ。少しでも、不安があれば、安全サイドでプログラムを書いた方がいい。
又、VMはJava以外にも存在し、WANの世界では、一つのVMだけで成り経たなくなっている。したがって、現在は複数のVMを習得しておくのは必須だ。
| VM | 使用できる言語 | 備考 |
|---|---|---|
| JVM | Java(SE,EE,ME) | Appletはブラウザーではあまり使われなくなった。現在サーバーサイドで多く使用されている。現在Oracle社が提供。 |
| Flash Player | ActionScript | 現在ブラウザーで一番使われているAdobe社が提供するプラグインプログラム。videoが有名。なお、単独で動かせるAIR環境がある。 |
| .NET Framework | VB,C# | マイクロソフトが開発したアプリケーション開発、実行環境。 |
| HTML5 | HTML,CSS,JavaScript | HTML5はVMと呼んでも遜色のない環境だ。ブラウザーは複数存在する。 |
慣れるしかない
さすがのアムロも最初はエバンゲリオンを使いこさせないだろう。VMも同じだ。使って使って慣れるしかない。
オブジェクト指向(VM)登場以前
オブジェクト指向(VM)登場以前のアプリケションプログラム作りは以下のようになっていた。
上記手順で気になるのはリンクだ。要は、ハードウェアーなどへのアクセスはプラットホームが準備しているライブラリィを使用することになる。概念的には、桃太郎が、猿、犬、きじを引き連れて鬼が島に鬼退治に行くようなものだ。
現実問題として、猿、犬、きじは、あまり技を持ち合わしていないので、桃太郎が勇敢でも、百戦錬磨とは行かないだろう。
オブジェクト指向(VM)登場後
オブジェクト指向(VM)登場後のアプリケションプログラム作りにはリンクは不要だ。前もって、VMが準備しているオブジェクトを使えばいいし、もしオブジェクトに機能が足りないでのあれば、ポリモーフィズムにて、プロパティやメソッドを変更もしくは追加すればいい。
概念的に言えば、VMであるガンダムに、アムロが乗り、ジオンと戦うことに等しい。その結果、アムロは、シャーが嫉妬するくらい成果を上げた。
もしかすると、桃太郎も、猿、犬、きじ、に頼るのではなく、VMというロボットに乗り込み、鬼退治をおこなったら、百戦錬磨だったかもしれない。
'90年初頭まで
90年初頭までのソフトウェアの作りは何処も同じだった。アプリケーションはCOBOLを筆頭に、逐次処理の世界だった。逐次処理は、理解するのも早いからだれでもプログラマーになれた。反面、ＯＳやデータベースなどのシステムプログラムは、このアプリケーションの逐次処理を支えるため、複雑になっていた。
でも、当時、日本のコンピュータは世界に通用していた。そして、自分自身、自分が製造に携わったメインフレームに引け目を感じたことはなかった。
ゼロ戦
グラマン・ヘルキャット
対戦当初、ゼロ戦に負けていた米国海軍は、グラマンに対して、「ゼロ戦より早く、持続力があり、旋回能力があり、多くの爆弾が搭載できるような戦闘機」を要求した。その要求に対して、グラマンの技術者が出した回答がターボチャージャーだった。
私はこのターボチャージャーがソフトウェアーにおけるオブジェクト指向だと思っている。
仕組みよりメリット
車を運転する人がターボチャージャーの詳細な仕組みを知っているだろうか？でも、ターボチャージャー付の車のメリットは誰でも答えられるはずだ。オブジェクト指向も同じだ。まず、オブジェクト指向を使って、なれて、メリットを知るべきだ。
昨今、オブジェクト指向がなくなるような記事を専門誌で読んだことがあるが、私の主観としてありえない話だ。cやLISPのような関数型言語と、JavaScriptの関数は違う、なぜなら、JavaScriptの関数はオブジェクト（私はこの概念を使いこなす為に多くの時間を費やした）だからだ。今のコンピュータの世界は、オブジェクト指向は深く浸透し、いまさらオブジェクト指向を語る必要ながくなっている。
AI
私が初めてオブジェクト指向に出会ったのは'80年代だった。
当時データベース診断エキスパートシステムを研究所で研究員(工学博士)と二人で構築した。エキスパートシステム構築ツールは同じ研究所で構築したLISPベースのツールを使用した。ちなみにこの構築ツールの仕様書がなかったので、研究室の応接室に席を準備してもらい、ツールの使い方が判らないと、研究員を呼び出し直接聞くという方法で構築した。構築ツールは、静的知識ベース、動的知識ベースで構成されていた。動的知識ベースはif文の羅列のルールベースで、静的知識ベースがオブジェクト指向だった
私にとって、オブジェクト指向は難しい概念ではなかった。なぜなら、CODASYL仕様のデータベース、特に論理スキーマは、クラス・インスタンスの概念で作られていたので、オブジェクト指向はすぐに理解できた。「UML 2.0クイックリファレンス」クラス図の関係に説明させれている「依存」「関連」「集約」「コンポジション」「汎化」は当時から変わっていない。
ＡＩが普及しなかった理由
オブジェクト指向は簡単にデータ構造が構築でき、データとともにアクセスメソッドも設定できたので、使い勝手は良かった。でも、 オブジェクト指向には大きな欠点があった。それはオブジェクトを二次媒体に格納できないから、管理できるオブジェクトの容量は自ずと制限ができるということだ。私は当時この欠点を気づいていたので、ＡＩは普及しないと思っていた。ＯＯＰ
現代のオブジェクト指向は、オブジェクト指向の汎化の機能の一部だったポリモルフィズムをコンピュータ・アーキテクチャに組み込んだシステム(VM)になったことだ。これはJAVAが確立した技術だ。
現代のオブジェクト指向という概念を私なりに説明したいと思います。
| 期間 | 内容 | プラットホーム | 使用言語 |
|---|---|---|---|
| '75～'79 | TSS系OSの総合試験 | メインフレーム* | COBOL,BASIC,PL/I |
| '79～'82 | TSS系OS セション | メインフレーム* | システム言語 |
| '82～'86 | データベース診断システム AI |
メインフレーム* DEC MS-DOS |
COBOL,システム言語 LISP C |
| '86～'90 | OSI トランスポート層 クラス0,2 |
メインフレーム* | システム言語 |
| '95～'07 | CAD,Exel 工事費数千万～数億規模の土木設計 |
Windos | Exel VBA |
| '07～ | 閲覧者0人のWebサイト 設計、製造、メンテナンス |
ブラウザー, Windos,Linux,GAE |
Java,PHP HTML4,5 ActionScript3.0 C/C++ |
