YAMAGUTIseisei wrote:
> PR : シンギュラリティ系有料メールマガジン発行を構想致しております
> 無料メールマガジン版 ( 別途有料版開始時打切 )
> http://mailux.com/mm_dsp.php?mm_id=MM53D8AF3589BC7
> 
> 
> 
> Google 翻訳 http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
> 
> 
> バージニア大学コンピュータサイエンス学科
> CS655：プログラミング言語
> 2001年春
> 
> 
> Smalltalkの背後にある設計原則
> 
> 
> ダニエルHHインガルス
> 
> 学習研究グループ
> ゼロックスパロアルトリサーチセンター
> 
> BYTE Magazine、1981年8月。（c）ニューヨークのThe McGraw-Hill Companies、Inc.。
> http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html
> からコピー
> Dwight Hughesによってスキャンされ、（再作成されたグラフィックを含む）HTMLに変換された。
> 
> 
> 
> Smalltalkプロジェクトの目的は、すべての人の創造的な精神にコンピュータサポートを提供することです。 
> ? ry ハードウェアを ry から流れます。 
> 私たちの仕事は創造的な個人と利用可能な最高のコンピューティングハードウェアとを含むビジョンから湧き出ます。 
> ? 私たちは2つの研究分野に ry モデルの間のインターフェースとして働く記述言語（プログラミング言語）とそれにマッチする相互作用の言語（ユーザーインターフェース）。コンピュータのそれに人間のコミュニケーションシステム。 
> 私達は 2 つの根本分野に集中することを選択しました：人間の心の中の各モデルと計算ハードウェアの中のそれらとの間のインタフェースとして稼働する記述言語 ( プログラミング言語 ) 、
> そして、インタラクション言語 ( ユーザインタフェース ) たる、コンピュータのそれにマッチするヒューマンコミュニケーションシステム。 
> 私たちの研究は2年から4年のサイクルをたどり、それは科学的方法と平行していると見ることができます。 
> 
> ? * 現在のシステム ry
>  * カレントシステム内でアプリケーションプログラムを構築する（観察をする）
>  * その経験に基づいて、言語を再設計する（理論を定式化する）
>  * 新しい設計に基づいて新しいシステムを構築します（テスト可能な予測を作成します）。 
> 
> Smalltalk-80システムは、このサイクルで5回目を迎えました。 
> この記事では、私達が私達の仕事の過程で観察した一般原則のいくつかを提示します。 
> プレゼンテーションではSmalltalkの「母性」について頻繁に触れますが、原則自体はより一般的であり、他のシステムを評価したり将来の作業を導いたりするのに役立ちます。

> ? ただウォームアップするために、 ry 偏りに主に責任があるという原則 ry ：
> 単にウォームアップ実行の為には、私は技術的よりも社会的であり、そしてそれがSmalltalkプロジェクトの特定の偏りにとって大きな役割を果たす、という原則から始めます：
> 
> ? パーソナルマスタリー： ry することであるならば、 ry 。 
> 自己マスタリー： システムが創造的な精神を提供するならば、それは一人の個人にとって完全に理解可能でなければなりません。 
> 
> ここで重要なのは、人間の可能性は個人の中に現れるということです。 
> この可能性を実現するために、私達は一人の個人によって習得することができる媒体を提供しなければなりません。 
> ユーザーとシステムの一部との間に存在するあらゆる障壁は、最終的には創造的表現に対する障壁となります。 
> ? 変更できない、または十分に一般的ではないシステムの部分は、障害の可能性が高い原因です。 
>システムの、変更できないか又は十分には汎用的でないか、の部分は障害要因に大いになり得ます。 
> システムの一部が他の部分とは異なる動作をする場合、その部分は制御するために追加の努力が必要になります。 
> そのような追加の負担は最終結果を損なう可能性があり、その分野における将来の努力を妨げるであろう。 
> したがって、設計の一般原則を推測することができます。
> 
> ? 良いデザイン： ry は統一された枠組みの中に保持 ry 一般的なもの ry 。 
>良い設計： システムは、最小限の変更不可能な部分で構築する必要があります。  これらの部分はできるだけ汎用的にしてください。 そしてシステムのすべての部分は統一フレームワークの中に保持されるべきです。 
> 
> 言語
> コンピュータで使用する言語を設計する際に、役に立つヒントを見つけるために遠くを見る必要はありません。 
> 人々の考え方やコミュニケーションの仕方について私たちが知っていることはすべて適用可能です。 
> 人間の思考とコミュニケーションのメカニズムは何百万年もの間設計されてきました、そして我々はそれらを健全なデザインのものとして尊重するべきです。 
> ? ry 、その逆ではなく時間を ry 。
> さらに、今後数百万年間この設計を使用しなければならないので、コンピュータモデルを心と互換性のあるものにすると、そうしない色々な選択肢よりも時間を節約できます。

> ? ry おける主要な構成要素を ry 。 
> 図１は、我々の議論における原理的構成要素を示している。 
> 人は体と心を持っていると表現されます。 
> 身体は主要な経験の場であり、そしてこの議論の文脈では、それは宇宙が知覚され、それを通して意図が実行される物理的な経路です。 
> 経験は心の中で記録され処理されます。 
> ? 創造的思考は（そのメカニズムに入らずに） ry 。 
> 創造的思考 ( そのメカニズムに立入る事を除く ) は心の中に自然に現れる情報と見なすことができます。 
> 言語はその情報の鍵です。
> 
> 言語の目的 : コミュニケーションの枠組みを提供する。 
> 
> 2人の個人間の相互作用は、 図1では2つの円弧として表されています。 
> 実線の円弧は、明示的なコミュニケーションを表しています。実際の言葉や動きが発声され、認識されます。 
> ? ry 背景を形成 ry 。 
> 破線の弧は暗黙のコミュニケーションを表しています。それは、明示的なコミュニケーションの文脈を形成する文化と経験の共有です。 
> ? ry ような混乱の周りに構築されます。 
> 人間の相互作用において、実際のコミュニケーションの多くは共有された文脈への参照を通して達成されます、そして、人間の言語はそのような機微の周りに構築されます。 
> これはコンピュータにも当てはまります。

> コンピュータが図1の参加者の1人として見なされることがあるのは偶然ではありません。 
> ? ry 、「本体」は、 ry 表示および人間 ry するために提供される。 
> この場合、「体」は、情報の視覚的表示の為と人間のユーザからの入力を感知する為とに提供される。 
> コンピュータの「心」には、内部メモリと処理要素、およびそれらの内容が含まれます。 
> 図1は、コンピューター言語の設計にいくつかの異なる問題が関係していることを示しています。
> 
> 範囲： コンピュータを使用するための言語の設計は、内部モデル、外部メディア、および人間とコンピュータの両方におけるこれらの間の相互作用に対処する必要があります。 
> 
> この事実は、Smalltalkをより制限された意味でコンピュータ言語を見る人々に説明することの難しさの原因です。 
> ? ry は単に手順 ry 方法ではなく、 ry 手法でもありません。 
> Smalltalkは単なる、手順を体系化するためのより良い方法でも、ストレージ管理のための別の手法でも、ありません。 
> ? ry 単なる拡張 ry 階層、またはグラフィカルユーザインタフェースではありません。 
> それは単なる、拡張可能なデータ型の階層でも、グラフィカルユーザインタフェースでも、ありません。 
> ? ry 示した対話をサポート ry 。
> 図1に示したインタラクションをサポートするために必要なのは、これらすべてのこと、およびその他のすべてのことです。
> 
> 
> 図1： 言語デザインの範囲 
> 
> 
> 2人の間（または1人の人とコンピューターの間）のコミュニケーションには、2つのレベルでのコミュニケーションが含まれます。 
> 明示的な通信には、特定のメッセージで送信される情報が含まれています。 
> ? ry 、2人の人間に共通 ry 。
> 暗黙のコミュニケーションには、二者に共通の関連する仮定が含まれています。
> 
> 
> 
> ? 通信オブジェクト
> コミュ二ケーティングオブジェクト
> 
> ? 心は即時のものでも記録されたものでも、広大な経験の世界を観察します。
> 心は広大な、即時と記録済との両方の、経験の宇宙を観察します。
> ? この経験をそのままにすることで、宇宙 ry 。
> この経験をシンプルにそのままにして置く事で、宇宙との一体感を導き出すことができます。
> ? しかし、文字通り宇宙に参加するために参加 ry 。
>しかし、宇宙の中の、文字通り
>一部として
>、参加したいのであれば、区別をつける必要があります。
> ? ry 、同時に残りはすべてその物ではなくなる。
> そうすることで、人は宇宙の中の物を識別し、同時に、それでない物に残り全てがなる。
> それ自体で区別することは始まりですが、区別するプロセスはそれ以上容易にはなりません。
> ? ry について話をするたびに、 ry 。
> 「あそこのあの椅子」に付いて話す事を希望する度に、あの椅子を見分けるプロセス全体を繰り返さなければなりません。
> これが参照の行為が起こるところです：我々はオブジェクトとユニークな識別子を関連付けることができます、そして、その時から、その識別子の言及だけがオリジナルのオブジェクトを参照するのに必要です。

> ? ry システムは、頭脳の中でそれらと互換性があるモデル ry 。
> 私たちは、コンピュータシステムは、心の中の各モデルとの互換性があるモデルを提供するべきであると言った。
> したがって：
> 
> ? ry 、その世界のオブジェクト ry 統一された手段を提供 ry 。 
> オブジェクト： コンピュータ言語は「オブジェクト」の概念をサポートし、その宇宙のオブジェクトを参照するための統一された意味 ( 意味論的な ) を提供するべきです。 
> 
> ? ry 全体に対してオブジェクト指向のメモリモデルを ry 。 
> Smalltalkストレージマネージャは、システム全体のメモリに対してオブジェクト指向モデルを提供します。 
> システム内のすべてのオブジェクトに一意の整数を関連付けることで、均一な参照が簡単に実現されます。 
> この均一性は、システム内の変数が大きく異なる値をとることができ、しかも単純なメモリセルとして実装できることを意味するので重要です。 
> オブジェクトは式が評価されるときに作成され、それらは統一参照によって受け渡しされることができるので、それらを操作する手続きでそれらの格納のための準備は必要ではありません。 
> ? ry 回収されます。 
> あるオブジェクトへの参照がすべてシステムから消えてしまうと、そのオブジェクト自体は消滅し、そのストレージは埋立てられます。 
> ? ry の比喩を完全 ry 。
> このような振る舞いは、オブジェクトのメタファを完全にサポートするために不可欠です。
> 
> ストレージ管理 : 真に「オブジェクト指向」であるためには、コンピュータシステムは自動ストレージ管理を提供しなければならない。 
> 
> ? ry を調べる方法は、プログラムが自分たちがしていることをやっているように見えるかどうかを確認することです。 
> ある言語がうまく機能しているかどうかを見出す方法は、彼らプログラムがしている事を彼らがやっている、かの様な彼らを見る事ができるかどうかです。 
> 彼らがストレージの管理に関連するステートメントをふりかけているならば、それらの内部モデルは人間のそれとうまく一致していません。 
> ? ry 話すそれぞれのことのために誰かを準備 ry トピックを通り抜けてそれが忘れられること ry
> あなたが彼らに話す事それぞれの為の何かを準備しなければならないか、またはあなたが与えられたトピックを遂行し且つそれを忘れる事ができるとき彼らに知らせなければならないことを想像できますか？
 
> 私たちの宇宙のそれぞれの物はそれ自身の人生を持っています。 
> ? ry に、脳は各精神的対象の記憶と共に独立した処理を提供する。 
>同様に、独立した処理を夫々の精神オブジェクトのストーリッジと共に脳は提供する。 
> これはデザインの3番目の原則を示唆しています。

> ? ry よって一様に呼び出すことができるオブジェクト ry 。 
> メッセージ： コンピューティングは、メッセージを送信することによって統一的呼出しができるオブジェクト固有の機能と見なす必要があります。 
> 
> オブジェクトストレージが明示的に処理されるとプログラムが煩雑になるのと同じように、処理が外部的に行われるとシステム内の制御が複雑になります。 
> 数に5を加える処理を考えてみましょう。 
> ほとんどのコンピュータシステムでは、コンパイラはそれがどんな種類の数であるかを把握し、それに5を加えるためのコードを生成します。 
> ? 正確な種類の数はコンパイラによって決定できないため、 ry 。 
> 数の正確な種類はコンパイラによる決定ができない為、これはオブジェクト指向システムには十分ではありません（詳細は後述）。 
> ? ry 調べる一般的な加算 ry 。 
> 考えられる解決策は、近似アクションを決定するために引数の型を調べる汎用加算ルーチンを呼び出すことです。 
> ? ry 、この重要なルーチンは、 ry 。 
> これは良いアプローチではありません。というのも、このクリティカルなルーチンを、自分のクラスの数字を試してみたいという初心者が編集しなければならないことを意味するからです。 
> ? オブジェクトの内部構造に関する詳細な知識がシステム全体に散らばっているため、これもまた不適切な設計です。
> それは貧弱な設計でもあり、何故なら、オブジェクトの内部構造に関する詳細な知識がシステム全体に散らばっている為です。
> 
> ? ry します。受信側が目的の操作を実施する方法を最も ry 上で、番号に対するメッセージとして目的の操作の名前を引数 ry 。 
> Smalltalkは、より明確な解決策を提供します。欲求されたオペレーションを実行する方法を受信側が最もよく知っていることを理解した上で、欲求された操作の 名前 を数に対するメッセージとして引数とともに送信します 。 
> ? データ構造を強打したり略奪したりするビットグラインディングプロセッサの代わりに、私たちは互いに礼儀正しく彼らの様々な欲求を実行するように要求する行儀の良いオブジェクトの世界を持っています。 
> データ構造を強姦したり略奪したりするデータプロセッサの代わりに、彼らの様々な欲求を実行する為に礼儀正しく打診し合う行儀良いオブジェクトの宇宙を、私達は持っています。 
> ? メッセージの送信は ry であり、メッセージはオブジェクト間を移動するので、これは当然のことです。 
> メッセージの転送はオブジェクトの外側で行われる唯一のプロセスであり、必然的に、その際にはオブジェクト間をメッセージが旅します。 
> ? 優れたデザインの原則は、言語について言い換えることができます。
> グッドデザインその原則は、言語に付いても言えます。
> 
> ? ry 、あらゆる分野で一様に適用 ry 。 
> 統一的なメタファー： 言語は、あらゆるエリアで統一的に適用できる強力なメタファーを中心に設計する必要があります。 
> 
> この分野での成功例としては、リンク構造のモデルに基づいて構築されたLISPがあります。 APLは、配列のモデルに基づいて構築されています。 Smalltalkは、通信オブジェクトのモデルに基づいて構築されています。 
> ? ry 構築されている基本単位と同じように見なされます。 
> いずれの場合も、大規模アプリケーションは、システムを構築している基本単位を参照するのと同じ方法で参照されます。 
> ? ry オブジェクト間の相互作用は、コンピューターとそのユーザー間の最高レベルの相互作用と同じ方法で表示されます。 
> 特にSmalltalkでは、最も原始的なオブジェクトの間のインタラクションは、コンピュータとそのユーザとの間の最高レベルのインタラクションと同じ方法で参照されます。 
> ? ry 、が低整数であっても、 ry する一連のメッセージ（ プロトコル ）を ry 。 
> Smalltalkのすべてのオブジェクトは、たとえそれが小さな整数であっても、そのオブジェクトが応答できる明示的な通信を定義するメッセージのセット ( プロトコル ) を持っています。 
> 内部的には、オブジェクトはローカルストレージを持ち、すべての通信の暗黙のコンテキストを構成する他の共有情報にアクセスすることができます。 
> ? ry は、被加数がメッセージを受信した番号の現在値であるという暗黙の前提を持っています。
> たとえば、メッセージ+ 5（5を加算）は、数がメッセージ受信するに既に持っている値が被加数であるという暗黙の前提を運びます。
> 
> 
> 組織
> 
> 統一メタファーは、複雑なシステムを構築するためのフレームワークを提供します。
> いくつかの関連する組織原則が、複雑さの管理の成功に貢献しています。
> まず始めに：
> 
> モジュール性： 複雑なシステムのどのコンポーネントも、他のコンポーネントの内部の詳細に依存するべきではありません。
> 
> 
> 図2： システムの複雑さ 
> 
> 
> システム内のコンポーネント数が増えるにつれて、不要な相互作用の可能性が急速に高まります。 
> このため、コンピュータ言語はそのような相互依存の可能性を最小にするように設計されるべきです。
> 
> 
> この原理は図2に示されています。 
> システムにN個のコンポーネントがある場合、それらの間にはおおよそNの2乗の潜在的な依存関係があります。 
> コンピュータシステムが複雑なヒューマンタスクを支援することになるのであれば、それらはそのような相互依存を最小限に抑えるように設計されなければなりません。 
> ? ry 目的を実行するために受信者が使用した方法から ry 。 
> メッセージ送信メタファは、メッセージの目的 （その名前で具現化されている）を、その目的の実行の為に受信者によって使用されたそのメソッドから切り離すことによってモジュール性を提供する。 
> オブジェクトの内部状態へのすべてのアクセスはこの同じメッセージインタフェースを介して行われるため、構造情報も同様に保護されています。
> 
> ? ry は、よく似た ry で軽減できます。 
> システムの複雑さは、似たコンポーネントをグループ化することでしばしば軽減できます。 
> このようなグループ化は、従来のプログラミング言語でのデータ型指定、およびSmalltalkのクラスを通じて行われます 。 
> クラスは他のオブジェクトを記述します - それらの内部状態、それらが認識するメッセージプロトコル、そしてそれらのメッセージに応答するための内部メソッド。 
> そのように記述されたオブジェクトはそのクラスのインスタンスと呼ばれます 。 
> ? ry 適合します。 それら ry 、オブジェクト記述のための適切なプロトコルと実装を記述する。
> クラス自体もこのフレームワークに適合します : それらはクラスClassの単なるインスタンスであり、適切なプロトコルと実装とをオブジェクト記述の為に記述する。
> 
> ? 分類： 言語 ry オブジェクトを分類し、システムのカーネルクラスと同等に新しいクラスのオブジェクトを追加する手段 ry 。 
> クラス化 : 言語は、類似のオブジェクトをクラス化する為の、そしてオブジェクトの新しいクラスをシステムのカーネルクラスと同等に追加する為の、手段を提供する必要があります。 
> 
> ? ry of ness ness.
> ry of nessness.
> ? 分類はネスの客観化です。 
> クラス化は性質性の客観化です。 
> ? ry 文字通り「あのもの」であると同時に「その椅子のようなもの」として抽象的にとられています。 
> 言い換えれば、人間が椅子を見るとき、経験は文字通りな「あのもの」であると同時に抽象的な「その椅子のようなもの」であると二通り得られています。 
> ? ry chair ness.
> ry chairness.
> ? ry 抽象化は、それ自身が心の中の別のオブジェクト、プラトンの椅子または椅子のネスとして現れます。
> そのような抽象化は、「似た」経験を融合するという心の素晴らしい能力から生じます、そしてこの抽象化はそれ自身を、心の中の別のオブジェクトである所の純精神的な、椅子又は椅子性として顕在化します。
> 
> ? ry 、クラスが拡張の主なメカニズムです。 
> Smalltalkでは、クラスは拡張の重要なメカニズムです。 
> ? ry 、 ノート 、 メロディ 、 スコア 、 ティンバー 、 プレーヤーなどの表現とインタラクションプロトコルを ry 。 
> 例えば、音楽システムは、 Note 、 Melody  、 Score  、Timbre  、 Player 等の、表現とインタラクションプロトコルとを記述する新しいクラスを追加することによって作成されるでしょう。 
> ? ry 「等脚」節は重要です。 
> それが設計されたようにシステムが使用されることを保証するので、上記の原則の「同等」節は重要です。 
> ? ry 、メロディはピッチ、 ry 表す整数の ry 、言語が整数と同じくらい簡単にメモを処理できる場合、ユーザはメロディをメモの ry します。 。 
> 言い換えると、メロディは、ピッチ、長さ、その他のパラメータを表す Integers のアドホックコレクションとして表すことができますが、 Notes を Integers と同じくらい簡単に言語が扱える場合、ユーザはメロディを音符のコレクションとして自然に記述します。 
> ? ry がそれを提供する場合、人間は当然最も効果的な表現を選択します。 
> 設計の各段階で、システムが提供する場合、最も効果的な表現を人間は当然選択します。 
> ? ry ます。
> モジュール性の原則は、システム内の手続き型コンポーネントにとって興味深い意味合いがあります :
> 
> 多態性： プログラムはオブジェクトの動作だけを指定し、それらの表現は指定しないでください。 
> 
> ? ry 、与えられたオブジェクト ry が決して宣言するべきではなく、整数プロトコルに応答するということだけであるということです。 
> この原則の従来の言い方は、所与オブジェクトがSmallIntegerまたはLargeIntegerであることをプログラムは、決して宣言すべきでなくそして整数プロトコルに応答するだけにすべき、です。 
> ? ry 一般的な説明は、 ry 。
> そのような汎用的な記述は、現実世界のモデルにとって非常に重要です。
> 
> 自動車交通シミュレーションを考えてみましょう。 
> そのようなシステムにおける多くの手順は、関係する様々な車両を参照するだろう。 
> ? ry 、道路掃除人を ry 。 
> たとえば、道路清掃車を追加したいとします。 
> コードが操作するオブジェクトに依存している場合、この単純な拡張を行うには、かなりの量の計算（再コンパイルの形で）と起こり得るエラーが関係します。 
> メッセージインタフェースはそのような拡張のための理想的なフレームワークを確立します。 
> 道路清掃車が他のすべての車両と同じプロトコルをサポートしていれば、シミュレーションにそれらを含めるための変更は不要です。
> 
> ? ファクタリング： ry しか表示されません。 
> 因数分解 ( 因枢分解 韻枢分解 ) : システム内の各独立したコンポーネントは1箇所にしか現出しません。 
> 
> この原則には多くの理由があります。 
> まず第一に、システムへの追加が一箇所でのみ行われる必要がある場合、それは時間、労力、およびスペースを節約します。 
> ? ry 簡単に見つけること ry 。 
> 第2に、ユーザーは特定のニーズを満たすコンポーネントをより簡単に配置する事ができます。 
> ? ry 同期化し、相互 ry 。 
> 第3に、適切な因数分解がないと、変更を同期化しそして相互に依存するすべてのコンポーネントが一貫していることを保証する際に問題が発生します。 
> ? 因数分解の失敗は ry 違反になることがわかります。
> 因枢分解での失敗がモジュール性の違反に達する様をあなたは目にします。
> 
> ? Smalltalkは継承を通じて、よく練られたデザインを奨励します。 
> 継承を通じたよく因枢分解されたデザインをSmalltalk は奨励します。 
> すべてのクラスはそのスーパークラスから動作を継承します。 
> ? この継承はますます一般的なクラスにまで拡張され、 ry デフォルトの動作 ry 。 
> より一層一般的なクラス達を通じてこの継承は拡張し、最終的にはシステム内のすべてのオブジェクトのデフォルト動作を記述するクラスObjectで終わります。 
> ? ry デフォルトの動作が継承され、さまざまな場所で同じ概念が繰り返されません。 
> 上記の交通シミュレーションでは、 StreetSweeper （および他のすべての車両クラス）は一般的なVehicleクラスのサブクラスとして記述されているため、適切なデフォルト動作を継承し、様々な場所での同概念の繰返しを避けます。 
> 継承は、ファクタリングのさらに実用的な利点を示しています。
> 
> ? ry よく調整されていれば、 ry 。 
> レバレッジ： システムがよく因枢分解されていれば、ユーザーと実装者の両方にとって大きなレバレッジが得られます。 
> 
> 順序付けられたオブジェクトのコレクションをソートする場合を考えてみましょう。 
> Smalltalkでは、ユーザーはOrderedCollectionクラスでsortというメッセージを定義します。 
> これが完了すると、システム内のすべての形式の順序付きコレクションが、継承を通じてこの新しい機能を即座に取得します。 
> ? 余談ですが、比較プロトコルはテキストと数字の両方をサポートするクラスで認識されるため、同じメソッドでテキストとソート番号をアルファベット順に並べ替えることができます。
> 余談ですが注目すべきは、テキストと数字との両方をサポートするクラスで比較プロトコルは認識されるため、テキストアルファベット順化をだけでなく数値ソートをもがその同一メソッドは可能です。
> 
> 実装者にとって構造の利点は明らかです。 
> まず、実装するプリミティブが少なくなります。 
> たとえば、Smalltalkのすべてのグラフィックは単一のプリミティブ操作で実行されます。 
> ? 1つの作業だけで、実装者はすべての命令に愛情のこもった注意を捧げることができ、効率のわずかな ry ことを知っています。 
> 1 つの作業をするだけで、全ての命令に愛情篭った注意を実装者は捧げる事ができ、効率の其々僅かな改善がシステム全体で増幅される事を知ります。 
> ? ry 、どの一連の基本操作で十分であるかを尋ねるのは自然です。 
> コンピューティングシステム全体をサポートするには、どんなプリミティブ操作セットならば足るかを尋ねる事は自然です。 
> この質問に対する答えは仮想マシン仕様と呼ばれます。
> 
> 仮想マシン： 仮想マシン仕様は、テクノロジを適用するためのフレームワークを確立します。 
> 
> ? Smalltalk仮想マシンは、保存用のオブジェクト指向モデル、処理用の ry 。 
> Smalltalk バーチャルマシンは、ストーリッジのオブジェクト指向モデル、プロセッシング用のメッセージ指向モデル、および情報の視覚的表示用のビットマップモデルを確立します。 
> ? ry コード、そして ry することで、システムの他の利点を損なうことなくシステムのパフォーマンスを劇的に向上させることができます。
> マイクロコードを、そして最終的にはハードウェアを使用する事を介し、システムの他の美点に如何なる妥協も伴わずのシステムパフォーマンス劇的向上が可能です。
> 
> 
> ユーザーインターフェース
> ユーザーインターフェイスは、 ry 。 
> ユーザインタフェースは単純に、コミュニケーションの大部分が視覚的な言語です。 
> ? ry は確立された人間の文化と非常に重なるので、 ry 。 
> 視覚的表現は確立済人間文化と著しくオーバラップするので、審美性はこの分野で非常に重要な役割を果たします。 
> コンピュータシステムのすべての機能は、最終的にはユーザーインターフェイスを通じて提供されるため、ここでも柔軟性が不可欠です。 
> ? ry 指向の原則と言えます。
> ユーザーインターフェイスの十分な柔軟性を実現するための有効条件は、オブジェクト指向な原則と言えます。
> 
> ? ry コンポーネントは、観察と操作のために意味のある方法でそれ自体 ry 。 
> 反応原理： ユーザーがアクセス可能なすべてのコンポーネントはそれ自身を観察と操作との為に、意味のある方法で提示できるべきです。 
> 
> この基準は、通信オブジェクトのモデルによって十分にサポートされています。 
> 定義上、各オブジェクトは対話のための適切なメッセージプロトコルを提供します。 
> このプロトコルは本質的にまさにその種のオブジェクトに特有のマイクロ言語です。 
> ? ry キーボード操作 ry 使用を通して ry 。
> ユーザインタフェースのレベルでは、スクリーン上の各オブジェクトに適した言語が視覚的に（テキスト、メニュー、写真として）提示され、キーボード活動とポインティングデバイスの使用とを介して感知されます。
> 
> オペレーティングシステムはこの原則に違反しているように思われることに注意してください。 
> ? ry プログラマーは、他の点では一貫性のある記述の枠組みから離れ、どんな文脈が構築されていようとも、まったく異なる、通常は非常に原始的な環境を扱わなければなりません。 
> ここでプログラマは、一貫性ある記述フレームワークから逆に立去り、構築済な如何なる文脈も置去りにして、全く異なったそして通常とても原始的な環境を取回します。 
> これはそうである必要はありません：
> 
> ? ry 集まりです。 ないはずです。 
> オペレーティングシステム： オペレーティングシステムは、言語に収まらないものの集まりです。 それらを一つにすべきでない。 
> 
> ? これは、Smalltalk言語に ry 。
> これらは、Smalltalk言語内に自然に組み込まれてきた従来のオペレーティングシステムコンポーネントの例です。
> 
> * ストレージ管理 - 
> 全自動 
> ? ry され、それ以上の参照が存在しなくなったとき ry 。 
> オブジェクトは、そのクラスへのメッセージによって作成され、そして存在するそれらへの参照がもはやなくなった時に回収されます。 
> 仮想メモリを介したアドレス空間の拡張も同様に透過的です。
> * ファイルシステム - 
> ? ry 持つファイルやディレクトリなど ry 。
> ファイルアクセスをサポートするメッセージプロトコルを持つ Files や Directories などのオブジェクトを通じて、通常のフレームワークに含まれます。
> * ディスプレイの取り扱い - 
> ? ディスプレイは単に継続的に見えるFormクラス ry 。
> ディスプレイは継続的可視な単なる Form クラスのインスタンスであり、そのクラスで定義されているグラフィカル操作メッセージは可視画像を変更するために使用されます。
> * キーボード入力 - 
> ? ry に、状態を判断したり、一連のイベントとして履歴 ry 。
> キーボード入力 - ユーザー入力デバイスも同様に、それら状態を判断したり、イベントのシーケンスとして履歴を読み取ったりするための適切なメッセージを持つオブジェクトとしてモデル化されています。
> * サブシステムへのアクセス - 
> ? ry 大規模な記述領域を利用でき、ユーザーとの対話を伴うサブシステムはユーザーインターフェイスのコンポーネントとして参加できます。
> サブシステムは、Smalltalk内に独立したオブジェクトとして自然に組み込まれています。そこでは、既存の大規模な記述の宇宙をキャンバスにでき、それらは、ユーザインタフェース内のコンポーネントとして参画できるユーザとのインタラクションを取込んでいます。
> ? ry は、一連のスタックフレームを所有 ry 。 
> Smalltalkプロセッサの状態は、スタックフレームのチェーンを所有するProcessクラスのインスタンスとしてアクセスできます。 
> * デバッガ - 
> ? デバッガは、中断された ry 。 
> デバッガは、サスペンドされたプロセスの状態を操作するためのアクセス権を持つ、単なるSmalltalkサブシステムです。 
> ? ry 唯一の実行時エラーは、 ry 。 
> Smalltalkで発生する可能性があるほぼ唯一のランタイムエラーは、メッセージが受信者によって認識されないことです。 
> 
> ? Smalltalkにはそれ自体「操作システム」はありません。 
> Smalltalk はそれ自体では「操作システム」を持ちません。 
> ? ry 必要な基本操作は、その他の点では通常のSmalltalkメッセージに応答して基本メソッド ry  。
> ディスクからページを読み取るなどの必要なプリミティブ操作は話が別であり通常の Smalltalk メッセージに応答するプリミティブメソッドとして組み込まれています。
> 
> 今後の取り組み
> 
> 予想されるように、Smalltalkでの作業はまだ残っています。
> 説明が最も簡単な部分は、このホワイトペーパーの原則の継続的な適用です。
> たとえば、Smalltalk-80システムは階層継承のみをサポートしているため、ファクタリングが不十分です。
> 将来のSmalltalkシステムはこのモデルを任意の（複数の）継承に一般化するでしょう。
> また、メッセージプロトコルは形式化されていません。
> ? 組織はプロトコルを ry 。
> オーガナイぜーションはプロトコルを規定していますが、プロトコルがクラス間で一貫していることは現在のところスタイルの問題です。
> これは、一貫して共有できる適切なプロトコルオブジェクトを提供することで簡単に解決できます。
> これにより、多態性の利点を失うことなく、プロトコルによる変数の正式な型指定が可能になります。
> 
> ? ry ことがより容易ではありません。
> 他の残りの仕事は明瞭にする事が容易と言うに足りません。
> この論文では扱われていない、人間の考えには明らかに他の側面があります。
> ? ry できる比喩として識別 ry 。
> これらは既存の言語モデルを補完することができるメタファとして識別されなければならない。
> 
> 時には、コンピュータシステムの進歩は憂鬱なほど遅いように思われます。
> ? 蒸気機関車が ry を忘れています。
> 蒸気機関が私たちの祖父母にとってハイテクであったことを我々は忘れています。
> 私は状況について楽観的です。
> ? 実際、コンピュータシステムはより ry 。
> コンピュータシステムは、実際、よりシンプルになり、その結果、より使いやすくなっています。
> ? ry を閉じたいと思います。
> 私はこのプロセスを支配する一般原則を纏めたいと思います :
> 
> ? ry き換えられるべきです。 
> 自然な選択： 健全なデザインの言語とシステムは存続するでしょう、より良いものだけによって置換えられて。 
> 
> 時計が刻々と動いている間でさえ、創造的な精神のためのますます優れたコンピュータサポートは進化しています。 
> ? すぐ助けに行くからね。
> 救援は途中まで来ています。
> 
> CS 655     バージニア大学
> CS 655：プログラミング言語
> evansATcs.virginia.e
> ? ry 22秒
> 最終更新日：月曜日3月19日17時13分22秒 2001 年
> 
> 
> 
> -- 
> フリーソフトウエア関連ボランティアの皆様に感謝申上げますと共に
> 当原稿執筆編集の甚大コストへの御配慮に厚く御礼申上げます
> 三菱 UFJ 銀行 平針支店 ( 普 ) 0111481 ヤマグチセイセイ
> 郵便局 218普2449768 ヤマグチセイセイ
> Yahoo pt 1362821068616323 Rakuten pt 1100-3310-4065-1717
> http://yahoo.jp/HsDIGs?#_2TB_0S03224



> 訂正 : 世界の構造を学習する事を新皮質内カラムがどの様に可能にするかの理論
>> 世界の構造を学習する事を新皮質内カラムが如何にして可能たらしめるかの理論
> 
> 
> 訂正 : ハイデルベルクニューロモルフィックコンピューティングプラットフォームへのHTMモデルの移植
> 
>> ? そのようなシステムの連続時間およびVLSI実装は、文献 ry 。
>> ? さらに、同じ入力カウントを受け取る列間の関係を解決するモデルの機能が示され ry として選択されず、少数の列のみが ry 。
>> シミュレーションはこの図に示されてもいる様に、データを既存ソフトウェア実装によって完全再現します。



-- 
YAMAGUTIseisei ( str_h__namae = { :sei => "山口" , :mei => "青星" } )
http://hello.to/seisei/ mailto:seisei@.68..net  tel:081-70-5152-1104
heiwa furiisekkusu 1tu