情報技術の聖家族（批判的な批判の形での4月の論文）

警告：この記事は、鋭い論争的な方法で書かれています。 その中のほとんどすべてが非常に誇張されており、論理的および概念的な不合理さをもたらしています。一般的に、これは記事ではなく、1つの大きな詳細なレプリカです。 特に印象的な読者は、この記事を安全にスキップして、自分にとってより有益なものを見つけることができます。 しかし、突然、誰かがあなたの魂に反応し、ある種の「スタートアップ」を作成するというアイデアが生じた場合、私はこれに非常に満足します（少なくとも少しは、開発者の意識を誰もが知っている）。 そのため、私の記事をエイプリルフールの抽選とは見なしませんが、このような適格なコミュニティを好ましい方法でプレイすることは非常にうれしいです。

露出：2種類の開発者

（遠く、しかし「威勢のいい」90年代に）最初に単純なHTMLページを作成するかなり魅力的な機会に出会った開発者を想像してください。 彼は、すべてがシンプルになったと考えています。テキストを入力し、タグを貼り付けて（チームです）、結果を作業サーバー上のファイルに保存すると、ユーザーは自分が必要としているものを受け取ります。 開発者は、HTMLコードを解釈し、最初のブラウザーを作成するアプリケーションを実装するのは非常に簡単であることをすぐに認識します。 新しくないもの、結果、またはより正確には効果がここで重要です：ユーザーは特定のページをリクエストし、事前に準備されたHTMLコードを受け取り、ブラウザーはこのコードを（オブジェクトモデルに従って）解析し、最終結果が画面に表示されます。 とても印象的ですか？



開発者は、実際にはユーザーが必要とし、あらゆる種類のタグ（コマンドもあります）：斜め、太字、フォント、セクション見出し、リストなどの質問に悩まされません。 など 開発者は、リストの作成、画像の挿入、およびハイパーリンク（「すべて」の対象となるもの）の機能を導入します。 開発者が操作する世界は単純明快です。ブラウザにはウィンドウが1つしかないため、ユーザーには1つの機会しかありません。新しいページをロードして、同じ単一のブラウザウィンドウですべてを見ることができます。 そのため、ブラウザに「戻る」ボタン（およびキャンセルをキャンセルするための「進む」ボタン）、訪問の履歴、ページをブックマークする機能がブラウザに表示されました。



現実には、そのような開発者はそうではなく、ほとんどありません。彼らはそれぞれブラウザの作成に貢献するよう努めています。 いくつかのブラウザがあり、ドキュメントのコンテンツを最適に表示する方法については、さまざまな企業が互いに競合しています。 互換性の問題が前面に出ており、ページの作成者は、特定のブラウザーで表示される（または表示されない）方法と内容についてより多くのことを覚えておく必要があります。



WEBが静的である限り、賢明なことは何もできません。 あなたの製品を窓に置くことができ、美しくそこに置くことができます。 ただし、ユーザーは受動的なオブザーバーにすぎません。 一方、WEBを介してビジネスを遂行したいという要望があります。そのためには、ユーザーのアクションに応じて実行する必要があるプログラムコードをどこかに持つ必要があります。 通常の（ローカル）アプリケーションは、すべてのプログラムコードを（実行可能ファイルで）実行し、WEB上でコードを配置することはより複雑です。コードはサーバー側に配置できます（サーバーは何らかの方法でネットワーク経由でユーザーからコマンドを受信する必要があります） ）、クライアント側に配置できます（そして、このコードはもちろん、ユーザーのコンピューターでCPU時間を消費するため、ページ自体に配置する必要があります）。 この事実に気づいたことで、一方ではスクリプト言語の出現とそのような言語のインタープリターのブラウザーへの埋め込み、そして他方ではユーザー入力フォームを作成するために設計された特別なタグのHTMLでの出現に至りました。 次に、XMLが誕生し、ASP、JSON、RESTテクノロジーが登場しました...



読者によく知られている事実のリストを退屈させることはもうありませんが、どの分野でも急速に成長しているのは、ソフトウェア製品の最初のバージョンの開発者が直面する単純さにあります。 これらの幸せな開発者は、最初はシンプルで目に見えるオブジェクトを扱います。 彼らは、それがすべて後の結果になるのかまだ知りません。 それらは、実際的なタスクのフレームワークによって制限されません。 彼らの地平線は非常に狭くなっています。 しかし、同時に、技術の新規性の要素が重要な役割を果たします。 そして、この要素は技術の急速な発展を引き起こします。 これから多くのお金を稼ごうとする人もいます。 他の人は、新しい分野で多くの興味深い問題を発見し、ソリューションで非常に良い結果を達成しています。 さらに、雑誌のページでこの生命の暴動を観察し、説明しています...



別のはるかに思慮深い開発者を想像してください。 このような開発者は、次の質問を自問するでしょう。

1. WEBの従来のデスクトップアプリケーションと根本的に異なるアプリケーションとは何ですか？
2. WEBアプリケーションでの作業をサポートするソフトウェアインフラストラクチャはどうあるべきですか？
3. そして、ユーザーは本当に何を必要としますか？

そのような開発者は結論に急ぐことはなく、最初のブラウザーの作成に急ぐことはありません。 第一に、思慮深い開発者は、WEB上の通常の「デスクトップ」アプリケーションを使用できるかどうか、そして分散環境での作業方法を教えるためにアプリケーションに追加すべきことを明確に考えます。 たとえば、データ自体がリモートサーバー上にある場合、データベースアプリケーションはどうすればよいですか？ 第二に、ユーザーが特定のサイトで正しく作業できるように、オペレーティングシステム自体に何を含めるべきかを明確に考えます。 さらに、コードを「クライアント」と「サーバー」に分割する問題は、思慮深い開発者にとって本当の頭痛の種になります。開発者がパフォーマンスとセキュリティの両方の点で満足できる問題の解決策を見つけるまで、この痛みは止まりませんとアメニティ。 最後に、3番目に、思慮深い開発者は、WEB自体を最適に編成する方法、およびWEBで動作できるオペレーティングシステムをどのようにすべきかを明確に考えます。



もちろん、思慮深い開発者には何もする時間がありません。 一般的に、彼は何もする時間がありません。 行われることはすべて、多くの単純な開発者によって行われます。 そして...完了しました。



その結果、何が得られますか？ 私たちが持っているもの、それから私たちは持っています。



技術のパイがあります。



多くの非常に異なるオプションと実装方法があります。



設計には多くのアプローチがあり、一般に、サイトの設計と

データストレージの組織と相互作用の組織。



今日与えられたリンクが明日無効になると、WEBの脆弱性が生じます。



静的なページや全文検索の代わりに、あらゆる種類の動的なアプリケーションがあるため、ほとんどのWEBが見えなくなる状況があります。 同時に、検索エンジンはほとんど情報のゴミのみをクエリに返します。 ただし、WEBインフラストラクチャそのものであるため、（ほとんどの場合、必要のない情報の）情報が絶えず複製されます。 データの保存と送信のセキュリティに大きな問題があるという事実についても話をしていません。これにより、開発者が安全でない製品をリリースすることを非常に簡単に許可し、その安全性とそれらの料金を要求します！ 同時に、（ソフトウェア製品の）脆弱性を常時検出することは誰にとっても日常的なものになり、ソフトウェア開発業界のあらゆる段階のユーザーは自分のコンピューターを制御する方法がますます少なくなり、後者は「個人」ではなくなりました...



しかし！ 世界は異なる可能性があります。 なぜ彼は望んでいないのですか？ そして、私たちにとってより良いと思われる世界は何でしょうか？ そして、最も重要なことは、この他の世界は本当に「美しい」ものであり、私たちは他の「美しい世界」についての幻想で自分自身を楽しませているのでしょうか？

開発

最初から始めましょう。 ところで、これはどこから始まったのでしょうか？ ここでは、さまざまな角度から行動する必要があります。 まず、ページ自体、つまりユーザーに直接表示されるものがあります。 第二に、ページのデータソースがあります。 第三に、リクエストの形成と配信をサーバーに実行し、リクエストの結果をクライアントに配信するものがあります。 これは、一方で呼ばれるものです。 一方、これが一般的にどのように見えるかについては疑問があります。ユーザーの観点から、オペレーティングシステムの観点から、ネットワークの観点から。 問題の3番目の側面は、開発者が（実際に）すべきことと、ソフトウェア開発業界がどのように機能するかです。 最後から始めてソフトウェア開発に関する長いデマゴジーを始めるのは非常に魅力的ですが、私たちは一緒になって、それにもかかわらず、最初から始めます：すなわち、ユーザーに表示されるページ自体から。

エピソード番号1：TeX for WEB'a

構成されたテキストはブロックで構成されます。 すべてのWEBページもレイアウトの結果です。 したがって、WEBの任意のページは主にブロックで構成されます。 つまり、ページにテキストまたはより複雑なオブジェクトを表示する前に、そのブロックを作成する必要があります。 テキストを書いてドキュメントを作成するとき、どのブロックにも興味はありませんが、ドキュメントの各要素が特定のブロックにあることを事前に知っています。 ブロックは、ドキュメントの物理的な組織レベルの一部であり、ドキュメントの作成中に、特定の段落、セクション、セマンティックハイライト、リンク、脚注、式、図、グラフなどを含む論理レベルで作業します。



ブラウザが既にコンパイルされたドキュメントを受信する場合、ブラウザはブロックを受信します。これらのブロックを作成するには、レイアウトシステムを介してドキュメントのソースコードを渡す必要があります。 この場合、ブラウザはブロック自体とブロックのみを正確に受信する必要があり、すでに各ブロックがそのコンテンツを担当しています。 実際、各ブロックはデータを交換するための名前付きパイプです。 ブラウザがこれらの同じブロックでのみ動作するように制限されている場合、ブラウザは簡単に実装できます。



ブラウザーなどのアプリケーションでは、このような機能がかなり狭いと感じる人もいるかもしれませんが、考えてみると、ブラウザーが（実際に表示するだけでなく）実行すべき多くのタスクを見つけることができます。 まず、「マウス」とキーボードからのメッセージの主要な処理を提供する必要があります。 ユーザーは、（このブロックに入力のフォーカスを移して）別のブロックを選択し、たとえば、このブロックに関連付けられたコンテキストメニューを呼び出すことができる必要があります。 メニュー自体は、たとえば、ファイルとしてディスクに保存する操作（より正確には、単純または複雑な構造のドキュメントとして）またはプリンターでの印刷（プレビューありまたはなし）の操作を提供できます。次に、ブロックを制御する機能を提供する必要があります。 ブラウザがブロックのリストを受け取り、各ブロックに独自のタイプがある場合、ユーザーはサイトを「面白い写真」としてではなく、構造として表示できます。ここに段落のリスト、図のリスト、式のリスト、およびベースがありますデータ。 そしてこれは、ユーザーが非常に単純な（原始的でないとしても）ルーチンで膨大な種類のタスクを解決する機会を常に持っていることを意味します。 たとえば、特定のサイトから特定のページセットを取得し、各ページから非常に特定のオブジェクト（ブロック）を取得し、それらから1つのドキュメントを作成して...他のサイトに配置することができます。 第三に、コンテンツフィルターを適用し、同じ情報の（現時点で）希望する表示を個別に選択できる必要があります。 たとえば、フォーラムで作業する場合は、選択肢を用意する必要があります：レプリカの単一ストリームとして（単一のリンクされたドキュメントとして）フォーラムを読むか、すべてのレプリカを順番に（時系列で）調べるか、または特定の2人の参加者間の1行の会話だけを見る（それから再び線形フローになります）か、すぐに全員と全員の会話全体を見る（そしてインデントまたはレプリカの階層を表示する他の手段を使用します）; また、ウィンドウを2つの部分に分割すると便利です。1つの部分にはすべてのソースの注釈と脚注が表示され、もう1つの部分にはレプリカのみが表示されます。 。 したがって、ブラウザにはさまざまな機能がありますが、同時に、ブラウザは常にブロックのみを処理し、アプリケーションの問題を解決する責任はないことを理解する必要があります。



そしてここで、ブラウザは本質的にオペレーティングシステムとそれほど違わないという強い疑念がすぐにあります。 各ブロックは、本質的に、独自のウィンドウ機能を持つ独立したウィンドウです。 この場合、任意のオペレーティングシステムとWEBアプリケーションのユーザーインターフェイスの構築に違いはありません。 つまり、クライアント側での動作の実装では、同じユーザーインターフェイスコンポーネントが常に責任を負います。したがって、クライアント側で機能するコードの実装では、必要なものはすべてオペレーティングシステムに既にあります。 またはそれがあるはずです。 突然、このサイトを操作するために根本的に新しいものが必要な場合、この最後のケースでは、サイトでの作業を開始する前に新しいソフトウェアをダウンロードする必要がありますが、このダウンロードは他のインストールと同じですたとえば、ディスクからインストールする任意のアプリケーション。 TeXでこれがどのように起こるかを覚えておいてください：たとえば、新しいフォントを使用する場合、レイアウトを開始する前に計算が実行され（特別なMETAFONTサブルーチンを使用）、その後、新しいフォントを使用するすべてのドキュメントは既に正しく表示されます。 （フォントの例は文字どおりにのみ理解されるべきではありません。実際の状況では、「フォント」はプログラムコードとしても理解できます。フォントは、フォントのように、それぞれが固定のセマンティクスを持つ特定の論理的位置によって特定の方法で注文および配布できます）



（ただし、ここで別の質問が発生します-オペレーティングシステム自体に既に実装できないサイトで具体的にできることは何ですか？-しかし、この質問は記事の最後に残します。これは非常に重要な質問です。よく準備してください。）



上記は、単純なテキストで単純なページを作成する場合でも特定のレイヤーが必要であり、これらのレイヤーがドキュメントのコンテンツとのやり取りを直接制御することを示すことを目的としています。 一部のブロックは、ドキュメントの論理構造に対する上位構造です。 他のブロックは、機能と操作へのアクセスを担当し、ユーザーインターフェイスの最終コンポーネントによって追加する必要があります。 3番目のブロックが設計を担当します。 選択したタスクとユーザーの具体的な意図に応じて、ブロックの構成も変わります。 テキストを読むだけなら、それは1つです。 説明とヘルプを得ることができるようにしたい場合は、異なる場合があります。最後に、テキストを編集する場合は、ブロックの構成が3番目になります。 最後に、動的コンテンツを扱う場合は、...オプションが多すぎますか？

最初の余談（長い）

これまたはそのオペレーティングシステム（OS）をコンピューターにインストールすることで、何を受け取ることができるのか疑問に思ったことはありませんか？ 理論的には、「すぐに使える」作業のための「ターンキー」システムを完全に準備する必要があります。 あなたには、OSがこれに必要なすべてのツールを備えていることを期待する権利があります。 一方、実際には、別のことが起こります。最初にOSをインストールし、次に必要なアプリケーションをインストールします。 なぜこれをしているのですか？ いいえ、もちろん、あなたはそれをしなければなりません。 これには理由があります。 あなたが作家なら、将来の出版物を準備するための特別なツールが必要です。 あなたがアーティストまたはデザイナーである場合、描画または構築を自動化する特別なツールが必要です。 あなたがソフトウェア開発者である場合、コンパイラと開発環境が必要です。 すべて1つまたは別の汎用オペレーティングシステムを使用し、自分に必要なソフトウェアを選択してインストールします。 しかし... ...これを行う必要がない場合はどうなるか想像してみてください！ もちろん、私はこれを取り除くことを提案しません、それは完全に不可能です。 同じ質問を別の角度から見て、実際の問題を見ることをお勧めします。



アプリケーション自体から「抽象的」推論を始めましょう。 このような各アプリケーションは、モノリシック設計です。 「歴史的に発展した」と言うことができます。 はい、そうです。 そして今、質問を自問してください：このアプリケーションにはOS自体にはありえないものは何ですか？ 通常、各アプリケーションは特定の形式のファイルで動作するため、このアプリケーションの主な典型的な操作は、（対応する形式の）ファイルの処理です：オープン、ロード、編集、保存。 OSが操作を管理するために設計された完全なシステムである場合、一般的なファイル操作はOS自体の不可欠な部分である必要があります。 必要なアプリケーションを「インストール」することにより、実際に、特定の形式のファイルを処理する特定の方法をOSに伝え、OSは考えられるすべての形式のファイルのファイルにアクセスするための単一のユーザー（および共通ソフトウェア）インターフェイスを提供します。 実際、OSは腸内に独立してプログラムオブジェクト（「アプリケーションレベル」プログラムオブジェクトの適用タスクを解決するためのオブジェクトを任意に呼び出す）を作成する必要があります。これは、OSとこのアプリケーション間で共有されるリソースのようなものです。 プログラムオブジェクトはドキュメントとも呼ばれますが、呼び出されないため、プログラムオブジェクトの本質は変わりません。プログラムオブジェクトはアプリケーションの「内部」にあるように作成されますが、OSによって管理されます。 したがって、各アプリケーションはドキュメントファクトリであり、OSに処理中のドキュメントのフォーマットの記述（仕様）を提供し、すでにOSがユーザーインターフェイスを作成する基本機能を引き受けます。 次に、OSは各アプリケーションに独自の環境を提供します。これは、アプリケーション自体のタイプとユーザーが現在解決しているタスクによって決まります。 このアプローチにより、OSとデータベースを比較することができます。データベースでは、すべてのデータが整然と格納されており、それらへのアクセスはクエリ言語を使用して実行されます。 残念ながら、アプリケーションの「堅牢性」は、このアプローチの実装を著しく妨げます。



アプリケーションがモノリシックではないことを想像してください。 これはどういう意味ですか？ 通常の状況では、OSは起動されたアプリケーションをRAMにロードし、制御を与えます。 あなたがしたいことをしてください！ しかし、第一に、各アプリケーションは「真空中の球状の馬」ではなく、特定の問題を解決するために設計された一種のエンティティです。 この意味で、各アプリケーションは特定の「シェルフ」上のOSに「横たわる」必要があります。 OSをデータベースとして認識した場合、このデータベースには、実際には本格的なシソーラスまたは概念の登録を含む参考書「命名法」のようなものがあり、各アプリケーションはこのディレクトリの特定の位置に関連付けられます。 第二に、各アプリケーションは、相互接続され相互接続されたコンポーネントのセットとして認識される必要があり、各コンポーネントもOSによって制御される必要があります。 したがって、OSにコンポーネントの特定のプールをインストールすると、新しいアプリケーション（コンポーネントの新しい組み合わせ）を収集して、新しい問題を解決できます。 プログラムコードがいくつかのテーブルのOSに保存されている場合、適切に構造化されたクエリをプログラムコードデータベースにコンパイルし、命令の順序選択の形式で最終コードを取得することで、必要なアプリケーションを作成できます。 第三に、各「モノリシック」アプリケーションは「そのまま」（実行可能ファイルの形式またはコンパイル済みパッケージの形式で）配信され、アプリケーションからソースコードを抽出する方法がありません（これは彼の著書「ソフトウェアエンジニアリング」のSergey Tarasovもちろん、このアプリケーションの開発者がこの幸福な機会を（突然）提供しなかった場合を除き、「絶望的なプログラミング」と呼ばれる内部から）。 アプリケーションの開発がコンポーネントモデルに従って厳密に実行される場合、対象のアプリケーションで常に「ウィザード」モードに切り替え、分解し、コンポーネントレベルに移動し、必要なコンポーネントのソースを抽出し、それを修正し、変更を自動的に保存できます。新しいバージョンとして、古いバージョンと一緒に新しいバージョンを使用します。 （はい、これは基本的に、ソースコードを隠し、ハッキングに対する特別な保護を作成するという一般に受け入れられている慣行とは相反します。）



上記は非常に明確な結論に達します。OSは、異種データベース（コードデータベース、アプリケーションデータベース、およびユーザーが処理する最終データを含むユーザーデータベース）を管理するDBMSのようなものでなければなりません。 各アプリケーションは、リストされている各データベースに一定の貢献をします。実際、それ自体はデータベースのようなものです。 したがって、アプリケーションのインストール、操作、および破棄は、さまざまなデータベースで実行されるトランザクションです。 そして、ここで非常に重要な質問に行きます。ここで、このアプリケーションに固有のコードはどこにありますか？ 同じ質問の別のバージョン：このアプリケーションのソースコードは（OSの場合）どの形式で配信されるべきですか？ここでは、インストールされた各アプリケーションを宣言形式で（そして開発者が提供する）アプリケーションに最適なアプローチがあり、コンパイルがこのアプリケーションがOSにインストールされているときにのみ実行されるようにしますか？この質問に対する肯定的な回答は、いくつかの重要な結果につながります。第一に、OSは最初からすべての主要なタイプの対話である可能性があり（そうあるべきです）、典型的なタスクが実装されています。これは、OSと共にインストールされるプログラムコードは、事前に定義済みの典型的なタスクに最初に結び付けられる必要があることを意味します。第二に、典型的な操作と典型的な相互作用には、ユーザーインターフェイスを作成するためのかなり形式化され、自動化されたスキームが含まれます。そしてこれは実際、アプリケーションはすべての種類のダイアログボックスを開くことに関連する同じ機能の実装を引き受ける必要はありません。第三に、既製の宣言と作業コンポーネントがあるため、新しい宣言と新しいコンポーネントを従業員または対話者に配信することにより、新しいアプリケーションを作成できます。部分的に、それは突然本格的なOSになる1Cアプリケーションに似ています。実際、上記のすべてを簡単に説明すると、技術プラットフォームとしてのOSは特定の「構成オブジェクト」をサポートし、構成自体はユーザーデータを処理するためのモデルを記述し、ある時点で何らかのデータが使用されます（実行および機能）デスクトップの外観、使用可能な機能などを決定する1つの構成。さまざまなダイアログボックスを開くことに関連付けられています。第三に、既製の宣言と作業コンポーネントがあるため、新しい宣言と新しいコンポーネントを従業員または対話者に配信することにより、新しいアプリケーションを作成できます。部分的に、それは突然本格的なOSになる1Cアプリケーションに似ています。実際、上記のすべてを簡単に説明すると、技術プラットフォームとしてのOSは特定の「構成オブジェクト」をサポートし、構成自体はユーザーデータを処理するためのモデルを記述し、ある時点で何らかのデータが使用されます（実行および機能）デスクトップの外観、使用可能な機能などを決定する1つの構成。さまざまなダイアログボックスを開くことに関連付けられています。第三に、既製の宣言と作業コンポーネントがあるため、新しい宣言と新しいコンポーネントを従業員または対話者に配信することにより、新しいアプリケーションを作成できます。部分的に、それは突然本格的なOSになる1Cアプリケーションに似ています。実際、上記のすべてを簡単に説明すると、技術プラットフォームとしてのOSは特定の「構成オブジェクト」をサポートし、構成自体はユーザーデータを処理するためのモデルを記述し、ある時点で何らかのデータが使用されます（実行および機能）デスクトップの外観、使用可能な機能などを決定する1つの構成。新しい宣言と新しいコンポーネントを従業員または対話者に配信します。部分的に、それは突然本格的なOSになる1Cアプリケーションに似ています。実際、上記のすべてを簡単に説明すると、技術プラットフォームとしてのOSは特定の「構成オブジェクト」をサポートし、構成自体はユーザーデータを処理するためのモデルを記述し、ある時点で何らかのデータが使用されます（実行および機能）デスクトップの外観、使用可能な機能などを決定する1つの構成。新しい宣言と新しいコンポーネントを従業員または対話者に配信します。部分的に、それは突然本格的なOSになる1Cアプリケーションに似ています。実際、上記のすべてを簡単に説明すると、技術プラットフォームとしてのOSは特定の「構成オブジェクト」をサポートし、構成自体はユーザーデータを処理するためのモデルを記述し、ある時点で何らかのデータが使用されます（実行および機能）デスクトップの外観、使用可能な機能などを決定する1つの構成。技術プラットフォームとしてのOSが特定の「構成オブジェクト」をサポートしていること、構成自体がユーザーデータを処理するためのモデルを記述しており、デスクトップの外観、使用可能な機能などを決定する1つの構成が常に使用（実行および機能）されていることd。技術プラットフォームとしてのOSが特定の「構成オブジェクト」をサポートしていること、構成自体がユーザーデータを処理するためのモデルを記述しており、デスクトップの外観や使用可能な機能などを決定する1つの構成が常に使用（実行および機能）されていることd。など



...そして、ここで質問があります。これらの悪名高いコンポーネントは、WEBページに関連して以前に話したブロックに類似していますか？

エピソード2：コンポーネントアプローチ

簡単なプログラムを作成する場合、簡単な手順の形式でそれを調整します。通常、この手順のプログラムコードを注意深く読んで、それが何をするのかを理解するだけで十分です。特に書く場合、特定の（常に同じ）スタイルを遵守します。コードの一部のフラグメントには独立した重要性があることがわかり、これらのフラグメントを独立したプロシージャとして設計したいと思うかもしれません。新しい機能ブロックを作成し、それに名前を付けると、一度決定した人質になります。これがあなたのコードである場合、それは一つのことです。そして、あなたは新しい手続きを書くことができます。もう1つは、これが自分のコードではない場合、この関数のバージョンを（可能な場合）作成できるか、そうでなければ内容に満足する必要がある場合です。



手続き型のアプローチに従う限り、すべては特定のフレームワーク内に残ります。しかし、開発されたユーザーインターフェイスを使用する必要があるとすぐに、すべてが非常に複雑になります。最初に、ユーザーインターフェイスコンポーネントが表示されます。次に、コンポーネント自体にイベントがあり、これらのイベントをどこかで処理する必要があります。第三に、実際には、開発ツールで使用されるコンポーネントの構築方法に制限されます。実際、コンポーネントの出現は、コンポーネント間でコードが「ぼやけている」という事実につながります。これにより、アプリケーションのソースコードの調査が大幅に複雑になります。



ただし、ここでは大きな問題が1つあります。これについては時々話されますが、どういうわけか非常に気楽に話されます。問題は、コンポーネントとは正確に何であるか、具体的にはコンポーネントのロジックをどこで記述する必要があるかです。問題を非常に簡単に定式化すると、次のように言えます。コンポーネントからのメッセージの処理を担当するのは誰ですか？実際、これはソフトウェアアーキテクチャを構築する上で重要な問題です。任意のコンポーネントの実装には、少なくとも3つのオブジェクトが必要です。1つのオブジェクトは外部（ユーザー）インターフェースを記述し、このオブジェクトで初期イベントが発生します。 2番目のオブジェクトは、内部（ソフトウェア）インターフェースを定義し、最初のオブジェクトのイベントの一次処理を実行します。 3番目のオブジェクトは具体的なアクションを実行します。本質的にコンポーネントのロジックは3番目のオブジェクトに実装されており、コントローラーとして認識できます（MVCの用語を使用）。すぐに使用できるビジュアルコンポーネントを実装しようとするのは間違いです。たとえば、表形式の視覚コンポーネントに基づいて[実行中の] [Calendar]コンポーネントを実装しようとすることができますが、テーブルビューは単なるビューであり、カレンダーは本質的に特定の機能のセットであり、ある意味では特定のデータ型。新しいコンポーネントを作成しようとするのではなく、既存のコンポーネントをデータオブジェクトに接続（バインド）する必要があります。このアプローチでは、データコンポーネントとビジュアルコンポーネントへの内部（ソフトウェア）インターフェイスを指定するだけです。オッカムのカミソリのようなものがここで機能し、視覚的なコンポーネントのツリーが大きくなりすぎないようにします。しかし、この方法で、一般に、必ずしも視覚的ではないコンポーネントを処理できると想定されている場合、一般的なコンポーネントプログラミング方法を想定して、コンポーネントなどを使用すると、コンポーネントからアプリケーションを構築するための単一のスキームを実装できます。したがって、コンポーネントアプローチでは、一部のコンポーネントで発生するイベントを他のコンポーネントによって生成されるアクションに変換する特別なインターフェイスオブジェクトのレイヤーを常に作成する必要があります。実際、コンポーネントをチェーンでリンクすることで、大規模システムの一部を説明します。これらのコンポーネントをコンポーネント間の接続とともに記述する言語は、多くの人が考える非常に本格的なモデリング言語になります。



いくつかのプログラムコードを一連の命令として想像してください。通常の状況では、プロシージャとして設計されたこのコードは、プロセッサによって直接実行されるコードに一度コンパイルされます。特定のオブジェクトが各変数の後ろに隠れており、各操作がオーバーロードされている場合、いわば、アイドル状態でプロシージャを開始し、このプロシージャ用に構築された解析ツリーを再現できます。これは、実際のデータを使用して実際の計算を実行する前であっても、必要な構造を準備できることを意味します。言い換えると、データの実際の処理だけでなく、たとえば、イベントのプロトコルを維持したり、データをある形式から別の形式に変換したりするソフトウェアオブジェクトの追加の層が自動的にあります。ユーザーインターフェイスを管理し、特定の機能へのアクセスを制限します。この中間層がある場合は、既製のアプリケーションを使用して、ソースコードの形式で保存できます。しかし、ここで特に重要と思われるのは、厳密な手続き的アプローチを順守して、すべてのプログラムを作成する機会です。また、たとえば、いくつかのパラメータの入力を必要とする特定の計算アルゴリズムを実装する場合、これをデータ入力として設計する必要がありますが、入力自体を何らかの方法で記述しないでください：オブジェクトの中間層は、入力データと入力フィールドの必要なバインディングを実行しますまたはファイル選択ダイアログで。したがって、コンポーネントアプローチを使用すると、同じプログラムコードを再利用できます。コンテキストに応じて、このコードの結果は異なります。そして、最終（ユーザー）データの処理中に実際に実行される計算は、「中間」計算の結果として、ソースコードで指定された一般化されたアルゴリズムの代わりに、アプリケーションの現在の構成によって決定される特定の実装が定義されるため、所定の計算とは異なる場合があります

二度目の余談（それほど長くない）

適切な方法でプログラミングを「数学化」し、ある種のスカラー積を検討することは非常に魅力的です。類推の意味は、特定の空間を設定し、その中に乗算（2つのオブジェクトの相互作用）と加算（結果の連結またはマージ）を設定することです。次に、スカラー積演算は、かなり広範囲の現象を記述することができます。また、スカラー積はどこにありますか、グラム-シュミット直交化プロセスがあります。ここでは、線形独立の概念が必要です。線形に独立した「ベクトル」のシステムがあるので、正規直交システムに進むことができ、正規直交ベースのスカラー積は非常に簡単に説明されます。ソフトウェアを作成するときは、この単純さを追求する必要があります。



データの直交化とは何ですか？事実は、エンティティが状況によって異なる形で現れるということです。これは、現実世界の同じオブジェクトが、さまざまな相互作用のさまざまな役割で現れることを意味します。したがって、そのようなタイプの対話ごとに、独自のプログラムオブジェクトを作成する必要があります。ただし、そのような各オブジェクト（またはオブジェクトのクラス）は、独自の個別のコンポーネントを使用して処理されます。実際、さまざまなタイプの制御フローを作成することにより、開発者は最も一般化されたコードを作成することができます。



そして、直交化は操作にとって何を意味しますか？これは、すべての操作への便利なアクセスをいつでも整理できること、操作の種類ごとのリストを作成できること、操作用に別のデータベースを維持できることを意味します。特に重要なように、統一された方法でオブジェクトの操作をコーディングしてこのコードを作成する機会がありますプログラムコードの物理的表現の一部。FORTHを、プログラムを再帰関数のバンドルとして表現するというアイデアとともに思い出してください。関数（操作）のテーブルがある場合は...有限状態マシン（Shalytoによる）を構築することで、文字通りあらゆる問題を解決できますが、理論上、この機能はOSに構築する必要があります！

エピソード3：プログラミング言語の階層

プログラミングと複雑なドキュメントのレイアウトの比較は、非常に示唆的なものです。通常、プログラムのソースコードが最初に（何らかのプログラミング言語で）記述され、次にこのコードがターゲットマシンのコードに変換されると想定されています。 （いわゆる「バイトコード」という形式の重要な中間プレゼンテーションもありますが、これは今ではそうではありません。）



ここには2つの問題点があります。



一方では、複雑なソフトウェアはそのソースコードの形式ではなく、何らかの特別な形式で提示する必要があります。この意味で、アプリケーションのソースコードは、何らかのプログラミング言語のコードではなく、データベースのようなものでなければなりません。実際、開発環境は、高度な機能を備えた単純なソースコードエディターではなく、たとえば一種の「アカウンティング」を可能にするドキュメント指向システムである必要があります。このような環境で各アクションを特定の「アカウント」を持つ操作として認識する場合、複雑な企業システムの「プログラミング」は、特定の「アカウント」に後続の「レポート」の準備を補充することからなり、異なるタイプの「レポート」は異なるタスクに対応します（たとえば、設計されたシステムのドキュメントも一種の「レポート」と見なすことができます）。 （これに、私の意見では、結果として、大企業システムの真面目な開発者がやってくる。しかし、残念ながら、このアプローチは「当たり前」になりません。）



アプリケーションは、最初は常にプロジェクト状態にあることが重要です。つまり、プログラムコード（最終プログラミング言語）は、開発者の作業の最終結果であり、このプログラムコードの前（必要な場合にのみ）製品の実際の動作）は完全に準備でき、開発者は多くの作業を行い、最初のリリースは、同じ開発ツールに座っている顧客と請負業者が最終的に「握手」し、切望された「赤W「ボタン（例えば、呼ぶことができる、」新発売「）。これにより、ソフトウェアの作成とドキュメントのレイアウトが非常に近くなります。「ソースコード」を記述し、印刷の直前に、作成した「コード」をレイアウトシステムに渡します。もちろん、常に中間結果を確認できますが、しかし、たとえば、あるコレクションの記事を書いた場合、「ソースコード」だけをエディターに送信することがあります。



一方、手続き型アプローチと宣言型アプローチの関係については疑問が生じます。実用的な例を使わずに、「言葉で」質問の本質を説明することは困難です。あらゆる種類の宣言を非常に広く使用できる場合は、...たとえば、ネットワークを介してデータを送信するためにのみ使用します。 （この時点でXMLは作成されていませんでしたか？）。宣言のみを受け取ることにより、OSは、指定された宣言に従って、独自のコードをコンパイルできます。 （そして、それは安全でしょう！）この意味で、OSは言語の階層として認識できます。つまり、OSには翻訳者を作成するための組み込みツールが必要ですが、質問は今日のように提示されません-どの言語を選択するかプログラミング環境と開発環境、ただし反対の方法：どのプログラミング言語を作成する必要があるか、特定のタイプの問題を最適に解決するため。私はまだこれを知りませんが、関数型プログラミングはこの質問に対する答えを明らかにし、ある種の3次元メモリを作成する分野での将来の発見（同じデータを非常に多くの方法で配置でき、タスクに応じて）彼らはいわゆるのパフォーマンスの問題を解決します「レイジーコンピューティング」は、概念的に透明であり、証拠が正確であるため、非常に有望と思われます。エラーのないプログラミングに進む！3次元メモリ（タスクに応じて、同じデータを膨大な数の方法で配置できる）により、いわゆる「レイジーコンピューティング」は、概念的に透明であり、証拠に正確であるため、非常に有望と思われます。エラーのないプログラミングに進む！3次元メモリ（タスクに応じて、同じデータを膨大な数の方法で配置できる）により、いわゆる「レイジーコンピューティング」は、概念的に透明であり、証拠に正確であるため、非常に有望と思われます。エラーのないプログラミングに進む！

Reprise：何が起きているのか？

なぜすべてが起こるように起こるのですか？



まず第一に、これには経済的な説明があります。完全な多機能で安全なソリューションの詳細な検討と実装に必要な時間はありません。「今ここ」ですべてが必要です。その結果、作品の前面に最初に賭けた企業が勝者となります。ある日、特定のアクティビティを実際に自動化する製品を作成すると、将来の世代にはパンがなくなります。



「政治は集中した経済です。」したがって、その影響を時間と空間に広げるためには、ユーザーにとって自分自身の重要性を常に維持する必要があります。実際のタスクが簡単に解決される場合、何らかの方法でそれらを整理する方法がある場合、通常の操作を1回自動化し、現在のユーザーの問題を解決するためにその場でアプリケーションを設計できる場合、...ソフトウェアを開発する多くの企業が必要なのはなぜですか？



そして、「集中政治」とは何ですか？そう！科学！そして、科学は私たちに何を教えてくれますか？興味のある読者に、ハイパーリンクの元のアイデアは、あるドキュメントから別のドキュメントに切り替えることを可能にすることではなく、2つのドキュメント間に不可解なリンクを作成して、1つのドキュメントを表示しながら別のドキュメントを同時に使用できるようにすることであることを思い出してください。 。 WEB全体の変化の動的な性質を反映できるようにするには、本質的にハイパーリンクが必要です。つまり、1つのドキュメントを開くと、関心のある主題に関連する情報を自動的にアップロードできます。ある種の成果（JSONおよびREST）として最近報告されたものは、当初は分散データストレージのテクノロジー全体の基盤になりました。しかし、この情報の「楽園」を実現するには、理解する必要がありますそれ：第一に、WEBは大規模な分散ナレッジベースである必要があります（つまり、アイデアは階層型分散セマンティックデータベースに基づいており、通常のリレーショナルデータベースは名誉あるが、それでも下位の「中級」 「位置」;第二に、このシステムが機能するためには、トラフィックを最小限に抑える必要はありません（通常行われます）が、データの絶え間ない交換を確立するために、それを定期的にします（つまり、特にDDoS攻撃ができないことを意味します。そのため、「特定のページをリクエストすると、特定の情報のみをリクエストすることが可能になります）;第三に、WEBユーザーの場合、各ページに編集の履歴がある大きなウィキペディアとして表示される必要があります。いつでもディスカッションを作成したり、編集に参加したりできます。一言で言えば、このようなWEBは、「壊れた」リンクが存在しない、ユーザーが文書を扱う、各文書に独自の履歴などがある現実の世界に似ています。などはい、はい。「悪くない」を夢見ていますか？

コーダ：まだ始まったばかり

なぜこの記事を書いたのですか？



まず、自分の考えを少し整理して、それらを首尾一貫した方法で提示することにしました。一貫して失敗したと述べた。非難する。いくつかの異なる物語やエピソードが判明しました。理論的には、ここで、この記事では、私の熱狂的な想像に出会った氷山を連想させ、かなりまともな記事のいくつかの空白が埋められ、一般的に言えば、Habrahabrでここに書くべきです。



第二に、私は自分自身の興味の輪を自分自身のために概説しようとし、自分の検索の領域を自分のために決定しました。コンポーネントアプローチ（開発する必要があります！）に基づいて柔軟なソフトウェアシステムを開発することは、私にとって非常に興味深いでしょう。一般化されたプログラミングを実装し、プログラミングにおける手続き型と宣言型の原則の比率の魅力的な問題を解決する非標準的な方法を探します。



第三に、...そしておそらくすべてがすでにそこにあるのでしょうか？すべてがすでに発明されていますか？必要なものはすべてすでに存在していますか？さて、それから私は他の人からそれについて聞いて喜んでいるでしょう、そして私はすぐに本当の問題に対処することができます。そして、私を信じてください、私がこの道で何をしたかについて書く多くの理由があるでしょう...



かつて言われたように、「あなたがどのように一生懸命働いているかについて話すのではなく、達成したことについてもっと教えてください。」