[#38020] irb で %W(#{...}) — yoshihisa masuda <sacong@...>
マスダといいます。
[#38036] undef variable — hirocy <hirocy@...>
hirocyです.
[#38039] proc method — "K.Sasada" <ko1@...>
こんにちは。ささだです。
[#38056] ファイル書換え? — 中村文建 <tx6f-nkmr@...>
初めまして、MLに参加させて頂く中村と申します。
[#38057] [ANN] Ruby-GNOME2-0.6.0 — Masao Mutoh <mutoh@...>
むとうです。
[#38059] [ANN] rbbr-0.3.0 — Masao Mutoh <mutoh@...>
むとうです。
[#38073] module extendable? — Takeshi Horinouchi <horinout@...>
堀之内と申します。
[#38080] ポートが閉じているときの例外など — Mitsuru Ogino <ogino@...>
荻野と申します。いつも質問や要望ばかりですみません。
なかだです。
いわおかです。
荻野です。
なかだです。
いわおかです。
In message <20030812150516.GV37221@barber.fe.rn.tuat.ac.jp>
中川と申します。
In message <20030814.140757.707824131.tetsuo@sapphire.siz.nes.nec.co.jp>
なかだです。
In message <200308160517.h7G5HcPL012839@sharui.nakada.kanuma.tochigi.jp>
なかだです。
In message <200308180959.h7I9xnb7001977@sharui.nakada.kanuma.tochigi.jp>
なかだです。
まつもと ゆきひろです
[#38090] ruby-1.8 で eruby が SEGV — Kazuhiko <kazuhiko@...>
かずひこです。
[#38104] XMLRPC::ModRubyServer — OHARA Shigeki <os@...>
大原です。
[#38122] ruby-tcpwrap and mkmf.rb — Takahiro Kambe <taca@...>
こんにちは。
At Sat, 16 Aug 2003 12:51:55 +0900,
In message <200308160518.h7G5IXPL012842@sharui.nakada.kanuma.tochigi.jp>
なかだです。
In message <200308160714.h7G7ErPL014647@sharui.nakada.kanuma.tochigi.jp>
前田です。
In message <87d6f3znlc.wl@kirk.priv.netlab.jp>
前田です。
わたなべです。
[#38164] Ruby1.8.0でRuby-PostgreSQLがビルドできない — kensaku Maki <sakaki@...>
はじめまして、まきと申します。
[#38183] String << の動作につきまして — kuto@...
うと と申します。
たけ(tk)です。
ふなばです。
たけ(tk)です。
ふなばです。
たけ(tk)です。
ふなばです。
ども、西啓一朗@Ktouth Brand. です。
ふなばです。
ども、西啓一朗@Ktouth Brand. です。
[#38195] 理解の進め方(Re: String << の動作につきまして) — Tadashi Oh-Ya <toy@...>
おおやです。
たけ(tk)です。
In "[ruby-list:38206] 理解の進め方:シュールな世界"
たけ(tk)です
[#38198] Tmailで送るメールに日付がつけられなくなりました — 川田誠司 <kawada.seiji@...>
はじめまして
[#38256] かみ砕いた説明をすべき範囲 — 西 啓一朗 <receiver@...>
ども。西啓一朗@Ktouth Brand. です。
なかだです。
たけ(tk)です
なかだです。
たけ(tk)です
いわおかです。
たけ(tk)です
まつもと ゆきひろです
たけ(tk)です。
たけ(tk)です。
[ruby-list:38207] Re: 理解の進め方:シュールな世界
お世話になっております。 A.中村です。 久々に楽しそうだなあ:-) On Sun, 24 Aug 2003 03:44:57 +0900 Take_tk様 ggb03124@nifty.ne.jp wrote: > ただし、プログラミングの世界を日常用語で説明する、というのは突き詰めて考 > えれば必ず破綻します。 「必ず」は言い過ぎかと。 日常概念をそのまま持ち込んでそれで 円満に説明できる部分「も」有り得ますよね? 少なくとも原理的には、それが絶対に無いという理由は無いはず。 日常概念で喩えられる旨いものが、 本当に無いのか、 単に話者が旨いものを気づかなかっただけ(^^;なのかは、 まあケースバイケースとしか言いようが無いんじゃないかな。 さて。 箱を使う説明は、「出来れば避けたほうが良い」と俺も思う…かも。 他に旨い説明を見つければ箱を使わずに済むので、 躍起になってもっとマシな(しかも日常の何かと似てる)説明を探すかなと。 Ruby的な変数の位置付けについては、 たしか数ヶ月前のCマガジンで出てきた何かの説明 (ごめんなさい、よく思い出せない。現物も手元にないし) の漫画絵が、旨い説明だったと思います。 なにかというと、オブジェクトちゃんとでも呼ぶべきか、 それともペットなのか、なんかそんな雰囲気の 可愛い(^^;オブジェクトが、「鎖で杭に」つながれてたんです。 で、杭が「変数」なんですね。 ちなみに杭には名前欄が有ったようです。 #鎖は、一部の分野で使われる「束縛」って奴を意味するんでしょうね。 #あとたしか、地面は「メモリ空間」だということになっていたような気が。 #オブジェクトちゃんも杭も、地面の上に居るんですよね。うん。 で、オブジェクトちゃんそのものと杭とは、あくまで別ものなので、 1つのオブジェクトちゃんに二本の鎖をつないで、二つの杭につなぐ ということも、出来ちゃうわけです。 ----- ところで、「共有」という言葉の意味のほうは 考証しなくていいのかな?と思います。 犬だってオブジェクトちゃんだって、 人間は(笑)、鎖で繋いだだけで「所有」を主張しちゃうわけです。 二本の鎖で繋いで「共有」を主張しちゃう二人の人も居るかも知れない。 ---- > kuruma = "車体番号123のベンツ" > kuruma2 = kuruma + kuruma > > というプログラムでは、2行目の左右のkuruma変数は同じオブジェクトを指して > います。つまりこの行は「一つのオブジェクトを二つ使って」新しいオブジェク > トを作っています。いわば世界に1台しかないベンツを2台結合する、というよ > うな処理を行っています。そうとうシュールです。 > > もちろん、2つの車庫に同じ1台のベンツが入っている、というのもシュールで > す。(変数=箱説の破綻) > > しかし、名前説も破綻します。 > > kuruma1 = "車体番号123のベンツ" > kuruma2 = "車体番号234のベンツ" > kuruma2 = kuruma1 > > このプログラムでは、最初は2台のクルマがあったのに、「kuruma2 = kuruma1」 > で"車体番号123のベンツ"にkuruma2という名前をつけた途端に、"車体番号234の > ベンツ"が消えてしまいます。かなりシュールです。 うーん。シュールなのはそこじゃなく、 そこよりもっと奥底の部分なんじゃないかと思います。 奥底ってのは、たぶん、世界を「認識」する手段が 「名前」しかない、という世界(観)です。 ベンツ云々がシュールに見えるのは、 我々がベンツを認識するために「(例えば)目」で見る ことに慣れてるからなんじゃないかな。 あとは触覚というか接触。 光はそう簡単に曲がらない(笑)ので 実世界ではselfはselfのツムジを見れないわけですし、 剛体にとってはselfにselfが接触する(ぶつかる)のは 壊れない限り無理。 でもプログラム(正確に言えばRuby方式の)では、 剛体や光みたいな曲がりにくい存在がベースになってなくて、 オブジェクトは「形」を持たないんですよね。 なんでも名前さえ呼べばOKで、 名前さえ呼ばれればselfの尻がselfの頭にくっつくことも出来る。 剛体ではないので、そういうことが全然無理じゃない。 そういう感じで動いているような気がしています。 なんてーかな、オブジェクトは「もの」ではあり、 しかも「数えられる」ものではあるんだけど、 剛体みたいに「かたち」を持ってるわけじゃなく、 だから「かたち」に縛られることがない、という。 「かたち」が無いってことは、ゼロ次元つまり「点」なのかな、 という気が最近しています。 オブジェクト指向って、(点もモノだという意味では)確かに 「モノ」を扱えるだけど、 我々が見慣れた剛体や弾性体や豆腐のような「モノ」が メモリ上に存在するわけではないんだよなあ、と。 #でも、こんにゃくだと思いたい人は思っても良いかも知れない。 そうそう。ついでに言えば、 一部のお馴染みの演算子やメソッドが、 箱モデルを無理矢理(笑)真似るように作られてる、 ということはあるかも知れません。 「+」なんかは、ひょっとしたらそれかも。 ----- > 名札説では「クルマに名札を貼りつけたはずなのにクルマを調べても名札が見つ > からない」というのも、かなりシュールな名札ということになります。 > > この論争は、「光は波か粒子か」という論争を思い起こさせます。 それ、たぶん、波か粒子かという問題とは違うと思います。 波と粒子のほうは「どっちも正解」なわけです(だったよね?)が、 箱と名札は、「どっちも正解じゃない」ですよね。 上記の杭鎖動物モデル(???)ならば、そういう問題を 引き起こさないような気がします。 つまり名札をselfが持たなくて杭しか持ってない世界。 あー。つまり、「第三(あるいはもっと沢山)の説明方法」が 有る(こともある)のでは?と。