2014/07/21

プログラムは書いたとおりに動くのか

もちろん、コードはバグも含めて書いてあるとおりに動く。だからプログラマは自分の意図をなるべく無駄なく正確に記述出来る言語を望むわけだ。自分が思うとおりにプログラムを動かしたいからね。

けれども、プログラムの振る舞いというのは、書いてあるコードだけでは決まらない。矛盾するようだけど、「決まる」のレイヤが違うのだ。

プログラムの出力は、当然、コードだけでなく与えられたデータで決まる。プログラムの目的が、ただデータを受け取り処理して出力するだけなら、その処理過程はコードにすべて記されているのだから、コードがすべてと言える。

けれども現実のプログラムのほとんどは、プログラムとしての入出力の他にもデータを抱えていて、プログラム総体としての動作はコードだけでなく内部データにも依存している。プログラマとしては、自分の責任はコードが仕様通り動くところまでだよ、望む動作をさせるために必要なデータは各自用意してね、と言いたいところだけど、ユーザから見れば、どこまでがコードで決まりどこから内部データ=内部状態に依存しているかはどうでも良いことだ。

昨今は、プログラムがユーザから見て「正しく」動くためにこの内部データの比重がどんどん増しているように思う。例えば統計的スパムフィルタ。ユーザから見た「正しい動作」とは、ユーザがスパムだと思うメールを弾いて、ユーザがそう思わないメールを通すことだ。コードだけ見ていくら正しさを検証したとしても、ユーザにとっての正しい動作は保証できない。ユーザにとっての正しい動作に近づけるには、データの性質に沿うようにコードを変形させ適合させてゆく必要がある。

また、コードとデータの境界というのは、それほどはっきりしているものでもない。

ゲームのエフェクト。アーティストが用意したデータファイルを読み込んで表示するようにするか、プログラム的に生成するか、一部は素材として読み込んで一部はプログラムで生成するか、どこに線を引くべきかは、開発リソースにも依存するし、どんな出力が欲しいかによっても変わってくる。出来を見ながら試行錯誤する段階で、線引きがころころ変わることもある。実装上も、外部ファイルから読んでいればいかにもデータっぽいが、プリプロセッサ通して静的なデータとしてプログラムにリンクしたり、さらにデータからパラメータを抽出してそれを埋め込んだコードを生成したり、とやってゆくとどこまでがコードかわからない。

言語処理系をいじってるとコードとデータの境界は相対的なものにしか見えなくなる。 Scheme処理系にとって、処理対象のSchemeプログラムはデータだ。 GaucheがSchemeスクリプトを読んで何か意味のある動作をする時、 Gaucheに着目すればSchemeスクリプト自体は内部データだが、 Schemeを見ればそれはコードだ。しかも総体としてのプログラムにとって、 Schemeコードが実行時解釈されているかコンパイルされてコードの一部になっているかはどこまで部分評価してるかという程度問題で、ユーザにとっては意味をもたない。

★ ★ ★

さて。自分の書いたコードについて、その動作を隅から隅まで把握し、正しさを保証したい、と思うのはプログラマとして無理からぬことである。静的型システムや、副作用の排除といった枠組みはそれを助けてくれる。

でも、それで完璧に正しいコードが書けたとしても、プログラムの動作を決めている内部データの方がうんと大きかったら、それで保証される正しさはごく限定的なものになる。

むしろ、現在のソフトウェアの趨勢を見ていると、未来のプログラムのあり方というのは、何だか良く分からない可塑性のある膨大なデータが永続的に存在していて、各種プログラムは後付けでそこにそれぞれの意味を見出して寄生するような形になるかもしれない。

入力データの仕様と出力データの仕様が決まってからプログラムが書かれるのではなく、プログラムを書きながら、バージョンアップを重ねながら、当初見えなかったデータの「かたち」を彫り出して、思いもかけなかった出力を得てゆく、そういう「プログラミング」の重要性が増してゆくかもしれない。

Tag: Programming

Comment (1)

2014/07/20

#permalink

誠実さ

プログラミング教育における「ふたこぶラクダ」の話はプログラマ界隈では有名だろう。 2006年の論文で、プログラミングの入門教育をすると、好成績グループと低成績グループの二つの山に分かれる、そして好成績をおさめられるかどうかは、生徒があらかじめ「一貫したメンタルモデル」を持っているかどうかでだいたい決まる--- つまり、メンタルモデルを持ってない生徒にはいくら教えても無駄になる可能性が高い--- という話 (少なくとも、そう受け取られた話)だ。

Coding Horrorで取り上げられたのがポピュラーになった一因かな。

わかりやすいサマリ

60%の人間はプログラミングの素質がない

その当の論文の著者から、「あれは言い過ぎでした。取り消します。」という記事が出された。

Camels and humps: retraction

元論文にあるテストを行ってかような結果が得られたのは事実で、しかもその実験自体には再現性がある。しかし、その実験事実からだけでは、「一貫したメンタルモデルを持ってる生徒がプログラミングをマスターしやすく、そうでない生徒は落ちこぼれやすい」ということは言えない、ということだそうだ。

科学的事実というのは、直接目に見えないことが多い。見て分かるものがすべてなら手品師は皆本物の魔術師だ。人間の目や体験は事実を正しく捉えられないからこそ、様々な測定をして客観的な指標を得ようとする。けれども、その実験が本当に欲しいものを測っているのかどうかを判断するのは難しい。

実験は、目隠しして対象物に触ってるようなものだ。触って、何らかの感触が得られたなら、そういう感触が得られたというのは事実だ。でも触っているものが本当に触りたかったものなのか、それは別に証明しないとならない。「触っているものが違うものだったとしたら、どういう可能性があるか」「直接触ってるつもりで間に何か別のものが挟まってるとしたら、どういう可能性があるか」といったことを思いつく限り列挙して、それらの可能性を排除するような実験を組む。それでも、全ての可能性を網羅することはできない。ただ、そうやって慎重に実験を重ねることで、徐々に元の仮説の蓋然性が高まってゆくだけだ。

元論文の実験は、何かの事実を指している可能性がある。けれどもふたこぶラクダ現象自体は別の説明が可能で、また使われたテストが本当に見ていたのは何かもはっきりとはわからない。科学的に誠実な態度は、「まだわからない」ということになる。

上のretractionの記事は、少々読んでて苦しくなるのだけれど、誠実さというのが伝わってくる文章だった。

Tags: Programming, Science

Comments (14)

2014/07/19

#permalink

ピアノレッスン133回目

Ginastera: Tres Piezas - 1. Cuyana
- AIPF終了後、前からやってみたかったGinasteraにチャレンジしようといくつか注文していた楽譜がやっと先週届いたのでひとまずこれをさらっていった。
- 木管とギターの2重奏みたいな感じ? 録音を聞くと結構和声的なんだけど、譜面では左手は和声だけじゃなくて半音階的進行の対旋律で結構忙しい。うまく主旋律と絡むと良い感じになるが、クリアさを保ったまま速くしてゆくのは難しそうだ。
Beethoven: Waldstein
- 第1楽章、ヒナステラにかまけててあまりさらえなかった。後半ぐだぐだ。
- 左手に旋律が移るところ、ちゃんと意識すること。

Tag: Piano

Comments (0)

2014/07/05

#permalink

ピアノレッスン132回目

Beethoven: Sonata No.21 (Waldstein)
- 第一楽章ゆっくり通し
- 旋律が単音、伴奏が重音の時、旋律が薄くなりがちなのでバランスに注意
- 第二主題、上声の旋律を均一につなげる
- 早いパッセージからオクターブに変わるところ、音がつぶれる感じになってるのでもっと軽く掴むように

さて、新曲を持っていってみたのだけれど、今習っている先生が今月一杯でハワイを離れてしまうそうな。今月末までにヴァルトシュタイン全部は出来ないなあ。

今の先生とやりたい曲がまだ数曲、キューに残っているのだけれど残念。

Tag: Piano

Comments (0)