いつの間にか日経ソフトウェアから日経エレクトロニクスへ異動した 大森さんによるErlangの紹介。しかし、いまだに心の中で「えるらんぐ」と発音しちゃうな。 正解は「あーらん」です。
さて、この記事には事実とやや異なる点がいくつかある。その辺を指摘しておこう。
まず、一番気になる点はタイトルから。「組み込みから生まれた」とあるが これは私の知る限りでは事実に反する。
Erlangは，1987年ごろにスウェーデンのEricssonで開発されました。元々は，信頼性が要求される通信機器のために設計された組み込み用のプログラミング言語です。
確かにErlangは「1987年ごろにスウェーデンのEricssonで開発」されており、 「信頼性が要求される通信機器のために設計された」が、 その通信機器とは電話交換機である。 電話交換機はそれはそれで面白い領域ではあるのだが(CHILLのような専用言語もある)、 しかし、一般的には「組み込み」とは言わない分野だと思う。
もうひとつは、私がこの言語に感じている思いについて。
まつもと氏は今でもErlangがお気に入りらしく，今年4月には自身のWeb日記で，「次」に来る言語の候補としてErlangの名前を挙げています
もちろん、私がErlangに注目しているのは事実で、 私を経由してはじめてErlangを知った人も多いだろうとは思う。 また、「次の言語」の候補として名前を挙げたこともある。
しかし、Erlangは最初から私の「お気に入り」の言語ではない。 たとえばLispがそうであるようには。 Erlangと比較するならばPythonでさえ、私のお気に入り言語と呼んでもよいと思う。
では、私はErlangの何に注目して、何が気に入らないのか。
注目しているのは、もちろん、アクターモデル(プロセスモデルと呼んでもπ計算モデルと呼んでもよいのかもしれない)による、高生産性並列プログラミングである。
たいたいにおいて並列プログラミングは難しいのだが、 Erlangにおいては、他言語のオブジェクトと同程度に軽量な「プロセス」と、 それらの間のメッセージ通信モデルにより、比較的簡単かつ高生産性で 並列プログラミング可能である。
しかも、関数型言語として値がimmutableであるが故に 同期や排他制御のコストがない(または低い)ので、 コアの数が増えれば増えるほど性能が向上する点も見逃せない (ただし、Erlang言語処理系そのものが驚くほど速いわけではない、らしい)。
気に入らない点は3つ。
ひとつは文法。Erlangには文法に気を使わない人によって設計された言語の臭いがする。 慣れの問題かもしれないけど、正直、Erlangの文法はお世辞にもわかりやすいとはいえない。
もうひとつは計算モデル。個人的に関数型言語はどうにも相性が悪いのだが、 Erlangはさらに相性の悪い論理型言語(具体的にはProlog)の感触もある。 これもかなり慣れの問題で、気にならない人は気にならないだろう。
最後も非常に個人的なことなのだが、ソースコードが読みにくい。 「Erlangの秘密」を探ろうと思ってソースコードを眺めたのだが、 どこになにがあるのかさっぱりわからなかった。残念。 もっとも、他の人にとってはRubyのソースコードだって読みやすくないかもしれないわけで、 「お前に言われたくない」と思った人もいるかもしれない。
というわけで、正直な感想は「Erlangは注目すべき言語だが、おそらくは将来の他言語に影響を与える礎になるのではないか」である。
RubiniusのEvan Phoenixのインタビュー。
そうか、こんな風にしてるんだね。 まだRubiniusのソースコード読んでなかったよ。
しかし、これはこれで茨の道だと思うけど、 それをある程度動くところまで持っていったEvanの努力(と根気)は 大したものだと思う。
こんどはJRuby方面。
ある種のメソッドは予約語にしたい、という話。 以前、ささだくんも似たようなことを言ってたから気持ちはわかる。
ある種のメソッドとは
要するにコールフレームに属する情報を参照したり書き換えたりするメソッド。 たとえば、evalとかlocal_variablesとかがあがっている。
うーん、どうしよう。確かにそうするとコンパイル時にできることが増えて、 うれしい(特に実装者が)というのは理解できるけど、 予約語が増えるとろくなことはないし。悩ましい。
それにString#gsubとかIO#getsのような「普通の顔をしてるけど、 実は特殊なメソッド」をどうするのかとか考えると夜も眠れない。
で、最近は結構午前中に寝てたりする。
とりあえず、String#gsubについては、 ブロックにMatchDataを渡す新しいメソッドを用意するのはどうだろうか。 より使用を促すためString#sとか短い名前を付けるのが良さそう。
Rubyのためのリファクタリングツール。
実際に使ってはいないが、ドキュメントを読んだり スクリーンキャストを見たりする限りでは結構いろいろと リファクタリングを自動化できそう。
私自身はEmacsでバリバリと書いちゃって、 リファクタリングツールなんて使わないオールドタイプだけど、 それはそれとしてリファクタリングツールがあるのは良いことだ。
あー、こういう風なソフトウェア開発っていいなあ。
って、今でも好き勝手に開発してるんだから、 こういう風に開発できるようにすればいいのに。
そうか、私はチーム開発が圧倒的に苦手だから、 こういうスタイルの開発をまともにしたことがないのか。 それはそれで反省したり、いろいろ考えたりすべきことだろう。
でも、こういうのをTracよりももっと積極的に支援するツールって あったらうれしいんじゃないかな。それともTracで十分？