このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

プログラマの「常識、理解、説明」の中間報告(になってない)

まず、ちょっと経緯と状況の説明を。

最初、「『プログラマの常識』ってなによ?」ってエントリを僕が書いたのだけど、「プログラマの常識」って表現が誤解を招きやすかった、謝罪します(見出しの訂正はしないけど)。一般的な文脈で「プログラマの常識とは何か」という議論をする気は全然ないので、 そのての話はナシ

僕の問題意識としては、「理解の基盤」とか「説明の方法」だったのです(→「常識」というよりは「理解の基盤」と「説明の方法」)。で、その意図をちゃんと汲んでいただいたトラックバックをいただいたのですが、あらためて、いろんな論点があるんだなー、と感じましたね。それらの論点を整理するのは難しいので、“とりとめもない”スタイルでゴチャゴチャ書きますよ、っと。

こんなご意見・ご助言があった

最初は、tenyさんのエントリー。んっ、んん? このセミコロン2つってのは…

;; いや、勝手な思い込みですが。

tenyさんて、旧ten.blog.mu.tcのtenさんみたいね。

ああ、以前にも檜山さんにはゾウガメ時間の教えを頂いているというのに……

そうか、ゾウガメ昔、言いましたよ、そんなこと。それでね、「ゾウガメの飼育」なんて検索でここに到達する人がいるんです。ペットにゾウガメ飼うのでしょうか、それとも動物園の人かな?

いやいや、そんな話じゃなかった。tenyさん曰く:

プログラマにとっての常識とか前提知識とか、所謂、`暗黙知' に相当する様な概念を、まだそれが培われていない人にどの様に伝えるか、という様なことがテーマになっている様に思われます。

まさにそのとおりです。これに関して、bonotakeさんが非常にうまい表現をしてまして:

「最もポピュラーとなりうる操作的意味論を定義するには、どんな抽象機械を想定すればいいか」



「どういう操作的意味論を論じれば、一般のプログラマに最も自然に受け入れられるか」

そう、理解や説明の拠り所となる抽象機械なんですよ、僕が問題にしたいのは。それとですね、そういう抽象機械の概念が、最初にどう獲得されるのか、どうやったらうまく概念形成できるのだろうか、ってことを知りたい。

tenyさんとbonotakeさんのエントリーには、なぜか呼応するフレーズがあったりします。
teny

スタックフレームを仮定してしまうと、スタックメカニズムの存在しない処理系 (メインフレームなど) のプログラマにはちょっと苦しいかもしれないなあ、などとは思ってしまいました。
いや、メインフレーム (汎用機) でも C 言語などの実行環境が載ってるならエミュレートされているので問題ないでしょうが。

bonotake:

たとえばスタックを想定して書かれたソフトを動かすにはスタックを備えたハードウェアが必ず必要になるんです。もちろん「これがスタックです」という物理的な機構が存在する必要はなくて、等価で自然な実現方法が別にあればそれで代替可能なわけですが、いずれにしろ、「スタックを実現する何か」は必要になってきます。

現実のハードウェアにスタック機構があるかないか、ってのは大した問題ではありません。ハードウェア機構ではなくて概念としてのスタックを知って欲しい。さらには、スタックを経由して理解して欲しいのはむしろ、サブルーチン(関数、手続き、メソッドなどをひっくるめて、かつ幾分視線をローレベルに下げてこう呼ぶことにする)の概念ですね。サブルーチンからの“戻り”を実現するために、戻り番地スタックはいるけど、引数&戻り値スタックはそれとは別(スタックもう一本)でもいい(式の評価が簡単になる)し、なんなら、ローカル変数領域はヒープにとってもいいですよね(return buffer;しても大丈夫:-))。

いまの問題意識を再確認

さて、1つ前の段落では、意図的に「スタック」、「サブルーチン」、「ヒープ」とか使ってみました。そんな用語が散らばったこの段落を理解できる人も、よく分からない人もいるでしょう。そこに今回の僕の問題意識があるのだけど:

  1. 技術的トークのなかで、「スタック」、「サブルーチン(関数とかメソッドでもいいよ)」、「ヒープ」なんて用語・概念は「常識」として使いたい。
  2. しかし、誰であれ、最初からこれらの用語・概念を知っていたわけではない。
  3. あるときに、学習し理解した経験・経緯があるはず。
  4. また、これから学習し理解する(であろう)人々もいる。
  5. 最初の学習/理解のときに、どうように概念提示と認知モデル形成をするのが適切か、効果的か?

当初の、“前提/基礎知識の明白化”から、“学習/理解/教育/トレーニング”のほうに論点がスライドしているきらいはあるのですが、「知っておくべきことを知る」というテーマで通底してます。

これから考えること

で、現状で僕が「もっと考えなきゃな」と思っているは次のようなことです。

  1. 「実装」という言葉を明確にした上で、「説明は実装に依存すべきでない」という主張の意味と妥当性を考える。(川俣さんの示唆)
  2. 抽象機械、あるいはそれによる認知モデルに対して、その抽象度はどのくらいが適切なのか、と考える。(bonotakeさんの示唆)
  3. 「理解する」とは言っても、理解する当人のそれまでの経験や属する“文化圏”の影響はまぬがれない。それをどう考慮すべきか。(tenyさんの示唆)

それはそうとしてさ、bonotakeさんのこのエントリはメチャ笑えた(実感がわかなくて笑えない人、実感がありすぎて笑えない人がいるだろうが)。