2003/09/23
なぜ翻訳書はダメなのか？： 翻訳には翻訳ならではのスキルや創造の余地があるんで、 自著が書けない人が翻訳をするというのは少し極論かもしれない。 （オリジナルと翻訳とは頭の使う場所が違うのでバランスを取るのにいいと 言ったのは村上龍だったっけ）。
むしろ、健全なフィードバックが作られにくいというのが翻訳の質を 上げにくい理由ではないか。原書が読める人は翻訳を手に取ってその 質を調べたりはしないから、まずい翻訳がけなされることは少ない。 一方で良質の翻訳をしても、原書の評判を上げこそすれ、 翻訳が広く褒められることはあまりない。
皆が原書を読めるならそれでも良いのだけれど、翻訳書の必要な場面が 無くなるとも思えない(自分も日英以外はほとんど全て、どちらかへの翻訳で 読んでいるし)。翻訳を評価するという行為がもっと一般的に なれば良いのかもしれない。でも、原書読んでから翻訳読むのは二度手間で 億劫なのは確かなんだよなあ。
なにぃぃぃっ→yomoyomo in Tokyo Reloaded。 その時間は東京にいたのに。 RHG読書会とハシゴすればよかった。
Tag: 翻訳
2003/09/15
「コードの再利用」ってのはオブジェクト指向アプローチの メリットとしてよく語られてたけど(最近はそうでもないか)、 実は関数指向アプローチの方がずっと コードの再利用がやりやすいように思える。
OOのコード再利用ってのは、 誰もがagreeできるような性質を持つオブジェクトに対しては可能だけど (stringとか、GUIコンポーネントとか)、そういうものはむしろ少なく、 同じものであっても見方によってモデリングの方法が変わって来ることの 方が多い。全ての見方に対応しようとするとインタフェースが爆発する。 色んな見方で組み立てられるように、要素を分割してモデリングして、 使うときに必要なものだけ集めてやろうとしても、継承使うなら 多重継承やmixinの嵐、コンポジションでやるのも小さなオブジェクトの 管理がめんどい。
関数指向は、ものの操作のみに注目する。 Scheme:オブジェクト指向表現?でちょっと話が出たけど、 例えば木のトラバースをする関数は、(1)対象物がleafであるかどうか、 (2)対象物の子ノードへ操作をマップ、の2種類の操作さえ与えられれば、 対象物が何であるかは知らなくてよいし、そもそも対象物が 木としての動作を本質的に備えている(e.g. treeインタフェースを持つ)ことさえも 要求しない。本来は木じゃないものを、たまたま一時的に 木として見たくなった、といった場合に、呼び出し側はその場で 上記(1)(2)の操作をでっちあげれば、トラバース関数が使える。
言い替えれば、関数指向では、全てのコンポーネントは、対象物に対して何も仮定を 置かなくて済むということだ。なぜなら必要な操作は呼び出し側が提供して くれるから。従って、汎用的な操作を部品化する時に「それが誰に、どのように 使われるか」を気にせずに、アルゴリズムのみに集中できる。
オブジェクト（クラス）指向はむしろ、具体的な問題が与えられた時に、 関数指向で用意された部品を集めて具体的なものを実現する際の骨組みとして 大いに役に立つ。 そういう骨組みは問題毎に異なるから、 多くのクラスはその問題専用に作られ、再利用されることはない。
つうわけで、「部品はFP」「アプリはOO」ってのが結構いいんじゃないかと 思う次第。
Tag: Programming
2003/08/27
PS2で一般的なn×m行列を扱う場合、quad wordに揃わない 場合の処理をごちゃごちゃやらなくちゃならないんで、VU使ってもあんまり 速くならない。COP1でアキュムレータをうまく使った方が速いこともある。
SIGGRAPHで会ったMさんとも話してたんだが、年喰ってくると アセンブラを触るのがだんだん億劫になる。 面白さはまだ感じるのだが、 やたら時間を取られるのがたまらんと思うようになってきた。 知識を得るにつれ、やりたいことは増える一方で、やれる時間は減る一方だから、 開発効率を上げていかんと話にならん。
Tags: Programming, Assembly
Comments (2)