この論文をさらに詳しく作成します。
プログラマーをホストと考えるとき、私は彼が自分でプログラムを作成することを意味します。 すべてのリソース、すべての手段（仮想的または物理的に-それは重要ではありません！）自由に、彼は彼の行動とその結果の唯一かつ最終的な判断者です。
使用人プログラマーのことを考えると、提示されたタスク仕様を知覚する通信チャネルという形で主に思われます。 仕様の正確さに対するプログラマーの責任は非常に限定されていますが、一方で、受け入れられた仕様を慎重に実装し、クライアントに製品プログラムを提供する義務を負います（1回限りのアカウントまたは永続的な使用の場合、それは重要ではありません！）
当然、この違いは多くの人に気づかれました。 F.L.Bauer [1]は、プログラマー-サーバント契約プログラミングの作業を呼び出します。 したがって、ホストプログラマプログラミングの作業を自分で呼び出すことができます。 E. Sandeval [2]は、「ターミナル」プログラマーのグループを強調して、緊密なアプローチを開発します。 この区別は、使用人とマスターをそれぞれ専門的プログラミングと非専門的プログラミングという用語を使用して行うことがあります。 このような解釈は、プログラミングとしての社会的側面、たとえば職業倫理などをアクティビティとして検討する場合に受け入れられます。 内部コンテンツを念頭に置いてプログラミングについて話すと、この場合、素人としてのホストプログラマーの見方が誤解につながる可能性があります。
サーバントプログラマは、特定の（非常に深い）意味で、顧客が何を望んでいるかを知らず、問題の定式化のみに依存しています。 もちろん、彼は文盲ではなく、対象分野について多くのことを知ることができます。 彼は仕様に多くの矛盾があることを発見することにより、顧客に貴重なサービスを提供できます。 ただし、これはすべて計画を超えています。 その主な唯一のビジネスは、仕様を信頼できる効果的な結果、つまりプログラムまたはデータに変換することです。
これは、ほとんどの作業が行われ、プログラミングの開発中に支配された種類のプログラミングです。 この作業により、プログラムの構築におけるすべてのステップが厳密に実証される可能性が生まれました。この可能性は、間違いなく、計算科学における最大の成果です。 プログラム可能なタスクの実質的な知識から抽象化する方法論の原理は非常に有益であることが判明しました。それは、基本操作と述語の解釈されていない署名でのプログラムの図式表現に基づいて、プログラムを操作し、それらについて推論するための普遍的に有効で強力な方法の開発につながりました。
ただし、プログラミングの別の形式もこの間ずっと存在していました。 しかし、プログラミングの裏庭に向かっている彼は、パーソナルコンピュータの出現と開発に関連して「第二の風」を獲得しています。 さらに、機器を搭載したキッチンのシステムプログラマーは、しばしばホストのように振る舞います。 拡張可能な言語、マクロプロセッサ、書き換えシステム、コンパイル期間の操作、ユニバーサルエディタなどの資金が、この経済にすでに蓄積されています。 しかし、この品揃えは偶然に開発されたものであり、優れた理論や信頼できる方法論によって順序付けられているわけではありません。 つい最近、集合的な用語が登場しました。この用語の下で、バナーのように、システムフリーのシステムプログラマーが集まります-プログラミング環境（プログラミング環境）、または-より広範囲に、より正確にはロシア語に-プログラムを構築するための動作環境。 このファッショナブルな使用法を、堅実な理論的正当性を持つ一貫した方法論に変えることは、80年代の理論的およびシステムプログラミングの重要かつ魅力的なタスクです。
ホストプログラマは必要なものを知っています。
これは、契約プログラミングと自己プログラミングの基本的な方法論的な違いです。 この原則は、実験用パソコンの開発者によって経験的に感じられました。彼はためらうことなく、計画よりも行動を優先しました。
J.アタルディが言ったように[3]：「見ることと行動すること、覚えて書くことではない」。 当然、厳密なアプローチの支持者はこれを異端と見なしますが、実際には、理論的な理解と精緻化を必要とするプログラミングの新しい現象です。
このノートの目的は、ホストプログラマーが働くソフトウェア環境の理論モデルのバリエーションを提示することです。 このモデルを変換マシン（TM）と呼びます。 マシンは、プログラムとデータのペアから「aデータプログラム」のペアへのさまざまな変換（変換）をサポートしています。 適切に構築されたTMは、変換されたペアの機能的不変量を保持します。 （p ′、d′）= t（p、d）、ここでtはマシンによって実行される変換である場合、p ′（d′）= p（d）。
変換マシンのもう1つの重要な特性は、プログラマー自身によって構築されることです。 その構造は階層構造であり、コンテキストのE. Sandeval、A。A. Bers、およびP. K. Leonovに従って、この階層の選択されたレベルを呼び出します。
変換されたペア（p、d）と一連の基本的な変換がコンテキストで利用でき、それぞれがペア（p、d）から別のペア（p '、d'）への基本的な（このレベルでの）変換を実行して、関数不変量を保持します。 基本的な変換は、削減、開示、変換の3つのカテゴリに分類されます。 削減は、基本的な（このレベルの）操作と述語の解釈を扱い、開示は複合構造を明らかにし、変換は本質的に組み合わせの概念です。 縮小の例としては、たとえば、ソースの場合は構造を置き換える、そうでない場合はBすべてがAまたは3 + 5で8になります。開示の例は、オープン置換によるプロシージャコールの実装です。変換の例は、メモリの再割り当てまたは一致する部分式の保存です。
何が重要ですか？
基本的な変換を自由に適用できることが重要です。 任意のシーケンスでのアプリケーションの適用は、変換されるペアの機能的不変量に違反しません。 これにより、主な問題が解決されます。プログラマーは、ミスを恐れることなく自分のやりたいことを実行できます。 これでは十分ではありません。 開示と変換による削減には、完全性という特定の特性があります。 簡約と開示の完全性により、ペアの通常の形式（p、d）を一意に見つけ、それらを基本的な変換の固定点として受け取ることができます。
ペア（p、d）の機能不変量が定数c = p（d）である場合、このペアの正規形は、完全に縮小されたプログラムとデータフィールドの計算結果を含むペア（0、c）です。 ペア（p、d）の不変式が
関数ϕ（y）の場合、（p、d）の正規形は、ソフトウェアコンポーネントに
residualの残差プログラム、およびデータコンポーネントには、引数名yおよび（おそらく）いくつかの定数と中間名が含まれます。
変換には、プログラムとそのデータの回路不変式または標準形式に関する完全性の特性もあります。
コンテキストの階層は、削減の固定点または変換の標準形式を見つけることが次のレベルのコンテキストでアトミックな行為として扱われ、コンテキストの基本的な変換が内部コンテキストによって明らかにされるという事実によって達成されます。 また、変換マシンは、型と操作の説明が開示によって実装され、簡約と変換が公理に対応する抽象データ型を実装するための便利な概念であると思われます。
コンテキストの階層が発生し、プログラマーの意志に従って構築されるという事実により、彼はコンパイル、解釈、直接計算の間の関係についてソフトウェアプロセッサを非常に微調整し、これらの区別を移動可能、柔軟、管理可能にします。
もちろん、プログラマーによって考案された変換ルールはarbitrary意的ではありません。 ソフトウェア環境モニターは、機能の依存関係、構成階層の一般的な規則、命名、制御、および情報接続に関するいくつかの知識を具体化し、維持する必要があります。 この一般的な知識により、あらゆるレベルで抽象的な不変式を維持することが可能になり、機能的不変式の保存が保証されます。
このノートで提示される考慮事項は、プログラミングへの変換アプローチに沿って元の論文を作成します。 その特異性は、プログラムを操作する方向が一般的な状況によって決定されるので、事前計画をそれほど必要としないという事実にあります。
ただし、ホストプログラマーは、自分のアプリケーションの分野をよく理解している場合にのみ、自分に与えられた行動の自由を十分に処理できます。 プログラマーは、ドライバーが広くて透明なフロントガラスを必要とするのと同じように、大きくて透明なディスプレイ画面を必要とします。 しかし、フロントガラスのリアリティ自体がドライバーの交通標識や状況に置き換わる場合、システムプログラマーにとっては、英数字ディスプレイの盲目のキャラクターをプログラムとデータのコンパクトでクリアなイメージに変えるために一生懸命努力する必要があります。 いわゆるオブジェクト指向言語によって提唱された、人間と機械の相互作用のいくつかの新しい原則に読者の注意を引きたいと思います。このオブジェクト指向言語では、最初にSmoltok言語を区別する必要があります[5]。
プログラミングの外観の精神の区別に再び戻りますが、最終的には同じデバイス（コンピューター）に依存して、両方のプログラミング形式が数学的に完全に翻訳可能であることを認識すべきです。 それにも関わらず、実用的および理論的な区別が原因となり、プログラマーの両方のカテゴリーに適切な操作手段、方法論的設定、数学的理論を提供することができます。
1.契約の履行としてのBauer FLプログラミング。 -In：「Infotechの最新レポート、シリーズ9、No.6。 システム設計。」 -Maidenhead：Pergamon Infotech、1981年、p。 167–174。
2. E.サンドウォール。 実行可能なアプリケーションモデルの開発および使用のための環境。 -In：1982年5月3〜7日、カプリ、第2回ソフトウェア技術セミナーの記録、p。 12 + 43p
3. AttardiG。オフィス情報システムの設計と実装。 -（テクニカルレポート）Cnet No.47。 Incitituto di Scienze dell'Informazione Univers。 di Pisa、Pisa、1980、44p。+ ii。
4. Ershov A.P. 混合コンピューティング：潜在的なアプリケーションと研究の課題。 -In：人工知能と体系的プログラミングの問題における数理論理学の方法。 レポートとメッセージの要約。 パート2.ナドザグで：数学とサイバネティックス研究所ANLITSSR。 ビリニュス、1980年、26〜55ページ。
5. Ingalls DH Smalltalk-76プログラミングシステム：設計と実装。 -In：1978年、プログラミング言語の原則に関する第5回ACMシンポジウムの議事録。
1982
Yershov Archiveから[ ソース ]