人口知能と人間の深層心理

この前行われた電脳王戦（コンピュータ対人間）を特集したNHKの科学番組を見た。
まず、面白かったのは、コンピュータを開発した人は、ほとんど将棋を知らない人だった。
では、この人は何を開発したのか、
それは、データ検索方法だった。
そのデータ検索は滅茶苦茶ユニークで、対戦戦局の盤から勝利の比率（数字）を導きだものだった。

・・・

将棋盤は碁盤の目になっている。要は将棋盤はx軸とY軸で出来ている、つまり2Dだ。
ここから、ある特定の駒を結びつけポリゴン化し、その面積で勝利の手を導きだす。
>
・・・

この方法を聞いていた将棋関係者のコメントが面白かった。
「もしかすると、プロ棋士もこの方法を無意識に行っているのでしょう」

・・・

私は30年前、エキパートシステムに携わっていたとき、人間の無意識つまり人間の深層心理を見出せれば、最高の人口知能ができると確信していた。
そして、人間の深層心理は、ビッグデータの中に隠されているはずだ。

FierFox(日本は仏作り魂入れず)

'96年日経パソコン（夏合併号）に「Netscape　ブラウザーがOSに変わる」という記事があります。

当時、OS製造を手がけたことがある私は、「Windod95でも凄いのに、Windod95上で動くブラウザーがOSになるわけがない」、と苦笑したことを記憶しています。（記事ではJavaScriptよりJava　Appletを重視している） あれから約18年、「ブラウザーはOSである」と言っても、誰も笑う人はいません。当時、ブラウザーがここまで発展するとは私は想像も出来ませんでした。

NetscapeはマイクロソフトのIEに敗れ去りましたが、技術はFierFoxに引き継がれました。そして、スマートホーンのOSとして再び表舞台に登場しようとしています。

もし、Netscapeが日本で誕生し、IEに敗れ去っていたらここまでブラウザーは発展しなかったでしょう。本当の資本主義とは、捨てる神あり、拾う神ありの世界であり、将来を見越した資本家が存在する社会だ、と思いました。 反面、日本の資本主義は単なる西洋のコピー（仏作り魂入れず）でしかない、とブラウザーの発展を見てきた私は思います。

日本も早く、目先の利益だけでなく、本当に消費者が欲する製品を作ってほしい。

タスク

タスクは死語?

私がプログラマーになったとき一番最初に教わったのがタスクだった。だが、タスクの概念を理解すまでに数年かかった。新人にも一応タスクの説明をするが、納得することはなく、首をかしげるだけだ。そんな時いつも「タスク人だ。いつか理解できる」と言ってお茶を濁した。
メインフレームが無くなったと同時にタスクも無くなった。小型のコンピュータでは、タスクに変わりシェルもしくプロセスとなった。だが、タスクとシェル，プロセスは構造が違う。Linuxで初めてプロセスに出会ったとき、目が点になった。fork,exec実にユニークだ。

私が関わったタスクは以下のような構造になっている。メインフレームでは、基本的なメモリーはどのタスクからも参照できた。ただし、リングレベルが7つあり、メモリーは完全に保護されていた。
仕事をしてもらうタスクにはイベントを渡し、目的の仕事を実現してもらう。完了通知はスリープで待つか、イベントで待つかタスクにより違った。
Javaが普及してきて、マルチスレッド が普通に使えるようになった。私はこのスレッドをタスク代わりによく使う。

デフォルトモードネットワーク

デフォルトモードネットワークはコンピュータ用語ではない。脳科学の言葉だ。ここでは、デフォルトモードネットワークを話題にしていない。
先日NHKの科学番組で、このデフォルトモードネットワークを特集していた。その時、番組のＭＣと脳科学者が会話していたが、その会話の中に、懐かしきことば「タスク」が頻繁に出てきた。どうも、脳科学の世界では、「タスク」という言葉は死語にはなっていないようだった。「タスク」について説明はなかったが、話の内容から、「脳」の機能をつかさどる部位のことを言っているようだった。そこで、私が知っているタスクを人間の脳に当てはめてみることにした。

どうも、人間の脳の構造は以下のようになっているようだ。

上記脳の構造に私の知っていタスクにかってに置き換えてみる。

タスクディスパッチャーはアイドルループ中に、イベント通意及びMakeUpを行う。赤矢印は、その際タスクをサーチする為のリスト構造だ。
たぶん、人間の脳の構造をシェル，プロセスでは、説明できないだろう。イベントをターゲットに動くタスクだからこそ、人間の脳の構造を説明できるはずだ。（私は脳科学者でないでの、単なる憶測でしかない）

ないとは思うが、もし誰かが私にタスクのことを聞いてきたら、人間の脳をモデルに説明しようと思う。

情報技術者の生産物

50過ぎてプログラマーとして再就職する為、地元では大手のソフトウェア会社の面接を受けたことがある。(当然再就職はできず）

この時、面接官に「当社は、ベースのプログラムを修正することにより、生産性を向上させている」」旨の話をした。

チョイ待て、ここではまだプログラムをグラム売りしているのか。

・・・

私はプログラマになった当初から、情報技術者の生産物は「情報」だ、言い聞かされてきた。そして、私も新人に同じことを言ってきた。その時、だいたい同じ例え話をした。

・・・

地元の旧家のしきたりとして、毎日の天気を記録してきた。この記録は数百年にも及ぶ。この記録と他の気象情報から、地元の天気をピンポイントで予想できる ようになった。だが、この天気予測は単なるデータでしかない。しかし、この天気予測データをお金を出してでも欲しい人がいるはずだ。たとえば、イベント目 当ての弁当屋さん。この人にとって天気予想はデータではなく情報になる。つまり、金になるデータが情報だ。

・・・

私の考え方は間違っていない、情報技術者の生産物はプログラムなんかじゃない、「情報」だ。その証明を、「Google」が立証している。

オブジェクト指向について その4

データを構築するオブジェクト指向は簡単

「アルゴリズムとデータ構造」によると基本的なデータ構造は、配列、連結リスト、木構造がある。このデータ構造を操作することを、アルゴリズムと言っている。オブジェクト指向が一般化する以前は、データ構造をプログラマーが好きなアルゴリズムを使用し、操作していた。でも、これでは、冗長処理いたるところに発生し、この冗長にバグが多数組み込まれ、苦労していた。
しかし、オブジェクト指向では、このアルゴリズムをテンプレート(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も同じだ。使って使って慣れるしかない。

オブジェクト指向について その3

オブジェクト指向(VM)登場以前

オブジェクト指向(VM)登場以前のアプリケションプログラム作りは以下のようになっていた。

1. コーデング
2. コンパイル
3. リンク
4. RUN

上記手順で気になるのはリンクだ。要は、ハードウェアーなどへのアクセスはプラットホームが準備しているライブラリィを使用することになる。概念的には、桃太郎が、猿、犬、きじを引き連れて鬼が島に鬼退治に行くようなものだ。
現実問題として、猿、犬、きじは、あまり技を持ち合わしていないので、桃太郎が勇敢でも、百戦錬磨とは行かないだろう。

オブジェクト指向(VM)登場後

オブジェクト指向(VM)登場後のアプリケションプログラム作りにはリンクは不要だ。前もって、VMが準備しているオブジェクトを使えばいいし、もしオブジェクトに機能が足りないでのあれば、ポリモーフィズムにて、プロパティやメソッドを変更もしくは追加すればいい。
概念的に言えば、VMであるガンダムに、アムロが乗り、ジオンと戦うことに等しい。その結果、アムロは、シャーが嫉妬するくらい成果を上げた。
もしかすると、桃太郎も、猿、犬、きじ、に頼るのではなく、VMというロボットに乗り込み、鬼退治をおこなったら、百戦錬磨だったかもしれない。

オブジェクト指向について その２

'90年初頭まで

90年初頭までのソフトウェアの作りは何処も同じだった。アプリケーションはCOBOLを筆頭に、逐次処理の世界だった。逐次処理は、理解するのも早いからだれでもプログラマーになれた。反面、ＯＳやデータベースなどのシステムプログラムは、このアプリケーションの逐次処理を支えるため、複雑になっていた。
でも、当時、日本のコンピュータは世界に通用していた。そして、自分自身、自分が製造に携わったメインフレームに引け目を感じたことはなかった。

ゼロ戦

ゼロ戦は、設計も優れているが、それに加え、この戦闘機を製造した大勢の優秀な工員がいたから、欧米に負けない戦闘機ができた。当時のメインフレームも、大勢の優秀なプログラマに支えられていたから、日本製のコンピュータは欧米に負けていなかった。

グラマン・ヘルキャット

対戦当初、ゼロ戦に負けていた米国海軍は、グラマンに対して、「ゼロ戦より早く、持続力があり、旋回能力があり、多くの爆弾が搭載できるような戦闘機」を要求した。その要求に対して、グラマンの技術者が出した回答がターボチャージャーだった。
私はこのターボチャージャーがソフトウェアーにおけるオブジェクト指向だと思っている。

　

仕組みよりメリット

車を運転する人がターボチャージャーの詳細な仕組みを知っているだろうか？でも、ターボチャージャー付の車のメリットは誰でも答えられるはずだ。オブジェクト指向も同じだ。まず、オブジェクト指向を使って、なれて、メリットを知るべきだ。
昨今、オブジェクト指向がなくなるような記事を専門誌で読んだことがあるが、私の主観としてありえない話だ。cやLISPのような関数型言語と、JavaScriptの関数は違う、なぜなら、JavaScriptの関数はオブジェクト（私はこの概念を使いこなす為に多くの時間を費やした）だからだ。今のコンピュータの世界は、オブジェクト指向は深く浸透し、いまさらオブジェクト指向を語る必要ながくなっている。