2009/10/05
登場人物の気持ちを述べよ
国語ネタを出したついでに。「この(台詞|行動)に込められた登場人物の気持ちを述べよ」 みたいな問題は「国語のわけのわからなさ/無意味さ」を示す例としてよく槍玉に上がるけれど、 この問い自体は無意味でもわけわからないものでもない。その証拠に、 今この瞬間にも、この問いを仕事の一貫として真剣に考えている人が たくさんいる。これは役者が脚本を読む時に必ず向き合う問いだからね。 役者に限らず、フィクションを咀嚼して自分の栄養として吸収したいなら、避けて通れない問いだ。
教科としての国語がうまくいってないとすれば、それはこの問いが悪いんじゃなくて、 大事な前提をちゃんと言ってないからだと思う。それは：
- この問いには唯一の正解はない。ただし、明らかな不正解はある。
ってこと。唯一の正解が無いからといって、何でも答えればいいとか考える意味がない ということにはならない。どういうのが不正解かっていうのは、理屈で説明できることも あるし、説明しにくいこともある。でも映画や芝居をみて登場人物の行動が 嘘くさかったり、登場人物に関心を持てなかったりしたら、それは役者が正解を当ててないことの かなり良いインディケータだ。観客は、たとえ役者がたどりついた「解」そのものが 何かをピンポイントで理解しなくても、その「解」が正しいか間違っているかについては 恐ろしいほど敏感に反応する。
学校の試験という場においては、明確な採点基準が必要とされるために、 この問いの意味が歪められてしまっているのだろう。よく「出題者の意図」がどうこう 言われるが、あれは採点のために「無数にありえる正解のうち、 特定のもの以外を排除できるように仕込んである不自然な仕掛け」を見抜くって話であって、 問いの本質とは離れてしまっているのだ。
問いの本質とは。これもまた、国語の授業ではっきり教えてくれれば良いのに あんまり教えてくれない事実である。
- この問題の意味は「どこかにあるはずの正解を探し当てる」のではなくて、「文章を素材にして回答者自身が正解を創造する」というところにある。
このことを知らずに、どこかに正解があると思ってる生徒にとって、 国語がわけわからなくなるのも無理はない。
テキストは、木の塊の表面に記されたスケッチだ。この問いに答えることは、 そのスケッチの線に忠実に沿いながら、立体像を掘り出すという作業になる。 元のスケッチの制約を満たす立体像は無数にありえるだろう。そのどれもが 正解なのだ。もっとも、「素直」に掘ってみたら大抵の人がたどり着くであろう 形というのはあって、それが回答として挙げられるにすぎない。 (高校の現代国語の試験で、私は時々「ひねくれた、しかし筋の通る解」を ひねり出して答えていた。教師もそれを面白がって満点をくれた。 国語が面白くなったのはそれからだ。)
あ、あともう一つ、国語で陽に教えてくれないけれど大事なこと。
- 作者がどう思って書いていたかは実はあんまり関係ない
今日もラジオ番組向けに数人の役者で短篇小説を読む公開録音を やってきたんだけど、その小説の作者本人が観客席にいて、 「こんなにおもしろい話だとは思わなかった」って感想をもらしてた。 役者がたどり着いた解釈が実は作者も想像してなかったことだったってのは、 かなりよくあることだ。でもそれで良いのだ。"whatever works" と良く言うのだけれど、 不正解でない限りどんな解釈でも許されるし、むしろ作者も自分の 想像を越えた解釈をされることを望んでいるだろう。そうなることが、 作品が作者の手を離れて自立した証なのだから。
(番組は12/22(火)と12/29(火)の2回に分けて、18:30から KIPO (89.3FM)でオンエア。ストリーミングもあるみたい。 詳しくはAloha Shortsのページに。)
2009/10/04
空気読み会話は日本人の専売特許じゃないよ
習った当時はなるほど、と感心したものだが、20年近く経って改めて思い出してみると、まったく恐るべきハイコンテクストというか、空気読み会話である。時計の箇所など、発される言葉のすべてにメタメッセージが載せられている。人間同士が会話のキャッチボールをしている背後で、スタンド同士がドドドドドドドと擬音つきで殴りあっているようなもの。西洋人にはおよそ理解できない、いかにも日本的なやり取りだろう。
その作品を読んだことはないのでもしかすると想像を絶する空気読み会話なのかも しれないけれど、一般的に言えば、会話文にメタメッセージ(subtext)を 載せるのは現代のテキストなら洋の東西は問わず普通のことで、 上のブログで紹介されている作品も解説を読む限りでは 「西洋人に理解できない、日本的なやりとり」であるようには見えない。
近代以降の戯曲やシナリオを読む場合は「登場人物は本音を台詞では語っていない」と いうのは出発点であって、良くできた芝居や映画では(たとえ「ハリウッド映画」で あろうとも良作なら)全ての会話シーンは「人間同士が会話のキャッチボールをしている背後で、 スタンド同士がドドドドドドドと擬音つきで殴りあっているようなもの」と言ってよい。 だってそう作ってるのだから。
しばしば英語圏での会話には腹の探り合いとか空気の読み合いが無いと思われる ことがあるが、それは異なる文化を持つもの同士が、 コンテキストを共有していないという自覚がある場合に、 敢えてノーコンテキストでストレートな会話をしているだけだ。 英語文化圏や英語文学自体に日本文化圏や日本文学に比べ コンテキストや空気の読み合いが欠如しているわけではない。 「わかりやすい」ハリウッド映画やsitcomは、 気楽に観れるようにわざとそう作っているってだけにすぎない (それが視聴者を適切に扱っているのかどうかは別。 なおsubtextの欠如という点では日本のテレビドラマの多くも どっこいどっこいに見える。)
2009/09/25
プログラミング言語の進化
プログラミング言語の歴史を眺めていると、経験の中から立ち現れるベストプラクティスを取り込んだものが多いことに気がつく。
- 構造化
- 例外サポート
- オブジェクト指向
- 並列サポート
言語の進化はベストプラクティスをサポートするためにあるんじゃなかろうか。
そういったケースが多いのは確かだろうけれど、それだけ見てるとまずいと思う。
言語というのは表現の道具であって、動作するプログラムを表現するには 言語を使うしかない。では、これらの「ベストプラクティス」が言語に 取り込まれる前には、どうやって表現されていたんだろう?
- 他の機能を組み合わせて無理やり表現していた (e.g. CによるOOP)
- プログラムとして表現するのを諦めて、自然言語で表現してプログラマが逐一実装してた (e.g. デザインパターン)
どちらにせよ、これは表現として不自然だ。 そのプラクティスが有用であることが既にわかってるなら、 不自然な表現でも何とかそれを使おうとして、やがてそれが広まり 言語にサポートされることになるわけだけれど、そもそも最初に そのプラクティスを始めようと思った人達は、どうやって その不自然な表現を乗り越えたんだろう?
例えば、内包表記は便利で、いろんな言語が採用し始めているけれど、 多くの言語は他の言語の内包表記を見て便利なことを知って採用したんだと思う。 内包表記のおおもとの起源は数学記法だけど、「これを プログラミング言語に取り込んだら便利だろう」と最初に思って 実行した人がいたはずだ。その時点では、内包表記は 「経験の中から立ち現れるベストプラクティス」ではなかったはずだ。 だってプログラミングで内包表記を使うという経験はそれまで無かったわけだから。
あるいはスタティックスコープ+無限エクステントでもいい。 スタティックスコープは前からあったけれど、それを無限エクステント にしてlambdaがクローズするようにしたら、funarg問題があっさり解決しちゃった。 でもSchemeがそれをやってみせるまで、人々はfunction特殊形式みたいな アドホックな方法でfunarg問題を解決しようとしてたわけで、 決してスタティックスコープ+無限エクステントがベストプラクティスと みなされてたわけじゃない。
つまり、プラクティスの中には、「実際にその言語機能を使って書いてみるまで それがベストかどうかわからない」というものがある。
代替の表現方法が「ちょっと面倒くさい」程度ならまだ、その手間をかけて まわりくどい方法で書いてみようという人はいるだろう。けれど、今ある言語機能では 実現するのが非常に面倒くさい、実現できるかどうかもよくわからない、 というプラクティスについては、よっぽどモティベーションが高くない限り、 遠回りな方法で今の言語上に実現してみようとは思わないはずだ。 ベストプラクティスを取り込むという点だけ見ていると、そういう妙な アイディアを見逃すことにはならないだろうか。
逆に、ベストかどうかわからないけど、妙なアイディアを思いついたら 気軽に言語の方を変えてそのアイディアを表現できるようにしてしまう。 そしてそれを使ってみる。うまくいけば広めればいいし、ダメならスクラップすればいい。 そういう過程もまた、言語の進化には重要だと思うのだ。
Tag: Programming
2009/09/21
らむ太の質問攻撃
噂には聞いていたが、これが質問攻めというやつか。
- とうさん、星の中には何が入ってるの?
- 星の中には火が燃えてるよ。
- とうさん、太陽の中には何が入ってるの?
- 太陽の中にも火が燃えてるよ。
- とうさん、木の中には何が入ってるの?
- 木の中には色々入ってるなあ。幹があって、根っこがあって、葉っぱがあって…
- とうさん、町の中には何が入ってるの?
- 町の中にはおうちがあって、ビルがあって、人がいて、車があって、道路があって…
- とうさん、あの横に長いのなあに?
- あれは電線
- とうさん、電線の中には何が入ってるの?
- 電線の中には電気が流れてるよ
- とうさん、タイヤの中には何が入ってるの?
- タイヤの中には空気が入ってるよ
- とうさん、ロボットの中には何が入ってるの?
- ロボットの中には部品が入ってるよ
- とうさん、ゆーちゅーぶの中には何が入ってるの?
- YouTubeの中にはビデオが入ってるよ
めちゃくちゃペースが速いのでちゃんとした答えを考えてる時間がない。 反射能力が試される。
Tag: 生活
2009/09/20
SICPのSchemeコード
書こうと思ってたネタなんだけど別のところ で書いたのでこっちに転記。
SICP is a really good book to learn what is abstraction in programing, but keep in mind that it intentionally uses very limited range of features of actual Scheme to achieve its goal---here by "actual Scheme" I mean Scheme that is used to write real programs. Some people seem to get an impression from SICP that Scheme is minimalistic and you have to write your own structure or object abstraction using cons cells and closures, and conclude it is not a practical language you can use in your jobs.
Any modern Scheme implementation, in which you can write code at work, consists of not only the standard core language (RnRS) but also a large body of SRFIs (a kind of common libraries) and implementation's extensions. Unfortunately the extension part is fragmented among implementations, but in general, any decent implementation is far from "minimalistic" and comes with rich tools. SICP tells that Scheme allows you to make your own abstraction, but that doesn't mean you have to make ones every time.
「SICPはSchemeを学ぶ本ではない」という理由はこれね。プログラミング言語についての 説明を最小限に止めたいためにSchemeを使ってるのだから、Schemeの機能のうちでも 説明に必要な最小限の機能しか出てこないよ、ということ。
もちろんその最小限の機能を組み立てて色々できちゃう、ってところが醍醐味で、 それは知ってないとならないんだけれど、現場のSchemeコードを書く時も 小さなコアから全部自分で組み立てるなんてことはしないってこと。
Tags: Programming, Scheme
