Common Lisp, Scheme Part 14
■ このスレッドは過去ログ倉庫に格納されています
0334デフォルトの名無しさん
2006/01/15(日) 08:39:41開発はインタラクティブな処理系でやって、実行バージョンを
Stalinでコンパイルするとかやってる人はいるよね。
ただ、実行コードの速さってそれだけじゃあんまり訴求力が無いんだよね。
CPUのクロックだのキャッシュミスだのを削るような世界の連中は
大抵CかC++、時にアセンブラで仕事してて、Schemeなんて眼中にない。
流行のLLで抽象力を楽しんでる連中は、自分の言語がもう少し速く
なってくれたらとは思ってるけれど、実行速度だけが乗り換えの動機には
ならない(そもそも実行速度をあまり気にしないからその言語を選んだわけで)。
どっちのグループにも、少数ながら相手のグループの(速度|言語機能)を
横目で見ながらもなんらかの事情で自グループの言語を使わざるを得ない
連中がいる。めっさ速いScheme処理系を持ってけば、そういう連中は飛びつく
かもしれない。でも残り大多数は動かないだろう。
ひとつ突破口があるとすれば、めっさ速いScheme処理系をつくって、それで
流行のLLを実装することだ。結果がそのLLのデファクトの処理系より速ければ、
十分な乗り換えのインセンティブになる。乗り換えさせてから、「実は裏では
S式が動いててマクロだってほら自由自在〜」のように洗脳してゆくのだ。
■ このスレッドは過去ログ倉庫に格納されています