つれづれ

その131

“羽ばたき機”を作ろう! オライリー主催イベントで野尻さんがワークショップ

記事本文から一生懸命「パンツ」という単語を抹殺しようと努力されているのですが、冒頭の写真が全てを台無しにしています。

ところで、

今後の開発構想については『そらのおとしもの』第2話ED映像に近づけるべく立体化や固定翼のロケットグライダーなどを検討中

ジャージの両足にジェットエンジンを突っ込んだバージョンは?

その132

C++の参照の話が予想に反してホッテントリで、ちょっと驚いています。最初、喩え話が過ぎて「これはひどい」祭りが起きたんだと思ってビビりました。(きむら(K)さんとかに怒られたか!?とか思ったり)

わたしは小心者なので先にいいわけしてしまいます。あれは単なる比喩と捉えた方が良くって、特に C++ の参照としてはいまいち正しくはないです。

C++の参照は、わたしの大好きな C++プライマー第4版によると

参照とは、あるオブジェクトの別名になるものである。

で、ここで言うオブジェクトとは、

オブジェクトとは型を持つ、メモリの一区域である。

と、書いてあります。

変数とは、具象的な話としてメモリの話、抽象化の話として名前付けの話、その両方を併せ持つものになります。そして C++ の参照は明確に「名前だけ」の存在です。これが一番。

「名前だよ」が一番正しい、とは別に、あの説明は実の所 一般の「参照」についての説明で、C++ の参照はアクマで「名」と言う点が注意です。別の名をつける元ネタがいないと作れなかったりと、そこらへんも「嘘だ!」とか「ダメだなァ戦人」とか言われてしまわないかビビるポイントだったり。


その133

わたしのフック比喩では、オブジェクトを風船さんにしてしまいましたが、ここは比喩であることを明らかにするために



としたほうが良い、パンツであるべきだ!・・という力強いお言葉を某氏から頂きました。

すると箱変数はこんな感じでしょうか。



どういうシチュエーションよっ(..とひとり上手)

そして、



あぁっ、ガベージコレクタっ!!

その134

というわけで、「変数と値」について考えるとき難しいのは

  • 『値』...ビットパターン
  • 『オブジェクト』...型を持ったメモリチャンク
  • 『名前』...対象を特定するシンボル

の三つが絡んでくることです。


名前で抽象化するだけだったら簡単なのに、こうなってくるとややこしい。だから、Cの普通の変数のようなモデルについて、これを比喩で理解させようとしたのが、箱比喩です。

箱変数(造語)は、変数と値を

  • 変数 := 『名前』 + 『オブジェクト』
  • 値 := 『値(ビットパターン)』

で構成してるのですが、箱比喩は「箱」で変数の役割

「(名前による)抽象化カプセル」+「(型付きの)区切られたメモリ」

を上手く喩えたものです。箱は中にモノをしまうことで「何を入れても同じように使える」というXboxな抽象化カプセルを連想させますし、現実の箱がスペースを食べること、中に入れられるスペースが限られることは区切られたメモリを連想させます。

これはかなり良くできた比喩なので、結構広く広まっています。


* * *


ところが、参照変数の場合、

  • 変数 := 『名前』
  • 値 := 『オブジェクト』+『値(ビットパターン)』

と言う風になっていて、実は「変数」や「値」という語の責務分担からしてちょっち違うという。もはや「箱」で比喩できるものではありません。(更にここで言う「値」は、しばしば OOP における Object に相当したりします。あー、ややこしい..)*1


こうしてみると、C にどっぷりハマッて居る人が、動的型付け が「型無し」のように思えてガクブルしてしまうのが解る気がします。

型を持っているのは『オブジェクト』なので、それが 箱変数モデル での 変数側から、参照変数モデル での 値側に移っていることを知らないと、普通「変数に型がなければ何処にも型なし」と思うよね。あと、同値 と 同一 で戸惑ったりするのも、ここら辺に原因があるようにも思えます。

実は、このあたりって、丁寧に教え込んだ方がよい事柄なのかなぁ?・・と少し思ったり、思わなかったり。アンラーニングが難しいことを感じる次第です。


――と、話が少し脱線したので元に戻します。そんなこんなで 箱比喩は上手くできているものの、一部「本当のモデル」と違う所があります。

それは「箱は空に出来る」けれど「箱変数は空に出来ない」ということ、裏返せば「値」が実体のあるモノのように扱われることです。箱比喩の「値」は実はむしろ参照変数モデルの「値」に似ている・・ということ。

そこを逆手にとって、「箱比喩」の染みついた脳にも「フック比喩」をすんなり喉を通せてしまう、そんなちょっとしたトリック(=嘘)がありました。



その136

こちらも面白かった!

D

こんなこともあろうかとっ!

その137

わかったり聞いたりわからなかったりするはなし。

わたしも新人のとき先輩に「わからないところを何で聞きに来ないっ!」と怒られたことがありますが、「何処が解らないのか解らないんですっ!」と逆ギレ(?)して答えた思い出があります。

・・これはこれで、どうなんでしょ。


その138

もともと、あの説明は「参照からポインタに変換」とか、主に記法面での混乱と、コピーされているのか居ないのかがよくわからなくなってしまう混乱とかを取り除きたいというのがありました。

具体的には、箱変数と参照変数は、水と油のように思ってもらいたかったです。たとえば、

int i = 10;
int &r = i;

で、2行目の i は、「変数」ではなく「値」のことです。

一見「箱変数」と「参照変数」が直接関連を持てるように錯覚してしまいがちですが、i が右辺値として暗黙に値に置き換えられていて、参照変数と箱変数は、間に「値」に立ってもらう(仲介してもらう)事でしかお付き合いすることは出来ない、
まさに水と油です。「値」という界面活性剤が無いとダメな間柄です。

ここら辺の 間に「値」がワンクッションはさまっているというイメージが、「アハッ!」ポイントになるんじゃないかな、と期待してのものでした。

その139

http://www.takeda-shinichi.com/0-HP-memo/9-08/9-08.htm の 9/10(木)より、理系と文系のはなし。

 先日、あるブログを見ていたら、
「写真は体でおぼるもの」
 とあった。そして話は、
「ところがデジタル時代になってからは、何でも理屈で解決しようとする理系マインドが幅を利かせ過ぎていて、それに不安を感じる。」
 と続いた。
 だがおそらく、その方は理科系のことをご存じないのだろうと思う。理科系の研究には常に技術が付きまとうし、理科系の人は技術をとても大切にする。
 技術とは体得するものであり、理科系の人は職人でもあって、体で覚えることをむしろ重視するのだ。

 その点むしろ、僕は、文系の人の方が頭の中ですべてを解決してしたがる傾向にあるような気がする。自然写真家でも、理科系出身の人は技術者や職人肌である傾向が強く、文系出身の人は、議論好きで、むしろ理屈っぽい傾向があるように思う。

そうですよねーっ、と思いました。

その140

http://www.takeda-shinichi.com/0-HP-memo/9-09/9-09.htmの 9/8:光合成の水流 より、

 ある時、魚の調査のプロにある池を案内してもらった際に、そのプロが、
「この池は、午後になると水泳をする子供たちの影響で水が濁ってくるから、撮影はその前にした方がいいよ。」
 と教えてくださったのだが、僕はその池に潜ってみて、水が濁るのは子供たちの水泳の影響ではないと感じた。
 ではなぜ、午後になると水が濁るのか?
 それは、水草光合成だった。

僕にとってはその現象が、生き物たちのこと以上に興味深かった。水草から立ち上る酸素は微量であり、その水流も極めて微弱ではあっても、実はそれも水中の環境に影響を与えているのである。
 ということは、魚が泳ぐ際にできる水流にも、水をかき混ぜる役割があるだろう。水がかき混ぜられることは、おそらくその池にとって、重要なことであるに違いない。

「自然」と「人工」の区分けラインは、ここらへんにあるのかも、と思いました。



「人工」は人が設計したものですが、人の頭の複雑さへの脆弱性より、上記の自然のような設計はムリ。アレグザンダー(「パタンランゲージ」の人)の「人工都市」と「自然都市」の話みたいに。

パターン、Wiki、XP より

アレグザンダーは、人工都市がツリー構造になってしまう原因は、人間の認識能力の限界にあるとしました。人工都市は少数の建築家が全体を設計するため、複雑に絡み合った条件を必然的に少数の要素に還元して考えます。つまり、要素間の関連性は必然的にツリー構造に還元されてしまいます。それに対して長い年月を経てできあがる自然都市は、そのようなツリー構造を持ちません。1つの場所が複数の役割を同時に担うセミラティス構造を持っています。

(「パターン、Wiki、XP」より)


とすると、よく無根拠とバッサリ切って捨てられる、自然物を「安全」とありがたがって人工物を「危険」と思い込んでしまう思考は、人間の設計力(認識力)の限界ゆえ信じられない・・という直感なのかもしれないな、とか妄想したり。

その141

・・・なぁんて 思ってしまったのは、最近読んだ「パターン、Wiki、XP」に影響されて。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)


Smalltalk に惹かれ読んでみたのですが、トップダウンでツリーなアレはいくない、ユーザを仲間に引き入れてインクリメンタルに作っていこうぜっ!アジャイルだぜっ!・・みたいな話が、実は建築の世界――アレグザンダーの「パターン言語」 からの思想で、それがソフトウェアの世界に伝播していく物語が、すごくすごく面白く書かれています。

長らく積ん読してあったのですが、もっと早く読めば良かった!

その142

true tears のBlu-ray ですが、どうしましょう、と悩んでおります。

ごらんのとおり、わたくし true tears が大好きです。(ちなみにわたくし乃絵派ですの)

普段だったら絶対買ってたのですが、この不景気で収入は激減ですし、ボーナスも絶望的ですし、貯金を切り崩して買うしか手がない状況です。

本当にどうしたものかしら。うーむ。



ジャッジメントですの。

*1:箱モデルでの値は、DDDで言うところの Value Object みたいなもので、参照モデルでの値は DDDで言うところの Entities みたいなもの、というと解りやすい?・・いあいあ。