『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
_ Seasarメディア準備号 - ひがインタビューひがさん、めっちゃRails意識してます、という話。
私自身はJavaやその上のSeasarを使う必要も、予定も、興味もないのだが、 技術動向としてはいつも注目している。
そういう「部外者の観点」から見ると、 Seasarプロジェクトのプロダクトは、 どれがなんだかすぐにわからなくなる。 Churaってなにとか、Buriってなにとか。
沖縄語(方言と呼ぶべき？)に使えそうな語彙がたくさんあるのは、 すごくいいことだと思うけど、耳になじんでないうえに、 それぞれの単語とプロジェクトの間に 連想が効かないのは結構つらい。
きっと中に入ってなじんでしまったら、なんでもないんことなんだろうな。
ところで、ChuraはJava界のRailsになることができるのだろうか。 つまり、適切なフレームワークの設計やツールの支援があれば、 Ruby抜きでRails(の本質)を実現できるのだろうか。
個人的にはLisp on Railsならば、やれば出来そうな気がするけど、 Java on Railsってのは相当難しい気がする。 たとえ、「3分でWebアプリケーション」が作れても。
そこはしばしばRailsの利点といわれているけれども、 Railsの本質はそこではないような気がするから。
_ 20XX年のユビキタス、ロボット、Web／Ｔｅｃｈ総研対象領域が近いのでえとさんの予測が特におもしろかった。
未来予測は当てようと思うとしんどいが、 利害関係なくただ単に考えるだけならけっこう面白いなあ。
じゃあ、私も予測してみよう。
プログラミング言語も超メニーコアの時代になって、 1PCに65536個くらいCPUが載るようになると 並列性を人間に取り扱える形で(つまり、あまり見せないように)、 取り扱える言語が求められるようになり、 FORTRANのベクトル化技術に類似するものが復権して スクリプト言語を含めて広く利用されるようになる。
か、並列化が行いやすい副作用のない関数型言語が今とは別の意味で注目される。
とかね。
This work is licensed under a Creative Commons License.
“The best way to predict the future is to invent it !” Alan Kay
ということで超並列を取り扱うスクリプト言語を“発明”する :-)
「並列化が行いやすい副作用のない関数型言語が今とは別の意味で注目される。」というのは、私も全く同感です。
Railsの本質ってなんでしょうか？ 松本さんはどうお考えですか
>並列性を人間に取り扱える形で(つまり、あまり見せないように)、取り扱える言語が求められるようになり、 FORTRANのベクトル化技術に類似するものが復権してスクリプト言語を含めて広く利用されるようになる。<br><br>DSPなんかの並列処理が得意なプロセッサでリアルタイム処理を書こうとすると,C言語でさえコンパイラの最適化の性能がおいつかなくてアセンブラで書くハメになったりするので,こういうのはすごくほしいです.
yuum3さん、<br>まわりの人に聞くと、それは動的言語的性質による変化への対応の速さと、(Rubyによる)プログラミングの快適さだそうです。Python, Lispとかならともかく、Javaでは難しそうですよね。<br>JavaにはJavaの快適さはありそうですけど、それはRailsとは違うものではないでしょうか。
だれも私には聞かないと思いますが、私が「Javaどうですか？」と聞かれたら、「いい言語だと思いますよ。もう少しコーディング量が少なくて済むならば。」と答えるようにしたいと思います。
まつもとさん、回答ありがとうございます！<br>私はRailsからRubyに入って来た人ですが、今はRubyが好きです。<br>Railsはセンスというかバランスの良さを感じますが、その良さが論理的に説明できないのです ^^;
先日のCTCユーザ会のイベントで聞いた話だと<br><br> 初期コスト Ruby >> Java<br> 実装コスト Ruby ≒ Java<br> 保守コスト Ruby >> Java<br><br>だそうで、で、最初のコストがしばしば取りざたされるが、実際にはこれはたいしたことはなくて(差は大きくても全体としての作業量も少ないから)、保守・変更コストが低いのが重要なのだそうです。<br><br>Javaでの変更が伴う保守コストがどれだけ大変なのか私は知らないのですが、普段はJ2EEばっかり使っているという人がそう言っていたので、そういうものなのだと思います。<br><br>で、Javaがその重要なコストである保守コストを下げることができるかですが、もちろん不可能ではないと思うのですが、<br><br> * そのためにJavaらしさを失う<br> * Railsとは違う道を選ぶ(生産性のため動的言語の代わりにIDEを使ったように)<br><br>のいずれかで、Railsを追うのはJavaにとって危険な道なんではないかなあ、という気がちょっとしてます。杞憂かもしれないけど。
とりあえずmapやeachの並列版があると面白いかなー、とか。
「mapやeachの並列版」というのは、発想は良いと思うのですが、ブロックを動的に評価しながら並列動作させなければならないと思うので、矛盾が起きないようにするのは、とても難しくないでしょうか？
私はハードウェア設計に使えるスクリプト言語を開発してほしいです・・・<br>VHDLを書いているとソフトウェアの世界から遅れすぎていて悲しくなります。
現実的なもの求めるとおそらく妥協が必要に感じます。map{|i| Thread.start(i) {|t| p t } } に近い動作をするものだったら楽かなーとは思うのですが。もっとも、実際にこれでどの程度うれしいかは難しいところ。
mapとかeachの評価順序って言語的には厳密に定義されているのでしょうか？<br>まあ、それはともかく、並列版があると面白いですね〜
配列の場合、インデックス順ということになってます(でないとinjectとか動かない)。しかし、Rubyにはそもそも「厳密な定義」は存在しないような。
ところで、ほんとにこんな並列動作するコレクションを作ろうと思ったら、OSレベルでメニーコアをサポートする機能が必要ではないかと思います。でないと、スレッド管理コストが高くて使い物にならなそう。それかpthreadライブラリが今よりもずっと高効率になるか。