Erlangについて思うこと
端的に言えば、言語的にはかなり古いのに今になって注目されているのが面白いというか。
このErlangの話題はどれくらい続くのかなあ。本1冊は出る位は続いてほしい。
ソフトウェア工学でのErlang
Usecase/OOSEのIvar Jacobsonがいたところでもあるので、ソフトウエア工学分野では、エリクソンの論文(電話業界の話ですが)が多いのです。Erlangはその中で結構言及されていた(言語自体のことはなくて、それで実装したとかそういう部分だけですが)のでだいぶ昔から知っていた。
論文中で元のC実装とソフトウエアエンジニアリングの結果としてのErlang再実装を比較してたりしていて、エンジニアリング関係なしに関数型言語ならそれだけで生産性(LOCの少なさとか)はCの何十倍になるんじゃないの、とかって感じで。
Wings 3Dの実装言語としてのErlang
その実装を始めて触ったきっかけはフリーの3DモデラーWings3DがErlangで実装されていたのを知ったときだった。コードはまったくわからなかったけど。
ちなみにWings3Dは当時フリーの3Dモデラーが少ない状況ではで結構重宝した。独特の操作だったけど、Blenderよりは形作りしやすかった。
ActorモデルのErlang
その後、Erlangのspawn/!(send)/receiveのActorモデルは、並行プログラミング関係の論文でよく見かけた。一時並行モデルの言語統合にのめりこんでたときがあったので。Stackless PythonとかPolyphonic C#とか、ScalaでActorとかの論文で。
直近だと http://d.hatena.ne.jp/bellbind/20070222 でJavaScript 1.7でyieldを使ったActorモデル実装をしてみたりしてる。Erlangとのマッピングでは、channelがProcessID、engine.addがspawn, channel.sendが!、yield channelがreceive。これに http://d.hatena.ne.jp/bellbind/20060315 で書いたパターンマッチングシステムを組み合わせれば、かなりErlangっぽくできると思う(taskとreceive channelの一体化は必要だけど)。
ただ、自分が一番Erlangで印象に残ったのはsend receiveよりも、むしろ並列処理でのタイムアウトのようなエラー処理の記述方法だった。メッセージ処理と同じようにかけるという点で。
