Matzにっき

“The best way to predict the future is to invent it !” Alan Kay

ということで超並列を取り扱うスクリプト言語を“発明”する :-)

「並列化が行いやすい副作用のない関数型言語が今とは別の意味で注目される。」というのは、私も全く同感です。

Railsの本質ってなんでしょうか？ 松本さんはどうお考えですか

>並列性を人間に取り扱える形で(つまり、あまり見せないように)、取り扱える言語が求められるようになり、 FORTRANのベクトル化技術に類似するものが復権してスクリプト言語を含めて広く利用されるようになる。

DSPなんかの並列処理が得意なプロセッサでリアルタイム処理を書こうとすると,C言語でさえコンパイラの最適化の性能がおいつかなくてアセンブラで書くハメになったりするので,こういうのはすごくほしいです.

yuum3さん、
まわりの人に聞くと、それは動的言語的性質による変化への対応の速さと、(Rubyによる)プログラミングの快適さだそうです。Python, Lispとかならともかく、Javaでは難しそうですよね。
JavaにはJavaの快適さはありそうですけど、それはRailsとは違うものではないでしょうか。

だれも私には聞かないと思いますが、私が「Javaどうですか？」と聞かれたら、「いい言語だと思いますよ。もう少しコーディング量が少なくて済むならば。」と答えるようにしたいと思います。

まつもとさん、回答ありがとうございます！
私はRailsからRubyに入って来た人ですが、今はRubyが好きです。
Railsはセンスというかバランスの良さを感じますが、その良さが論理的に説明できないのです ^^;

先日のCTCユーザ会のイベントで聞いた話だと

  初期コスト Ruby >> Java
  実装コスト Ruby ≒ Java
  保守コスト Ruby >> Java

だそうで、で、最初のコストがしばしば取りざたされるが、実際にはこれはたいしたことはなくて(差は大きくても全体としての作業量も少ないから)、保守・変更コストが低いのが重要なのだそうです。

Javaでの変更が伴う保守コストがどれだけ大変なのか私は知らないのですが、普段はJ2EEばっかり使っているという人がそう言っていたので、そういうものなのだと思います。

で、Javaがその重要なコストである保守コストを下げることができるかですが、もちろん不可能ではないと思うのですが、

  * そのためにJavaらしさを失う
  * Railsとは違う道を選ぶ(生産性のため動的言語の代わりにIDEを使ったように)

のいずれかで、Railsを追うのはJavaにとって危険な道なんではないかなあ、という気がちょっとしてます。杞憂かもしれないけど。

とりあえずmapやeachの並列版があると面白いかなー、とか。

「mapやeachの並列版」というのは、発想は良いと思うのですが、ブロックを動的に評価しながら並列動作させなければならないと思うので、矛盾が起きないようにするのは、とても難しくないでしょうか？

私はハードウェア設計に使えるスクリプト言語を開発してほしいです・・・
VHDLを書いているとソフトウェアの世界から遅れすぎていて悲しくなります。

現実的なもの求めるとおそらく妥協が必要に感じます。map{|i| Thread.start(i) {|t| p t } } に近い動作をするものだったら楽かなーとは思うのですが。もっとも、実際にこれでどの程度うれしいかは難しいところ。

mapとかeachの評価順序って言語的には厳密に定義されているのでしょうか？
まあ、それはともかく、並列版があると面白いですね〜

配列の場合、インデックス順ということになってます(でないとinjectとか動かない)。しかし、Rubyにはそもそも「厳密な定義」は存在しないような。

ところで、ほんとにこんな並列動作するコレクションを作ろうと思ったら、OSレベルでメニーコアをサポートする機能が必要ではないかと思います。でないと、スレッド管理コストが高くて使い物にならなそう。それかpthreadライブラリが今よりもずっと高効率になるか。