[過去ﾛｸﾞ] (強いAI)技術的特異点/シンギュラリティ156 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
71: yamaguti 2019/04/04(木)20:13 ID:oZpuEpFw(4/22) AAS
2chｽﾚ:future SaitouSenseiMesoddo NanoKeizai
72: yamaguti 2019/04/04(木)20:14 ID:oZpuEpFw(5/22) AAS
>28 名前：yamaguti E-mail：sageYdzZn_giE4w 投稿日：2019/03/27(水) 08:44:21.46 ID:qWdbt0oO?2BP(0) \>112 yamaguti 190316 1859 oq9O0c4s?
>> Google 翻訳 http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
>>
>>
>> バージニア大学コンピュータサイエンス学科
>> CS655：プログラミング言語
>> 2001年春
>>
>>
>> Smalltalkの背後にある設計原則
省21
73: yamaguti 2019/04/04(木)20:15 ID:oZpuEpFw(6/22) AAS
http://google.jp/?q=alan+kay+curtis+OR+dainabukku+OR+ruby+OR+rubinius/squeak
2chｽﾚ:future 45,35 : HPKY # 40 : MetaAL , DSL Suityoku
2chｽﾚ:future KenRon # DSL Suityoku
http://google.jp/?q=hamada-hozumi-urr+OR+futamura-syaei+OR+subleq+OR+k-gyaku-konpaira
http://google.jp/?q=hannya-singyou+tetugaku
http://google.jp/?q=smalltalk+mvc+css+OR+vm+OR+hp-palm-pre+OR+webos+OR+firefoxos+OR+chromeos+OR+nextstep+OR+webobjects+OR+dxopal+OR+jiritu-supuraito+OR+hotruby-flash+OR+palmos6foleo
2chｽﾚ:future YuukiKa # TRONCHIP 68 32bitARM ## E2EDGE
2chｽﾚ:future BurokkuDaiaguramu : SW26010 Cell
リンク先
>145 yamaguti~貸 171005 1350 Mw10xW3l? >176 yamaguti 180528 1221 x4HB0Rxw?
省6
74(1): yamaguti 2019/04/04(木)20:15 ID:oZpuEpFw(7/22) AAS
? ry 、クラスが拡張の主なメカニズムです。
Smalltalkでは、クラスは拡張の重要なメカニズム
? ry 、 ノート 、 メロディ 、 スコア 、 ティンバー 、 プレーヤーなどの表現とインタラ ﾚを ry 。
例えば、音楽システムは、 Note 、 Melody 、 Score 、Timbre 、 Player 等の、表現とインタラクションプロトコルとを記述する新しいクラスを追加 によって作成されるでしょう。
? ry 「等脚」節は重要です。
それが設計されたようにシステムが使用されることを保証するので、上記の原則の「同等」節は重要
? ry 、メロディはピッチ、 ry 表す整数の ry 、言語が整数と同じくらい簡単にメモを処理できる場合、ユーザはメロディをメモの ry します。 。
言い換えると、メロディは、ピッチ、長さ、その他のパラメータを表す Integers のアドホックコレクションとして表すことができますが、 Notes を Integers と同じくらい簡単に言語が扱える場合、ユーザはメロディを音符のコレクションとして自然に記述します。
? ry がそれを提供する場合、人間は当然最も効果的な表現を選択します。
設計の各段階で、システムが提供する場合、最も効果的な表現を人間は当然選択します
省7
75: yamaguti 2019/04/04(木)20:18 ID:oZpuEpFw(8/22) AAS
自動車交通シミュレーションを考え 。
そのようなシステムにおける多くの手順は、関係する様々な車両を参照す
? ry 、道路掃除人を ry 。
たとえば、道路清掃車を追加したいとします。
? コードが操作するオブジェクトに依存している場合、 ry 。
操作するオブジェクトにコードが依存している場合、この単純な拡張を行うには、かなりの量の計算（再コンパイルの形で）と起こり得るエラーが関係します。
メッセージインタフェースはそのような拡張のための理想的なフレームワークを確立
? ry です。
道路清掃車が他のすべての車両と同じプロトコルをサポートしていれば、シミュ にそれらを含めるための変更は不要です :
? ファクタリング： ry 各独立したコ ry トは1箇所にしか表示されません。
省9
76: yamaguti 2019/04/04(木)20:22 ID:oZpuEpFw(9/22) AAS
? Smalltalkは継承を通じて、よく練られたデザインを奨励します。
継承を通じたよく因枢分解された設計をSmalltalk は奨励
すべてのクラスはそのスーパークラスから動作を継承
? この継承はますます一般的なクラスにまで拡張され、 ry デフォルトの動作 ry 。
より一層一般的なクラス達を通じてこの継承は拡張し、最終的には すべてのオブジェクトのデフォルト動作を記述するクラスObjectで終わ
? ry デフォルトの動作が継承され、さまざまな場所で同じ概念が繰り返されません。
上記の交通シミュ では、 StreetSweeper （および他のすべての車両クラス）は一般的なVehicleクラスのサブクラスとして記述されているため、適切なデフォルト動作を継承し、様々な場所での同概念の繰返しを避けます。
? ry ます。
継承は、ファクタリングのさらに実用的な利点を示しています :
? ry よく調整されていれば、 ry 。
省6
77: yamaguti 2019/04/04(木)20:24 ID:oZpuEpFw(10/22) AAS
実装者にとって構造の利点は明らか
まず、実装するプリミティブが少なくなります。
たとえば、Smalltalkのすべてのグラフィックは単一のプリミティブ操作で実行
? 1つの作業だけで、実装者はすべての命令に愛情のこもった注意を捧げることができ、効率のわずかな ry ことを知っています。
1 つの作業をするだけで、全ての命令に愛情篭った注意を実装者は捧げる事ができ、効率の其々僅かな改善がシステム全体で増幅される事を知ります。
? ry 、どの一連の基本操作で十分であるかを尋ねるのは自然です。
コンピューティングシステム全体をサポートするには、どんなプリミティブ操作セットならば足るかを尋ねる事は自然
? ry は仮想マシン仕様と呼ばれます。
この質問に対する答えはバーチャルマシン仕様と呼ばれます :
仮想マシン： 仮想マシン仕様は、テクノロジを適用するためのフレームワークを確立
省4
79: yamaguti 2019/04/04(木)20:26 ID:oZpuEpFw(12/22) AAS
ユーザーインターフェース
? ユーザーインターフェイスは、 ry 。
ｰザインタフェースは単純に、コミュニケーションの大部分が視覚的な言語です
? ry は確立された人間の文化と非常に重なるので、 ry 。
視覚的表現は確立済人間文化と著しくオーバラップするので、審美性はこの分野で非常に重要な役割 。
ｰタシステムのすべての機能は、最終的にはユーザーインターフェイスを通じて提供されるため、ここでも柔軟性が不可欠
? ry 指向の原則と言えます。
ｰザーインターフェイスの十分な柔軟性を実現するための有効条件は、オブジェクト指向な原則と言えます :
? ry コンポーネントは、観察と操作のために意味のある方法でそれ自体 ry 。
反応原理： ユーザーがアクセス可能なすべてのコンポーネントはそれ自身を観察と操作との為の有意義な方法で提示できるべき
省5
80: yamaguti 2019/04/04(木)20:29 ID:oZpuEpFw(13/22) AAS
オペレーティングシステムはこの原則に違反しているように思われることに注意
? ry プログラマーは、他の点では一貫性のある記述の枠組みから離れ、どんな文脈が構築されていようとも、まったく異なる、通常は非常に原始的な環境を扱わなければなりません。
ここでプログラマは、一貫性ある記述フレームワークから逆に立去り、構築済な如何なる文脈も置去りにして、全く異なったそして通常とても原始的な環境を取回します。
これはそうである必要はありません：
? ry 集まりです。 ないはずです。
ィングシステム： オペレーティングシステムは、言語に収まらないものの集まりです。 それらを一つにすべきでない。
?
これらは、Smalltalk言語内に自然に組み込まれてきた従来のオペレーティングシステムコンポーネントの例です。
* ストレージ管理 -
全自動
省12
81: 2019/04/04(木)20:31 ID:UJwAImLJ(1) AAS
どうなってんだ？
迷惑なやまぐちとあぼーんしかない
82(1): yamaguti 2019/04/04(木)20:36 ID:oZpuEpFw(14/22) AAS
* サブシステムへのアクセス -
? ry 大規模な記述領域を利用でき、ユーザーとの対話を伴うサブシステムはユーザーインターフェイスのコンポーネントとして参加できます。
サブシステムは、Smalltalk内に独立したオブジェクトとして自然に組み込まれています。そこでは、既存の大規模な記述の宇宙をキャンバスにでき、それらは、ユーザインタフェース内のコンポーネントとして参画できるユーザとの、インタラクションを取込んでいます。
? ry は、一連のスタックフレームを所有 ry 。
Smalltalkプロセッサの状態は、スタックフレームのチェーンを所有するProcessクラスのインスタンスとしてアクセスできます。
* デバッガ -
? デバッガは、中断された ry 。
デバッガは、サスペンドされたプロセスの状態を操作するためのアクセス権を持つ、単なるSmalltalkサブシステムです。
? ry 唯一の実行時エラーは、 ry 。
Smalltalkで発生する可能性があるほぼ唯一のランタイムエラーは、メッセージが受信者によって認識されないこと
省4
83: yamaguti 2019/04/04(木)20:38 ID:oZpuEpFw(15/22) AAS
今後の取り組み
予想されるように、Smalltalkでの作業はまだ残っています。
説明が最も簡単な部分は、このホワイトペーパーの原則の継続的な適用です。
たとえば、Smalltalk-80システムは階層継承のみをサポートしているため、ファクタリングが不十分です。
将来のSmalltalkシステムはこのモデルを任意の（複数の）継承に一般化するでしょう。
また、メッセージプロトコルは形式化されていません。
? 組織はプロトコルを ry 。
オーガナイぜーションはプロトコルを規定していますが、プロトコルがクラス間で一貫していることは現在のところスタイルの問題です。
これは、一貫して共有できる適切なプロトコルオブジェクトを提供することで簡単に解決できます。
これにより、多態性の利点を失うことなく、プロトコルによる変数の正式な型指定が可能
省5
84: yamaguti 2019/04/04(木)20:40 ID:oZpuEpFw(16/22) AAS
時には、コンピュータシステムの進歩は憂鬱なほど遅いように思われます。
? 蒸気機関車が ry を忘れています。
蒸気機関が私たちの祖父母にとってハイテクであったことを我々は忘れています。
私は状況について楽観的
? 実際、コンピュータシステムはより ry 。
コンピュータシステムは、実際、よりシンプルになり、その結果、より使いやすくなっています
? ry を閉じたいと思います。
私はこのプロセスを支配する一般原則を纏めたいと思います :
? ry き換えられるべきです。
自然な選択： 健全なデザインの言語とシステムは存続するでしょう、より良いものだけによって置換えられて。
省8
上下前次1-新書関写板覧索設栞歴
あと 917 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ ｱﾎﾞﾝOFF
ぬこの手 ぬこTOP 0.593s*