『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
春分の日でお休みなので、 下の二人を連れてフォーゲルパークへ。 鳥たちをみて喜んでいた。
モモイロペリカンがけっこう頑張って芸をしていた。 頭、いいのね。そうとう大きい(羽を広げると1.5m以上ありそう)が、 まだ生後10ヶ月というのも驚き。
しばらく前に献本していただいていた本を読む。
しばらく前に言語探訪で紹介していたりするのだが、 こうやってまとめて読んでみるとかなり知らないことが多い。
「ビット構文」とか、pack/unpackより便利かもしれない。 あと、多重代入の代わりにパターンマッチとか。
ただ、文法はちょっと分かりにくい。 よくわからない句読点のルールとか、endとか。
単一代入しかない関数型言語というのは 「普通の言語」とは、かなり異なったプログラミングスタイルを要求するが、 その故に便利な点も数多くあるなあ。副作用がないから プロセスが遠慮なく中断できる点とか。
しかし、改めて考えてみると Erlangってば、参照透過性はないし、 静的型はないし、関数型言語である必要はないのではないか。
Erlangを真に特徴づけているのは、
ではないだろうか。他のものは目立つけど実はそれほど重要じゃない。
アクターモデルがあるから、並列プログラミングが簡潔に記述でき、 値がimmutableであるから、「オブジェクトの状態」で悩むことがない。 オブジェクトのアイデンティティが重視されないから、 メモリ空間を超えて値を伝搬しても影響がない。
おまけに(GCの)実装としてはライトバリアが要らなかったり、 循環参照がないことも保証されるから、リファレンスカウントでも十分だったりするのもありがたい。
としたら、たとえばRubyとそっくりな外観で 値がすべてimmutableな言語があったとしたら、どうだろう。 関数型というパラダイムの代わりにオブジェクト指向というパラダイムを提供する Erlang的な言語。
文字列や配列についてはさほど問題はないだろう。 Pythonをはじめ文字列がimmutableな言語は珍しくないし、 配列も(一部の「容器」として使っている場合以外は)大丈夫。
問題になりそうなのは、 ハッシュやオブジェクトである。 これらが状態を持たない、というのはかなりプログラミングスタイルに変革を要求しそう。
そもそも書けるんだろうか。 入出力とかはLazyなSequenceとして扱うんだろうか。
Ruby on Railsを使っている有名企業。
あまり公表はされてないが筆者(Obie Fernandez)の知ってるのでは、他に
もある。
>循環参照がないことも保証される
高階関数があれば、そうではないのでは。
クロージャがselfをキャプチャしちゃうということでしょうか。
それだけならいくらでも対応できそうですが。
それ以外にもありましたっけ。
Erlangはよく分からないのですが、プログラミング言語も極まってくると、対称性が自発的に破れて来るものなのでしょうか?
クロージャを使ったlazyなデータ構造では、単に自分自身への直接的な参照にとどまらず、相互に参照し合う循環的なグラフ構造が作れてしまうと思うのですが。
そうか。そうですね。
ということは、GC的にはうれしさはあまりないのかな。