English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

ゲスト
1 / ?

絶対バイナリでのプログラミング

最初のプログラマーは絶対バイナリで書きました。すべての命令 & すべてのアドレスが生のバイナリ数字で。単一の命令は 01100101 00001010 のようになります — 命令コード & メモリアドレス(バイナリ)。

スパゲティコード問題

エラーが発生して新しい命令を挿入する必要があるとき、プログラマーはジレンマに直面しました。その場に挿入すると、その後のすべての命令アドレスが1つシフトします — プログラマーがプログラム全体のすべてのアドレス参照を更新する必要があります。壊滅的です。

解決策:挿入ポイントの直前の命令を、空のメモリへのジャンプに置き換えます。その空のメモリ位置で:上書きされた命令を書き、新しい命令を追加してから、ジャンプバックします。修正にエラーが出現したときは、他の空のメモリを使って同じトリックを適用します。

結果:プログラムを通じた実行パスは、一見ランダムな位置へジャンプします。ハミングはこれを「スパゲティの缶詰」と呼びました。制御フローパスは紙に描くと、絡まったスパゲティに見えました。

エスケープルート

2つの即座の改善がありました:八進法表記(バイナリ数字を3ケタのセットでグループ化)& 十六進法(4ケタのグループ、9を超える値にはA~Fを使用)。これらは書き込みエラーを減らしましたが、基本的なアドレス問題は解決しませんでした。

シンボリックアセンブリ(例えばIBMのSAP — Symbolic Assembly Program — & SOAP — Symbolic Optimizing Assembly Program on the IBM 650)により、プログラマーはバイナリではなく命令名(ADD、MOVE)& シンボリックアドレスラベルを書くことができました。アセンブラーは入力時にバイナリに変換し、自動的にアドレス割り当てを管理します。

SOAPは追加の最適化を実行しました。回転ドラム上に命令を配置して、次の命令が前の命令が完了したちょうどそのときに読み取りヘッドに到着するようにしました — 最小遅延コード。SOAPは自分自身を編集しました。プログラムAはデータとして処理され、Bを生成し、BはA上で実行されて自己編集がどの程度改善したかを測定します。

解析木 & 言語階層

ライブラリ & 再配置可能なコード

ハミングは、再利用可能なソフトウェア(数学ライブラリ)の考え方が非常に初期段階から存在していたことに注目しました — バベッジはそれを想定していました。問題は:絶対アドレスライブラリは、使用されるたびに同じメモリ位置にルーチンが存在する必要があることです。ライブラリ全体が大きくなると、プログラムは同じアドレスを争います。

解決策:再配置可能なコード。アセンブラーは、絶対アドレスではなく、ベースアドレスからの相対オフセットを参照する命令を生成します。リンカーはロード時に最終アドレスを解決します。

フォンノイマンの未発表レポート(広く流通)は、必要なプログラミングトリックを説明しました。最初の出版されたプログラミング本(Wilkes、Wheeler & Gill、EDSAC、1951)はこれらの技術を成文化しました。

絶対アドレスライブラリがスケーラビリティの問題を生み出した理由と、再配置可能なコードがそれをどのように解決したかを説明してください。絶対アドレスの何が衝突の原因になったか、そして技術的に「再配置可能」とは何を意味するかを具体的に説明してください。

言語設計の分岐

FORTRAN(1957年、IBM)& ALGOL(1958年、国際委員会)は、根本的に異なる結果を生み出した2つの設計哲学を表しています。

FORTRAN

ジョン・バッカスがIBMのFORTRAN(FORmula TRANslation)プロジェクトを主導しました。設計目標:言語を使いやすくします。特に科学者 & エンジニアのために。FORTRANは自然に思える数学表記を受け入れました。A = B + C * D ではなく ADD B, C; STORE T; MULTIPLY T, D; STORE A

FORTRANは60年以上生き残りました。科学計算、流体力学、気候モデリング & 計算物理学で継続して使用されています。ハミングはこの耐久性を成功した設計の証拠として指摘しました。

ALGOL

ALGOL(ALGOrithmic Language)は、論理学者 & コンピュータ科学者の委員会によって設計され、数学的厳密性を目指しました:論理的にクリーンで、形式的に定義可能な言語。BNF(Backus-Naur Form)表記法は文法を説明するためにALGOLを指定するために発明されました。

ALGOLは実践的に失敗しました。その論理的優雅さ & その後の言語設計に対する莫大な影響(Pascal、C、& ほぼすべての最新言語がALGOLの文法の概念から降りてきます)にもかかわらず、ALGOL自体は決して広くデプロイされていません。ハミングの判定:論理的に設計され、人間の使い方がない。

言語階層

ハミングは機械コードからアセンブリ、高級言語、そして最終的に「問題指向言語」まで自然な階層を説明しました。これは、特定の分野(生物学、財務、物理学)の実践者が自分の問題領域について自然に考える方法に近いものです。各レベルは、機械効率のコストで人間の可読性を追加します。

ハミングの4つの言語設計基準

ハミングは、FORTRANとALGOLの教訓を、成功するプログラミング言語の4つの基準に蒸留しました。

1. 学習しやすい — 初心者は迅速に生産性を上げることができます

2. 使いやすい — ルーチンタスクには最小限の儀式が必要です

3. デバッグしやすい — エラーが意味のある、特定可能なメッセージを生成します

4. サブルーチンを使いやすい — 再利用 & 抽象化は英雄的な労力を必要としません

彼は構造的観察を加えました:人間言語は約60パーセントの冗長性を持っています。書き言葉は約40パーセント。低冗長言語(APLのような)は専門家が美しいと感じ、初心者が不明瞭と感じ、単一の文字が意味を変えるときに検出不可能なエラーを含む簡潔な1行を生成します。

含意:論理的優雅さのために設計された言語は、間違った読者を最適化します。プログラマーは人間です。人間は冗長性が必要です。エラーをキャッチし & 意図を伝えるために。

よく知っているプログラミング言語にハミングの4つの基準を適用してください。各基準を1~5で採点してください(5=優秀)。次に、強化すると言語が最も改善される基準を特定し、具体的な変更がどのようなものかを説明してください。

心理的対論理的言語設計

ハミングはFORTRAN/ALGOLの対比に言語設計だけでなく、制度的 & 人的ダイナミクスの教訓として戻りました。

FORTRANは心理的に設計されました — それを使用する人間のために、特に数学表記法で考えた科学者。ALGOLは論理的に設計されました — 形式的正確性 & 理論的優雅性のために。

ハミングが特定したパラドックス:人間が抵抗する論理的に正しい言語は失敗します。人間が採用する実用的に設計された言語は成功します。 論理的により乱雑でさえ。

彼はAPLを極端な場合として引用しました。論理的に優雅、1行で表現可能、独自の特殊文字セット付き。エキスパートはそれを愛しました。通常のプログラマーは読めないと感じました。1文字の変更はプログラムの意味をサイレントに変換できます。APLには小さな献身的なコミュニティ & ほぼゼロの主流の使用があります。

人間冗長性の議論:話し言葉は約60パーセント冗長です(反復されたコンテキスト、明確な単語、予測可能な構造)。書き言葉は約40パーセント冗長です。この冗長性はエラー検出を提供します — 人間は信頼できないため、言語は繰り返された十分な情報を運ぶように進化して、エラーをキャッチ & 修正してください。低冗長言語はこの安全ネットを削除します。

コンパイラ階層

ハミングはコンパイラ/インタープリターレイヤリングを説明しました。プログラムは高級言語で読み込まれ、低級言語に変換されます。これらのレイヤーをスタックします — 各レイヤーは1つのレベル下に変換します。上部では、分野の専門家(生物学、金融、物理学)が自然に書く領域固有言語。下部では機械コード。各遷移はコンパイラまたはインタープリターです。

言語の生存を予測する

1993年までに、ハミングは多くの言語の成功 & 失敗を見ました。FORTRAN(1957年)は生き残りました。ALGOL(1958年)は失敗しました。COBOL(1959年)はビジネスコンピューティングで数十年生き残りました。LISP(1958年)AI研究で生き残りました。PL/I(1964年)はすべてを統一しようとして失敗しました。

ハミングの心理的対論理的設計の区別 & 4つの基準を使用して、あなたが知っている1つの言語が繁栄し、1つが失敗した(または失敗している)理由を説明してください。説明は、採用 & 拒否を駆動した具体的な人間要因を特定する必要があります — 単なる技術的特性ではなく。

反復パターン

ハミングのソフトウェア歴史章には反復される構造が含まれています。

1. 痛い制限が存在する(絶対アドレス、バイナリ表記法、保守不可能なコード)

2. 誰かが制限を隠す抽象化層を発明した

3. 抽象化は新しいスケール可能にし、新しい痛い制限を作成します

4. 繰り返す

バイナリ → 八進法/十六進法 → シンボリックアセンブリ → FORTRAN → 構造化プログラミング → オブジェクト指向言語 → 領域固有言語。各レイヤーは前身の最も急性の痛みを解決しながら、新しい問題のクラスを導入します。

スパゲティコードの問題(絶対アドレス)はシンボリックアセンブリにつながりました。大規模なアセンブリプログラムはFORTRANにつながりました。大規模なFORTRANプログラムは構造化プログラミング & その後のオブジェクト指向につながりました。ハミングの講義はこれらの後の遷移の前に終了しましたが、パターンは継続します。

エンジニアに対する彼の教訓:あなたはいつも前の抽象化によって露出した痛みを解決しています。現在のレイヤーをいる理由を理解するには、その下のレイヤーが存在する理由を知ることが必要です。

定期的に作業するソフトウェア抽象化層を特定してください。それが隠す抽象化層の下の痛い制限は何ですか。そして、あなたの現在のレイヤーが導入する新しい問題のクラスは何ですか — 次のレイヤーが解決する必要がある痛みは何ですか。