2011/11/30
ピアノレッスン25回目
- 基礎: スケール、アルペジオ M=144。B♭ majorで両手がばらけるのは、 下降に転じた時に左が遅れるからということがわかった。
- ベトベン、テンペストソナタ1〜3楽章通し。「好きなのはよく分かるが、気持ちが入りすぎて荒くなってる ("too wild")。フレーズの変わり目でミスが多発するから特に注意。あとどんどん速くなるので気をつけること。」
Tag: Piano
2011/11/30
Meisner intensive 3回目の4
速いペースで進行
- Three moments -> repetition
- Independent Activity
- Emotional preparation
今日のIndependent Activityは個人的にリアルで集中できるタスクを 用意してったんだけど (D-subコネクタのハンダ付け)、集中しすぎて 相手へのフォーカスが十分で無く、 エクササイズとしてはあんまりうまく行かなかった。
日常生活でIndependent Activityのようなシチュエーションに なることはとてもよくある (集中して仕事してるときに話しかけられてむっとするとか)。 あれは、外乱にも反応しなければならないっていう義務感があるから コンフリクトが起きるんだよなあ。単に機械的にrepetitionをしている だけだとダメなのかもしれない。
Tag: 芝居
2011/11/28
Win32のstatの妙な振る舞い
GaucheのMinGW版のtest failureを潰してて気づいたのだけれど、 ローカルな時刻が1970/1/1 00:00以前になるタイムスタンプを持つ ファイルに対して _stat() を呼ぶと、struct statの対応する タイムスタンプ位置にUINT_MAXが入ってくるようだ (Vista SP2で確認)。 うちの場合GMT-10なので、UTCで36000以下の値を_utimeでセットすると、 _statで読み出した時に値がUINT_MAXになる。 dirで見るとちゃんと設定されてるので、 statの実装のどっかでUTCではなくローカルタイムを見てエラーとして弾いちゃってるとかかな。
まあ現実的に問題になることはないと思うが、 ちゃんとマニュアルに書いといてくれないと時間を無駄にするではないか。 POSIX互換インタフェースなんて重視してないのかもしれないが。
… と書いたが、よく見たらGaucheは_stat()ではなくstat()を呼んでるんで、 これはMinGWのせいかな? ソース見てみる。
いや、直接_stat()を呼んでも同じだった。やっぱりWin32の方だ。
Tag: Programming
2011/11/25
教育について
ここで何回か内田樹さんのブログの記事に 批判的に言及したことがあったけれど、 単に「何か言いたくなった」時だけ言及してるからそうなってるだけで、 別に何から何まで批判的に見てるわけではない。 特に教育についてのエントリは深く頷くことが多い。 このエントリは全くその通りだと思った。
ところで内田さんはしばしば「市場原理主義者」に言及するするんだけれど、 内田さんの描写するところの彼らは、どうもあまり賢くない、B級映画の悪役のような 雰囲気を漂わせている。実際にそういう人たちがいるのか、それとも内田さんが誇張しているのか、 それは判断がつかないのだけれど。
例えば上のエントリでは批判対象として、「骨の髄まで市場原理と競争原理に毒された」 教育施策があげられていて、それは「国際競争に勝つため」の教育だという。
教育の目的は競争に勝つことだと書いてあります。競争に勝てる人材を育成することだ、と書いてあります。彼らは「激化する国際競争」にしか興味がないんです。だから、教育現場でもさらに子供同士の競争を激化させ、英語がしゃべれて、コンピュータが使えて、一日２０時間働いても倒れないような体力があって、弱いもの能力のないものを叩き落とすことにやましさを感じないような人間を作り出したいと本気で思っている。
けれど、市場や競争のことを知っている人なら誰だって、一番強いのは 「競争に勝つ人」ではなく、「競争のルールを作る人」だってことを知っている。 真の市場原理主義者ならば、「ルールを作れる人間」を 育てることを志向するはずだ。つまり、既存のルールに疑問を持ち、 声を上げ、新たなルールを提案して周囲を説得して納得させる、 という過程こそを教えなければならない。 現在のルールを疑わずそれに向けて最適化することだけに長けても、 ルールを変え得る人には決して勝てないのだから、 前者を教育目標にするのは初めから負ける手である。
だから内田氏が言うように、「市場原理主義者」が本心から上のような教育方針を 信じているのかってことが疑問なんだよなあ。 むしろ、密かに一部のエリートだけルールを作れる教育を施し、 残りを従順なソルジャーにするつもりだと考える方が整合性があるような。 そりゃ陰謀論になっちゃうか。
でも、上の「市場原理主義者の教育方針」が「建前」にすぎないとしたら、 そこだけ正面から批判してても相手はあんまり痛くないんではないかな、という気もする。 まあ、本音がわからない段階では表向きは建前を批判しておくしかないわけで、 内田さんもそう思って仕方なくやってるのかもしれない。でもそれなら、 内田さんの「市場原理主義教育施策批判」そのものもまた、 建前ということになる。そこにちょっと弱さを感じる。
Tag: 教育
2011/11/25
多段ビルド文化
The price of a messy codebase: No LaTeX for the iPad - Valletta Ventures
表題から、増築を繰り返した老舗旅館みたいなコードベースは移植しようにも手がつけられないよ、って話かと思って読んだら、まあそうなんだけど、ちょっと違うニュアンスもあった。そんで複雑な気分になった。
基本的には、LaTeXをiPadに移植するために単一バイナリ化しようとしたけれど諦めたって話。 正確には、多段のビルドプロセス (大元のソースαをプログラムβで処理して得られた言語γのソースδを別のプログラムεによって言語ζのソースηに変換しそれをζコンパイラでコンパイルして得られるオブジェクトθとやはり言語ζで書かれた拡張ライブラリιをリンクして…) をさんざん苦労しながら移植してたんだけど、kpathseaがランタイムにbashスクリプトを呼んでそっから別のバイナリを呼び出してて、それを単一バイナリで実行するならbashインタプリタを内蔵しないとだめじゃん、ってとこで心が折れた、というようなことらしい。
まあ似たような経験あるからその気持ちはわかる。時々、ソフトウェアって庭つくりみたいだなと思うことがある。一度作ったら完成、ってんじゃなくって、継続的に手をかけてやらないと、色々枯れたり雑草が生えたりしてしまいには荒地と区別つかなくなる。昔のコードに戻って古いスタイルを整理していると、雑草取りしてるみたいだなあと感じたり。
ただ、元記事は要点がちょっと混ざってる気がした。(La)TeXのコードベースがレガシーを引きずってて無用に複雑化している、書き直せばもっとすっきりするはず、っていうのと、複数言語の混用とか多段のビルドが移植の障害になってる、っていう点。前者については完全同意なんだけど。
これは言語実装者の性向なのかもしれないけど、「ソースコードを生成する」というのに私はあまり抵抗がない、というより、少しでも「機械的に」ソースを書かなければならないことがあると積極的にそこを自動生成しようとする。Cがメインだった頃にもawkでプリプロセッサ書いて記述量減らしたりとか、Cソースをパーズしてメタ情報を取り出してインタプリタから呼ぶスタブコード生成したりとか。そうやって多段に抽象化を重ねられることがソフトウェアの強みなんだから、むしろそういうのを推奨すべきだと思ってる。
最近の統合開発環境に馴染めない理由のひとつは、統合開発環境が「ソース」→「バイナリ」の一段変換を前提としてデザインされている感じがすることだ。もちろん設定をいろいろいじれば、「まずこのソースをこのスクリプトで変換してからコンパイルして、出来たバイナリでデータを読み込んでソースに変換して、それを別のソースと合わせてコンパイル」みたいなことを記述できるけれど、一気に面倒臭くなる。makefileなら一段ビルドも多段ビルドも同じくらい簡単なのに。まあ、新しい技術についていけないロートルになっただけかもしれないんだけど、こういう多段生成をやりにくくするっていうのは、技術の大事な面をそぎ落としてるような気がするんだなあ。
言語内にメタプログラミングの機能があればソースからの一段変換前提でも色々なことが出来る。あるいはIDEにコード生成機能をつけてみたりとか。でもそれらは部分的な解決であって、単純な問題の一部だけを取り出して大げさに解決しているように見える。(C++のテンプレートは強力で、特に型に触れるところはLispのマクロより強いと思うけれど。例えば外部のデータファイルをコンパイル時に読み込んで宣言を生成したかったら?)
こういう多段の抽象化の積み重ねに自分が触れたのって、思い返すとKernighan/Pikeの『The Unix Programming Environment』でUnixを学び始めた時だと思う。既存のツールをシェルスクリプトで組み合わせる。それで足りなければ、足りない機能ひとつを実現するプログラムをCで書く。Cでの表記が冗長になるなら、「Cプログラムを生成するプログラム」を使う。この文化では、kpathseaが実行時にシェルスクリプトを呼び出すのは自然だ。それぞれの言語が得意分野を分担して、それを組み合わせて使えばいい。私はこの文化は「良いこと」だと思ってるので、それがレガシーになってしまうとしたらちょいと寂しい。
まあ、選択肢が「Cか、グルー言語(shとかawkとか)か」しか無かった時代(Lispはあったけど…)に比べ、今ではほぼ両方の領域をカバーできる単一言語の選択肢が増えているんで、今ならそういうスクリプト言語で全部書き直す、って選択肢はありだと思う。でも、多言語混在、多段ビルドがふさわしいものについて、「将来別プラットフォームへの移植が大変だから」という理由でまわりくどい単一言語、一段ビルドにこだわるのは、長期的にみて良くないんじゃないか。新しい抽象化は、それまで積み上げた抽象化の上に作られるものだ。 積み上げることを許さない環境は、新たな抽象化の芽を摘んでしまう。
レガシーなスクリプトの移植に関しては、新しい言語がそういうものを解釈できるようになってれば良いんじゃなかろうか。Gaucheでもいつかbash互換モジュールを書きたいと思ってるんだけど、なかなか手をつけられずにいる。それが出来たらログインシェルをgoshにするんだけど。
Tag: Programming
Comments (2)