Nm

目次

Blog 利用状況

書庫

日記カテゴリ

視点と命題

ずっとblogについて考えつつネットを見ていたら、ハッと閃きました

今まで定義とかオブジェクトと私が呼んでいたものは、数学用語の「命題」でした
wiki等の説明を読む限り、私のイメージと完全に一致します  

ソフトウエア、もしくは任意のスコープを一つの公理系としたとき
そのスコープ内にあるものは全て命題として扱うことができます

 

wikiの内容を超えるところがあるので、もう少し詳細をだします。
そもそも命題とは何かというと、真偽値をもつ明確な文です。

・私の身長は160cm以上である
これは意味的に不明瞭なところがみあたらないので命題

・彼は偉人である
これは偉人の定義が不明瞭なので命題ではない

 

さて。
ではここで、ほとんど全ての文を命題に変えてしまえる魔法のようなテクニックを紹介しましょう。
それは、「全ての単語の前に<<○○にとっての>>と付け加える」ことです。(より正確に言うなら、それを行った全ての用語の定義も必要。そのスコープ内で一つの用語には一つの定義しかないという前提も必要)

 

先ほど命題ではない例として出した「彼は偉人である」を命題に変えてみましょう
そのためには誰かが必要なので、A君を出してみます。
・A君にとっての彼はA君にとっての偉人である。
これで命題になりました。

 

他にもいくつか作ってみましょうか。
「富士山は美しい」は命題ではないが、「A君にとっての富士山はA君にとっての美しいです」は、命題です。
「5000は大きい」は命題ではないが、「A君にとっての5000はA君にとっての大きいです」は命題です

 

この<<○○にとっての>>と付け加えた上で、その用語を定義する技法を
抽象化と呼びます。・・呼べるはずです。

ありとあらゆる全ての抽象化でこの技法が使われています
映画しかり、小説しかり。人もそうですね。


そして数学でもそうです。

数学では、実は必ず公理系を選択しなければいけません。公理系が選択されていなければ全ての文は命題となりません。
ある公理系Cでは、AはBである。
これは命題です。

(公理系が不明な時、) AはBである。
このように、公理系を選択しない文は、命題ではありません

 

ソフトウエアを独自の公理系と考えます。公理系という言葉になじみがあまりないので、以後視点と呼びます
ソフトウエア内部にあるものはすべて"そのソフトウエアにとっての○○"です
そのソフトウエアにとっての○○の定義は、プログラムのソースとして全て存在するはずです
だからソフトウエアは、命題という形で全てをあらわすことが可能だと思います
(もし一部例外が出たばあいは、命題として扱えるものだけを対象とする、と変更するかもしれません。まだそこまで考えが固まっていません)

投稿日時 : 2009年2月16日 3:27

コメントを追加

# re: 視点と命題 2009/02/16 9:41 インドリ

そんなあるふさんには、Prologをお勧めするピヨ♪
一度触ってみるといいと思います。
もしかしたら、あるふさんの求めているものかもしれません。

# re: 視点と命題 2009/02/16 9:53 aetos

とりあえずWikipediaのことをWikiと略すんじゃねぇ、とお決まりの突っ込み。

> ・A君にとっての彼はA君にとっての偉人である。

「彼は2009年2月16日9時48分現在のA君にとっての偉人である」くらいまで限定しないと命題にならないというのは屁理屈ですか。屁理屈ですね。

# re: 視点と命題 2009/02/16 12:42 それは・・・

> そんなあるふさんには、Prologをお勧めするピヨ♪
それはちょっと違うんじゃ?
あるふさんがやろうとしていることは、SelfTest をオブジェクト指向に自然に取り込むこと (だと思っている) であり、全てを命題で記述することではありませんよね?

> ではここで、ほとんど全ての文を命題に変えてしまえる魔法のようなテクニックを紹介しましょう。
これは、魔法のようなテクニックではなく、条件を追加しているだけですよね。
より制限された命題に置き換えている、と言ってもいい。
そして、

> この<<○○にとっての>>と付け加えた上で、その用語を定義する技法を
> 抽象化と呼びます。・・呼べるはずです。
これは違うでしょう。
抽象化とは全く逆、具象化です。
詳しくは
http://209.85.175.132/search?q=cache:aiMbicWOm-oJ:www.biwa.ne.jp/~mmura/SoftwareDevelopment/twentyfirstcentury3.html+http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/twentyfirstcentury3.html&hl=ja&ct=clnk&cd=1&lr=lang_ja
を参考にしてください (404 になってしまうため、Google のキャッシュです)。

# re: 視点と命題 2009/02/16 16:47 通りすがりのhoge

○○にとっての
と付けた段階で具体的な特定条件に制限しているので
抽象的ではない・・・・

と、突っ込まれているのに突っ込みたくなってしまう衝動

# re: 視点と命題 2009/02/16 21:26 Jitta on the way

じゃあ、抽象化の反対はなんというもので、どの様になるのでしょう?

# re: 視点と命題 2009/02/16 21:44 ちゃっぴ

先に突っ込みから。

>> この<<○○にとっての>>と付け加えた上で、その用語を定義する技法を
>> 抽象化と呼びます。・・呼べるはずです。
> これは違うでしょう。
> 抽象化とは全く逆、具象化です。

見方の問題ですね。複数の物事の共通部分を見つけ同じものであると定義するのは「抽象化」です。ただ、限定することは多くの場合必要になりますが、必須要件ではないのでそれを定義に含めるのはどうかと。全く制限を加えていない「抽象化」から見ると「具体化」ですし、全く「抽象化」されていない状態から見ると「抽象化」になります。

> 「彼は2009年2月16日9時48分現在のA君にとっての偉人である」くらいまで限定しないと命題にならないというのは屁理屈ですか。屁理屈ですね。

でもないと思いますよ。それに、

> ・私の身長は160cm以上である

この命題も時間軸抜きにして語れないですから。
前者はともかくとして、後者は成長した後では急激に変化するものではないですから、そういった場合、前回あるふさんが主張したようなある程度の期間で一定であると決めつけてしまう方法が有効ですね。

ただし、変化する可能性が 0 では無いですから、変化する場合どうするか? といった事前考慮が必要になります。変化する可能性が限りなく低いけれども 0 ではない場合、万が一に備えているかどうかは多くの場合、重要になります。解消方法としては、software で対応する場合もあれば、人手で解消するといった手法もありますね。理想論としては、双方の利点・欠点と発生頻度を加味して比較検討しより良い手法を採用するべきでしょう。全く考慮しないというのは論外です。

理想化された環境で単純化して考えることは基礎理論を確立するための有効な手法です。ここで述べている基礎理論とは、限定された環境下で成り立つ普遍的な理論ということです。

ですが、現実の software 開発の置かれた環境は、様々な要素が複雑に絡み合う状況が多く、理想化された環境ではありません。Micro level で成り立つ理論であろうとそれを正確に計算できなければ、その集合たる macro level での正確性を保証することはできません。現実では、micro level で判断して正しいと思ったことが、重要なことを見逃したために macro level で覆る。よくあることです。

そのため、理想化された環境で求められた基礎理論を基に現実世界に落とし込んで問題が無いか検討することが必要になります。現実の system 設計ではこのことを何度と繰り返し結論を出します。

いままでの主張されたあるふさんの意見では、正直この部分の考慮が全く足りていないと思います。

理想化された環境のみ扱うのであれば問題はありませんが、software 設計は現実世界を扱っています。現実世界を扱う以上、理想化された環境化で求められた理論はそれだけでは全く役に立ちません。まさに絵に描いた餅です。

ということで、多くの人を納得させたいのであれば、現実の software で扱うものを具体例にすることが必要でしょう。

# re: 視点と命題 2009/02/16 23:44 Jitta on the way

ちゃっぴさん
> 全く制限を加えていない「抽象化」から見ると「具体化」ですし、全く「抽象化」されていない状態から見ると「抽象化」になります。
んー?それはそうですが、出発点が「全く抽象化されていない状態」ではないので、おかしいでしょう。
過去のエントリやコメントを見ると、例えば「鉛筆」がわかっていて、鉛筆に「消しゴム付」という条件を付けようとしています。条件がない状態から、状態を条件として付加しようとしているのですから、具象化ではないでしょうか。

「花柄模様の赤色鉛筆」から、「赤色鉛筆」とするのであれば抽象化ですが、「鉛筆」から「赤色鉛筆」にしようとしているのだから(「この<<○○にとっての>>と付け加えた上で、その用語を定義する技法を抽象化と呼びます。」)、これは具象化です。
「赤色であることが必要」なら、「赤色鉛筆」から「赤色の筆記具」という抽象化も出来ます。
「赤色鉛筆が必要」なら、「三菱製の花柄模様の赤色鉛筆」を「赤色鉛筆」と抽象化した時点で、抽象化は終了です。

# re: 視点と命題 2009/02/17 14:55 επιστημη

Prologを持ち出したのは"命題"に脊髄反射したインドリたんの早合点だね♪

# re: 視点と命題 2009/02/18 11:49 インドリ

うん♪そうかもw
あるふさんの説明がどうしてもしっくりこないから、Prologを触ったら「これじゃん!」って思うかな・・・と考えたんだ。
もしあるふさんがPrologを既に知っていて、その発想を元に既存のオブジェクト指向プログラミングを、論理型オブジェクト指向プログラミングにしたいのならばそういって欲しいな♪
だって、この記事Prologだったら殆ど違和感ないもの。
ボクは選ぶ言語パラダイム自体が間違っている気がするんだ。
命題したいならば単純にPrologしたらいいと思うんだけど駄目かな?
もしくは、欲しいPrologの機能を具体的に指定するとか・・・

# re: 視点と命題 2009/02/18 11:55 インドリ

例えば・・・
「A君にとっての富士山はA君にとっての美しいです」

美しい(富士山, *人)
とすると、富士山が美しいと感じるのは*人=A君と厳密に言えるじゃん♪
ほら違和感無い。

# re: 視点と命題 2009/02/19 7:39 Jitta on the way

↑「オブジェクトは、状態をサポートしなければならない」って言いたいんだって、過去のエントリに書いてあるやん。


使い手が欲しているのは「綺麗な机」。机は、綺麗であることを返せなけばならない。でも、「綺麗」の基準は bool ではない。int で「度合い」を返すことにする。
すると、前のエントリのコメントに書かれたことの矛盾がみえる。「綺麗の度合いで、何処からが綺麗なのか、定義出来ない。」
では、作業面が見えている度合いを返すことにする。やはりダメ。落書きは、作業面が見えている度合いでは表せない。また、作業面がせまくても、載っているものが秩序よく並んでいれば、綺麗と評されるだろう。


やっぱり、分析、設計をせず、いきなり実装しようと(してきた)ように思えるなぁ。

# re: 視点と命題 2009/02/19 15:12 インドリ

うーんやっぱり駄目かな?
ボクはこの記事見たとたんProlog連想したけどw
ひとまず、あるふさんにはProlog触って欲しい。
勿論、他の人も触ってみたらいいと思う。
だって、Prologでプログラミングしたらこの記事の内容に一致するもの。
そうすれば「パラダイムが違う」とボクがいった意味わかると思うな♪
ちなみに、命題を扱う場合誰の視点でするのかな?
エンドユーザーって言っても複数居るよ。
開発関係者もいっぱい居るし・・・
そこの部分を教えて欲しいな♪


>やっぱり、分析、設計をせず、いきなり実装しようと(してきた)ように思えるなぁ。

これ同感。ボクも何度かオブジェクト指向分析・設計・実装について囀ったよ。
ボクはオブジェクト指向は三位一体だと考えているからね。
でもあるふさん的には満足いかないらしい。
ボクは一応発明家でもあるからその違和感を知りたい。
オブジェクト指向の定義から明らかにずれているけど、あるふさんの発想を知るのはいい学習になるとボクは思うな。

# re: 視点と命題 2009/02/19 15:18 インドリ

まぁとにかく、間違っていると思ったら注意する事も大事だけど、その人の発想を大事にして、好意的にその発想を引き出すという事も大事だと思うんだ。
だからボクは批判よりも提案を書いているんだ。
他の人が間違いを指摘しているから、誰かがあるふさんの発想を引き出す役割をしないと駄目だからね。
誰しも間違うけども、その中には斬新なアイデアが含まれている可能性がある。
ボクはそれを大事にしたい。

# re: 視点と命題 2009/02/19 15:21 インドリ

まぁとにかく、間違っていると思ったら注意する事も大事だけど、その人の発想を大事にして、好意的にその発想を引き出すという事も大事だと思うんだ。
だからボクは批判よりも提案を書いているんだ。
他の人が間違いを指摘しているから、誰かがあるふさんの発想を引き出す役割をしないと駄目だからね。
誰しも間違うけども、その中には斬新なアイデアが含まれている可能性がある。
ボクはそれを大事にしたい。

# re: 視点と命題 2009/02/19 16:04 ゆーち

む・・難しい・・・(笑)

「オブジェクトは、状態をサポートしなければならない」
この考え方には共感できる部分があります。
SelfTestで包含できるというご意見には懐疑的(つか反対)ですが。

# re: 視点と命題 2009/02/19 20:17 Soda

Jittaさん
>>やっぱり、分析、設計をせず、いきなり実装しようと(してきた)ように思えるなぁ。

「ダックテストを考える3 オブジェクトの正当性 」の続きになりますが、この段階では、分析していないんじゃないですかね。
しないのではなく、この後でするってことだと・・・たぶん(^^;

インドリさん
>>オブジェクト指向の定義から明らかにずれているけど、あるふさんの発想を知るのはいい学習になるとボクは思うな。

から

>>まぁとにかく、間違っていると思ったら注意する事も大事だけど、その人の発想を大事にして、好意的にその発想を引き出すという事も大事だと思うんだ。
>>だからボクは批判よりも提案を書いているんだ。

この流れから見ると、インドリさんは、既に、あるふさんが間違っていると確信し、他の方も、それで批判していると思っていたのですか?
私は、あるふさんの考えていることを皆さんが理解しようとして、質問または確認を行っていると思っています。
今回の「視点と命題」では

>>今まで定義とかオブジェクトと私が呼んでいたものは、数学用語の「命題」でした

「命題」とは、あるふさんが表現していたものの、名称が変更されただけで、考え方が変わったわけではないですよね?
なぜか、スルーされていますが、2009/02/16 12:42 の時点で それは・・・さんが異議を唱えています。
その後、επιστημηさん、Jittaさんも違うんじゃないか? という意味で書かれています。

私はPrologというものを知りませんでしたので、詳しくはわかりませんが、「命題」で記述できる言語のようですね。
あるふさんはOOPを表現したいだけで、別のものを新しく作ろうとしているわけではないと思うのですが・・・
その・・・表現したいことの一部だけが一致しただけじゃないんですか?

3人の方が否定されていることを、その後も強調しているわけですから、他の人より、自分の意見のほうが正しいと考えているように見えます。
・・・ですが、根拠が少し弱くないですか?
今までの話も、あるふさんがPrologを知れば解決するんでしょうか?


ここから先はちょっと話ズレますが・・・

こー自分で自分のコメント読み直してみて、違和感を感じませんか?
また、あるふさんや他の方に失礼な部分があると思いませんか?

>>他の人が間違いを指摘しているから、誰かがあるふさんの発想を引き出す役割をしないと駄目だからね。

無意識の内に、あるふさんを下にみていませんか?
個人的に非常に気になったのですが・・・他の人のコメント方法が悪く、自分が正しい方法を見せなくては駄目だと考えてません?
現状では、まったく逆になっていると想像してみませんか?

追伸
別の場所で過去にも指摘されていたと思いますが、連続でコメントをする行為は、良く思われないことが多いですよ。
特に議論が活発な場所では、「あまり考えていない」ように見えてしまいます。
同じコメントを2回続けてしまったのは、サーバ側の問題や、単純なミスだと判断できるので、そんなに言われません。
また、別の人への返信など、意味があって分けてある場合も、批判は少ない・・・かな?
チャットとは違うので、この程度の量なら、1つにまとめたほうが良いですよ。

# re: 視点と命題 2009/02/19 22:39 インドリ

Sodaさんへ

>この流れから見ると、インドリさんは、既に、あるふさんが間違っていると確信し、他の方も、それで批判していると思っていたのですか?

オブジェクト指向の定義からみれば間違っているとボクが思う点がいくつもあるし、他の人の指摘は正しいと思っているよ。
だから確信とか言われるとちょっと違うと思う。
違うと思って発言している人は多いと思います。
あるふさんの定義がオブジェクト指向だと納得した人が今までいましたか?


>今までの話も、あるふさんがPrologを知れば解決するんでしょうか?

今まであるふさんのオブジェクト指向の考え方がちょっと皆と違う事は指摘されています。
だとしたら、オブジェクト指向ではなくて論理型言語の発想で話しをしている可能性もあるわけです。
視野を狭くして議論していても何もうまれません。
もしかしたら○○じゃないかな?と声をかけることも重要では無いでしょうか?
そうすれば、あるふさんも意外と「ああ、俺の考えていた発想はPrologにあるかもしれない」と考えるかもしれません。
それは、あるふさんにしか分からない事です。
だから、あるふさんがPrologを試してみればいいだけの事です。
そうすれば、「Prologの○○の機能をオブジェクト指向に入れたら?」とか話しが具体的になって議論が前に進むかもしれません。
他者の人が違うと力いっぱい否定する事かな?
あるふさんの頭の中の事を他者が言うのはおかしいとボクは思うよ。
あるふさんがProlog触るまでみんな待てないのかな?
ちょっと落ち着こうよ。


>無意識の内に、あるふさんを下にみていませんか?
いいえ。下に見ているのならば無視しています。
ボクはそんな暇じゃないし、意地の悪い事はしないよ。
共に発想を育てていこうというスタンスです。
発明は既存の概念から飛び出たところからうまれるからね。
そうじゃないと、発想を大事にしたいとは発言しないよ。
オブジェクト指向の定義からずれているからって否定して、斬新なアイデアが消えたらもったないないもの。

# re: 視点と命題 2009/02/20 8:33 Soda

インドリさん

うーーん、わかってもらうのは難しいのかなぁ。(^^;;;;;
ネットだと書き込んでいる人よりも見ているだけの人が圧倒的に多いんですよ。
既に私を含めて4人もの人が、わざわざ書き込みをして「インドリさん、それは違うんじゃない?」って言ってるのが現状。

>>もしかしたら○○じゃないかな?と声をかけることも重要では無いでしょうか?

○○を多くの人が正しいものだと判断できるまたは、できた場合は重要ですね。
でもね、○○が間違っていたら議論を混乱させるだけですよね?
それを指摘されているのですよ。

その場合、多くの人を納得させるような根拠や理由などが必要だと思いませんか?
もしかしたら結果的に、インドリさんの考えていることのほうが正しいかもしれません。
しかし、ここには他の人がいるんですよ。
結果までの過程も大切にしませんか?
他の人が問いかけている疑問に答えるって大事ですよ?
自分の意見を言うだけじゃなくて、他人の疑問にも回答しましょうよ。
そうじゃないと、インドリさんの本当に言いたいことが伝わりませんよ?

>>だから、あるふさんがPrologを試してみればいいだけの事です。

ここも・・・自信の表れだと思いますが・・・あまり簡単に言わないほうがいいですね。(^^;

>>他者の人が違うと力いっぱい否定する事かな?

あるふさんのお話の本質的な部分というか、本題を大きく否定しているのはインドリさんだけだと思いますよ。
他の方は、否定というよりも内容を確認されていることのほうが多くないですか?
用語のもつ意味などは否定されている場面が多数ありましたが、現時点では誰もあるふさんの考えていることを正確に把握できていないだけだと思います。

>>あるふさんがProlog触るまでみんな待てないのかな?

こーインドリさんの中で、「論理型言語の話をしてた」が確定しているようですね。
私を含めて、多くの方がその結論には到達できていません。
この文ってね、「俺の正しさが証明されるまで、待てないのか、皆せっかちだな」に近くないですか?
インドリさんがそう思っていなくても、そう受け止められる文章を書いていることは自覚したほうがいいですよ。(^^;

>>いいえ。下に見ているのならば無視しています。

ええーとね、あるふさんが間違っていることを前提に、「発想を引き出す役割」と書かれていますよね。
しかも、それは自分がやっていると。
これね、「間違っているあるふさんの中から、正規の考えではありえないが別の目的で良いものを拾い出す」ってことですよね。
根本的にあるふさんの本筋の全否定じゃないですか?(^^;;;;;;
自分が正しく、あるふさんが間違っているって上から下を見る視線に見えませんか?
ものすごーく失礼だと思うんだけど・・・

それとも、「あるふさんが間違っている」というのは、共通認識であり、私のほうの認識がズレてます?
今はまだ小麦粉の準備段階ですよね。
自分が知らないだけの小麦粉かもしれないし、呼び名が違うだけのものかもしれない。
呼び名が違ったためにパンではなく他のものを連想するかもしれない。

インドリさん、あなたが見ているのはパンですか、それとも小麦粉ですか?
私は小麦粉かどうかを確認している状態です。
インドリさんは、あるふさんが言うパンの呼び名を間違えていると考えているのですね?
確かに視野は広がりますが・・・広げすぎになってませんか?

# re: 視点と命題 2009/02/20 12:04 Jitta

うぅみゅぅ。。。Wikipedia に、「逆方向に抽象化を進め、データ型やクラスの内部を抽象化してそれらの複雑な関係を単純化し構造化することを委譲または継承と呼ぶ。」などと書いた御仁がおられる。
http://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E5%8C%96_(%E8%A8%88%E7%AE%97%E6%A9%9F%E7%A7%91%E5%AD%A6)
逆方向って、なんだよ?何を逆方向に進めるのさ?抽象化が「詳細を捨象(する)」ことなら、「詳細を取象(造語)する」ことが具象化だろうが。おう、こっちのページには「詳細化」と書いてあるよ。
http://ja.wikipedia.org/wiki/%E8%A9%B3%E7%B4%B0%E5%8C%96
「委譲」も違うだろうよ。抽象化と委譲は、関係ないだろう?

---

> 違うと思って発言している人は多いと思います。
 ずれているとは思うけど、違うとは思っていないよ。もっとも、今回の「抽象化」は違うと思うけど、上記のように、Wikipedia には「逆方向の抽象化」なんて言葉も出てくるので、あるふさんの様に思っている人も多いのでしょう。
 私は、まず、何がずれているのかを知りたい。何度も無視されているんだけど、「クラスと、クラスのインスタンス」がなぜ同じだと考えるのか、知りたい。私が知っている C++, C#, Java では、これは違うもの。言語によってはほぼ同じものもあるらしい。でも、あるふさんはメインが C++ のようです。それでなぜ「同じ」なのか、疑問。
 また、これも答えをいただけていないのだけど、「プログラム視点」というのがわからない。先に書いたように、開発者の視点とプログラムの視点は同じだと考える。どう違うのか教えていただけないと、違う見方ができない。これは、エントリを起こしていただけるようだけど。ここが理解できたら、改めて読み直してみようと思う。

> オブジェクト指向の定義からずれているからって否定して
 誰も否定していないよ。「紛らわしいから別の名前を定義して」とは言っているけど。これは、ひとつ前のエントリでSodaさんが書かれているように、重要なことです。
 そして、誰も、理解することを拒否したりしていない。理解しようとしているから、尋ねたり、わかるような解説を求めたり、自分が理解しているところとの差を提示したりしているんじゃないの?すぐ上のゆーちさんのコメントだって、「この考え方には共感できる部分があります」と書いてあるように、共感できる部分を探しているんだよ。共感できない部分は、今共感できないことは明らかだけど、説明を繰り返すうちに共感できるかもしれない。最初の方のエントリで、とっちゃんやbiacさんが「object oriented の定義は?」としつこく聞いたのも、何を目的に話をしているのかをキチンと把握するためでしょ?目的がわからなければ、一致するはずはないですよね?
 逆に、「~をやってみよう」とか「~するべきだよ」とか言い出すインドリさんの方が、「俺はおまえの言いたいことがわかった。おまえの言いたいのは、これだ。だからこれをやってみるべきだ。」と、見下しているように思えるのだけど。

# re: 視点と命題 2009/02/20 12:31 Jitta

最後の')'を補ってくだせぇ。
http://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E5%8C%96_(%E8%A8%88%E7%AE%97%E6%A9%9F%E7%A7%91%E5%AD%A6%29

# re: 視点と命題 2009/02/20 18:47 インドリ

うーん、何でも悪い方向に取るのね・・・
あるふさんの考えを全て理解できた人は居ないから、あふふさんの考えが純粋にオブジェクト指向だけとは誰も言い切れない。
という事は、他の「何か」を知るべきでは無いでしょうか?
なので、ひとまず他のパラダイムも言ってみる必要はあると私は思いました。
何のためにプログラム言語は複数のパラダイムがあるのでしょうか?
関数型言語だってオブジェクト指向もあるし、論理型だってオブジェクト指向はありえる。
そして私はその考えを「あるふさんに向けて」言ってみました。
それを他人の人があるふさんに不要と勝手に言うというのは非常に不可思議です。
それはあるふさんが考える事であって、他人が考える事ではありません。
あるふさんが「やっぱり違ったよ」というのか、
「惜しいね。後もうちょっとここを・・・」というのかはあるふさん次第です。
また

> 逆に、「~をやってみよう」とか「~するべきだよ」とか言い出すインドリさんの方が、「俺はおまえの言いたいことがわかった。おまえの言いたいのは、これだ。だからこれをやってみるべきだ。」と、見下しているように思えるのだけど。

という風に何故悪く解釈するのか不思議でなりません。
人の問いかけ方は十人十色であり、自分の路線と違う人を見下していると証するのは間違っております。
Prologいいかもといっただけの人に見下しているというのは逆だと思います。
だから私は最初に一言だけ「Prologいいかも」とだけいっているのです。
私にとっては貴方がたが「あるふさんの考えは把握できている、100%論理型の要素は無い」と勝手に断言しているように見えかねませんよ。
何故あるふさんに対する問いをあるふさんの考えを任せられないのでしょうか?
私は好意的に考えているのでそうはおもいませんけど、人によっては不快に感じると思います。
掲示板でもその様な事がありましたが、他者が自分と違う方法で話しかけるのを否定し、統一をはかるのは止めた方がいいと思いますよ。
そんな事をしているから議論が前に進まないのだと私は思います。

# re: 視点と命題 2009/02/21 23:32 Soda

インドリさん

>>うーん、何でも悪い方向に取るのね・・・

私の書き方が悪かったのかなぁ。(^^;
インドリさんの話は結果が先行しすぎてるんですよ。
最初の段階で、解説無しに、「Prolog」が出てるじゃないですか。
これ、解説というか、何でお薦めなのかを書いてあるだけでもだいぶ違うと思うんですよ。
インドリさんにとっては当たり前のことでも、第三者から見ると、「Prolog」が出てくる理由がわかりにくいんです。
2009/02/16 12:42 にそれは・・・さんが疑問を投げかけてますよね。
インドリさんから見たら否定のように見えるかもしれませんが・・・ここ温度差ありそうですね。(^^;

>>という事は、他の「何か」を知るべきでは無いでしょうか?

他の「何か」の中でも、「Prolog」を選んだ理由で、「命題を扱えること」以外のことがもう少しあればなぁっと。(^^;
第三者を納得させるのって難しいと思いますが、重要ですよね。

>>そして私はその考えを「あるふさんに向けて」言ってみました。
>>それを他人の人があるふさんに不要と勝手に言うというのは非常に不可思議です。

私は、インドリさんのブログにも目を通しています。
ネットでのやり取りに違和感を感じていましたね。
メールやチャットなどと違って、ブログのコメントや掲示板って1対1の会話を想定しないほうがいいですよ。
わんくまに所属しない私をみて、誰?なんで口出してきてるの?と感じていると思うのですが・・・
こー先生がいて、誰でも参加できる授業みたいなイメージをしてもらうとわかりやすいかな?
参加者同士がお互いの意見を検討してもおかしくないですよね?

インドリさんの考え方は、今までの会話では無かった新しいことだと思うのですよ。
当然、質問されることも多くなってしまいます。
このときに、「先生が判断すればいいことだよ」って言われると、質問者との会話を拒絶してるように見えません?

>>という風に何故悪く解釈するのか不思議でなりません。

これ、インドリさんがそう考えてるというよりも、見えてしまうってことが重要なんですよ。
書かれた本人の意思とは無関係に、見えているという事実がまずいんです。
書かれた文章の意味を判断するのは第三者なんです、これがネットで良くあるトラブルの原因です。
「また、ヘンな言いがかりつけられたよ~」って思うこと多くないですか?
多いと思ったら要注意ですよ。

#あぁ、数年前にも同じようなことを別の場所で書いた記憶が(笑
#思い出して、ちと懐かしい。επιστημηさんやaetosさんも苦労してたような記憶が(^^;
#その方のブログを見つけて、内容に衝撃を受けたのは内緒の話です・・・

>>私にとっては貴方がたが「あるふさんの考えは把握できている、100%論理型の要素は無い」と勝手に断言しているように見えかねませんよ。

うーん、そこまで強く思ってるわけじゃないんだけどなぁ。(^^;
私が疑問視した理由については、説明したつもりでしたが・・・納得できませんでしたか(^^;;;
どこの部分が納得できないのか、理由を頂けると参考にできるんですけど、いかがでしょうか?
また、「視点と命題」以外のあるふさんの発言から、どういう部分が「Prolog」で説明しやすい部分なんでしょうか?
そういう説明があれば、第三者からの印象はかなり違うと思うのですが・・・(^^;

# re: 視点と命題 2009/02/23 23:57 あるふ

>>aetosさん
>とりあえずWikipediaのことをWikiと略すんじゃねぇ、とお決まりの突っ込み。
すみません。もう一回くらいはやらかしそうですけど、次から気をつけるということで

>「彼は2009年2月16日9時48分現在のA君にとっての偉人である」くらいまで限定しないと命題にならないというのは屁理屈ですか。屁理屈ですね
いえいえ。とても重要なことですよ
いわれてなければ、多分そのうち私が持ち出してます
大抵の命題に時間制約(いつか、及びどれだけの期間か)があることをもって、
「命題をサポートするためには、動的な定義生成をサポートしなければいけない」ことの根拠にしています

誰にとってか、というのは全ての命題に含まれる条件なので表に出しましたけど、
時間制約は、必ずしも全てのものに含まれるわけでもない(と思う)ので、定義の方に埋めてます

だから本文では、A君にとっての偉人の定義=2009年2月16日9時48分現在 && A君内の偉人データベース内に入っている
のように、偉人の定義の方に時間制約がはいっていたということを想定しています
(A君の定義のほうに時間制約をいれるのもありなんですけど・・)



>>それは・・・さん
>あるふさんがやろうとしていることは、SelfTest をオブジェクト指向に自然に取り込むこと (だと思っている) であり、全てを命題で記述することではありませんよね?
そうですね。大体あってます。そういうことです
厳密に言うと、SelfTest をオブジェクト指向に取り込もうとは思っていませんが(少なくともオブジェクト指向を求めるという目標においては)
オブジェクト指向にSelfTestの概念はないですからね。最終的には消します
(SelfTestを中心とした話題にするのはその後です。オブジェクト指向を求めるという目標の時は、ちょっとしたおまけ程度の出番しかないです)

直接抽象化からオブジェクト指向はどうしてもつながらなかったのですが
命題論理を経由すると、オブジェクト指向を説明できることに気づいたんです

命題にするというのは、小さなテーマであって、大きなテーマというか本題はオブジェクト指向を求めることです


>>これは、魔法のようなテクニックではなく、条件を追加しているだけですよね。
はい。そうです
命題関連で検索した時、視点が不定になっている例が多かったのと、
視点は必ず規定しなければいけないので取り上げてみました

要は主観に関する問題です
主観が絡む問題は、主体のとりかたによって定義が曖昧になるので命題にはなりません
ただし、主体を固定化すれば定義が一意になるので、命題になります
その場合、その命題の真偽の有効範囲は主体の中だけです

数学という視点で見た時に得られた命題の真偽は、数学の中だけでしか有効ではありません
物理という視点で見た時に得られた命題の真偽は、物理の中だけでしか有効ではありません
私という視点で見た時に得られた命題の真偽は、私の中だけでしか有効ではありません
あるプログラムという視点で見た時に得られた命題の真偽は、あるプログラムの中だけでしか有効ではありません


>>抽象化とは全く逆、具象化です。
うーん。
なぜ具象化になるのか想像も付きません
提示いただいたページを見ても、特に反論がないし、別に新しいことも書いてないように見えます

ある主体の中に、主体の外のものと対応させるのは抽象化のはずでは?
もう少し詳しい説明をお願いします

(ここ以外の場所であれば、具象化のことも抽象化と呼んでいるかもしれませんけどね。
抽象化<->具象化の両方を含む概念/分野のことを広義の抽象化と呼ぶと思ってたのですが間違いですか?
今回のエントリでは、広義でも狭義でも具象化を使っていないはずなんですけど)



>>通りすがりのhogeさん
>>○○にとっての >>と付けた段階で具体的な特定条件に制限しているので >>抽象的ではない・・・・
○○にとってのをつけない、要はどこにも属さないものは
絶対的な真実以外ないと思うのですよ

もしそういうものがあるのであればこっそり教えてください


>>ちゃっぴさん
>>見方の問題ですね。複数の物事の共通部分を見つけ同じものであると定義するのは「抽象化」です。全く「抽象化」されていない状態から見ると「抽象化」になります。
私の言いたいのはこれですね。見方=視点=主体はとても重要です
まあ厳密に言うと多少違いますけどね。単なる「全く抽象化されていない状態」ではなく、「主体から見て全く抽象化されていない状態」です。

「命題」だともしかすると絶対的な真実があるかもしれないので、必須かどうかは微妙です
でも「抽象化」であれば、最低でも「抽象化した人」がいるので
抽象化した人にとっての○○になりますよね
何にも属さないということはないはずです


>>現実の system 設計ではこのことを何度と繰り返し結論を出します。
ではこちらに焦点を当てましょうか
プログラムに注目した時、一度コンパイルすると一個プログラムができます
一つのプロジェクトを通せば、数千とか数万個のプログラムを作ることになりますよね

ちゃっぴさんはおそらく、数千とか数万個のプログラムを一つのプログラムとみなしていると思います
そうではなく、この数千とか数万個のプログラムのうちの一つに注目した場合ならどうですか?
極めて現実的な仮定だと思いますが、どうでしょうか
(別にこうおく必要はないんですが、こうおくのが一番わかりやすいはず)

この場合、次のような指摘は的外れですよね
>理想論としては、双方の利点・欠点と発生頻度を加味して比較検討しより良い手法を採用するべきでしょう。
>全く考慮しないというのは論外です。
>現実の system 設計ではこのことを何度と繰り返し結論を出します




>>Jitta on the wayさん
>>「鉛筆」がわかっていて、鉛筆に「消しゴム付」という条件を付けようとしています
ん?こんなことをした覚えはないのですが。「消しゴム付鉛筆」が必要なら、「消しゴム付鉛筆」という定義を作るべきといっているだけですよ?

でも仮に「鉛筆」および「消しゴム付鉛筆」があったとしても具象化とは結びつかないです。
私が比較しているのは常に外の存在ですから。
ソフトウエアが主体だとすれば、
「鉛筆」 <--> 「ソフトウエアの外にある鉛筆」
「消しゴム付鉛筆」 <--> 「ソフトウエアの外にある消しゴム付鉛筆」


>>「赤色鉛筆が必要」なら、「三菱製の花柄模様の赤色鉛筆」を「赤色鉛筆」と抽象化した時点で、抽象化は終了です。
まさにそういうことです
「赤色鉛筆が必要」なら、「赤色鉛筆」と抽象化しなければいけません。
「赤色鉛筆が必要」な時、「鉛筆」という定義を作るのは意味がないし、
「赤色鉛筆が必要」な時、「色を取得する関数と、書くという関数を持つ」という定義を作るのは意味がありません




>>使い手が欲しているのは「綺麗な机」。机は、綺麗であることを返せなけばならない。でも、「綺麗」の基準は bool ではない
boolであらわすことができなければおかしいですよ

>使い手が欲しているのは「綺麗な机」
この時点で、「使い手にとっての綺麗な机」の定義がうまれているはずです
使い手が人だと実は不確定性原理とかでてきて難しくなるんですけど、
使い手がソフトウエアであれば、明白な定義が存在しています



>>ゆーちさん
>>「オブジェクトは、状態をサポートしなければならない」 この考え方には共感できる部分があります。
現状ではこの程度で十分です
私が確信にいたった理由もまだ出していないですしね。



>>Soda
>>この段階では、分析していないんじゃないですかね。 しないのではなく、この後でするってことだと・・・たぶん(^^;
はい。この段階では(プロジェクトという視点では)分析はしていないですね。
「プログラム視点で」といった時点で、すでに分析済みのものを扱います


>>インドリさん
・目的について
大きな目標はオブジェクト指向を求めることであって、命題であらわすことではありません

・オブジェクト指向の定義
何度も述べているように、オブジェクト指向をどう使うかの話ではありません
だから現状のOOPとはずれたものになっても狙い通りですね

あと論理学を適用するのも当初からの予定通りです
「命題」という単語にこれほど強い意味があったのは最初は気づいてなかったんですけどね


・Prologについて
入門をざっと見てみましたが、おそらくはだいぶ違いますね
命題の取り方と、命題に当てはめられるものがかなり違う印象を受けました
外部のものへの制御と状態の扱いが弱いように感じられましたがどうでしょうか


>>all
私以外の人にむけて、キツイ言葉/内容を使うのはやめてください
すでにいっぱいいっぱいなので、余計なことを考えたくないです

# re: 視点と命題 2009/02/24 8:12 Soda

なんとなく、現状がわかってきたような気がします。
あるふさんの考えている内容は以下のようなことかなぁっと。

・ソフトウエアの外にある○○
 現実にあったり、仮想的にあったりする、オブジェクトの原型。
 リソースといっている部分。

・抽象化
 リソースをオブジェクトとして考える第一段階。
 この時点では分析などは一切行わない。
 そのため、例として「赤色鉛筆」を出しているが、これを必要と考えるのは例としてだしているだけ。
 「赤色鉛筆が必要」は結果として存在するが、現時点ではリソースのどの部分がオブジェクトとして必要か考慮しない。
 リソースをオブジェクトとして考える「行為」そのもの。

 この行為は分析などを考慮していないので、1度しか行わない。
 そのため、リソースの要らない部分は削られることになるので、「抽象化」になる。

 明確に必要なものがわかっているとしたら、それはプログラマの意思が入ってしまう。
 もし、この段階で必要なものがわかるという状態であれば、あるふさんの説明は矛盾していると思う。 

>>「プログラム視点で」といった時点で、すでに分析済みのものを扱います

 今までの「プログラム視点」と同じ意味で使われています?
 「プログラマ視点」ではなくて?
 私は、「プログラム視点」がわからなくて、色々考えたんですが、言葉でいえば「オブジェクト視点」のような感じではないかと予想しました。
 オブジェクトを擬人化し、自分がどのように扱われているかを表現したかったのかなぁと。
 オブジェクたんではなかったのかぁ、また考え直さねば(^^;

>>>>使い手が欲しているのは「綺麗な机」。机は、綺麗であることを返せなけばならない。でも、「綺麗」の基準は bool ではない
>>boolであらわすことができなければおかしいですよ
 
「綺麗」には段階があり、その段階で処理をわけることを想定しているんだと思います。
たとえば、清掃が目的とかで、清掃方法が綺麗さで変化する場合など。
段階ごとに定義を考えるのが、あるふさん。(内部は数値でも判定はYes/No)
綺麗度を数値など比較できるもので管理し、その数値を直接判定するのが、Jittaさん。
段階が沢山あったら、定義も沢山増えることになるが、それは別の話って感じでしょうかね。

・・・と考えたが、違いますね、「綺麗」に段階を設けた時点で現状の視点とは食い違ってることになりますね。
段階があると考えるのはプログラマであり、現時点で仮に「綺麗な机」としてオブジェクトにする場合は、「綺麗な机」であるかどうか
つまり、「定義にあっているかどうかのYes/No」だけと考える。
机が綺麗なのではなく、綺麗な机というオブジェクトかどうかってことですよね?
Yes/NoだけだからダックテストやSelfTestの話を経由し、最終的には、これらも否定もしくは消滅する予定ってことでいいのかな?

# re: 視点と命題 2009/02/25 2:16 あるふ

>>Sodaさん
ごめんなさい。見直してたら、前回のレスでさんをつけるのを忘れてました
単なる付け忘れです。すみません

>>あるふさんの考えている内容は以下のようなことかなぁっと。
はい。ほぼこのとおりです


>>言葉でいえば「オブジェクト視点」のような感じではないかと予想しました。
>>オブジェクトを擬人化し、自分がどのように扱われているかを表現したかったのかなぁと。
はい。私のイメージもこんな感じです

>分析済み
これは、プログラマにとっての分析は終わっているという意味で使いました
要するに・・ここは私のほうが間違えていたような気がします
(プログラマの思惑というのも、プログラムからみたらリソースのひとつに過ぎません)

>>きれいな机
これについても、同じ認識です


そろそろ本題には入ってもよさそうな気がしてきました

# re: 視点と命題 2009/02/25 17:34 Jitta

わかんね。。。。orz
つーか、だんだん言ってることが変わってきているような気がする。
読み込む気力が続かないorz

# re: 視点と命題 2009/03/12 13:17 aetos

なんか、ファジイ理論を思い出した。

オブジェクト指向は基本に集合論があります。
クラスはインスタンスの集合。
で、あるインスタンスがあるクラスに属するか否かは、bool で決まります。

ファジイ理論だと、bool になりません。
「若い人」クラスのインスタンスは年齢が20歳以下と定義すれば bool ですが、じゃあ21歳になったとたんに老け込むのかというと、実際にはそうではありません。
「若い人」と「若くない人」というクラスがあった時、人は加齢に伴って、「若い人」に属する割合が減り、「若くない人」に属する割合が増えていきます。
そんな感じで、どのクラスに「どの程度の割合で」属しているか、というのがファジイ理論の基本です。

オブジェクト指向のベースにある集合論をファジイに拡大したら何か面白いことができないだろうかと昔思いましたが、面倒になって放り出しましたw

# re: 視点と命題 2009/03/14 15:55 あるふ

>>aetosさん
>クラスはインスタンスの集合。
クラス-クラスインスタンス は、帰属ではなく包含かもしれないと考えてます
クラス-型-クラスインスタンス-ソフトウエアの外と、他にいくつか階層あるのかもしれませんが

>ファジイ理論
>若い人の例
"定義"と"実際には"では主体が違いますね

ファジィ理論はざっとwebで調べたんですが、確かに無関係ではないのかも知れないように思いました
勉強するかもリストに入れておきます

# re: 視点と命題 2010/07/07 11:57 pandora

 今までの「プログラム視点」と同じ意味で使われています?
 「プログラマ視点」ではなくて?
http://www.pandora-eshop.com/
http://www.salestiffany.com/

タイトル
名前
URL
コメント