AUTHOR: schwarz1009
TITLE: カーネルやコンパイラをどうしたら短く書けるか
BASENAME: 2020/12/27/202543
STATUS: Publish
ALLOW COMMENTS: 1
CONVERT BREAKS: 0
DATE: 12/27/2020 20:25:43
CATEGORY: CPU・メモリ・カーネル
CATEGORY: プログラミング
僕は、カーネルやコンパイラをどうやったら短く書けるかを考えている。
最近のプログラミング言語は、
「データと手続きをクラスに詰め込む」のように、
多くが、データと手続きを同じものにして、
データの中に手続きがあるかのような考え方をしているが、
むしろ、「データと手続きをより分離する」ようにしたらどうだろうか。
たとえば、プログラムにおけるデータは全てどこかに移してしまって、
具体的なコードは全て部品化されたものを使い、
主に書くのは「抽象ステートメント」というべき「単なる数行のコード」とする。
リファクタリングが必要ないくらい、抽象化された小さなコードが可能となる。
すなわち、フレームワークと同じように、枠組みだけを記述する。
ひとつの枠組みのもとにコードを書くというよりは、
たくさんの小さな部品があって、それの大まかな枠組みを書くことで、
プログラミングを行うのである。
僕が思ったのは、
「Rubyの機能をカーネルに使えないか」ということである。
Rubyのモジュールやオブジェクトを使うことで、
なんとなく、良いものは作れそうである。
しかしながら、Rubyは動的なインタープリタであるため、
そのままではカーネルに使えない。
最低限のRubyの機能を持った独自のコンパイル言語を作る必要がある。
上手く設計すれば、
ウィンドウシステムも、デスクトップ環境も、ブラウザも、オフィスイートも、
全て、短く書けるはずである。
もっとも短く、同時に実用的なOSと操作環境を作れないかと少し考えた。
そう、データとステートメントは、
本来まったく違うものではないかと僕は思う。
データは開く、読む、書く、閉じるでデータをCRUD操作するものであり、
ステートメントは上から下へと順序実行されるものである。
歴史と記憶を同じものにするのはおかしい。
データからステートメントを排除し、
ステートメントからデータを排除する。
その方向で、上手く全体をデザインすることができないかと思う。
むしろ、統一すべきはデータとメソッドではなく、
むしろイベントではないかと思う。
イベントとはすなわち、
「関数を呼び出したタイミングでコードが実行される」ということ全般である。
さまざまなイベントがまずあり、
その上でデータとステートメントがあるのである。
中心に置くべきは「イベントの発火とその時起きる現象」であり、
歴史や記憶はその後に現れるべきものである。
僕は、データの中に手続きを書くのが、
気持ちが悪いのである。
むしろ、グローバル変数とオブジェクト指向は、程度が変わらない。
グローバル変数を個別にインスタンス化し、
グローバル変数にアクセスできるメソッドをfriendするのと同じである。
より素晴らしいデザインとは、
全ての全体像がまずあって、
そこからイベントが発火され、
イベントに応じてコードが実行され、
そのイベントがデータであり、メモリやファイルであり、
同時に実行されるコードであるかのようなシステムである。
しかしながら、これはまだ賢いデザインとは言えない。
なぜなら、関数をイベントと言っているだけにすぎない。
しかしながら、データを共有されるものであるとするなら、
「データ共有プール」がまずあって、
そのデータにアクセスできるコードをあらかじめ書いておいて、
そのコードを使ってさらにプログラムを書く、
という、言ってしまえば
「オブジェクト指向全体主義」のようなシステムにすることで、
全体は綺麗になるだろう。
しかしながら、こうした場合、自由度は無くなるだろう。
ソ連の計画経済が自由度がなくなって破綻するのと同じで、
このシステムはすぐに破綻するだろう。
そして、僕が考えるのは、メッセージを使う方法であり、
これは「リクエストすればレスポンスが返ってくる」という
メッセージの性質を使うものである。
すなわち、システムマネージャにイベントを発火するリクエストを要求し、
それがデータ共有プールにアクセスし、
いろいろとコードを実行した上で、レスポンスを返す、
これら全てを「メッセージ」として実現する。
ここで、僕はマルチタスクを導入する。
すなわち、イベント全てが並列で動くようにし、
メッセージすべてはパケットがデータ回線を伝わるように、
キューとして実現する。
全てのイベントは並列で動き、
メッセージキューは常に生成・削除され、送受信される。
こうすれば、ネットワーク化された分散環境を作ることもできる。
僕は、データを必ずしもインターフェースのユーザーから隠蔽する必要はない。
なぜなら、たとえばOSI参照モデルでは、
データを隠蔽するモデルではなく、
ヘッダやテイルを付加・除去するモデルを取っている。
たとえば、ウィンドウシステムのウィンドウを使うのに、
クライアント側にサーバ側がシステムを隠蔽するのではなく、
サーバ側が与えるリソース全てを隠蔽せず自由に公開することはできる。
ここでOSIのようなリファレンス型の階層型アーキテクチャを取ることはできる。
ウィンドウシステム層の上にツールキット層があり、
ツールキット層の上にアプリケーション層があり、
それらにヘッダやテイルを付加することで、各層でデータのやり取りを行えばいい。
ただし、前述したモデルは上手くいかないだろう。
より基本的なモデルは、
まず、ウィンドウシステムサーバーがグラフィックス画面を描画領域として与え、
同時にツールキットサーバーがツールキット部品を与え、
アプリケーションがその使用方法と実行されるコード部品を与え、
それらを統合してアプリケーションを動作させる
「マネージャ」が中央管理をするモデルである。
そのマネージャがOSとなる。
ここでは、まるでアプリケーションがサーバーであり、OSはクライアントだが、
実際、OSはむしろクライアントであるべきである。
なぜなら、むしろGUIを表示するUI画面こそが、
クライアントであるべきではないかと思う。
むしろ、本当はGUIのUI画面すら、サーバーであるべきである。
全て、サーバーであるべきであり、
サーバーとは要するに「機能を提供するもの」であり、
その機能について操作を行う
「ユーザーが主体となる使い手」になるべきだからである。
アプリケーションは明らかにサーバーであるべきである。
なぜなら、それはおかしなことではない。
ウィンドウシステムサーバーとツールキットサーバーを使う、
クライアントであるアプリケーションは、
ユーザーから見ればサーバーである。
よって、アプリケーションサーバーに対する「画面端末」が
最終的なクライアントとなる。
また、プロセスとスレッドに区別は必要ない。
全てのプロセスがスレッドを通じて実装されるべきである。
なんだかマイクロカーネルのようになってきたが、
まあ、Machがどうしても動かない理由がよく分かる。
セイト先生に感謝を申し上げます。
僕が見たのは以下の動画。
https://www.youtube.com/watch?v=vMjSC4TQa6c
この動画を見て、いつまでも本ばかり読んでいても意味がない、
ということが分かった。
まさに、「作れ」ということです。
何か、作ってみよう。
考えても読んでも書いても意味がない。
プログラミングをするためには「作る」ことが一番だと
僕もようやく悟ることができました。
ちなみに、以下の動画も見ました。
https://www.youtube.com/watch?v=BOrx1GEZY4o
6割ぐらい理解できていることを、
もっと詳しくやろうと思っていましたが、
むしろ、6割のままで何かを作った方が良い、
ということが分かってよかったです。