矢野勉のはてな日記

ObjectWorks 2008/01/15 09:50 「Smalltalkが実現できなかった実マシンに捕らわれない仮想マシン上でのオブジェクト指向開発を実現しつつ」とありますが、Javaが出てくる遙か前からSmalltalkはマルチプラットフォームで動作する商用の開発環境が出ていましたよ。ObjectWorks Smalltalkというもので、Unix,Windows,Mac,NeXT,OS/2などをサポートしていました。現在はVisualWorksという名前になっています。

sumim 2008/01/15 11:37 いや、たぶん t_yano さんは、その後の「…しつつ、パフォーマンスと開発効率の両方を同時に実現」のほうに重きを置いていらっしゃるのでしょう。＞ObjectWorksさん　　ただ、Java の高速化には、たぶんに Smalltalk から派生した言語処理系の技術（SELF や Strongtalk の…）が活用されていることは頭の片隅においておいていただきたいな（つまり一方的に DIS るだけではなく、ちょっと持ち上げても罰はあたらんのでは？）とは個人的には思いました。（でもこれは宣伝のエントリーなので、他を DIS ってナンボってところもありですよね(^_^;)）

t_yano 2008/01/15 16:56 どうも矢野です。
そうですね、「Smalltalkが実現できなかった実マシンに捕らわれない仮想マシン上でのオブジェクト指向開発を実現」と書いてしまうとまるでSmalltalkの商用実装が存在しなかったかのように見えますね。私自身もJavaを始める前にMacでSmalltalk/Vとか使ってオブジェクト指向を勉強してましたので、実装が存在しただけでなく、普通に買えたことも知っているわけで、あきらかに誤った記述ですね。ご指摘ありがとうございます。

書こうとしたのは「仮想マシン上でのオブジェクト指向開発の広い普及を実現した」しかも「開発効率と実行効率の両立を目指した」ことだったのですが、そもそもここでSmalltalkを持ち出すこと自体がWicketの話とは関係がないので、そもそも書くべきではなかったですね。

私自身は書いた段階で「DISる」気持ちはなかったのですが、DISってますね。すみません。

該当箇所を削除するのがいいのかもしれませんが、するとこのコメント欄でのやりとりの意味がわからなくなるので、文面変更でいこうと思います。元の文は訂正線をひいて残す形で。

・本文記述を「Smalltalkで培われた技術をベースに高速化を行い、仮想マシンでのオブジェクト指向の広い普及を実現した」といった感じに変更。
・注釈欄でStrongtalkの仮想マシン技術がSunに移り、Javaの高速化に使用されていることを記述。

といった修正をしようと思います。

Youchan 2008/01/15 17:56 「そこにはServletの仕様に押し込められた世界ではなく、Javaプログラマが愛してやまない世界が広がっています。」
むしろステートフルはServletだからこそ実現できることなのだと思います。
ServletがひとつのJVMで実行され（分散されることもあるけど、仮想的にひとつと捉えてよいでしょう）セッションで共有する情報をメモリ上に蓄積できるからこそ実現できるわけです。
こうしたServletの特有の利点をきちんと生かしているというのは、まさにJavaらしい、正常な進化だと思います。
LL流りの昨今ですが、軒並みServletのようなアプリケーションサーバーを持たない現状においてはまさにJavaの独壇場だと思います。（ASPのことは忘れて＞＜）
wicketにはとても興味が惹かれますね。

sumim 2008/01/15 18:19 正直なところ、Smalltalk ファンの一人として、スルーされるよりは多少ネガティブでも言及はあったほうが良いと思っています。その点、修正案は Java の現在の優位性が確立されるにあたっての Smalltalk 貢献がふまえられていて、すばらしいと思います。

t_yano 2008/01/15 20:50 前述の方針で記事の修正を行いました。ObjectWorksさん、sumimさん、ご指摘ありがとうございます。

Youchanさん、そうですね、たしかにJavaのウェブアプリケーションはほぼ確実に「サーブレット・エンジン」で動いてそこでセッションを管理できるからこそ、セッションを使ってのステート維持をフレームワークのベースにできるんですね。このあたり私は普段あまり意識してませんが、ふとほかの環境をつかっててこの違いに気づくことがあります。

戯 2008/01/27 13:04 こんにちわ。Ruby大好きですがRailsには疑問感じてました。その核心を「Strutsの延長」という言葉で突いてもらえて強烈に納得しました。

Struts系(アクション系？)とコンポーネント系の違いは、状態保持モデルの「厚さ」の違いな気がします。Strutsは薄っぺらさを感じてます。VB的なコンポーネントモデルに親しんだ身としては、入力系(ActionForm)と出力系(TagLib)とが完全に分かれてて連携は自力管理しないとならないモデルなんて、理解すら出来ませんorz。

私にはStruts系は「作って地獄」に思えてなりません。つまりGUIが数十年前に通過したターニングポイントをまだ通っていないんです。Webアプリもそろそろ次の時代に行くべき。

LLのServletについては、RubyでいえばWEBrickがモロにServletを自称してますし、定番サーバApacheにmod_rubyというブリッジをかませばServlet的なモノになります。つまりCGIじゃなく常駐型に。ただAPI体系のスタンダードが無いだけで。mod_xxxxは他の言語用もそれぞれ有るらしいので、常駐型のメリットから目を背けてるLLばかりではないはず。

スパム対策のためのダミーです。もし見えても何も入力しないでください

画像認証