なんじゃこりゃぁー!

まあ、最初にわけがわからなくなるのが、代入?です。

最初に、変数X*1に10を代入します。

X = 10.

インタプリタで実行します。

続けて、

X = 4.

と入力するとエラーが出るそうです。なんで?

そういえば、どこかのページに、Erlangの変数は、

const int X = 10;

と同じようなイメージだと書いてありましたが、最初の代入(X = 10.)は、「物理アドレス上にストアされた10という数字に変数Xを結び付ける(束縛する)という操作なんだそうです。

そんでもって、一度、変数に(ポインタ?の)代入(でなくて束縛)をすると、二度とその値は変更できないんだそうです。

なにそれ?

そんでもって、二回目の代入(ではないのですが)(X = 4.)はまた意味が違って、「Xに結び付けられている数値と4は等価であると評価できるか?」という意味なんだそうです。

ですから、

X = 4 + 6.

は、(4+6)をXに代入するのではなく、Xに束縛された値と(4+6)の結果は同等であると見なせるか?
という意味なんだそうです。

#むしろ、数学の等号に近いですね。考え方としては。

ですから、Xという文字をみて、「Xは変数だろ?」とか、=という記号を見て、「当然、代入でしょ?」と思うと全然違うわけです。

#まあ、ここに効率よく、堅牢なプログラミングを可能にするための
#コアとなるコンセプトのようです。読み進めてみるとわかるんですけど。

*1:変数の最初の文字は大文字じゃなきゃだめなんだそうです。

歳をとると、新しい概念を受け入れるのがきつくなる?

前回紹介した、

プログラミングErlang

プログラミングErlang

この本を昨日買ってしまいました。

読んでみると、いままでのプログラミング本の感覚で読み進められないので、とても頭がつかれました。

#何がおかしいのかは、これから説明しますが。

読み進めながら、この本のことを思い出しました。

計算機プログラムの構造と解釈

計算機プログラムの構造と解釈

個人的にはLispについては、

  • 美しいとは思う。
  • でも括弧が多すぎて、書きづらいし、読みづらい。
  • 気軽にいつでも使うという雰囲気ではない。
  • 逆にEmacsのカスタマイズ以外に使わないんじゃないか?
  • 再帰ばっかり使って、そのうち動かなくなったりするんじゃないか?

といった程度の認識しかありませんでしたが、かなりいろいろ共通点があるような印象を受けました。

Erlangの方が個人的には書きやすそう?

Microsoft Parallel Extensions to .NET Framework 3.5, December 2007 Community Technology Preview

というわけで、並列計算や分散コンピューティング、遅延/動的評価の話をしていたところに、

Microsoft Parallel Extensions to .NET Framework 3.5, December 2007 Community Technology Preview

なんて素敵な.NET Frameworkの拡張が発表されていたりします。

#はやくいじってみたい!

DLRに関する話題

DLR resourcesというページにいろいろDLRに関する情報が出ていたりして、DLRも割と早く実用的なレベルに到達するのでは?と期待が膨らみます。

あと、こんなページもあって、

IronPython, IronRuby and F# openings in dev, test, and PM!

DLR関係のプロマネ(だと思うんだけど・・・?)が紹介されていたりします。

F#

こちらの方は、まだあまり情報がないのでよくわからないのですが、

  • CLR(というか.NET Framework)で(と言っていいのか微妙だが。)動作する関数型言語
  • C#の後継というわけではなく、C#の苦手な部分を補完する言語

だそうです。

.NET Frameworkが使えて、並行/分散プログラミングが簡単に書けるのであれば、かなり実用的になるのではないか?と期待されます。

#そもそもGUIアプリケーションのメッセージ通信なんて、みんな非同期通信だし。
#Webアプリケーションでも非同期通信が大流行ですから。

Erlang

なぜErlangに興味を持ったのか?と言いますと、

  • 簡単に並列プログラミングができる。
  • 簡単に分散コンピューティングができる。

という点です。

こういうことをやると、線形分離な演算や、非同期処理をするようなケースに簡潔かつハイパフォーマンスなコーディングができるのでは?と期待したわけです。

DSPやゲートアレイのようなハードウェアが得意とするような演算が、
#ハードウェア設計と同じような感覚でソフトで書けるかも!

しかし、いろいろ調べてみると、どうもErlang数値計算などは苦手のようですね。

あと、なかなかクセが強いというか、理解に苦しむのは、

  • なぜ、あんなにムキになって再帰を使わなきゃなんないのか?

というあたりでしょうか。

しかし、マルチプロセッサ化、マルチコア化、OSの仮想化などが進む昨今、こういった設計の言語が生産性と性能の向上の両方を支える技術になる時代は近いのかもしれません。

オープンソースコミュニティに頼りきっている私としては、もうちょっといろいろな
#ライブラリが充実して欲しいところです。

あと、早速買って読んでみたいと思ったのはこの本です。

プログラミングErlang

プログラミングErlang

関数型言語の時代の到来?

最近、医学論文のチェックもネタにするようにしてから、だんだん数学やプログラミングネタを書き込む時間がなくなってきちゃいました。

まあ、そんななかでも、ちょっと面白いと思ったのが、

の話題ですね。

いわゆる関数型言語と呼ばれるものらしく、私がちらちらネットや本屋で目にしていたのはHaskelだとか、Ocamlですが、積極的に乗り換えたい理由というのがよくわかりませんでした。

そもそも、関数型言語と聞いて、FORTRAN*1みたいなもの?なんて思っていたくらいなので、かなり勘違いしていたわけですが。

#カリー化だとか、ラムダ表現、遅延評価などは、結構スクリプト言語では当たり前に使えるので、
#私がよく使うIronPythonやRなどを超えるメリットを感じなかったわけです。

しかし、このテの言語の歴史は結構長いんですね。
Lispくらいしか実際に使ったことはなかったですが、Erlangなんて、どうして今までしらなかったんだろう?と不思議に思うくらいです。

*1:FORTRAN関数型言語ではなくて、手続き型言語なのですね。