Lisp

僕のバイト先の会社では，ちょっとしたCADのプログラムを書いている．画面に入力された線分群から特定の図形を構成しているものを抽出したりとか，そんな感じだ．これは，相当に複雑なプログラミングであると言えよう．

しかし，歴史的な理由でうちの会社で利用しているプログラミング言語はVBである．まあいろいろ考えるとVBも悪くはないのだが，しかしこういう複雑な問題に対してはどう考えても力不足であろう．構造体が再帰的に定義できないとか，ポインタに相当する概念が存在しないとか*1，まあVBのおもちゃみたいな部分にも歯がゆい思いをするのだが，本当の問題はこんなことではない．

つまり，ファーストクラスのクロージャが欲しい．

FORTRANやCOBOL，Cくらいしかなかった時代に，CADのプログラムはLispで書かれていることが多かったらしい．これ，納得．Lispで大正解だよ，ほんと．

うちの会社もいつまでもVBでやるわけにもいくまい．そうなると，やはり.NETに乗り換えることになるだろう．そのときまでに，ちゃんとしたLispのコンパイラが登場してると，できればVisualStudioでサポートされてると，実に嬉しい．

あ，自分でやれって？

※追記１

今見たらC#にもクロージャ入るみたいね．Genericsも入るみたいだし，.Netもそろそろ成熟してきたかな．これは期待できる．Microsoftのいつものパターンだけど，.net frameworkやVS.Netも三度目のバージョンアップで，やっと使おうって気にさせてくれたか．

β版落とそうかな・・・

※追記２

C#のGenericsはC++のTemplateとはずいぶん違うようだ．C++のTemplateが（よくも悪くも）「詰まるところマクロ」だったのに対し，ずいぶんと変な制約が加えられている．あと，匿名関数（要するにクロージャか）の実装にも癖がありそうななさそうな．

この辺は，すこし調べてみる必要があるな・・・

JavaのGenericsはMSのC#の資料ではぼろくそに言われているが，興味深い．曰く，要するに自動でダウンキャストとかしてくれるだけだから，パフォーマンスは全然改善しない，と．確かに，こんなGenericsならいらないな．

Partial Typeに関しては，気が狂っているとしか考えられない．C++より便利になったとは，とても思えない．

※追記３−Genericsの制約に付いて

public class Dictionary<KeyType, ValType> where KeyType :IComparable
{
   public void Add(KeyType key, ValType val)
   {
      ...
      switch(key.CompareTo(x))
      {
      }
      ...
   }
}

みたいに，whereとかで型の制約を明記しなくてはならないらしい．って，これって今までどおりに

public class Dictionar
{
  public void Add(IComparable key, object val)
  {
    ....

と書くのとどう違うんだろうか．

JavaのGenericsがプログラマの手を省くことを目的として実装されている（様に見える）のとは対照的に，こちらはBoxing-Unboxingに伴うオーバーヘッドを解消したいだけに見える．

この方向性の差異は，なかなか興味深い．

僕としては，がんばって型推論しろよと言ってみたい．

あと，どうでもいいんだけどどうしてMSのサンプルコードはインデント幅3なんだろうか．これがMS標準？気が狂ってる！

*1:これは誇張だけど