NetBeansのRubyサポート

うわさには聞いていたが、かなり賢い。
Rubyのコードを解釈して補完してくれたりするのだが、Rubyの構文は人間には優しいがコンピュータには厄介な代物なので、よくやったなあと感心する。
これでIDEがないとプログラミングできないタイプの人もRailsに来るんじゃないかな。

# 本当はそういう奴はプログラミングの世界に来るべきじゃないんだが。

Blogged with the Flock Browser

NetBeans+JRuby+Rails

何気にNetBeansのRubyサポートはいい。
Glassfishの上でJRuby on Railsがさくっと動く。今はWEBrickベースなようだが、Glashfishを前提にした本番環境が出てくるだろうね。期待しよう。

Common Lispの美点

t2ruさんのCommon Lispの美点を読んで。

あえて付け加えるなら、最適化のための汚いコードをマクロの背後に隠すことができる点も強みとして加えてもいいかなあ。
現実のアプリケーションでは、いったん出来上がったコードに最適化のためのコードやアドホックな修正のためのコードが追加されることが多い。そうすると、普通の言語ではどんどん本来の処理が見えにくくなってしまう。その点、Common Lispなら大丈夫だ。

Objective Camlの使いどころ

カリー化がわかってみると、Objective Camlは良さげに思えてきた。
しかし、実際に何に使おうと思案してみると、意外に使いどころがない。

いや、どんな応用に使っても良いんだろうとは思う。
だが、僕にとっては速度を気にしないならRubyがfirst choiceで、速度が重要なのであればCommon Lispがfirst choiceになっている。そこに割って入るには、相応に理由付けが必要だ。

Ocamlのストロングポイントは、静的型付けの安全で効率的な実行可能ファイルを（Javaあたりなどと比べて）より短いコードで書けるところにあるだろう。
静的型付けという点を除くと、だいたいCommon Lispの方が勝る。特にコードが短くなる点と表現の自由度という点では勝負にならない。
だから、あえてOcamlを使うからには、プログラムの正しさをコンパイラで確認したいというニーズが必要だ。つまり、性能と正確さが要求されるケースだ。

その要求が成立するには、仕様をフォーマルに記述しうる状況が必要だ。RubyやCommon Lispには柔軟性があるから、仕様がフィックスしていない案件で力を発揮する。僕の仕事では、仕様がフィックスしないことの方が多いのだ。

ここ数日、Apacheのアクセスログを解析する高速なプログラムを書きたいと思っていて、Common Lispでやろうかと思っていたのだが、これこそOcamlの出番のように思われる。すでに運用中のプログラムがあるので、仕様はもう固まっているからだ。