未来のMira気楼

2008年初頭、州下院議員の提出により、国家OSを作成する必要性についてインターネット上で議論が行われました。 Ruslan Bogatyrevのリーダーシップの下にイニシアチブグループが登場しました（すべてのデルフィストは彼を覚えておくべきであり、彼はPascalについて多くのことを書きました）。 私はいくつかの手紙をルスランと交換し、そこで私の考えのいくつかを表現しようとしました。 残念なことに、内部の組織的矛盾のためにRuslanが説明したように、プロジェクトは行き詰まりました。今日、それがどのような状態なのかわかりませんが、私たちの通信の一部を公開することで議論を再開することにしました。





Ruslanは彼のブログ投稿No. 30で、Turchinのメタシステムの理論について話しました。 OSとプログラミング言語の両方の設計において優れたツールとして機能するように思えます。 私が理解しているように、その重要なポイントの1つは、特定のシステムの複雑性レベルの定性的な跳躍の間に発生するメタシステムの移行の概念です。 そのようなメタ遷移の存在に関して、コンピューター、OS、およびプログラミング言語の進化を考慮することが可能です。

明確にするために、特に多くの人がこのアナロジーを使用しているため、コンピューターシステムとライブシステムのアナロジーを使用します。 次に、コンピューターの利用可能なハードウェアリソースは、たとえば、プログラムの寿命が発生する主要なバイオブロスを表します。 機械コードとアセンブラの最初のプログラムは、最初の単細胞生物として機能します。 それらの機能は、基本的な計算操作を実行し、メモリセルを操作することによって制限されます。 「単細胞」は環境などから「アミノ酸」を摂取します。



このような「単細胞」の複雑さが増すにつれて、最初のメタ遷移が発生します。 プログラムは高水準言語で書き始めます。 言語構造のシェルの下に多くの基本操作を隠すツール。 これが「多細胞生物」の出現です。 ハードウェアはオペレーティングシステムから切り離され始めます。 つまり プログラムの「栄養培地」もより複雑になっています。これらは、CPUコマンドやメモリセルの操作ではなく、OSへのメモリの割り当てまたは三角法計算の要求です。 そのため、最初のメタ遷移は、ハードウェアデバイスの小さな詳細を隠すが、実行されるアクションの正確で詳細な説明を必要とする命令型言語とOSの出現です。 つまり 言語がより複雑になったとしても、メモリ領域などの小さなエンティティを処理する必要があります。



なぜ命令型言語のみを強調するのですか。 私の意見では、機能的および論理的プログラミングの出現は、言語レベルの新しいメタトランジションです。 関数型言語では、プログラムはメモリ領域と計算操作ではなく、システム状態とそれを変更するためのアクションでは動作しません。 また、論理言語では、計算も「隠されています」。 つまり 私の意見では、関数型言語はメタ遷移の結果として命令型に置き換えられるべきであり、それらは論理型に置き換えられるでしょう。 しかし、メタ遷移は、システム全体がその準備ができており、OSのハードウェア機能と組織が準備ができていない場合にのみ可能です。

複雑なシステムと同様に、プログラミングではさまざまなレベルの制御が区別され、さまざまなメタ遷移が発生します。 機能的および論理的な方法がプログラムプロセスの組織化におけるメタ遷移と見なすことができる場合、構造プログラミングの出現はサブシステムの組織化とその相互作用におけるメタ遷移でした。 モジュールおよびオブジェクトプログラミングは、サブシステムの編成における次の移行です。 さらに、この観点からは、それらはほぼ同等です。 ただし、オブジェクトアプローチを別のメタ遷移として使用することもできます。 彼はサブシステムの複雑さを増すための新しいメカニズム-継承を追加しました。 しかし、ここでの問題は、継承によりマルチレベルシステムを増やし、サブシステムをより多く組織できるが、新しいサブシステムに新しいレベルの制御が追加されないという事実によって複雑になります。 つまり、大まかに言って、プログラムレベルでは、「Entity.Method（）」構成は変更されず、このエンティティの下に隠れているもの（モジュール、親オブジェクト、または子孫）に違いはありません。

より可能性が高いのは、継承ではなく、多型がメタ遷移の役割を主張できることです。 次のように、プログラム管理を簡素化できます。 特定のメソッドへの呼び出しをディスパッチするデザインの数を減らすことができます。 さらに、ポリモーフィズムの内部構造を考慮すると、SmallTalkスタイルの動的ポリモーフィズムがこれに最適です。 A.I.教授が提案した興味深いオプションをここで言及するのが適切です。 シベリア連邦大学のLegalov（彼からこのアイデアを見ました）。 彼は、オブジェクトからではなくメソッドからポリモーフィズムを構築することを提案しました。 つまり、そのバージョンでは、「Method。Essence（）」の構築が判明しました。

なぜこのアプローチは私にとってより有望に見えるのですか？ 可能なエンティティの数は無制限にすることができます。 さまざまなソフトウェアオブジェクトを作成するという私たちの想像力は、そのようなシステムを制御し続ける能力によってのみ制限されます。 また、システムに新しいエンティティを導入する場合、それらが継承に適合せず、型制御を渡さない場合は、新しい制御構造を追加する必要があります。 オブジェクトに対する合理的なアクションの数ははるかに少なく、特定の制御スキームを開発したため、既存および新規に作成されたすべてのエンティティに適用できます。



それでは、プログラム生物からしばらく脱線して、OS環境に戻りましょう。 メモリセルとプロセッサリソースからのアミノ酸のプライマリブイヨンをAPIセットの形式で一種の植生に組織化したため、オペレーティングシステムは長い間このレベルのままでした。 唯一の重要なメタ遷移は、すべてのリソースをファイルとして表現するUNIXのような統一の出現と、読み取り/書き込み操作への多くのオペレーティングシステムアクションの削減としか言えません。 UNIXモデルの人気の誘因となったのは、コンピューターリソース管理におけるこのようなメタ遷移の存在でした。 そして、Windowsに対するLinuxの利点について語ることができないのは、まさに組織と管理の質的な違いの欠如です。これらは同じタイプのシステムです。



ただし、プログラミング言語でのオブジェクトモデルの開発により、OSでそのサービスをオブジェクトのセットとして表す新しいメタ遷移が発生するはずでした。 AppleのOpenDocアーキテクチャやBeOSシステムなどのプロジェクトの出現につながったプログラミング言語の組織レベルとOS組織をラインアップするために、このような移行が必要でした。 実際、Javaおよび.NETプラットフォームが成功したのは、環境のすべてのリソースを一連の高レベルオブジェクトの形で表すことにより、組織に質的な飛躍が存在するためです。 つまり オブジェクトの動物相がAPIフローラに登場したと言えます。 「生物プログラム」（OO言語で作成された複雑な生物、つまり「脳」、「胃」、「手足」などの複雑なサブシステムで構成される）は、他の生物間で生き残り、機能しようとする興味深い画像でした。他のOSプログラムとリソース。 すべての素晴らしさと多様性の動物の世界。



もう一つの「平行」な外観を作りましょう。 プログラミング言語とOSデバイスの複雑さを制御するためにメタ遷移が実行された場合、量的側面との戦い、つまり 文書、プログラム、ソースバージョンなどの数で、一般的なメタ遷移は1つだけで、階層ファイルシステムの発明でした。 残念ながら、バージョン管理システムのようなプログラムは、専門家の狭い範囲を超えていませんでした。 また、データベースベースのストレージシステムを作成しようとするMicrosoftの試みは、情報単位の数を管理する際のメタ遷移を垣間見るだけです。



それで、私たちは何をしますか？

ハイライトしたメタ遷移は次のとおりです。

• 言語（コンピューター操作制御）：命令型機能論理。
• 言語（プログラムの複雑さの管理）：構造プログラミングはモジュール化されたオブジェクトです。
• OS：オブジェクトのAPIセットのセット。

そして今、私は自分自身に次の定理を定式化することを許可します：

新しいシステムの成功は、古いシステムと比較して新しいメタ遷移が存在する場合にのみ可能です！



しかし、そのような移行が行われる品質のために、追加の長い反射が必要です...



再びTurchinの理論に戻って、メタ遷移は複雑なシステムでの制御の単純化によって特徴付けられることを思い出してみましょう。 これは、情報ロードを次のレベルに減らすために、以前の各レベルが一般的なデータストリームから主要なパラメーターのみを分離するサイバネティックシステムの組織に関するスタッフォードベアーのアイデアをある程度反映しています。 つまり、開発の主な動機は複雑さとの闘いです！ そして、メタトランジションはこの戦いにおける成功した解決策です。 したがって、開発目標を決定するには、開発中のシステムの新しい品質を得るために単純化する必要がある複雑さのレベルを識別する必要があります。



これらの考慮事項に基づいて、私はあえて次の論文を定式化することを敢えてします。



OSの複雑さ（カーネル）：

1. 異なる機器への転送を簡素化するためのハードウェアプラットフォームからの抽象化。
2. 使用可能なリソース（メモリ、プロセッサ時間など）の効果的な配布と使用。 おそらくこれらのリソースの動的な変化のコンテキストで。
3. プロセスの実装および相互作用の組織。 1つのプロセッサでの並列操作または複数のプロセッサでの並列化。 並列操作機器の相互作用。 ネットワークノード間のプロセスの分散。
4. 共有ライブラリーの編成。
5. 使用されるライブラリのバージョン管理。 おそらく、異なるバージョンのライブラリを共有します。
6. 動作中のモジュールの動的な再起動。
7. ソフトウェアおよびハードウェアエラーの処理。
8. （OSプラン9で行われているように）単一の使用パラダイムに適合するアプリケーションインターフェイスの最低限必要なセットを提供します。

プログラミング言語の複雑さ：

1. コンピューティングの組織。 これには、式、制御フロー制御、並列実行、例外処理などが含まれます。 つまり 仕事の側面のみを「数える」。 これには、プラットフォームに最適化されたコードをより簡単に取得する手段としての入力も含まれます。
2. 定義の観点からのコードの再利用（つまり、そのようなコードがプログラムでどのように作成されるか）。 これらは、関数とプロシージャ、モジュールとオブジェクト、継承、テンプレート、名前空間などです。 入力だけでなく、インターフェイスの一貫性を確保するためのツールとして。 つまり プログラムの異なる場所で同じ命令を繰り返し繰り返す代わりに、それらを1つの場所に置いて1回書き留めることができるすべてのメカニズム。
3. 実装の観点からのコードの再利用（つまり、そのようなコードを呼び出すためのランタイムメカニズム）。 ここでは、プロシージャを呼び出し、メッセージを送信し、一方でそのようなコードにデータを転送します（つまり、実際のパラメータをプロシージャに転送するか、別のノードで動作する可能性のある別のプロセスにデータを転送します）。 また、単一のアルゴリズムを異なるデータに適用するメカニズムとしてのポリモーフィズム。
4. 使用されるタイプとデータ構造の説明。 一方で、それは記憶の「構造化」です。 そしてもう一方-理想的な効果的なアクセスメカニズムの実装-均一、すなわち データ操作の多態性を保証します。

OSの複雑さ（ユーザーインターフェイス）：

1. データストレージを整理するためのモデル。 これは、OSの最初のタスクの1つでした。 まず第一に、これらは何らかのDBMSに移行する将来のファイルシステムです。
2. 現代のオペレーティングシステムでは完全に解決されていませんが、私の意見では、ユーザーデータのマルチバージョン管理と、その変更の履歴と関係の追跡という非常に緊急の問題です。 たとえば、「Life Line」などのシステムのOSへの統合。
3. OSとのユーザーインタラクションのメカニズム。 コマンドラインからグラフィカルインターフェースまで。 パラダイム「モデル-ビュー-コントローラー」のフレームワークでこの側面を考慮すると、すべての「アウトストリーム」は「ビュー」であり、すべての「インストリーム」は「コントローラー」です。 理想的には、OS自体がプログラムを使用される「view-controller」バンドルに適合させる必要があります。 同じプログラムをテキスト端末、フルサイズのPCモニター、スマートフォンのディスプレイで使用できます。

うーん、このように、最初の近似として...それは私が何かを見逃したということである可能性が非常に高いかもしれませんが、ここでは側面から見ずに行うことは困難です。

たぶん、提起された質問は誰かにとって興味深いものであり、彼は議論を続けたいですか？