2013/03/14

#permalink

ピアノレッスン86回目

Bach: Well-Tempered Clavier Book I No. 3 (C♯ major)
- Prelude, Fugueともに曲としてまとまってきた。細かいところを磨くのにもう一週。
Scriabin: Sonata No.4
- 超スローだけど最後までなんとか通し。何度も弾いているとだんだん曲の組み立てが見えてきた。ロマンチックなようだけれど構造としてはかなり厳格で緻密に作られている曲だなあ。

Tag: Piano

Comments (0)

2013/03/13

#permalink

リベラルアーツ

東工大と比較して、MITでのリベラルアーツ教育が充実しているって記事なんだけど、なんか論点というか見るべきところが微妙にずれてるような妙な感じがした。

私が大学生だった20年前と現在で日本の大学も変わっている、とか、東大は総合大学だから事情が違ったとかいう可能性はあるけど。

MITがリベラルアーツに力を入れる理由として、MITの文科系学部の先生の言葉を引いている。

大学で電子工学や機械工学を学び、そこで得た知識でコンピュータや自動車を作るとしても、その製品は社会に存在し、人間に使われるわけです。ならば、作り手に回る理系の人間こそ、社会と人間のことを徹底的に知っていなければ、理解しなければ、コミュニケーションがとれなければダメです。だから『教養』を身につける必要があるのです。

これと全く同じことを、大学に入った時にさんざん聞かされた。だから別に日本の大学がこういうことを考えていないってわけじゃないんじゃないかなあ。わざわざ「あのMITではこう言っている！」って引っ張ってくる言葉ではないような。

とはいえ東大の教養課程がこの記事にあるMITのように充実してたかというとそうでもないんだけど、それは理念の問題じゃなくて実践の問題だったんじゃないか、と思う。まあ、それは実際に記事中で触れられているんだけど：

かつて、日本の大学では今よりも教養教育を重視していたけれど、さきほど上田さんがおっしゃった「学び方――how to learn」については、ちゃんと教えてこなかった。

ところが記事の後半から、(最初の記事の「日本の大学では実学重視の要請を受けて教養を削ってきた」という流れを受けて) いやMITでもライティングやプレゼンなど実学指向のトレーニングもしているよ、という話題になる。

ただ知識を習得するだけでなく、論評し、考えをプレゼンする技法も身につけるわけですものね。教養の授業でありながら、実学も織り込まれている。教養と実学が二項対立ではなく、むしろセットになっている。

これを「教養と実学という二つのものをセットにしている」ってとらえるところからボタンを掛け違えているような気がする。

何にせよ学ぶということは表現することと表裏一体だ。頭の中に入れただけで「分かった」と「分かってるつもり」の区別をつけるのは非常に難しい。脳は自分に見えるものしか見ないので、「分かっていないこと」を見ることができないからだ。欠けている部分を自覚するには、一旦外に出して、他者の目を通してフィードバックを受ける必要がある。

そして、「自分が何を分かっていないかを分かる」ことはおそらく最も重要な「学ぶ技法」だ。

ライティングやプレゼンというのは実用になるテクニックという以前の、学ぶための基本的テクニック、あるいは学びの基礎練習だ。別々のものをセットにしてるんじゃなくて、必要なことをやってるだけ。

だから問題の根っこは教養の軽視とかいう以前にあるような気がしてならないし、この記事を見て「じゃあとにかく教養科目を充実させよう!」とか「実学指向のプレゼンテクニックも教えよう!」って流れになるとすれば、なんか違う。

何を教えるにしても、まずきちんと学ぶ場を作る。それがないとその上に何を作ってもすぐ崩れちゃうんじゃないかなあ。

(余談。日本で演劇教育がほとんど根付いていないのは何でかってずっと疑問に思っているのだけど、表現することに力が入れられてないっていう要因はあるのかも。教養の典型例としてシェークスピアが引き合いに出されることがあるけど、あれは読んだだけじゃわからないよ。演って初めて「わかる」。)

Tags: 教育, 大学

Comments (2)

2013/03/11

#permalink

時定数の大きな話とCL

こないだのコードの変更と型付けにちょっと関連して、向井さんが変更の時定数が大きい実例を書かれていた。 GUIでの座標管理。これまでひとつの座標系で済ませていたところに、複数の座標系を導入しなければならなくなった、という話。

古くて新しいGUI座標系の型の話

common-lispではいい手はあるのかな？　generic functionやオプショナルな型チェックはできるだろうし、マクロを使って型チェックを導入する（しかもリリースビルドではチェックを省略するとか）できるだろう。が、そう簡単にはいかないのではないか？という気がする。どこにチェックするかを指定する、ということは、テストを書くのと同じぐらい大変だ。型レベルの変更は、コンパイラが網羅的に検証してくれるので、楽だ、というのがここでの要旨なので。

Common Lispでやるとすれば、「これまで単なる整数で扱っていたものをオプショナルに実行時型付きで扱えるようにして、クリティカルな部分から徐々に変えてゆく」みたいな手順になるかなあ。

例えばこんなマクロを書いといて:

https://gist.github.com/5136967

(def-coords-macro global)
(def-coords-macro root)
(def-coords-macro display)

とする。そんで、例えばルートウィンドウの座標系を受け取る関数があったら:

(defun root-window-hoge (rx ry args)
  ... 
  (let ((gx (convert-to-global rx))
        (gy (convert-to-global ry)))
    (global-window-hoge gx gy ...)))

checking-root-coordsマクロで定義をラップする、などしてゆく。あと座標を他の関数に渡すところをboxで包んでゆく。

(checking-root-coords (rx ry)
  (defun root-window-hoge (rx ry args)
    ...
    (let ((gx (convert-to-global rx))
          (gy (convert-to-global ry)))
      (global-window-hoge (box-global gx) (box-global gy) ...)))
  )

この段階では、checking-root-coordsマクロでラップされた関数は、タグ付けされた座標 ((root . 100) とか) も生の数値も受け入れるので部分的に変更していっても全体は崩さない。呼び出し側で間違えた型をつけたときだけエラーが出る。

そんで、変更が全体に普及したと思ったら、def-coords-macro の定義を変えて、 unbox が生の数値を受けとるとエラーを出すようにする。

まあ、これもそこらじゅうにキャストをつけて回るようなものなんで、静的型でもってそれぞれの座標を別の型にして修正して回るのと手間は変わらんのじゃないか、と言われればその通りではある。 C++なら暗黙の型変換使えば、部分的に修正中でもコンパイルは通せるだろうし。

ただまあCLだと、型宣言とか性能計測用マクロを仕込むためだとかでこんな感じの全体を囲むマクロを作ることがちょくちょくあるので、そういうのが既にあるところに乗っかる形でアドホックな実行時型チェックを楽に仕込める、こともある。

もっとも現実には、こういうアドホックなマクロは締切りに迫られて大急ぎで書かれるせいでドキュメントとかが全然無くて、後からプロジェクトにjoinした人が暗号のようなマクロを解読するハメになってマクロ嫌いになったりするのだが。

Tags: Programming, Lisp

Comments (0)