2005/12/31
年の瀬である。ハワイでは年に2度しかない花火解禁日のひとつであるため、 これがチャンスとばかりに人々は街が煙ですっかり覆われるまで火薬を燃やし続けるのだ。 この国にはほどほどに楽しむというたしなみはあまり無い。
去年まではまあ我慢してれば良かったのだが、今年はらむ太が居る。 寝てれば音で起きるし、起きてればびっくりして泣くし、どうやって魔の数時間を 生き延びるかが本年の課題である (許可されているのは大晦日の21時から新年の1時まで、 ただ実際は夕方から2時くらいまでやってる)。 つうかこの事態は予想できたんだからさっさと静かなホテルでも取って避難する ことを考えていればよかったんだが、例によってぼさっとしてたら、もう大晦日である。 うーん、徹夜覚悟でドライブだろうか…
Tag: 生活
2005/12/24
るびま0012号で、 えとさんがhtmlを配列を使ったツリーで扱うわびさび方式 について書いているのだが、その欠点として「(文字列操作に比べて)遅くなる」 というのを挙げている。なぜだろう。
基本的にわびさび方式はSXMLなんかと同じなわけだが、SXMLで扱う場合、 データ構造の製作中はツリー同士の結合がツリーの大きさに係わらず O(1)でできるわけで、ナイーブな文字列連結のコストに対して非常に大きな ゲインだ。それに比べたら出力時の木のトラバースなんて問題にならない ように思える。なので遅くなる理由が思い付かない。
非常に単純なケースで、 バッファリング無し、フォーマッティング無しで文字列の断片を出力してく だけの処理ならツリーで扱うよりは速いだろうけれど。 エラー時の処理とか考えたら文字列で扱う場合でもどうしても一回は バッファリングが必要になると思うしなあ。
もちろん文字列の実装がスマートで内部的にツリーを使ってるなら 話は別だが。
Tag: Programming
2005/12/08
Paul GrahamのY Combinatorが出資した Reddit。最初はCommon Lispで書かれていたが、 つい最近Pythonで書き直された。 作者はLispに好意的ながらも、 スイッチの理由をいくつか述べている。 当然、Lisp界では議論が噴出。 ついに「へへん、俺なんかLispでクローンを1時間で書いちゃったぜ」なんてのも。
Lispの宣伝になるサイトが減るのは残念だけれど、個人的にはPythonで動くのなら それでいいんじゃないかって思う。この件や"Ruby is acceptable Lisp" の 記事でもって、Lisp界にも簡単なフレームワークとかproduction provenな ライブラリとかもっと大きなコミュニティとか必要じゃね? という話はあって それはそれで結構なのだけれど、もし他の言語で同じ位快適に同じ位良いソフトが書けるなら Lispが別言語に置き換わっても人類全体として損はしてないよな。
本当にLispの力が必要になるアプリは、逆にうんとハイエンドであったり、 開発リソースなどの他の条件が厳しい領域だろう。80年代のハードウェア で3DCGアニメーションを作る(WiLiKi:Lisp:Geometry)とか、あるいはもっと些細な例だけれど 限られた期間でがりがりチューンしてく場合とか (WiLiKi:Seminar:CommonLisp:2004の「ACL7.0の新しい正規表現」補足)。 そういう領域は決して大きくはならないけれど、無くなることもない。
そこにLispのエッジがあるのなら、たとえニッチであってもそのフロンティアを 広げて行くことを怠っちゃまずいだろうと思う。他の「人気の言語」と同じことを 後追いでやるのは、意味がなくはないけれど、それだけじゃねえ。
Tags: Programming, Lisp, YCombinator
2005/12/06
Binary 2.0、 ネタをここまで昇華するノリが素晴らしい。 行きたかったなあ。
感想を見ていると、軽量言語とは対極にある世界だ、というような言及が ちらほらあった。確かに高レベル言語の重要な機能の一つはプログラマが低レベルな 世界を気にしないで済むようにすることだけれど、二つの世界は表と裏、葉っぱと根っ子、 あるいは舞台と舞台裏。客として眺めるだけなら表を見ていればいいけれど、 この世界でプログラミングを生業とするなら両者は切っても切れない関係にあるはず。 何故なら、裏を知らないとトラブルに対応できないから。
だいたい、抽象度の高い、ハイレベルなものごとというのは泥くさい現実の ある面を特定の切り口で簡略化することで成り立っている。 (そもそも、デジタル回路からしてアナログな世界を閾値でえいやと 2分することで動いてるわけだし。) その際に、簡略化が成り立つ前提ってのが必ずある。システムが 正常動作してる間はそういう前提を余裕でクリアしているんだけれど、 システムがリミットぎりぎりまで使い込まれて、 マージンが無くなった時が問題だ。 トラブルとは、抽象化の壁のほつれである。 抽象化されたハイレベルな世界でいくら強固なロジックを組み立てても、 根元がぐらついたらそのロジックはぺしゃんこだ。 それを建て直すには、少なくともほつれた抽象化の壁の一つ向こうの 世界を知ってないとどうにもならない。
もう一つ、軽量言語と低レベルな世界をスペクトルの両端に置くのに 違和感があるのは、Lispでは両者はそんなに離れていないからかも。 inner loopを最適化する時は普通にdisassembleするし (そもそもdisassembleが言語仕様に含まれている)。
Tags: Programming, Conference
