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
2011/11/24
業界
--新人を採用するときには、何を重視しますか？
3DCGを作るにあたって、どの方向を向いているかですね。よく誤解している人がいるんですが「CG業界」なんていう大きな業界は存在しないんですよ。あるのはアニメ、実写、CM、ゲーム、建築、パチンコなど、細分化された各種業界です。CGはただの技術であって業界ではない。
「プログラマ」も同じだなあ。どの「細かい業界」にいるかによって、扱う対象も違うし優先順位も違う。優先順位が違えば選ぶ技術も違ってくるし、必要な知識も違ってくるし、何が良いやり方で何がまずいやり方かも違う。常識さえ違ってくる。
職を探す段階で「プログラマになりたい」というのはあまりに曖昧で指針になり得ない。ある意味プログラミングのスキルとは「文章を書くスキル」みたいなもので、職種によって必要条件のひとつではあるけど、「文章が書きたいです、文章を書かせてください」って志望してこられても困るわな。
もっと前の段階、具体的な職など考えてない時に、コンピュータを操ることの面白さに目覚めて、将来こういうことを仕事にしたいなあと思う、というのはありだと思う。小学生とか中学生くらいの時。でも大学生くらいになったら (今なら中高生でも十分) 現場に潜り込むチャンスはあるんで、潜り込んでみてプログラムを作るということがどういうふうに現実の問題を解決してるのかを知ったら良いと思う。
それも、出来れば複数の分野を見ておくといい。異なる常識に触れることで、特定の分野の常識を絶対のものだと思い込んでしまうことが防げる。それに、ある分野の発展が行き詰まっている時にそれを打開するアイディアは、他の分野からもたらされることが多い。アイディアをとられた方の業界人が「そんなことこっちでは20年前からやってるよ、ちっとも新しくないね」なんてくさすこともあるけれど、そういう人たちは自分のアイディアを他業界に応用できなかったわけで、いつだって実際に作って動かした人がエラいのだ。
関連エントリ:
Tags: Programming, Career
2011/11/23
ピアノレッスン24回目
午前中はらむ太の学校でThanksgivingのちょっとしたイベント (お芝居+potluck party)。 今朝ちょっと熱っぽかったんだけど、どうしても行きたいというので薬呑ませて様子みて、熱が下がったからイベントの前に連れてった。人前で何かするっていうのよりも、みんなで何かするってのが楽しいようだ。
先週撮影したToyota HawaiiのTV Spotがもう流れてるらしい。複数人から「あら、あなた昨日TVで見たわよ」と言われる。TV見る人って周囲を見ると減ってる感じだけど、それでも未だにTVのリーチって大きいな。TV広告料をかける理由がわかる。
パーティの途中で抜け出して、らむ太をかみさんに任せてレッスンへ。
- 基礎: スケール、アルペジオ M=144。左右がばらけないように気をつける。上に行って折り返すところで乱れがち。
- ベトベン、テンペストソナタ第3楽章。八分音符=120で一応通した。この曲覚えにくい〜。和声はだいたいわかるんだけど、起点となる音を覚えとかないと混乱する (展開部のところとか)。起点となる音でメロディラインを考えればいいのかな。クレシェンドしていきなりp、というところがいくつか出てくるがそのクレシェンドを見落としてるところがあって注意をうける。あとclosing themeの左手がうるさくならないように。
Tag: Piano
2011/11/23
Meisner intensive 3回目の3
RepetitionとThree momentsを復習した後、Independent Activity。
本日のquote: "There's no nothing." 反応するものが無い、なんてことはありえない。相手役、舞台の空間、あらゆる場所に反応すべきものはある。それが見えていないだけだ。
Split of focusについて: 役者はreality of doingへのfocusを失わずに、かつ周囲の出来事やテクニカルな詳細(mark、タイミング、カメラ位置など)に敏感に反応しなければならない。Independent Activityはその訓練でもある。
Meisnerではないけれど、split of focusに良いエクササイズの紹介
- 4人でやる。2人が向かい合って座り(A,B)、その後ろに補助で一人づつ立つ(Aの後ろにC、Bの後ろにD)
- AとD, BとCがそれぞれチーム。
- AはDが瞬きしたら立ち上がる。BはCが瞬きしたら立ち上がる。(立った後はすぐ座る)
- DはBが立ち上がろうとしたら背中を叩く。CはAが立ち上がろうとしたら背中を叩く。
- AとBは与えられた題でディベートする。どういうディベートをしても良いが、発言を途切れさせてはいけない。瞬きを見て立ち上がるアクションが無かったかのように発言を続けつつ、かつ背中を叩かれるのを避ける。
(追記2011/11/24 04:13:52 UTC): もうひとつ思い出した。"Often we hear an actor looking at the script and saying ``I wouldn't to this.'' or ``The character wouldn't do this.'' Then don't take the role. Your job, as an actor, is to find a compelling reason you can believe to do so."
Tag: 芝居
2011/11/21
海外のカンファレンス
ここ2ヶ月の間で3度海外の技術系カンファレンスに参加した。以前、「なんとなく海外のプログラマはスキルが高いのではないか」と思っていたのだが、期待ほどではなく、私の胸が熱くなるような話は少なかった。私が観測した限りでは、日本人の方がスキルも高いし、面白いことをやっている人が多い。
「海外のカンファレンス」でくくるのが多分良くなくて、
- 地域限定の集まり
- 「全世界」からその分野の選りすぐりが競って発表するところ
は全然別ですがな。前者については海外だろうが日本だろうが 似たようなもので、むしろ東京は技術者の密度が高いから地域的な 集まりとしては面白い方になると思う。
で、後者は、交通の便さえ良ければどこでやってもいいので 「海外のカンファレンス」とは限らないんだけど、 日本国外で開催されることも多いし、わざわざ海外に出かけて行く機会としては そういうカンファレンスの方が多いだろうから、一般的には「海外のカンファレンス」の 印象としてそっちが強くなりがちなんだろう。 それと国内の地域的カンファレンスを比べたら、そりゃ 全世界のてっぺんが集まる方が面白いに決まってる。 日本がぶっちぎりで進んでる、って分野でなければね。 「海外ってすごそう」っていう感じはそのへんから来てそう。自分はそうだったなあ。
「国内」「海外」っていう分類が、(旅行の手間という要素以外では)もはや あまり意味をなさないのだと思う。
あーでも成果は英語でも発信しといた方が、 網を英語圏に広げられるので良い。 同好の志を近く(国内)で探さなきゃならんってことは無いわけだから。
Tag: Conference
Comments (0)