#あ、なんか言い逃げみたいになってしまってすいません。問題としている対象領域がまだあまりよく知られていないような場合だと、どう書いたって書いた人以外にはよく分からないのはしょうがないと思うんですけど、他の言語で分かりやすくかけるものを Lisp のマクロで分かりにくく書いちゃったら、そりゃあみんな逃げるよなあと思うんですよね。
#逆に、他の言語だとどうがんばっても 10 行くらい必要なコードを、さくっと 2 行くらいで、誰が見ても分かるようにかければ、Lisp すげぇ、ってなりそうですけど。
#マクロの定義そのものが複雑になるのは、それは問題そのものの複雑さを反映しているでしょうから、どの言語を使ってもそんなに変わらないはずですよね。
#同意。
#てすと
#予告。0.9.1は0.9とABI互換性があり0.9で入れた拡張モジュールがそのまま使えますが、ディレクトリ構成をいじったので、0.9.1_pre1や0.9.1_pre2で入れた拡張モジュールは使えません。あしからず。
#trunkを使う猛者ならば再インストールしてくれるであろう、と期待。
##ある程度の規模まで成長させちゃったら、移植のコストより教育もしくは必要に応じてコンサルというコストの方が安くなるんじゃないかと。
#メインの開発ラインには載らないけど、ちょいと便利なツールをスペアタイムで作る→便利だからみんな使い出す→だんだんツールが成長して規模もでかくなり、わりと重要な地位を占めることに、ってなパターン。最初の時点で選ぶとしたら別にLispじゃなくても良かったんだけど、既に成長しちゃった時点で気がつくと、別の言語に書き換えるにはコストがかかりすぎる規模になってた、ってことはあり得る。
#最初にわかってたら「Lispじゃ他人がメンテできないから止めて」と言われたかもしれないけど、成長しちゃった時点では後の祭り。まあそういう事態が起きないように、たとえスペアタイムに作るサイドツールであってもよくわからん言語を使うことを禁ずる、という措置を取られる危険はあるけど。
#でもここにはスタートアップの生態系との相似があって、「作ってみないと有用かどうかわからない」ようなアイディアをとりあえず実装してみる、ってインセンティブは、使用言語を制限したりすると抑圧される。結局、「万が一当たった場合に移行コストを抑えよう」と思って制限をかけると、その当たりに成長するかもしれない芽を最初からつんでしまうことになりかねない。
#0.9.1のリリースノート書きがおわらない。夏休みの宿題をぎりぎりになってやってる気分。今日はもう寝る。
Gauche > Archives > 2010/12/11