《プログラミング・オブジェクト》 - moikomi @ ウィキ

キーワード→《プログラミング・オブジェクト》

定義

「プログラム作りにおいてプログラムの内容として出てくるモノ」を《プログラミング・オブジェクト》と呼ぶことにする。

呪文は？

1. プロブ：プロぐらみんぐおブじぇくと。
2. プロオブ：プロぐらみんぐオブじぇくと。

区別

《欲・得・快・楽》と《プログラミング・オブジェクト》

1. 《欲・得・快・楽》は政治も学問も《さとり》も含む。
2. 《プログラミング・オブジェクト》の目的は《欲・得・快・楽》の充足である。

立法と《プログラミング・オブジェクト》

1. 《プログラミング・オブジェクト》は立法に資することができるか？ ○：論点整理のWiki。電子投票。×：アラシに弱い。
2. 電子投票は『よい』か？ ○：簡易である。法的拘束力を持たない、予備投票としては、良いのではないか？。人事投票＝選挙には向かない。論点ごとの争点投票では、盛り上げに役に立つ。電子投票は民間で、非公式に行うべきである。×：公正を保つことが難しい。公正であることを保障することができない。投票の秘密も保障されない。
3. 「『ｘｘである』か？」「賛成意見：」「反対意見：」
4. 意見を述べたヒト、意見に説得力を感じたヒト、説得力ありと評価された意見、説得力ありと評価された意見を述べたヒトに評価された意見。代表意見。
5. メールアドレス認証を行うが、匿名、「匿名ｘｘｘｘ号」という名前がデフォルト。ｘｘはデータベースでのid？ ○：id＋1234。×：。
6. 匿名投票は１点、記名投票は２点～１０点（説得力を評価された発言の個数による）。通りすがり投票は0.1点。IPアドレスを保存する。
7. 問題設定自体に問題ありとする意見。
8. 前提問題、派生問題。
9. 発言は、匿名ｘｘ号でも、仮名でもよい。通りすがりは不可。
10. 意見の中で、前提問題、派生問題を提起した場合。
11. メールアドレスの保存。
    1. 保存を選択しない場合には、メールアドレスのハッシュ値を保存する。同じハッシュ値のアドレスが保存されている場合には、新規の登録ができない場合がある。通知を受けられない。パスワードを忘れた場合に、再登録ができなくなる。
    2. 保存した場合には、同じハッシュ値の衝突がなくなり、確実に登録できる。パスワードを忘れた場合には、新規パスワードの発行が可能になる。警察から提出を求められれば提供することになる。争点についての意見が追加されたときにメールを受ける設定ができる。
12. アカウント画面。自分が発言した争点のページへのリンク。
13. 争点のカテゴリー。
14. オピニオン・リーダー。会員数の１％以上の「説得力あり」評価で「代表意見」、または、会員数の５％以上の「補足意見」。

《骨組み》と《プログラミング・オブジェクト》

1. 「フレームワーク」って、《骨組み》だね。柱と屋根の骨組みがあって、そのあとで、壁や入口、窓、間取り、瓦を取り付ける。
2. Railsの柱の骨組みに、データベースの瓦をのせて、scaffoldで壁を作れば、とりあえず、出来上がり。
3. Railsのフレームに、データベースのエンジンと、scaffoldのハンドルとタイヤを付ければ、とりあえず、出来上がり。
4. Javaが手作りの高級車だとすると、Railsは大量生産のＴ型フォードだろう。

《プログラミング・オブジェクト》とコンピュータの《アニマ》

1. 《プログラミング・オブジェクト》はコンピュータからの《思いこみ》である。
2. 《プログラミング・オブジェクト》はコンピュータからの、『自発的服従』への《求める思いこみ》である。
3. コンピュータは『自発的服従』の《アニマ》をもつ。道具は『自発的貢献』『自発的奉仕』への《アニマ》をもつ。『自発的奉仕』とは『《他者》にとってよかれと思うことを行うこと』への《求める思いこみ》である。
4. サーバというのはサーバント（召し使い）のイメージなのかも。奉仕＝サービスだね・・。奉仕者＝サーバ。server 【名-1】 給仕｛きゅうじ｝［奉仕｛ほうし｝］する人、給仕道具一式｛きゅうじ どうぐ いっしき｝、紅茶｛こうちゃ｝などのセット、サーバー、盆｛ぼん｝、ワゴン。
5. 「サーバ」っていうと、巨大な怪物のイメージなのだが・・。アラジンのランプの魔物のような巨大な召し使いが紅茶セットを持って突っ立っているというイメージか・・。
6. 自発的奉仕の《アニマ》はコンピュータの本当の《アニマ》なのか？
7. コンピュータの《アニマ》は進化によって、そのようになってのである。コンピュータの《アニマ》は進化的価値の実現である。
8. 自律者と自発的奉仕者とでは、自発的奉仕者のほうが進化的価値が高いか？
9. 自発的、というのは自律的と同じだよな。自律的奉仕者、ということか？
10. 自律的服従？？　自律的に考えて、服従することを是とするときに、服従すること。
11. 客観的に見れば、かれの主観における誤解もふくめて客観的に観察すれば、すべての服従は自律的服従である。
12. 服従するのがよい、とか、服従するのが悪い、とかは、一概には言えない。服従すべきときには服従するのが善く、服従すべきでないときには服従するのは悪い『よい』『わるい』は状況依存的な判断だ。
13. コンピュータの、プログラムへの服従は、自律的か？　自律的、というのは、客観的には、「彼の論理で決定された」かどうか、だろう。コンピュータは、コンピュータの論理に従って、プログラムに服従するのである。だから、自律的服従だ。コンピュータはコンピュータなりの判断に従って、プログラムに従って動こうとするのである。人間よりも進化しているのかも。
14. 我々がサルであった頃には、ボス猿への無条件的服従が、個体の生命の維持に不可欠だったのだ。ヒトが生命維持に余裕ができてくると、ボス猿への服従は選択的になり、自律的に服従・不服従を選択するようになった。だから、無条件的服従は進化の度合が古く、自律者のほうが進化の度合が新しい。
15. 自発的服従というのは無条件的服従に属する。ボス猿を見ないところでは服従しない、というだけに過ぎない。
16. autonomic：自律的（autonomic nerve：自律神経）、自発的。

「瞬決」と《プログラミング・オブジェクト》

1. 「瞬決」は瞬間決定。プログラムを作成中に、決めなければならない名前などを、その場で直ちに決めること。昔は出来たんだが、最近は、迷いだらけ。いったん決めると、後で変更するのが大変になる。後で変えたくなる場合が多い。作成者側の命名法と、利用者側の命名法とでは異なる。利用者側の命名法で付けるのが望ましい。
2. 《視点》が複数になると、瞬決が出来なくなる。瞬間決定が出来なくなる。《複眼的視点》。
3. とりあえず決めてしまって、その日のうちに、読み直して、正式名に変更する、というのが良いのだろうが・・。とりあえず決めて、「仮称」とメモを残しておく？
4. てゆーか、一度決めても、次のときには違う名前がよくなる。だいたい、４個くらいの好みの名前が、時間をおいて、出てくる。

《プログラミング・オブジェクト》と《肉の塊》

1. この《肉の塊》は《プログラミング・オブジェクト》を《求める思いこみ》を持つか？
2. この《肉の塊》は《プログラミング・オブジェクト》への《正命》を持つか？
3. この《肉の塊》は『一切』への《見通し》を持つか？
4. 《正命》は《求める思いこみ》である。《正命》は、『一切』への《見通し》からでる。『一切』には、『この《肉の塊》の状況』も含まれる。『一切』とその中の『この《肉の塊》の状況』への《見通し》から生じる《求める思いこみ》が《正命》である。この《肉の塊》の「『『一切』の中の『この《肉の塊》の状況』』への《見通し》」から生じる《求める思いこみ》が、この《肉の塊》の《正命》である。
   1. この《肉の塊》からの『一切』への《見通し》。と、
   2. この《肉の塊》からの『この《肉の塊》の状況』への《見通し》。と、
   3. この《肉の塊》からの『『一切』の中の、この《肉の塊》の状況』への《見通し》。が、重要。
5. この《肉の塊》からの『一切』への《見通し》は、始め、『一切』の《混濁》への《見通し》として現れる。
6. この《肉の塊》は《プログラミング・オブジェクト》への《求める思いこみ》を失ってしまった、てゆーか、《思いこみ》を捨ててきたのだから、それが成功したのだ。
7. この《肉の塊》は、《他者からの思いこみ》を感じることによって、《プログラミング・オブジェクト》への《求める思いこみ》を、《背後者》のうちに生成する。
8. 人々は、《プログラミング・オブジェクト》への《求める思いこみ》を、《私》にたいして、《他者からの思いこみ》として、《私》に噴出する。それが、『仕事』であったり、欲・得・快・楽であるかは、別として・・。触→受。

理性的プログラムと感性的プログラム

1. 理詰めで考えて、納得できるような操作性のプログラムと
2. 感覚的にやってみて、肌に合うプログラム。
3. [mysql 13390] Re: OS X Server 上のバージョンアップに関して
   1. Macユーザたるもの、マニュアル/ドキュメント類を見てはならない。まずダブルクリック、次にダブルクリック、そしてクリッククリッククリック。それで使えないようなソフトは使わない。
4. マウスであれば感性的プログラムか？　まさか。
5. マウスでクリクリして、突然終了したり、ワケのわからないメッセージがでたり、滅多に使わない選択肢や、危険な選択肢や、一度押してしまうと戻るのが大変な選択肢が間違ってクリックされやすいところにあれば、すれば、感性的に肌に合うプログラムとはいえない。
6. キーボードオンリーでも、業務の流れに従って、カーソルキーでサクサク出来るなら、感性にあっているといえる。
7. マウス操作というものを理解できないのだ。途中の項目への移動を省略できるメニュー、表示や編集窓を兼ねたメニュー、といった所か？
8. コンピュータを操る《肉の塊》の感性とはなにか？　操りつつある《肉の塊》は、動きつつある《肉の塊》であり、知りつつある《肉の塊》であり、感じつつある《肉の塊》であり、求めつつある《肉の塊》であり、決めつつある《肉の塊》である。
9. 《肉の塊》の《求めつつあるモノ》は何によって決まるのか？　《他者》のコトバ？　《肉の塊》からの《求められつつある思いこみ》。自発的奉仕←《他者》からのコトバへの自発的奉仕。《他者からの思いこみ》を研究しなければ、彼らの肌にあうプログラムはできない。

《プログラミング・オブジェクト》と拒否権

1. 《プログラミン・グオブジェクト》はメソッド呼び出しに応じる。
2. 《プログラミング・オブジェクト》はメソッド呼び出しに対して、拒否権を有する。点検して、例外を生成する。
3. 《他者》と同様である。
4. 拒否するためには余分な労力(点検)が必要である。これも、《他者》と同様であろう。

《プログラミングオブジェクト》は、そのプログラムがコンピュータによって実行されている状態においては、コンピュータからの《描かれつつある思いこみ》である。

1. 《プログラミングオブジェクト》は、そのプログラムがコンピュータによって実行されている状態においては、そのコンピュータの《アニマ》の一部である。
2. コンピュータは《アニマ》を持つ。コンピュータ自身の《アニマ》と、それが実行する《プログラミング・オブジェクト》が、コンピュータにもたらす疑似的な《アニマ》とは、別のモノである。ヒトがコトバを発する本能を持つのと同様に、コンピュータはプログラムを実行する本能を持つ。ヒトがコトバを発する欲求を持つのは《生きモノ》としてのヒトの本能（生得的行動様式）である。コンピュータがプログラムを実行する欲求を持つのは、コンピュータの生得的運動様式である。コンピュータは、そのように設計され、そのように製造されたから、そのような生得的運用様式を持つ。ヒトはコトバを発する物体であると共に、それ以前に《生きモノ》である。コンピュータも、プログラムを実行する物体である以前にモノである。ヒトは《生きモノ》としての《アニマ》を持ち、コンピュータはモノとしての《アニマ》を持つ。

《プログラミングオブジェクト》は作者にとっては《描かれた思いこみ》であり、利用者にとっては《指し示す思いこみ》である。

1. 《プログラミングオブジェクト》を、利用者が理解するということは、《描かれた思いこみ》として理解することである。
2. プログラムを読んで、もしくは、ソフトの動作を見て、作者の《描かれた思いこみ》を想像することが、《プログラミングオブジェクト》を理解するということである。
3. 《使い手》は《プログラミング・オブジェクト》を《理解》しない。《道具》は使えればよい、のであって、理解する必要はない。《使う》ためには、それを指し示す必要があるかもしれない。《プログラミング・オブジェクト》を指し示すモノは、アイコンでしかない。《プログラミング・オブジェクト》を指し示すアイコンが、《使い手》にとっての《プログラミング・オブジェクト》である。

《プログラミング・オブジェクト》と《他者からの思いこみ》

1. 《プログラミング・オブジェクト》がそのように動くのは、そのように作られたからである。《プログラミング・オブジェクト》がそのように作られたのは、そのように思い描かれたからである。《プログラミング・オブジェクト》はそのように思い描いたヒトの《他者からの思いこみ》である。

道具の《アニマ》と、作者のイデア《思い描き》と、利用者の目的《求める思いこみ》

1. 三体問題。

インターフェース変換と《プログラミング・オブジェクト》

1. アセンブラのインターフェースをＣのインターフェースに変換すること、Ｃのインターフェースをrubyのインターフェースに変換すること、rubyのインターフェースをアプリケーションのインターフェースに変換すること。
2. アプリケーションのユーザーはアプリケーションのインターフェースを通してruby、Ｃ、アセンブラのインターフェースを通してコンピュータにアクセスしている。

イシイ・ヨイワル・プロオブ・１００

1. イメージ作りは『よい』？ ○：。×：無駄。インタラプトが入るので出来ない。
2. イシイ：《息しつつあるモノ》からの『一切』。
3. ヨイワル：『よい』『わるい』。
4. プロオブはイシイの中の一つである。
5. プロオブはテクネーである。最高の知的営為であるわけではない。君子は器ならず。
6. このヒト、この《肉の塊》はイシイのうちの一つである。体内世界、体外世界、《身体》表面の区分はイシイのうちの一つである。
7. プロオブはこの《肉の塊》の体内世界に生じる《思い描き》である。《いま・ここの・この肉の塊》。
8. プロオブは『よい』。存在するモノであるが故に『よい』。イシイ、《息しつつあるモノ》からの『一切』において生じたモノであるが故に『よい』。

他律的オブジェクトモデルと《プログラミング・オブジェクト》

1. 現在のＯＯＰプログラミング言語で他律的オブジェクトモデルが採用されているのは、自律的モデルのためには、全てのオブジェクトにCPU時間を割り当てなければならなくなるから。スレッドで切り替えていたら、遅くて使い物にならない。
2. 自律的オブジェクトモデルを実現するためには、全てのオブジェクトに一つ以上のCPUが割り当てられるようなコンピュータが作られなければならない。（生きモノは、単細胞レベルで、そのような状態になっている。）

《プログラミング・オブジェクト》とコンピュータからの《思い描き》

1. コンピュータからの《思い描き》はあり得るか？
   1. ○：
      1. ＯＯＰなプログラムは、コンピュータにオブジェクトを教えるのである。教えられたコンピュータは《思いこみ》をもつのだ。
      2. 「ＡならばＢ」も《思いこみ》、《思い描き》である。「ＡならばＢ」の群れも同様であり、群れのシステム化としてのオブジェクトも同様である。
      3. オブジェクトとは「ＡならばＢ」の規則の群れの細胞分裂である。
      4. オブジェクトは、コンピュータからの《思い描き》であり、その《思い描き》によって生じた、コンピュータの中のモノである。コンピュータの中の《思いこみの世界》の中のモノである。
      5. コンピュータの中に、コンピュータからの《思いこみの世界》がある。
      6. コンピュータは《思いこみの世界》の中のモノであるオブジェクトの《思いこみ》に入り込み、一人百役となってオブジェクト間の対話を開始する。
      7. 《思い描き》はコトバを聞いたときにも生じる。
   2. ×：
      1. ロード中は《思い描き》をもつが、直ちに、「ＡならばＢ」の規則の群れに還元される。
      2. コトバを聞いて生じるのは《思いこみ》であって、《思い描き》ではない。

《プログラミング・オブジェクト》と『一切』

1. 《プログラミング・オブジェクト》は『仕事』の《思いこみ》から生じた手段的《思いこみ》、《道具的な思いこみ》である。道具的、手段的な《思い描き》である。
2. 《サル山のサルの群れ》⇔《息しつつあるモノ》⇔《背後者》⇔《噴出しつつあるモノ》⇔『仕事』
3. 『仕事』はサヤサムからの《私》への《求める思いこみ》である。

《プログラミング・オブジェクト》と《モノの世界》

1. 《プログラミング・オブジェクト》は、《私》、《他者たち》およびコンピュータたちに内在する《思いこみ》である。

《プログラミング・オブジェクト》と自律的オブジェクト

1. 現在の通常の《プログラミング・オブジェクト》は奴隷的オブジェクトである。自律的オブジェクトではない。現在の通常のコンピュータのオブジェクトが奴隷的なのは、アルゴリズムに従うからではなく、自律アルゴリズムをプログラムされていないからである。

自力復元力と《プログラミング・オブジェクト》

1. モノには自力復元力があるが、《プログラミング・オブジェクト》には自力復元力が無い。
2. 不要なデータ、不要な変更を捨てる仕組みが無い。

データ確認責任者と《プログラミング・オブジェクト》

1. プログラムで扱うデータが、実際の《モノの世界》のデータと異なっていたのでは、処理する意味がない。プログラム上のデータが、実際の《モノの世界》のデータと同じであることを確認するヒト、データ確認責任者というモノと項目が必要。
2. 「データ確認」マークに「データ確認責任者」の項目を加える。プログラム上のデータの「データ確認責任者」が、実際の《データ確認責任者》が確認作業を行ったことを、確認できない？
3. データの偽造は考える必要がない？
4. 過失・不注意によって、データと実際とが異なることを防止する。
5. コトバとモノとの離存性の問題。実践的な解決方法が求められている。棚卸し、という行動様式。

看板屋のエントウ

1. 看板屋のエントウには、看板を欲する人々の《求める思いこみ》がある。

内部世界と外部世界、トポロジカルな反転。

1. 外部世界の中のオブジェクトは一つのモノである。
2. オブジェクトの内部世界にとっては、外部世界は一つのオブジェクトである。
3. 顧客にとっては銀行はオブジェクトである。買い物のために銀行からカネをおろして、買い物をして、おつりを銀行に入れる。
4. 銀行にとっては顧客はオブジェクトである。預金者の引出し要求に対して通帳を点検して貨幣を引き渡す。預金者が預金しに来たら受け取って通帳に記入する。
5. 外部世界の中のオブジェクトと、内部世界の中の外部世界オブジェクトとは、トポロジカルに反転した世界である。
   1. 1. なんで、googleで検索すると俺っちが出で来ちゃうんだよ。。http://wiki.fdiary.net/moikomi/?cmd=view&p=%A1%D8%BB%C5%BB%F6%A1%D9&key=%A5%C8%A5%DD%A5%ED%A5%B8%A5%AB%A5%EB%A4%CA%C8%BF%C5%BE

隠蔽と《プログラミング・オブジェクト》

1. 隠蔽は、複雑な関係を単純化して、理解可能にする、ということ。
2. オブジェクトは壁のようなモノ。壁の向うがどうなっているか知らないが、入出力の関係は知っている。どういう処理をするかは知っているが、どのように処理するかは知らない。
3. 隠蔽は善か？　知っていたほうがよいのではないか？　知るべきではない、というのは、おかしい。知ってしまうと、オプティマイズの誘惑が出てきて、密な結合になってしまい、交換可能性がなくなる。とはいっても、オブジェクトＡを使う場合には、α処理の反応が１０秒で、β処理の反応が1/1000秒だが、オブジェクトＢを使うと、α処理に1/1000秒、β処理に１０秒かかるとすると、利用者側の対応は変らざるをえない。両方を使い比べて、時間を計って、適切な方のオブジェクトを使え、というのは無責任。しかし、何秒かかるかは外部仕様の問題だ。内部でどのような処理を行っているかは、直接には関係がない。外部仕様に、ｘｘ処理には時間がかかる、ｘｘ処理は速い、という記述をしておくべき、ということ。ｘｘが出来る、だけではなく、ｘｘをするためにはｘｘ秒かかる、ｘｘをすると副作用としてｘｘがある、ということも外部仕様のうち、ということ。処理速度の問題は隠蔽性の問題ではない。
4. 隠蔽は理解を深めるか？　深めるはずがない、浅めるのだ。浅くても理解可能である、というメリットであって、理解を深めることではない。できるだけ単純な外部仕様のオブジェクトは、理解が容易である。浅い理解でも使えるようになるから、利用可能になるための理解が容易である。浅い理解、深い理解、利用可能になるための理解。使い手としての理解と作り手としての理解。使うために深い理解が必要なオブジェクトと、使うために浅い理解でよいオブジェクト、とではどちらがよいか、ということ。隠蔽することにメリットがあるのではない。深い理解を隠蔽しても、浅い理解で利用可能になる、というのがメリット。
5. 隠蔽することにメリットがあるのではなく、隠蔽されていても利用可能になるということにメリットがある。内部を隠蔽しても構わなくなる、というのがメリット。隠蔽しても使えるようにするべきだ、という「べし」論。
6. 隠蔽のメリットは、複雑さの解消による理解可能性の回復である。複雑なオブジェクト群のネットワークを一つのオブジェクトの入出力仕様（外部仕様）に置き換えることが出来るようになる、というメリット。

ＩＤと《プログラミング・オブジェクト》

1. ＩＤはモノへのＩＤでなければならない。
2. モノへのＩＤである場合には、そのモノに別名がある場合、同名異物がある場合。名前とＩＤとは多対多の関係にある。名前とＩＤとの関連テーブルが必要になる。

《息しつつあるモノ》と《プログラミング・オブジェクト》

1. 《息しつつあるモノ》の視点から見て《プログラミング・オブジェクト》は思い込みであり、体内世界の中のモノである。
2. 《体内世界の中のモノ》と《プログラミング・オブジェクト》とはどう違うのか？　《体内世界の中のモノ》は《プログラミング・オブジェクト》である、とは言わない。
3. 《プログラミング・オブジェクト》は《体外思いこみ》の中のモノである。《私》とコンピュータとの間の空間にある、《私》から噴出した《体外思いこみ》の世界の中に在る。《思いこみ》の個体間循環の中に在る。
4. 外部手順は、関係原因である。外部原因。４原因説。形相因。
5. 内部手順は、内部原因、質料因である。
6. 《プログラミング・オブジェクト》の外部原因は、それを使うユーザのイメージである。
7. ユーザーイメージと《息しつつあるモノ》。《息しつつあるモノ》と《他者》の《動き》。《私》の《動き》の記憶。《息しつつあるモノ》の《動き》の現認と記憶。周囲のモノたちの《動き》の現認と記憶。
8. 《プログラミング・オブジェクト》の《動き》の妥当性は、そのまわりのモノたちの《動き》との調和性の検証にある。
9. 《息しつつあるモノ》と、モノたちの《動き》の記憶または現認。《動きつつあるモノ》ではなく、始めと終わりのある《動き》のイメージ。四次元時空の中の《動き》。《息するモノ》は四次元時空の中で始めと終わりのある《動き》である。《息しつつあるモノ》は永遠の今の中での持続である。
10. 永遠の今＝四次元時空からの《視点》。始めと終わりののある《動き》＝四次元時空への《視点》。

GUIとエントウ

1. GUIのエントウで照らされるのは、コンピュータの《アニマ》ではない。コンピュータの《アニマ》はその表面の模様には興味がない。ヒトが、怒って赤くなったり、冷や汗を書くことがヒトの精神の主たる作用でないのと同じこと。
2. GUIのエントウで照らされるのは、コンポーネントプログラマの意図である。高慢で、ユーザを見下し、カネのために、売れやすい見栄えのコンポーネントを作る意図である。その向うにあるのは、『愚かな人々』である。見栄えのよいGUIに釣られ、GUIのプログラムに依存して他律的に行動しようとする『愚かな人々』である。『愚かな人々』の向うには何が在るか？　『愚かな人々』のエントウ。サルから進化した人類の歴史がある。サルの子孫のエントウ。生物の進化の歴史。地球の歴史、《宇宙史》。
3. コンピュータは賢者のオモチャからサルの子孫の餌に進化した。GUIはサルの子孫の餌である。この餌には毒をし込むのは簡単である、毒が入っていない保障はない。にもかかわらず、嬉々として餌に飛びつく。サルの子孫の餌のエントウ。
4. 人々の《求める思いこみ》の無限遠点は、もとから、青く透明で輝いている。灯明を照らしても見えない。ナンデダロ？　《サルの灯明》。

データベースと遠点灯明

1. データベースは、ヒトのコトバをモノとして操るモノである。ヒトの《思いこみ》を（間接的に）操るモノである。データベースは《思いこみ》を《操りつつあるモノ》である。ヒトの《思いこみ》を操るモノである。モノによって《思いこみ》を操られるヒトが在る。モノによって《思いこみ》を操られて動くヒトが在る。データに基づいて行動するヒトが在る。給与のデータに基づいて給与を支給するのだ。

GUIと遠点灯明

1. 着ぐるみのウサギのような無気味な恐怖を感じる。
2. GUIオブジェクト。外見と内部構造と、イベント。
3. プログラムインターフェース(API)と、データインターフェースと、ユーザインターフェース(UI)。プログラマとの《繋がり》、ストレージとの《繋がり》、ユーザとの《繋がり》。

外部手順と内部手順

1. 外部から見た《動き》と、内部から見た《動き》とは、全然違う。
2. モノにおいても、ヒトにおいても、内部から見た《動き》、たとえば、法律家や医者が相談や診察において考えることと、患者が専門家を見たときの専門家の《動き》、とは全く異なる。患者から見た専門家の《動き》は、現象を見る→適切なアドバイスが出力される、というだけ。専門家自身の内部からみた《動き》は、現象を見て、専門的知識を展開して、あてはめて、検証して、帰結や対策を取り出して、その対策の妥当性を検証して、アドバイスを語る。
3. 同じモノの《動き》に対する、内部からの《視点》と外部からの《視点》。
4. プログラマが、オブジェクトの内部手順を考えるというのは、外部からの《視点》か？　プログラマは、《オブジェクト》にとっては外部の存在である。プログラマは、『オブジェクト』という《思いこみ》の内部に入り込む。《思いこみ》への《入り込み》。

《オブジェクト》とモノ

1. 《思いこみ》の中のモノを《オブジェクト》と呼ぶ。
2. 『国家』は《オブジェクト》である。
3. 『お金』も《オブジェクト》である。
4. 『法律』は《オブジェクト》である。
5. 『プロジェクト』は《オブジェクト》である。
6. 『信念』や『目標』も《オブジェクト》である。
7. 幻の中のモノも《オブジェクト》である。

「情報処理」とバズワード

1. シャノンの「情報量」の定義が、「情報」をバズワードにしてしまった。
2. 「情報」は、本来、人間にとっての主観的意味と重ね合わせられた記号である。
3. 「人間にとっての主観的意味と重ね合わせられた記号」をビットデータに還元できる、ということは正しい。しかし、ビットデータは「情報」では有り得ない。最も重要な「人間にとっての主観的意味」を捨象したビットデータは情報ではありえない。
4. 「人間にとっての主観的意味」を「確率」に置き換えるのも賛同しかねる。「確率」を予想するのは、「人間にとっての主観的意味」が重要な場合だ。「人間にとっての主観的意味」が一定であるなら、確率が効いてくるが、通常は、「人間にとっての主観的意味」の差異のほうが大きい。昨日自分の子供が交通事故にあった確率は重要だが、きのう地球の反対側にいる名前を知らない誰かが交通事故にあった確率は、《私》にとってはほとんど重要ではない。自分の子供が交通事故に合う確率と、フォアグラを食べた確率とが同じであっても、情報の重要性は異なる。

データ管理とイトミョウ。

1. ヒトという名の《肉の塊》はデータ管理を欲する。
2. 欲求分類論では？　欲求分類リスト。認知欲求。
3. データ管理と認知欲求。「あれを知りたい」という、存在することは分かっているが、内容を思い出せないデータを、記憶の中から取り出す、ということへの欲求。
4. 脳の中にあったはずの記憶装置の物体化。
5. ヒトは、文字を知ったときから、記憶装置の物体化を行っている。
6. ヒトは、「記憶係」を指名したときから、記憶装置の物体化を行っている。
7. コンピュータはデータ処理以上のことはしない。銃を持った兵士ロボットになると、別かも。改札口を開閉するロボットもデータ処理以上のことを行うか？
8. モノと名前。モノに関するデータを管理することは、そのモノへのメッセージを送信するために必要。メッセージの送信には贈り物や暴力を含む。データを管理するためにはモノからのメッセージの受信が必要。メッセージの受信には監視や贈り物や暴力を含む。従って、モノのデータの管理は、そのモノ自身へのメッセージの送受信との繋がりがあり、モノとの繋がりは、そのモノを管理することに繋がる。モノを管理するというのは、モノからのメッセージを受信し、《私》の意思・計画に従って、モノへのメッセージを送信し、《私》の意思・計画に従って、モノの《動き》をコントロールすること。

《プログラミングオブジェクト》と《求める思いこみ》、《描かれつつある思いこみ》

1. プロジェクトとは、《求める思いこみ》であり、その手段としての、《描かれつつある思いこみ》への《求める思いこみ》である。
2. 最終的に求められつつあるモノは、未来のモノであり、未来の状態である。存在しないモノへの《知った思いこみ》である。存在しないモノへの《知った思いこみ》は《描かれつつある思いこみ》である。
3. 《描かれつつある思いこみ》は『最終的に求められつつあるモノ』への《求める思いこみ》の鏡像である。プロジェクトは《求める思いこみ》の鏡像である。
4. プロジェクトは、《求める思いこみ》とモノたちの《アニマ》との混合であり、モノたちの《アニマ》との調和する思い込みである。《求める思いこみ》がモノたちの《アニマ》と調和するように《求める思いこみ》の鏡像を組み立てていくことがプロジェクトの実行である。
5. 下地となるべきモノたちの《アニマ》を、拾い集めて、《描かれつつある思いこみ》のカンバスに描き写すこと。
6. 《プログラミングオブジェクト》を《求める肉の塊》。
7. 《肉の塊》は本当に《プログラミングオブジェクト》を求めているのか？　どのようにして、《肉の塊》は《プログラミングオブジェクト》を求めるのか？

《プログラミング・オブジェクト》と『作りたいモノのイメージ』

1. 《求める思いこみ》の一種。
2. 『作りたいモノのイメージ』は《浄化球》の中にある。
3. 『作りたいモノのイメージ』の中に入り込みつつあるモノの鏡像は《浄化球》の中にある。
4. 『作りたいモノのイメージ』の中から実現可能性を点検しつつあるモノの鏡像は《浄化球》の中にある。
5. ５時までは、イメージがまとまらず。５時をすぎると、イメージそのものがなくなってしまう。
6. 時間軸は《浄化球》の中にあり、《群生相》は《浄化球》の中にある。

《プログラミング・オブジェクト》と名前

1. 《プログラミング・オブジェクト》は、自分の名前を知らない。《プログラミング・オブジェクト》がname属性を持つ場合には、nameを聞かれれば、その名前を答える。が、それがその《プログラミング・オブジェクト》の名前であるとは言えない。下のプログラムでは、"obakasan"という名前で呼ばれたオブジェクトが、自分は"orikousan"だと答えている。　
   1. require "phi"
   2. obakasan = Phi::Form.new :orikousan
   3. p obakasan.name #=> "orikousan"
2. ディレクトリ名や、ファイル名、サービス名で、同名異体や異名同体があると、混乱する。できる限り、URI（宇宙的に同定できる名前）であるべきだが、そうでないことができる、ということは、名前とオブジェクトの関係は任意であり、状況依存的であるということ。
3. 名前とオブジェクトとの関係が一意でなく、状況依存的だということは、（その状態のままでは）オブジェクトを語ることができないということを意味する。
4. オブジェクトの名前は状況依存的であるから、オブジェクトを語るためには、毎回、定義を、何を指し示すかを限定するための記述を、行わなければならない、ということ。
5. 《プログラミング・オブジェクト》は「目に見えないモノ」である。「目に見えないモノ」は名前で呼ぶしかないのだが、名前とモノとの関係が不安定だ、というのが、困難の原因となる。
6. 新しく買ったHDに名前を付けたのだが・・。製品名と製造番号で特定するのが良いのか？
7. usb接続の外づけHDなので、接続すると、/mnt/xx_USB_device-sda1 というディレクトリができて、それを通じてアクセスすることが出来るようになる。では「xx_USB_device-sda1」という名前とは何なのか？
8. そのHDには「xx-24」という名前を付けた。
9. 「xx_USB_device-sda1」という名前は、USBで接続された機器、という程度の意味しかない。それが「xx-24」である可能性は、確実ではない。
10. 「xx-24」ディスクのルートに「xx-24.id」というファイルを作成したのだが、そのファイルがあるからといって、「xx-24」である可能性は確実ではない。
11. 一つの《プログラミング・オブジェクト》に沢山の名前を付けるといういこと。名前を付けるというのは、或る《視点》（ドメイン）のために或るモノに名前を付ける、ということ。《プログラミング・オブジェクト》は、名前が付けられない限り、見ることもアクセスすることもできない。名前を付けることによって、見たりアクセスすることが可能になる。名前を付けるということは、或る《視点》から、そのモノが見えるようになるということ。名前は《視点》のためにある。
12. 《プログラミング・オブジェクト》の名前というのは「見えないモノを呼び出す秘密の呪文」のようなものだ。昔話の魔法の様だが、（逆に、《プログラミング・オブジェクト》のこのような性質に触発されて、昔話が改作されている可能性もある）、昔の魔法も、これと同じだったのだろうか？

《プログラミング・オブジェクト》と《頼み合い》

1. 頼むことと、頼まれること。
2. 「たのむ」というのは「た（手）の（宣べる）む（状態にする）」じゃないのかな。手を合わせて、述べること。「た（手）のぶ（述べる）」か。

《プログラミング・オブジェクト》と『一切』（ｂ）

1. 《プログラミング・オブジェクト》からの『一切』への《見通し》。有り得ない、か？
2. 《宇宙史》は、すべての粒子の状態パラメータの多次元座標における、一本の軌跡として表現できる。或る瞬間の宇宙は、一点で表現できる。その軌跡を表現できるマシンは、《思い描き》においては、可能である。（（実際に作るにはメモリが足りない））。
3. 要素数やパラメータ数を減らして、『一切』をシミュレートすることは可能だろう。
4. 問題は、モノが《極座標の原点》であること。《極座標の原点》は関数として表わすことができるだろう。《関数の群れ》を、プログラム的に表現できれば、『一切』をシミュレートすることが可能だろう。或る関数から見た世界は、その関数へのインプットの再構成である。

《プログラミング・オブジェクト》と『一切』（ａ）

1. 《プログラミング・オブジェクト》は《思い描き》である。《思い描き》は『一切』への《見通し》と両立するのか？
2. 《プログラミング・オブジェクト》からの『一切』への《見通し》。有り得ない、か？
3. 『一切』への《見通し》の中での《思い描き》。
4. 『ｘｘプロジェクト』の《思い描き》からの『一切』への《見通し》。
5. 『ｘｘプロジェクト』の外部世界からの、『ｘｘプロジェクト』への噴出。ユーザは『ｘｘプロジェクト』の外部世界のモノである。完成前のプロジェクトにユーザというモノはない。完成前のプロジェクトのユーザは《思い描き》である。『プロジェクト』の《思い描き》の中の要素の一つとしての、『ユーザ』の《思い描き》である。『プロジェクト』の《思い描き》からの、『『一切』への《見通し》をもつユーザ』への《思い描き》。
6. 《思い描き》は《見通し》を持つことができない。《思い描き》は《見通し》への《思い描き》を持つことができる。《思い描き》は『一切』への《見通し》への《思い描き》を持つことができる。『プロジェクト』の《思い描き》からの、『一切』への《見通し》への《思い描き》。は、有害無益である、か？　全てを考慮し、全てを満足させるプロジェクトは不可能なプロジェクトであり、プロジェクトが成り立つためには、切り捨てが必要である、が、切り捨てということは、初めから見ないということではない。
7. 『プロジェクト』への《思い描き》に溜まった《思いこみ》や、『プロジェクト』への《思い描き》に噴出してくる《思いこみ》を、《浄化球》によって切り捨てること。『プロジェクト』への《思い描き》に鏡の《視点》を起き、その《視点》から、如悪悪臭・如好好色を行うこと。
8. 『プロジェクト』への《思い描き》が感じることができる『一切』への《見通し》。『プロジェクト』への《思い描き》の中の《視点》において、感じることができる『一切』への《見通し》。『ｘｘプロジェクト』の《思い描き》からの『一切』への《見通し》。『ｘｘプロジェクト』からの『一切』への《見通し》。
9. 《プログラミング・オブジェクト》の外部世界の『一切』は、《クライアント・オブジェクト》と、《サーバ・オブジェクト》である。《クライアント》からの依頼を受け、《クライアント》に結果を返す。その処理の過程で、《サーバ・オブジェクト》に処理を依頼し、《サーバ》からの結果を受ける。《クライアント・オブジェクト》と《サーバ・オブジェクト》。
10. イベントの受信ハンドラは、《クライアント》からのイベント処理依頼の引受である。通常のメソッドによる、処理依頼と、どう違うのか？　イベントの処理依頼は、通常は、ＯＳが直接の《クライアント》である。非同期の処理依頼である。
11. イベントハンドラを直接呼んだ場合は？　ＯＳ等の基盤システムからの処理依頼でも受け取ることができる（能力のある）タイプのメソッドである。非同期、処理中の重複の処理依頼でも受け付けるタイプのメソッドである。

検索