以下の記事の続編です。
note103.hateblo.jp
目的を共有する
前回の記事はわれながら丁寧に書いたなと思っていて、その時点で書き残したことはほとんどなかったのですが、ただ全体が長かったせいか、ちょっと意図が伝わっていないかな、と思える反応をいくつか見かけたので、まずは以下のまとめ部分を中心に、そもそもの目的について簡単に補足してみたいと思います。
変数は「箱」か? という問いに対しては、そうとも言えるし、そうじゃないとも言えます。
しかしいずれにせよ、大切なことは、「それが入門者にとって効果的なのかどうか」を考え続けることだと思います。
「とりあえずこんな風に説明しておけばいい」という標準的な例を洗練させながら、最終的には、その瞬間に目の前にいる「教わる人」に最適な説明を考えていくべきでしょう。
この最後の1行では、二つのことを言っています。
少しアレンジしつつ2行に分けると、このようになります。
- 「とりあえずこんな風に説明しておけばいい」という標準的な例を洗練させていけるといいな。
- でもそれはそれとして、最終的には一人ひとりの「教わる人」に最適な説明を考えていくべきだよな。
ぼくはこの二つは対立するものではなく、矛盾なく両立させることができると思っています。
より具体的に言うと、「もっと良い喩え話はないかなあ?」という考えは前者(1)にあたります。
そして、「喩え自体はなんでもよくて、教わる人が理解しやすければいい」という考え方は後者(2)です。
前回のぼくの結論は、「結局は2が大事だけど、現実的には1が必要とされる状況も少なくないから、1の質も継続的に高めていけるといいよね」みたいなことです。
しかしながら、Twitterなどで記事への反応を見てみると、1の「もっと良い喩え」に関する考えに対して、「結局は喩えなんだからそこにこだわっても意味ないよ」と、2の論理で打ち消すような意見が少なくないように感じました。
これは話が通じていません。長文ゆえの斜め読みのせいか、ぼくの文章が悪かったか、あるいはその両方でしょう。
くり返しますが、1と2は矛盾なく両立するものであり、打ち消し合うものではないと思います。
2を大切にしながら、1を洗練させられたらいいなあ、というのがぼくの言いたかったことです。
「わかりやすい」が意味するもの
ところで、本件に関する意見の中には、「箱の例を使ったほうがわかりやすいのだから云々」というものがいくつかありました。
しかし、これには以下のような疑問を感じます。
第一に、そこで言う「箱の方がわかりやすい」の「わかりやすさ」とは何を指しているのか? という疑問。
ぼく自身も前回の記事で、「箱の方が直感的」と書きましたが、しかし「具体的な箱のイメージを思い浮かべやすいこと」と、「変数を理解する際の助けになりやすいこと」は必ずしも一致しないような気もします。
もしかすると、そこで言われる「わかりやすさ」とは、「箱のイメージしやすさ」のことであって、それがいつのまにか「変数の理解しやすさ」にすり替わってしまっているのではないか、と思いました。
第二に、「箱の方が変数を理解しやすい」と言える根拠はなんだろう? という疑問もあります。
そのような実証研究が行われているのか、そしてその研究成果はすでに広く知れ渡っているものなのか。
おそらくそういうことではないですね。
これももしかすると、素朴に「箱自体のイメージのしやすさ」のことを言っているだけかもしれないと思っています。
ヒューリスティック
この話について考える際、何度か頭をよぎったのは「ヒューリスティック」という概念でした。
ぼくはこれまで、それについてくり返し言及しているので、またかと思う人もいるかもしれませんが、以前に別のブログに載せた引用を再掲します。
複雑なことにも私たちがなぜ直感的に意見を言えるのか、私から明快な説明を提案しよう。難しい質問に対してすぐには満足な答が出せないとき、システム1はもとの質問に関連する簡単な質問を見つけて、それに答えるからである。このように代わりの質問に答える操作を「置き換え(substitution)」と呼ぶ。ここでは、もともと答えるべき質問を「ターゲット質問」、代わりに答える簡単な質問を「ヒューリスティック質問」と呼ぶことにする。
ヒューリスティックの専門的な定義は、「困難な質問に対して、適切ではあるが往々にして不完全な答を見つけるための単純な手続き」である。ヒューリスティックという言葉は、「見つけた!」を意味するギリシャ語のユーレカを語源に持つ。(略)
ではここで、表1の左欄を見てほしい。ここに掲げられているのは難しい質問であり、どれ一つとっても、まともな答を出すためには他のもっと難しい問題に取り組まなければならない。
ターゲット質問 ヒューリスティック質問 絶滅危惧種を救うためにいくら寄付するか? 瀕死のイルカを見かけたらどんな気持ちになるか? 現在の生活はどのくらい幸福か? 今の自分は気分がいいか? 今から六ヶ月後の大統領の支持率はどの程度か? いま現在の大統領の人気はどの程度か? 高齢者を騙したフィナンシャル・アドバイザーにはどの程度の刑罰を与えるべきか? 金融詐欺に自分はどのくらい怒りを覚えるか? 次の予備選挙に立候補予定のこの女性は、政界でどこまで出世するか? この女性は誰か政界の大物と似ているか?
たとえば、絶滅危惧種以外に考慮すべき環境問題や社会問題は、他にどんなものがあるか。幸福とは何か。今後六ヶ月の間に政治はどのような展開になりそうか。他の金融犯罪に対する標準的な判決はどうなっているのか。候補者が直面する競争はどの程度厳しいのか、等々。
こうしたことを真剣に考え抜いてから答えるのは、どうみても現実的ではない。だがあなたは、完璧に論理的根拠のある答を出すには及ばない。ヒューリスティック質問に答えても、そこそこ筋は通る。このやり方はときにうまくいく――が、ときに重大なエラーにつながる。
右欄の質問は左欄の質問からたやすく思いつくし、答えるのも容易である。瀕死のイルカや金融詐欺に対する気持ち、自分の今の気分、候補者の政治的手腕の印象、大統領の今の人気などは、すぐに思い浮かぶことだろう。ヒューリスティック質問は、難しいターゲット質問に対しても、すぐさま答を出してくれる。(ダニエル・カーネマン『ファスト&スロー(上)』第9章より)
喩え話について考えているとけっこう頭を使いますし、その喩えと現実を結びつけながら次々に現れる矛盾を解消していこうとすると、負担はさらに増していきます。
だからその途中で、「あ〜面倒くさい! そもそも喩え話なんて本質的な問題じゃないんだから(以下略)」というふうに考えてしまっても、それはそれで自然なことだと思います。
とはいえ、冒頭にも書いたとおり「より良い喩えを考えてみよう」ということと、「どうすれば変数の概念をわかりやすく説明できるか」ということは、繋がってはいますが別々の問題です。
そしてこの「関係はあるけど別の問題」を、あたかも同じ問題であるかのように結びつけて、より答えやすい方の質問に答えてしまうという状況が上の引用で挙げたヒューリスティックというものです。
本件に関する反応には、そういった傾向が少なからずあるように思えました。
参照渡しと値渡し
一方、そのようなズレが生じてしまう理由は、ヒューリスティックによるものだけでなく、単に元記事の説明不足による場合もあるだろうと思っています。
たとえば、前回の話を「参照渡し」(CのポインタやPerlのリファレンスのような)の概念にまで広げて適用させようとしている人が何人かいましたが、ぼく自身は「初めてプログラミングを学ぶ人に変数を教えるなら」という前提で考えていたので、ここで言う「変数」とはあくまで初歩的な「値渡し」をするものであり、さらに言えば、Perlにおける「スカラー変数を使った値渡し」を想定していました。
「参照渡し」については、「値渡し/参照渡し」というふうに別々の名前が付けられていることからもわかるように、「値渡し」とは別の現象ですから、「箱」であれ「名札」であれ、ひとつの物をその両方に適用するというのはちょっと無理があるように感じています。
またそれに限らず、元々ぼくの方で暗黙のうちに設定していた様々な条件から外れた上での意見も複数あったので、こうした「喩え」に関する話、とくに「箱」や「名札」や「変数」のような一般的な(定義の曖昧な)名詞を使った喩え話について、不特定多数で考える際には、その土台となる条件・要素を可能なかぎり細かくすり合わせておかないと、不毛な状況になってしまいそうだなと感じました。
名札の問題
ところで、というかそれとも繋がる話で、これは後から気づいたことですが、前回「名札」の例を使った書籍として紹介した『初めてのRuby』では、名札のイラストを用いながら、じつは「参照渡し」が解説されていました。
ぼくは上記のとおり、前回の記事を書いた段階では「値渡し」についてのみ考えていたので、これにはけっこう驚きましたが、たしかに喩えの使用条件を限定すれば、その説明も成り立つとは思います。
またもう一点、これも後から気づいたことですが、その『初めてのRuby』や、同じく名札の例として挙げた『たのしいRuby』では、「名札」を旅行カバンに付ける荷札のように、実体(値・オブジェクト)と直接結びつかせるイメージとして使っていたので、これだと結果的に、箱の例がやっていることとあまり変わらないかな? とも思いました。
いずれにせよ、このことからもわかるように、名札には名札の問題があって、それは「名札」という言葉からイメージされるものが曖昧で、受け手にとって解釈の余地がありすぎるということです。
ちなみに、ではぼく自身は前回、「名札」と言いながらどんなものを想定していたのかというと、それは付箋や名刺のようなもので、同じ言葉(変数名)が記載されたそれを複製していくようなイメージで考えていました。
しかし後述のように、こうした喩えに人物の実名を交える場合は、書き換え可能な「変数」よりも書き換え不能な「定数」の例に使うほうが適切であるように今は思っているので、名刺は定数の説明に限定して使うべきかもしれません。
また、付箋の例だとそこには通常、変数名だけが記載され、それが指し示す対象の情報が入らないため、これもちょっと惜しい気がします。
あえて言えば、メールのように「件名(変数名)」と「本文(値)」を書き込める付箋(またはメモ用紙)という喩えなら諸条件をクリアできそうですが、実際にそのような道具や商品はあまり見かけないので、その点がちょっと弱いかもしれません。
新たな喩えの案
さて、そのように、既存のアイデアにそれぞれの問題があるのだとすれば、また新たな喩えを考えてみたくなるのが人情です。
これはあくまで楽しみとしての思索であり、その案を誰かに押しつけたいわけではまったくありませんが、この機会に考えたものをつらつら書いてみたいと思います。
「物体」ではなく「情報」として扱う
まず原則的な話として、「箱」や「名札(または付箋)」にどのような問題があったのかというと、実際のプログラミングでは物体ではないデータ(数値や文字や式など)を扱っているにもかかわらず、それを物体に置き換えようとしていた点に各種の不整合の原因があったように思えます。
ですから、ここからの案ではなるべく物体に置き換えるのではなく、それ自体は実体を持たないデータ・情報の領域から使える概念を探し、それに置き換えてみたいと思います。
値渡し(スカラー変数)
手始めは、最も初歩的かつ重要な値渡しの例ですが、これには「あだ名(ニックネーム)」、あるいは「仮の名前」という案を挙げたいと思います。
これらに共通するのは、「本名Aのことを仮名Bと呼ぶ」という、本来の名前を別の名前に付け替えるという行為です。
子供がどんな犬を見ても「わんわん」と言うとき、「わんわん」は変数(仮の名前)であり、そこで指し示される値(実体)は犬です。
そしてこの際、子供はその犬がゴールデン・レトリバーなのか、シベリアン・ハスキーなのか、柴犬なのかといった犬種を知らずとも、「わんわん」と言うことで「その犬」を指し示すことができ、これは次々と変数の値を更新し、また活用している状況を彷彿させます。
あるいは、自社にいる能力の高い社員を外部の人に紹介する際、「うちのエースです」などと言うことがありますが(実際にそういう現場に何度か遭遇したことがありますが)、ここで言う「エース」も仮の名前に入るでしょう。
この「仮の名前」があることによって、以前にそれを聞いた取引先の誰かが「ほら、なんという名前だっけ、御社のエースの……」と言えば、対象となる人物の実名を思い出せなくても、その人についての話を続けることができます。
これもまた、「一度宣言(+代入)すれば、その後は元の値をくり返し記述しなくても複数箇所で処理を進められる」という、変数を利用した状況に似ていると思います。
ちなみに、ここで大事なことは、その変数に格納される対象は交換可能な何かであって、交換不能ではない、ということです。
「わんわん」や「エース」は状況や時期によって交換可能ですが、もしこれが「イチロー」だった場合、それは厳密には本名ではない「仮の名前」ですが、とはいえ現実世界ではそこに格納される人物は一人だけですから、こうした名前は交換不能な「定数」の例として利用する方が適切だと考えられます。
値渡し(配列)
次に、配列の変数の例としては、プロ野球の「球団」と「打順」と「選手」の関係を使えるのではないかと考えています。
たとえば、「巨人の4番」といえば王貞治、原、落合、松井、清原、高橋……などが浮かびますが(世代によるでしょうが)、ここでは選手名が「値」、4番という打順が「添字」にあたります。Perlっぽく書くと、
print $巨人[4番];
という感じでしょうか。
実行すると、
みたいな。
(添字の4って実際は5番目だろ、というツッコミはご容赦ください)
あるいは年度も指定して、「配列の配列」とすればより具体的になりそうです。
print $巨人[2000年][4番];
実行。
値渡し(ハッシュ)
また、ハッシュ(連想配列・辞書型)の例としては、会社などの「肩書」や「役職」という案があります。
A商事の社長、B株式会社の営業部長、C銀行の広報担当というふうに、所属先の名前は基本的に一定ですが、それらの社名や肩書を通して呼び出される個々人は、人事異動のたびに入れ替わります。
たとえばマイクロソフトのCEOは、現在ナデラさんですから、以下のようになるでしょう。
print $マイクロソフト{CEO}; #=> サティア・ナデラ
あるいはこれも、年数と組み合わせれば「配列のハッシュ」の例に使えるでしょうか。
print $マイクロソフト[2008]{CEO}; #=> スティーブ・バルマー
参照渡し
さて、懸案の「参照渡し」ですが、これについては先に喩えを成立させるための条件を洗い出してみたいと思います。
第一に、これは変数であり、複数の場所に置いていろいろな人が同時に触れられることが前提ですから、変数自体が複製可能でなければいけません。
と同時に、この変数の中身を誰かがどこかで変更すると、他のすべての人の手元にあるそれの中身も変わってしまうものでなければいけません。
それで最初に思いついたのは、Wikipediaです。
Wikipediaは、基本的に誰もが自分の手元で更新でき、更新された情報はすべての人の目の前のスクリーンに反映されます。
「それを言ったらべつにWikipediaじゃなくても、掲示板やTwitterなどのWebサービスの大半がそれに該当するじゃないか」という気もしますが、まあ、イメージしやすいので……ということで。
とはいえ、コンピュータ・プログラミングの学習に関する喩え話で、コンピュータに関わる現象を例に使ってしまうのもちょっと筋が悪い気がするので、もう少し物質感のある、ソフトウェアから離れた例はないかと考えましたが、少し近いかなと思ったのは、新聞や雑誌、あるいはテレビやラジオにおける人生相談のような、ユーザー参加型のメディアです。
そういったメディアは不特定の人が購読・受信していて、たとえばラジオの人生相談のコーナーでは、リスナーの電話の声がそのままラジオ番組の内容を更新し、即座に他のリスナーの耳にも届きます。
ただ、これの問題は、あまり日常的には触れない事象だということですね。
もう一つ、いくつかの条件は無視することになりますが、感覚的に「これって参照渡しっぽいよなあ」と思う事例があって、それは「酔っ払ってTwitterに投稿すること」です。
覚えのある人ならわかると思いますが、当人はあくまで自分の半径数メートルぐらいの、ローカルな世界に対して何かを発信しているようなリラックスした(あるいは向こう見ずな)気分ですが、実際には仕事先や家族なども含む全世界のネットユーザーにその意見を開陳しているわけで、翌朝つらい気分になることも少なくありません。
これは値渡し(コピー)で得た手元の値に手を加えたつもりが、呼び出し元の実在に影響を与えていた、というときの冷たい驚きに通ずるものがあると思います。
寿限無
いろいろと考えてきましたが、最後に、本件に関する自分の原点のような例を挙げて終わりにしたいと思います。
じつはぼくが変数について考えるとき、いつも頭に思い浮かべる話が一つあって、それは落語の「寿限無」です。
もしもここに出てくる子供の名前を、実際の長々とした名前ではなく、「$寿限無」という数文字の変数に格納できていたら、話(噺)はずっとラクに進められるだろうに、と思います。
(もちろん落語の意味は変わってしまいますが)
これは前記した「仮の名前」の例でありながら、同時に落語の中のその子供、という特定の人物を収める変数なので、実際にはやはり定数の例として使ったほうが適切だと思いますが、とはいえ、ぼくが変数に対して「便利だなあ」と感じる以下の要素を満たしているという点で、それなりに有効と思われる題材です。
本来長い名前が入るはずの部分に変数「$寿限無」を使えば……
- 同じことを何度も言わずに済む。
- 修正をひとつの場所で行える。
- 1回修正すれば複数の箇所がすべて更新される。
- 複数の箇所を直す中で新たなミスが生まれるという事態を回避できる。