.NET vs Java -実行環境対決- (CLR vs JVM)

いよいよVisual Studio.net日本語版の発売も近づき、.NET環境向け
のアプリケーション開発を本格的に検討する時期に来ました。

一方、これを迎え撃つのがJava陣営なわけですが、結局、.NETとJava
ではどっちがいいのか？ということをﾏﾀｰﾘ語りましょう。

関連スレその１
「.NETとJ2EE、勝者はどっち？」
http://pc.2ch.net/test/read.cgi/tech/1004021441/

関連スレその２
「ＪＡＶＡ　　ＶＳ　　．ＮＥＴ 」
http://pc.2ch.net/test/read.cgi/tech/1014546144/

関連スレその１では.NET対Javaの話が熱く語られてて非常に参考に
なりますが、タイトルを見れば分かるとおり、どちらかというと
サーバ向けの話になってます。

このスレでは、もっとPC等を含めた、もっと一般的な話題について
話し合いたいと思います。でも、関連スレその２は、テーマが一般
的過ぎて、ネタすれと化してしまってます。

というわけで、このスレでは実行環境であるCLRとJVMについて
議論することにしたいと思います。

いいかげん次スレはイラねーって言おうと思ったのに…

VS.NET>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.

CodeRed以降、MS圧倒的に不利。
あんな騒動が２、３回きてあぼーん。

どうせ、.NETはWin環境だけになると考えると（違う？）
.NETFrameWは意味ないのかな？
LinuxにもＪＶＭみたいに簡単に乗せることが出来れば強いけど・・・
ＪＶＭはスピードだな。まあ、実用レベルではあるけど

俺の考えとしては、
サーバ向けは実績から言ってJavaの方が有利。
でも個人PC向けアプリなら.NETかな？
CLRなんて所詮ユーザから見ればVBﾗﾝﾀｲﾑの巨大版みたいなもんだから。

実行環境対決ということで考えると，実行速度はどっちが速いんだろう？
CLRは初めからJITを前提として設計してるから速いという話を聞いたことがあるんだが。

まあ、プラットフォームの種類の多さではＪＶＭだろうね
ただ、Ｗｉｎが圧倒的にシェアあるので
普及率では.NETが追い抜いちゃうかも

実行速度の比較するから .NET Framework SDK 日本語版くれ。

　　 ＼＼　　クソスレ ワッショイ！！　　　　　　　　／／
　　　　　　 ＼＼　　クソスレワッショイ！！　　 　／／
　　　　　　　　＼＼　　　クソスレ　 ワッショイ！！／／
　　　　　　　　　　 ∧∧　　　∩
　　　　+　　　　⊂(ﾟДﾟ ;)￣￣｀つ　　　　　　　　　+
.　　+　　　　　　　　彡∪￣￣　　　∧＿∧　　　　　　+
　　　　　　　∧＿∧　　　∧＿∧∩´∀｀　）　+
　　　　　(( （∩´∀｀）∩∩・∀・∩ヽ　　　つ　　　　　　+
　　　　+　 （ ﾉ　　　）ノ　ヽ　　　 ﾉ　/　/（＿）　　　))
　+　　　　　 ）　）　）　　　|　 |　 |　（＿）彡
　　　 　 　 （＿）＿）.　　（＿（＿）　　　　|l|　　ﾋﾟｮﾝ □ 単発質問

何で実行速度の比較に日本語版が必要なん？
とりあえず１０げっと

CLRって「クリア」って読むの？なんかSONYのPDAと
かぶりそう。

CLR と JVM って言語機能とは違う知識が要るから、俺はあまり話に参加できんな…
サマリーで良いから双方の長所と短所、まとめてくれんかのう ｹﾞﾎｹﾞﾎ

英語版のC#やVB.NETですごく簡単なベンチマーク(擬似積分)をしたことがあるけど
その時はC++と一割も変わらない速度が出た。
JVMは…とりあえずJBuilderの起動が信じられないぐらい遅い…程度の認識。

Microsoft .NET Pet Shop
http://www.microsoft.com/japan/msdn/net/compare/PetShop.asp

C#/ASP.NET を使うと、J2EE Pet Storeと比較して
1/4 のコードで28倍速いですが何か？

J# つかってまったく同じコードで比較すること出来ないかな

>>14
.NET と比較するなら構成的に Servlet-(ただの)Bean-JSP じゃなきゃ
意味ないじゃん。なんで EJB 使ってんの?

今時ベンダー発表のパフォーマンステストなんてネタ以外の何物でもなかろうに…

>>12
[CLR]
長所:
・Common Language Specification (CLS) という規格に準拠した言語であれば
　どのような言語でもCLR向けソフトを開発できる。
（C#, VB.net, managed C++, J# など。）
・とりあえずこのスレを見る限りでは速いらしい
短所:
・今のところWindowsでしか動かない
　( Monoとかがあるので, 将来はLinux等でも動くと思う )

[JVM]
長所:
・いろんな環境で動く

短所:
・基本的に開発言語はJavaのみ。
　（もちろん、理論上は他の言語でもバイトコードを生成できるし、実際に
　　他言語→Javaﾊﾞｲﾄｺｰﾄﾞのコンパイラも出てるが、所詮はマイナーな存在。）

…漏れがすぐに思いつくのはこのくらいだが, 他にもたくさんあるはず。
　追加きぼんぬ。

実行時コンパイルとインタプリタってそれぞれ
どういうメリットがあるのかまとめてくれると嬉しいな。
それともclrとjvmをそれぞれ上の二つに置き換えて
比較すること自体間違いだったりするのかしないのか。

個人的には
・インタプリタの利点
処理系（VM）をコンパクトに保てる
他のプラットフォームへの移植が容易

・インタプリタの欠点
速度（その根本的な原因は私には説明できません）

なんてふうに考えてます。おもに速度に関するものだけですが、、、
clrとjvmの両方ともプラットフォームの提供するプロセス（実行環境）
から独立してるから、悪意のあるコードからの安全性確保は
しっかりできてていいよね。

製品として違うものではあるけれど、それよりも
理論的に考えて両者の違いというのを知りたいな。
MSやSunなんて会社名を出さなくてもこれは説明できるよね？ｗ

とりあえず現時点で比較できそうにもないし、人柱が増えてノウハウが増えるのを待とうと思う。

それまでは安定した Java を使わせてもらうのが賢いんじゃないかしら。

（よほどのことがないと、結局は Java 使い続けることになっちゃいそうだけど・・・）

>>20
プログラムでこの先も食っていくつもりなら、β版を触っておくぐらいの心構えで
無いと辛いよ。
客や上司はJAVAしか出来ないプログラマが欲しいんじゃなくて、最適なツールを使
い分ける知識を有したエンジニアが欲しいんだから。
「.NETってどうなの？」って聞かれて>>20みたいな返事してたらナメられるよ。

C#のSDKがダウンロード出来なくなってる…。

3/22になったらダウンロードできるようになるかなぁ？

ベンチマークはもうやっていいんだっけ？

>>22-23
M$はケチだから、製品を買ってもらうためにSDKの公開を中止しました（藁

>>19
実行時コンパイル(JITコンパイル)が速い理由…
ループなどで, 同じｺｰﾄﾞが何度も実行される場合、その部分を何度もインタプリタ
に解釈させるよりは, その部分をnativeなｺｰﾄﾞに直してしまった方が高速に動作
する。
……というのが俺の解釈なんですが, そのほかにも理由があるのかも知れませんです。

JVMは元々インタプリタを前提として設計されたようですが，JITでもOK。
SunのJVMの場合, 基本はインタプリタだけど, 一部分はJITコンパイルするみたい。

一方, CLRはJITのみ。…そうなると、一回しか呼び出されず, 実行時間もかからない
ｺｰﾄﾞもわざわざコンパイルするわけで, その分遅くなるかも。でも, 全体的に考えると,
やっぱり全部JITコンパイルしちゃった方が速いのかな？

惨のｸｿVMなんかと比較するなよ･･･。
IBMのVMと比べればCLRはほぼ互角だと思うぞ。

ｸｿというけれども、JIT実装の物も含めた大抵のVMよりもSUNのやつの方が速い。
要は仕様よりも技術力と思われ。MS=IBM>SUN>その他って感じ。

JVMだと IBM>MS≒Sun っつー感じのよーな。
CLRは触ったこと無い

>>26
>一方, CLRはJITのみ。…そうなると、一回しか呼び出されず,
>実行時間もかからないｺｰﾄﾞもわざわざコンパイルするわけで,
>その分遅くなるかも。

事前コンパイルしてキャッシュしておくことができるのよ。
ASP.NETでもページと一緒にクラスもキャッシュする。

ベンチマーク見つけたよ。
http://www.javalobby.org/fr/html/frm/javalobby/features/jpr/part3.html

真ん中の方のグラフを見ると、SunのJVMよりもCLRのほうが全体的に速い
らしい。でも、IBMのJVMと比べると, 負けてる部分もあると。

てゆーか最速はuva

>>30
なるほど…PreJITって奴っすね。

インストール時にIL→nativeにコンパイルするというオプションがあるというのは,
俺的に、目から鱗ものだった。Javaもそうすればいいのにと思うんだけど、
うまくいかないんだろうな。

スマソ。sage忘れた。

>>21

微妙なのが、こういう新しい技術ってのは、誰が使うのを決めるかといったら
よくて開発チーム、悪かったら顧客がご指定されるわけで、つまり、どっちに
しろ自分じゃない。

自分が面白いと思わないとこういうものには手は出ないよ。
「.NET」はどうみても、Java のマネ。正直、面白くともなんともない。

>>35
だから、Javaでウェブサービスは...(以下略

>>36
放っておけ。
新技術に面白みを感じない奴なんて同業者と思うな。

同業他社の人間ならむしろ好都合

>>37

あ、しかし、.NET で XBox のリソースを使ったゲームプログラミングができる
ということになったら、（ガベージコレクションつきの本格的なゲームプラット
フォームという意味で）がぜん、使いたい。


しかし、今はぜんぜん、未知数だし、少なくとも同じもの作るなら既存のものより
マシなもの作らなきゃいけない。しかし、今はマシどころか、劣っているんだから
しょうがない。

>>35
MSの歴史はマネの歴史なんだから、しょうがないでしょ。

UNIXのマネ→MS-DOS
Macのマネ→Windows
Netscapeのマネ→IE
PS2のマネ→X-BOX
Javaのマネ→C#と.NET

良いか悪いかは別にして、真似したものの方が普及するのは事実。
（XBoxはどうなるか分からんけど。）

ただ、.NETは、マネだけではなく、技術的にも新しいものが入ってるので、
俺は面白いと思う。

会社の好き嫌いじゃなくてさ、
技術をネタに議論してくれよ。

>>40

議論できるものならしたいけど、掲示板を通しての議論は文字打つのめんどくさくてね・・・。

正直、.NET のドコに惹かれているのか、どうにも分からない。新しい技術なんて、いま一つ。コレといったものなんてない。

コレというものがあれば知りたい。このポイントだけ教えて。

>>42
スレのタイトルよく読め。ドアホ

>>5
確かに最初はWindows->.net, Unix->javaだろうけど
問題は家電、携帯、ＰＤＡ..etcでの勝負だと思う。
これから１０年どんどん一般ユーザーは
ＰＣ使わなくなっていくと思うから
そのときＯＳでの囲い込みが意味なくなるわけで。

.NETに期待するのは、実はWinCE上のCLRだったりするんだが、
WinCE.NETのCLRって性能どうなのかな？

実行性能は申し分ありませんが、
空きメモリが残り３Mしかないのが玉に瑕。

あいたた。それはちょっと残念。でも期待したいな、CE.NET。
別にPC上だとありがたみがないしな。

―――――――――――――‐┬┘
　　　　　　　　　　　 　 　 　 　 　 　 | 　　　　　　お前らのしょぼい
　　 　 　 ＿＿＿＿.＿＿＿＿ 　　 |　.＿＿　　　CEマシンなんぞ
　　　　　|　 　 　 　 | 　 　 　 　|　　 |　 ＼＿＼　　窓から
　　　　　|　 　 　 　 | ∧＿∧　|　　 |　 　 |. 　.｜　投げ捨てろ
　　　　　|　 　 　 　 |（　´∀｀）つ ミ |　 　 |.：　｜
　　　　　|　 　 　 　 |/ ⊃　 ﾉ　|　　 |　　
　 　 　 　￣￣￣￣'￣￣￣￣　 　 |　　

>>40
値段の安い技術が普及する。歴史の事実

>>49
LinuxはWindowsよりソフトウェアの代金としては安いけど
勉強するためにそれ以上本買ったりしないといけないから
高いとみなされてるのかな？

　　　　　 ∧,,∧＿__　　　／￣￣￣￣￣
　　　 ／ミ*ﾟДﾟミ／＼＜　　ちょっぴりご質問・・・
　　／|￣∪∪￣|＼／ 　＼＿＿＿＿＿
　　　 |＿＿＿＿|／
　　　 　,,,,∪∪,,, ,,

　質問なのですが。
　実際、Webサービスを作ったり利用したりして
　どんな面白い事、役立つ事が出来るんでしょか？

　自社サイトや自社ｼｽﾃﾑを構築するのに
　わざわざWebサービス作るというのがよくわかりません。
　ｻｰﾊﾞｰｻｲﾄﾞで処理させるのが速くていいと思うんです。

　ｱﾌﾟﾚｯﾄとかActiveFormとか
　散々面白そうな事出来そうだったけど
速度が遅いって事で、JavaもIEも廃れてしまったんだし。
　Webサービスはそれ以上に魅力的なのでしょうか？

　Webアプリの生産性が高そうてのは
　.NETで注目しているんですが…　

>>49
じゃ、、じゃあ、無料のDelphiやJBuilderなどは、、、、、
いや、聞かなかった事にしてくんさい。

>>51
個人的にはあれはビジネスモデル特許にサービス販売の
機会を与えるものだと思ってます。もちろんそれ以外にも
理由はあるんだろうけど。
もちろんシステムとして最終的なエンドユーザーを満足させることが
出来なければ廃れていくのは当然です。

というかここは技術スレ。汚してしまってごめんなさい。

　　　　　 ∧,,∧＿__　　 ／￣￣￣￣￣
　　　 ／ミ,,ﾟДﾟミ／＼＜　サンクス　
　　／|￣∪∪￣|＼／　＼＿＿＿＿＿
　　　 |＿＿＿＿|／
例えば、ショッピングカートｼｽﾃﾑや
ログイン認証ｼｽﾃﾑや
クレジットカード決済ｼｽﾃﾑなどを
Webサービスで出している会社と
取引して自社サイトで使うとかでしょうか？

こういうﾈﾀは
情シス板に逝きっすか？
でも。　あそこ、出張32って変なｺﾃﾊﾝがいて
　ちょっとなー。

　　ア．．．変なｺﾃﾊﾝって．．ﾜﾀｸｼも仲間かしら......

ああ、スレ汚しごめんなさい。ごめんなさい。

>>51　というかSOAPやXML-RPCやるだけで、その面白さとかお役立ち度は
すごく感じるYO!　ただそれが.NETでないと駄目かというとそんなことは
ない。つかあんたDel使ってるなら試してみろYO　漏れD6のSOAPのコンポ
使ってるけどﾔﾊﾟｰﾘ便利だよ。漏れの場合鯖側はJavaだけどな（藁
つかここはCLRやVMの話。スレ違いだな。

>>54

その SOAP, XML-RPC, ってのは要するに、CGI のようにキーと値を渡すような
ものを少しばかりカッコよくしたものと理解してよろしいでしょうか。

結局、コンピュータ処理はデータの交換に還元してしまえるので
その置き換えは無意味。

ﾄﾞﾄﾈﾄ大好きの皆さんもそうでもない皆さんも
たまには、息抜きで善行でもどうですか？

■生徒を植物人間にした暴力教師に処分なし■（高砂市）
【ｸﾘｯｸ】 押してみっかな【ｸﾘｯｸ】
http://www.geocities.co.jp/NeverLand-Mirai/2640/

これを見て少しでも協力する気になった人
この文を色々な板にコピペしてくれると助かります

ねえねえ、CLRって一般ユーザはどうやってｹﾞﾄｰするん？
Windows UpdateとWinXP SP1あたりと思ってええん？

>>31のベンチマーク見てると、
msとmsclrほぼ同等ってーか、一部逆に速いんだけど……。
期待していいの？

>>31ってBeta1以前のNGWS SDKじゃねーか。
.NETはBeta2で大幅に速度改善されてるよ。
>>31の結果よりはるかに速い結果が出るはず。

>>60
ということは, 正式版とかだと、IBMのVMにも勝てるかもしれないですね。
まあ、どっちにしてもSunのVMには勝ってるわけで…。

これって, MSのCLR開発チームの技術力がすごいからなんでしょうか？
それとも、もともとMSILコードはJavaバイトコードよりも早く実行できるように
出来てるんでしょうか？

>>58

そうそう、それ漏れも気になる。開発者以外の一般ユーザの環境に
CLRが当たり前に入るのはいつなんだろう？

DirectXの時みたいに徐々に雑誌に付くようになるっしょ

サンがJavaVMつけろ、.NETつけるなって
ヘンな訴えしたたけどどうなるんだろ？

一時期JDKって雑誌配布禁止にならなかったっけ？
java.sun.comから必ず落せみたいな感じに。

>>65
配布禁止じゃなくて高額な掲載料徴収。

最近のベンチだとそれぞれ得て不得手があって、どれかがどれかよりも
優れてるとはいえない状況になってたね。（ライブラリは考慮しない）
もちろんネイティブコードにも負けてない（メモリコストは悪いけど）

>> 61
どちらもハズレデス。
隠しAPIを使っている、まぁそれでもIBMは一番速いわけで。(ぷ

つーかVMはCPUの設計に依存するので無意味な>1は逝ってよし！！
IA32のインストラクションせっとをそのままVMの中間こーどとして
出せば、そりゃぁは多少は速く動くことを期待できるが、極端な依存
は他のあーきーてくちゃでは目も当てられないほど低速に陥るため、
過渡的なVM-CPU-ChipSetの関係に依存するVMの煽りなんか意味が無い。
どうせならCuroseとかIntentとか幅の広い荒らしを期待したい。

またｱﾎが１匹紛れ込んできたか･･･

IAにおいて最速で動くように設計するだろ。
EmotionEngineで最速に動いてもしかたねぇんだよ馬鹿。

ときどきいるね、「隠しAPIを使っている」と
証拠もないのに適当なこと言うヤツ。

>61
マジレス。
MSの技術力はすごい。
Javaのバイトコードが腐ってるわけではないだろうが、実行するための技術が腐ってる。
うだうだ言ってねーでコンパイルしろよ、って感じ。ILはコンパイルされるから
インタプリタのJavaよりはやい。それだけ。

＞72
だからそれほど変わんないんだって。ライブラリの出来がいいから.NETの方が
よく見えることはあるけどさ。

一つ思ったのですが、
Sunって研究者と実装者のレベルがかけ離れ過ぎてるきらいはないですか？

あと、関係ないですが、クルーソーがバイナリを動的に変換して
あれだけのパフォーマンスを発揮してるのは奇跡に思えるんですが。
どんなもんなんでしょうか？

例えて言えばこんな感じなんでしょうか？
上司が100個の仕事が書いてあるリストを部下に渡す。
・ダメな部下は上から順番に一つ一つこなしていく。
・中ぐらい秀才な部下はまず100個の仕事を自分のやりやすいように
順番を代えてから仕事に取り掛かる。
・めちゃくちゃ秀才な部下はまず自分のやりやすいように順番をかえる。
なおかつ仕事全体を見直し整理してからそれから仕事に取り掛かる。

こんな感じでしょうか？
こういったのって学問的にはどんなことを勉強すればいいのかな？
前にJavaHouseにそんなメール(2年ぐらい前?!)が流れ捲くってたから
過去ログ読み返してみるかな。首藤さんとかがまだMLに投稿してた頃。

>>68
「隠しAPI」は使ってるかも知れないね。
でも, ここでいくら議論してもMSが隠しAPIの存在を認めるわけないから
とりあえず置いておこう。

で、>>68の後半部分なんだけど、MSILはIA32のインストラクションセットを
そのまま中間コードにしたものと思っていいのかな？ まあ, Javaﾊﾞｲﾄｺｰﾄﾞが
そうじゃないってのはなんとなく分かるが。

まあ、そこらへんはプログラム板なんだから、jasminとilasmをバリバリ使い
こなしている人の話を聞きたいね。
（このスレのタイトル、jasmin vs. ilasm にしたほうがム板的には良かったかな？）

DQSでゴメン、jasminってなに？
JSKにハイってないんだけど。

検索しろや。

>>77
知らないんなら黙っとれ

>>76
バイトコード(Javaアセンブラコード)のディスアセンブラ。

>>76
ﾊﾞｲﾄコード用のアセンブリ言語からバイナリのJavaﾊﾞｲﾄコードを生成するアセンブラ。

ちなみに, ilasmはMSIL用のアセンブリから本物のILを生成するアセンブラ。

>>72
スタックマシンエミュレータを高速で動かすのって、土台無理が
あるような気がするんだけど…

当たり前のことだけど、これってコンパイラの最適化と
コンパイル時間の最適化の両方でパフォーマンスを計るんだよね。
奥深い世界だ・・・

もうちょっと踏み込んでclr vs. jvm vs. iaってのはどうでしょ。

>>73
何がそれほど変わらないんだ？実行速度？ぜんぜん違うじゃん。GUIは無視？

>>75
MSILはIA32とは何の関係もない。むしろかけはなれてる。

>>80
違う。MSILは言語の名前。ilasmはMSILのアセンブラ。x86アセンブリ言語に
対するmasm.exeのようなもの。

>GUIは無視
ILの話なんだからライブラリは無視でしょ。

>>81
CLRのＶＭってレジスタがあるの？

>85
jvmとclrの速度がそれほど変わらないならどうしてswingはあんなに遅いんだ？
開発者が間抜けだから？

>>87
クラス階層に無駄がありすぎるからだろ

>>87-88
はー。J++とWFCが生き残っていたら漏れも今頃幸せだっただろうな...

>>86
ない。

>>89
なんで？

>>88
クラス階層深くなると遅くなるの？

>>91
Swing遅すぎて他で稼がなきゃなんないから。

>>90
thx。それは作るの楽そうだ。
なんにしろ技術力はＭＳ＞ＳＵＮじゃないの？
これまでもWindows、IE、MSN messager..etcどれもマネ対象より速かったし。

おまえらGUI、GUI言ってるとDel厨を笑えねーぞ。

↑何言ってんだ、コイツ？

>>94
餅は餅屋。惨はハード屋。

>>39
　それいいね。 XBOXでWindowsネイテブアプリはM$の金儲けに絡んで×だろうけど

CLRのみに制限して、 CDR で焼いたソフトが Windows XBOX両用で走るって戦略に
すれば、ゲーム関係のシェア作家なんか飛びつくだろうし、
１８禁ソフトなんか出してくればXBOXユーザも満足。
M$も箱シェア上がって満足でいい感じじゃない？

GDI+ってめっちゃ楽やんけ。エロゲーには最適だと思うぞ。

すぐに PS2用も作れ！

>>100

Linux for PS2 上で Java 動かせるよ。

それって JIT使えます？

NGCだけ　仲間外れ・・・・

>>86>>90>>94
漏れはしろーとなのでよく分からないんですが，
レジスタがないと速いんですか？

あ、すまそ。俺はこのスレの１じゃないです。

レジスタがないとバイトコードの仕様を簡潔に書け、コンパイルも楽。

>>71
「隠しAPI」とやらがとにかく何でもかんでも速くなる魔法か何かだと
妄想してる馬鹿は放置しとくとしても
どんな隠しAPIがありえて、それを使うと何がどれだけどうして速くなって、
それは公開APIではどうして達成できないのかの議論には十分に
意味があると思われ

隠しAPIとか言ってるけどDLL調べればすぐにバレるじゃん。
妄想野郎が多いね。

でもメモリマネージャの動作を知ってるのは有利かも。

なぜVMが遅いか具体的な例がぜんぜんないが。
JIT使ったらCよりjavaのほうが速いていうの読んだことあるが

>>110
VMが遅い理由がわからんやつもめずらしいな

>JIT使ったらCよりjavaのほうが速いていうの読んだことあるが
狂言にきまってるだろ（ﾌﾟ

>>110
CPUと全く同じインストラクションのVM作ったら遅くならないと思うが
(そのCPUで実行すればいいんだし)
一般的なVMの話をしたいのか、それともJavaVM/MSILに限るのか。

>>110
そもそもJIT使うって事はVMが遅いからに他ならないだろ

JITもVMの内だと思うけどねえ。ま、言葉遊びに過ぎんが。

>>114
＞JITもVMの内だと思うけどねえ。ま、言葉遊びに過ぎんが。
アホ？

JITはコンパイルした結果を実行セクションに書き込み
そこに完全に制御を渡す。
VMは中間コードを解釈してVM自体が動作する。

これであってますか？

言葉の定義なんてなんだっていいのでは。
実際にはJIT-VMというのは普通に使われる言葉だから、うるさいことは言わないでいいと思う。

＞言葉の定義なんてなんだっていいのでは。
このスレではちゃんと定義しないと混乱の元だろ

116
で私の解釈は間違っているんですか？

JITとVMを日本語に訳してみろ

JI ｼﾞｻｸｼﾞｴﾝﾃﾞｼ
T ﾀ!
V ｳﾞｧｶ
M ﾏﾙﾀﾞｼ

>121
もう、正解!

やれやれだぜ。

.NETのexeはtext領域の先頭にスタブみたいなのが
くっついてて、それはただ.NETのclrのdllへ制御を
渡すだけなんだよね？
で、そこでILのmain関数を解釈してそれを実行セグメントに書き込む。
そのとき、関数の場所にはclr内の「コンパイル申請」関数への
アドレスが埋め込まれてる。ある関数が最初に呼ばれたときに
そこへ制御が渡り、必要なIL内の関数をコンパイルしセグメントに
書き込み　&　コンパイル申請関数が書き込まれていたアドレスを
コンパイル後の関数へのアドレスに書き換え。
以後、同様にこれを繰り替えす。

こんな解釈はあってますか？

誰も答えてくれない・・・（´・ω・｀）ショボーン

CLR>>>>>>>>>>>>>>>>>>>>>>>>JVM
まあ、後発なだけに

>>124
たぶんあってると思う。
ただ、本当のところはECMAのサイトにあるPDF資料(CLIだっけ？)を見てみないと
分からないんで、なんともいえない。

でも、あの文書、技術的には面白いことが書いてありそうなんだけど、あれを読んだ
ところで今後のプログラミングに役立つとも思えないんだよな…。それよりは
C#かVB.NETの勉強したほうが良いかな？って感じ。

でも、何でJavaVMが遅くてCLRが速いのかってのを知るには、あの仕様書を見るのが
一番だと思う。

386って特権モードじゃないと実行セグメントって書き込みできなくなかった？
ってことはclrはカーネルと一緒に動作してるかな？

>>124
まああってる。

VMっていろいろ定義があると思うけど、CLRはVMだと思うよ。Virtual Machine、つまり
この場合はIAマシンのさらに上に、メモリ管理もコードの実行管理も必要なくて、
JITという機能が存在するあたらしいアーキテクチャのマシンを作り出してるわけだろ。

とりあえず、情報
ECMAに提出したものの説明
http://msdn.microsoft.com/net/ecma/

ECMA
http://www.ecma.ch/ecma1/TECHREP/E-tr-084.htm

今日は明日は一日暇なので読んでみまーす。

>>129
プロセッサやOSのいいところを積極的に活用しようという
考えだからパフォーマンスを得たかわりに、移植性は極端に悪そうだよね。

>128
まあCPUのことは知らないんだが、Win32ではAPI経由で実行セグメントにも書き込みはできる。

>>124
スタブは実行ファイル側じゃなくてOS側にあるかもしれない。
Sunが今回の訴訟でつつく余地があるとしたらそのへん
(Javaバイトコードを直接実行可能に出来ない)。

>132
何を言ってるの？スタブがEXEにあるのは例のウィルスによってすでに
広く世に出ている事実なんだけど。

Sunの訴訟に関係ある理由が良くわからん。

>>133
それはベータまでらしいです。

いまTR84をざっと見たけど、
どうもCLIってのはインターフェイスの
規定だけで実装に関しては何も仕様はないらしい。
基本的クラスライブラリの説明だけしかなかったよ。
実装はターゲットとする環境次第でどうにでも
やっちゃって下さいってとこなのかもね。
ミニマムな環境の上にCLIを実装するもよし。
Windowsみたいにｺﾞﾃｺﾞﾃした環境の上に実装するもよし。

関係ないけどワードファイルはごみだなｗ。

ごめんちゃい、TG3の仕様がここに置いてありました。
http://lightning.csse.monash.edu.au/.net/CLI/

頼むからzipにワードファイルをくっつけるのはやめてくれー！ｗ

>134
あほかおまえさんは。作ってみてみればすぐにわかること。

>>137
よく分からん。確認手順希望。
ベータ残ってりゃいいんだが、英語の正式版しかないし。

はぁー、ここにも知ったかクンが一人・・・

つーかおまえら、crusoeの論文ぐらい読んでから来たまえ。
www.transmeta.com/crusoe/download/pdf/crusoetechwp.pdf

>>140
404

>138
スタブの有無だよな？HelloWorldコンパイルしてXP以外のOS上でネイティブコードのデバッガでステップインしな。
mscoree.dllへのjmpが見えるから。XPはスタブ実行しないからこれじゃ確認できないぜ。

>139
テメーだよ知ったかクンは。

www.transmeta.com/pdf/white_papers/paper_aklaiber_19jan00.pdf
こっちだった。
でも本当に知ったかで書いてるだけだからね。

>>143
情報少なすぎ

>>140
わかった。Crusoeの論文読んでくるーぞー。

>>142
XPしかないんやけど。

なぜにベータの話（スタブのことね）を今頃一生懸命してるんだか。

>147
なにが（スタブのことね）だ。ｳﾞｫｹ。日本語読めないやつは去ってよし。

スタブかどうかなんて.NETの全体からみたら大した問題じゃない。
この話題終了。

>>149
わかってなーね

>149
スタブ*かどうか*とか言ってる時点で、おまえは内容がわかってない。CORBAかなんかと勘違いしてるんだろ？

スタブじゃないっていいはってるヤシはどういう処理がOSに追加されたのか説明してみろよ。あとそれが.NET全体でみた影響力についてもな。

>152
ﾊｧ?あのさー、お前>124から始まるスタブの話をしてるんだよな？それでどうやったら
>152みたいなご意見になるわけ？いいから子供はもう寝ろや。

一言言っておこう。>124から読めば、誰も「スタブじゃない」なんていってないってことがわかるだろう。
あと、だれも処理がOSに追加されたともいってないから。じゃ、子供は早く寝な。

　　　 ∧ ∧　 　　　　　　／￣￣￣￣￣￣￣￣￣
|￣￣（ ﾟДﾟ)￣￣|　　　＜　　あったま来た、もう寝る！！
|＼⌒⌒⌒⌒⌒⌒＼ 　　＼
|　 ＼ 　　　　　 　 　 ＼ 　　￣￣￣￣￣￣￣￣￣
＼　 ｜⌒⌒⌒⌒⌒⌒｜
　 ＼ |＿＿＿＿＿＿＿|

おやすみ〜。いい夢見ろよ。

JVMが遅い。だからjavaのまけ

>>154
カワイイ・・・
萌えたよ

だれかツッコミ入れてくれよ。寂しいから。

(1゜4゜5）Σ＼(-。-何いうてんねーん！

>>136
おっと、一部で有名なモナッシュ大学じゃないか（　´∀｀）

スタブはexeに付くけどそれが実行されるとは限らない、というのが正解っぽい。
DOSスタブみたいなものだな。

だーかーらー、そう言ってるでしょ、最初から！

実行環境という言葉は微妙だな
アセンブリ vs .classファイル
というのもアリ？

>>163
MSIL vs Javaバイトコードならありでは

いや、アセンブリは .class file hell を回避するしくみが
もともと備わってるらしいけど、実際のとこどうよ？とか

ついこないだ .class file hell 見たよ。
クラス名同じなら先にJavaVMにロードされたほうが勝つという凄いｵﾁでした

>>165
>クラス名同じなら先にJavaVMにロードされたほうが勝つ

それを利用して改変が認められてないjarにパッチを当てるのってどう？

>>166 あれ、SecurityException とかにならなかったでしたっけ？
詳しい方の解説きぼんぬ。

>>167

jarと同じ階層のディレクトリを掘って、すり替えるclassをそこへ置いて、そこへ
jarより先にCLASSPATHを通す。
これで上手くいくんでない？

Microsoft apparently wants some silicon for an intermediate language - kind of similar to Java bytecodes but, of course, not that but .NET.

ttp://www.theinquirer.net/15030213.htm

http://www.research.microsoft.com/downloads/download.asp?FUID={84B63DDE-C508-457E-9048-09A8BBE6922F}&CodeName=Extended%20IL%20(ILX)%20SDK&Version=0.2
使ってみた人いますか？

169の話はなにげに面白いんだけど、
（　http://pcweb.mycom.co.jp/news/2002/03/19/04.html
にも関連記事　）
昔NEにx86チップにJavaアクセラレータ乗せるっていうのもアリだろ、
みたいな事チラッと書いてたが、結局いまだに出来てないけど。
ILコードのほうが現実性高いかな。
まあ、にしてもMSがCPU開発ってのは無しな話だろうが、IntelとAMD
に企画を持っていくくらいの事はするんでないの。

ｱｲﾀﾀﾀ...
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=913&forum=7

MSも機械全部ひっくるめて生産するｻｿやｱﾎﾟｰみたいになるってことですか？

憶測話はいいとしてさ、技術的にはどうなのよ。
ILの直に実行できるプロセッサって仕掛けとして大掛かり
過ぎないか？スレの上の方でクルーソーを持ち出してるひとが
いたが、あれのコードモーフィングみたいなものを間に
入れてVLIWのプロセッサで実行した方が早そうじゃないか？

ってこれも厨房ナ憶測話だった、、、


プロセッサの設計も絡む話なだけにおれには一生理解できないだろな

>>174
今、Javaアクセラレータチップって結構でてるし、
別に全部の命令を完全に実行できなくてもいいわけだから、
それほど大変なことじゃないよ。まあ専用のVMが必要だろうけど。
単純にバイナリコードへのトランスレータを埋め込むってのでもいいし。
そのうち、10億トランジスタのCPUが出来るんだろうけど、そこに
何を埋めていくかって考えれば、Javaと.NETのバイトコードを
両方解釈する回路を入れても無駄じゃないと思う。
（既にRISC信仰も無いわけだし、CPUにはもっと高度な事を
やって欲しいと思うデスよ）
JITと比べてもアドバンテージがあるんじゃないかと思うのだけど。

クルーソーのVLIWコードにバイトコードを変換する・・・というのは、
http://www.watch.impress.co.jp/pc/docs/article/20010619/kaigai02.htm
に関連記事があったヨ!

>>175
それって、パイプライン、スーパースケーラ、VLIWと来たCPU高速化の流れに
逆行してるってことになったりしない？

>>176
そうかな？確かにIA-64はVLIW構成になったけど、それと
アクセラレータ実装が矛盾するものじゃないってのは、まあ175に
載ってる記事にも現れてると思うのだけど。
主記憶は以前としてボトルネックだから、バイトコードみたいな
のは小さくていいと思うし。
熱の問題もあって、今までと違う方向にトランジスタを使うっていう
のは流れとしてあるよ。

>>81
VMがスタックマシンでもレジスタマシンでも、
高速実行のしやすさは同じだと思うよ。
いずれにせよJITコンパイル時にレジスタ割り付けが必須なことに変わりないから。

>>177
インテルがクルーソーに少しｼｮｯｸを感じたのは、動かしたときの
実際のバッテリー駆動時間というよりも、CPUの制御部をバッサリ切り捨てて
ソフトウェアでエミュレーションするような設計の方が効率がいいってことに
気が付いたからだと思う。その認識は今となっては少し怪しくなってきたけど。。

コンピュータって使われる用途やメインターゲットとする環境によって
設計とかも変ってくると思うから、全てに通用する答えはなかなか難しいね。

仮想マシンに関係するペーパーへのリンクが山盛り置いてあるサイトなんて
誰か知らない？

↑

>>179
Crusoeの方式だと効率がいいのは、
権利関係でIntelと戦う必要がない、っていう点。

JAVAのVMは欠陥とうことで
NETの完勝。２８倍？これて１０年NETが進んでるということで

はぁ、.NET だろ。

再頒布可能ランタイムのサイズで勝負しようぜ！

JRE1.4 : j2re-1_4_0-win-i.exe. 12,214,536 bytes. (マルチリンガル版)
.NET : dotnetredist.exe 20.4 MB (日本語のみ)

Javaの圧勝！

>>183
ここは技術スレ。いい加減な比較はご遠慮願います。

つーかSunのVMのどこがダメだというならソースのどこが問題なのか
指摘しろ。構造的な問題ならそれを挙げろ。

下手な比較はもう十分やっただろ。

姓名判断で勝負しようぜ！http://media.pmall.ne.jp/mcp/uranaigem/sub02/free00.html
>java virtual machine さん
>あなたの性格傾向
>90 点
>あなたはとても情け深く、義理人情に厚い、誠実で温かい心の持ち主です。
>あなたの個性
>70 点
>あなたはとても知的で、スッキリとした、合理的な感覚を持つ人です。
>あなたの行動
>80 点
>あなたの行動はとても上品で、気品にあふれた、たいへん優雅な印象を作ります。

>common language runtime さん
>あなたの性格傾向
>60 点
>あなたはとても明るくて、誰とでもすぐに友だちになるオープンな心の持ち主です。
>あなたの個性
>50 点
>あなたはとても活動的で、さわやかな、明るいイメージを持った人です。
>あなたの行動
>50 点
>あなたの行動はとても華やかで、オープン。たいへんさわやかな印象を作ります。

こんなんでました〜

>>187
CLRの方がオープンとでたか。

>>188
Sunの行動を見てるとある意味正しい。

>>187
それとなく当たってる印象（ｗ

servletだけでPETSHOP作ればnET
に勝つんか？MSはいんちき比較したんか？
訴えたらいいじゃん

まえからむかついたんだ。VMのとろさ。
マルチプラットフォームしか取り柄ないんか

>>192
とろいのはあんたの書いたプログラムだと思われ。
そんなんじゃ .NET もとろくて使えねーんだろーな。

>>192
そこをまねしたんだろ？.NETって

swingの糞重さに呆れたあなたでも.NETていうかWindowsFormsなら大丈夫。

.NETがまねしたってことは
Javaは認められるべき仕様だ
>>192ティンティンのいろピンクだとおもわれ

Javaに認められる仕様なんて一つもないですよ、実際。
引っ掻き回しただけという感があるなあ。

sun＞＞＞＞＞＞＞＞＞＞MS
でいいんか
ティンティンのいろピンクよ

VMは設計ミスとしかおもえない

まぁJavaは .NET等の次世代言語
の叩き台としては結構よかったんじゃないかと。

MSばんざい！
JAVAさんさようなら。
スミソニア博物館で会いましょう（ｗ

NETは遅さは真似てないぞ

VisualStudio.Net 最高。
俺でも使いこなせるからな（ｗ

>>203
それだけ自然なプログラミングモデルだということですな。

食わず嫌い。

春房大発生

Javaは先陣切ってVMを広めたというのは評価できると思う。ボロも出てるけど。
ただ、言語という境界で厨房を生産しちゃったという点はいただけないね。
.NETはそれを清算しちゃったのがよい。

.NETも そのうち厨房大発生すると思うけど。
普及するってのは良くも悪くもそーゆー事だし。

>>207
はいはい、ぼくちゃん一人で語らないでね〜

枯れ木も山のにぎわいってゆーしねぇ

Java厨必死だな
という言葉が似合うスレのことよ...

まあ、暫くはお祭りワショーイしてりゃいいんじゃないでしょうか。

だれか説明してください
なぜVMは遅いのか。
いままで納得いく説明はないのだが
どっかの企業がVMの遅さを解決するのに
乗り出したときいたが（マジで

http://www.netgene.co.jp/java/docs/javaPressVol14.html

VMそんなに遅いか？メモリが十分にあれば不満なのは起動時ぐらい。
Java専用ローダがあればどうにかなりそう？

技術的な話しろよ
どっちの方もってもいいからさ

くだらなすぎ

しつもーん。
両者のガベコレ戦略ってどんなもんなんですか？なんか資料とかある？

>>212
パソコンの場合と組込では事情が異なる
　組込み用のプアなCPUでは余分な事をすれば当然遅くなる。

パソコンの場合、実行だけ見れば、　CPUの命令サイクルがメモリサイクルに比べて十分に余裕がある為
VM実行という負荷が直接表面に出るわけではない。
だからソートのような命令が局所的で大量のデータを扱うような負荷で試験をすれば差は出ない

しかし、VMの為の余分なロードが結局は負荷になる。

なぜjavaは起動が遅いのですか？
クソだからですか
1995ねんからCPUはものすごくは早くなったんですけど（ｗ

あんたのPCが1995年のそれと同じくらい遅いからです。

読み込むファイルが多いから

>>218
ちなみに その「早い」は NG ですな。

javaはいい叩き台になってくれた。
.netのコンセプト、素晴らしいよ。
いつもそう。美味しく熟した果実を食べるのはＭＳ。
あはははははははははあｈ

CP/M→ ms-dos
lotus→ excel
mac-os→ windows
delph→vs.net
他にある？

一太郎 -> Word

モザイク->IE

ﾊﾘｰﾎﾟｯﾀｰ → ｹﾞｲﾂ

.NETの行き着く先は、もしかして…、Windowsのx86 CPU専用OSからの脱退では…。
アプリのコードをネイティブからCLRへ完全移行させれば、
なにも、CPUはx86でなくてもよい！
そのうちMacで走るWindowsなんかでてくるかも？

ﾋﾞｯｸﾘﾏﾝ→ﾎﾟｹﾓﾝ

つーかNTはAlphaとかでも走ってるし、特にIA以外に移るメリットも無い現状。

怪盗ルパン顔負けのMS

>>218
Java 2になったあたりから、それまでCで書かれていたコードが
Javaで書き直されてきた。
例えば、クラス管理まわり (see java.lang.ClassLoader.NativeLibrary)。
多分、JVM自身の移植性を高めるため。

Java 2でJVMの起動が遅くなった一因はこれ。

>>220
その通りで、起動時に読み込まないといけないクラス数が増えたのも一因。

>>217
いまどきのJVM(Sun,IBM)、
計算intensiveなプログラムのピークスループットがすごく高いよ。
C/C++と比較してみるとよろし。

２３２＞＞
java-pressにでていたね
以外とCようり速いのはびっくり

>>192
>>199
>>207
>>212
>>214

「VM」ってさあ、一般名詞なんだよね。

スレタイトルが読めない春厨がイパーイ

>>213
JVM仕様を直接読んだ方が早くない？

>>232
たとえば数年前のデータだと
http://www.knt.mech.tut.ac.jp/research/fmm/java/bench/page1.html
とはっきり差が出ている

これが最近になって、ベンチマークで差が出なくなったのは、>>217に書いた理由

235>>
マターリといきましょう

みんな酒でも飲んでるのか？

JVMはロードのとき、型チェックとかやばいループとかないか調べて
るから遅いんだろ。ロードの時間は安全代じゃないの。

>>240
意味ないけどね

JVMでは安全性とロード速度がトレードオフになってると思う
けど、CLRはどう？

>>242
何を持って安全とよぶかの定義によると思うけど。
240=242が言ってる安全って一体何？

どこがトレードオフになってるのか分からん

>>243
マシンコードのヴェリファイのことでしょ？
仮想マシンが、いきなり沈黙するようなコードがないかチェックする処理
http://www.google.com/search?num=50&hl=ja&ie=Shift_JIS&oe=Shift_JIS&q=Java+%83x%83%8A%83t%83@%83C&lr=

M$じゃあ、まずしないね。
その分、起動時間は短いだろう。

バイトコードベリファイアのことです。
オペランドスタックやローカル変数の取り得る状態の数が
組み合わせ爆発を起こすようなプログラムの実行を許可し
ていないというのに感心した思い出があるもので。

>>245
そういうの実行ににやるんじゃなくて、
.NETのめたデータに突っ込むような形でやるんじゃないのかな？
今やってないとしても。

247
プログラム取得時にってことです

チェックって限られた範囲でしか行われないと思うんだけど
その程度で安全と言ってしまっていいのかなあ。

死ぬほどメモリ確保しまくるコードや
死ぬほどスレッドを立てまくるコードは
どうせ検出できないでしょ？

意味あるのかね？

チェックじゃないよテストだよ。
しかも正しく動くかどうかのテストであって性能テストではない。
性能に関わるテストは別問題。

言葉の言い換えしてもしょうがないと思うが。
1. 「正しく動く」の定義は？
2. 1.の定義による「正しさ」の、実用上の意義って何？
249みたいなのを防げないテスト(?)をして、誰が満足するの？

もしかして言語屋のオナニーかな...

PEVerify.exe

>>251
ぺリファイは最低限のチェックや。
たしかに無くてもいい、オナニー機能だ。

セキュリティーや不正使用はチェックでけへんしね

.NETFrameworkのソースって逆汗できないの？
っていうかpreCompileしてあるんだよね、多分、、

JAVAでエラーをおこすプログラムを書くのは難しい。
例外をおこすやつなら簡単だけど。

.NETなんてダメダメ。本命はやっぱWindowsDNAでしょ。
COMとかDCOMとかActiveXとかVBScriptとか
ActiveDirectoryとかがあるからね。
マイクロソフトの技術だから、これからは
これが主流になっていくだろうね。
.NETみたいな数年で消える技術じゃなくて、
長く生き残ってゆく技術を身に付けていくにはやっぱ
WindowsDNAの勉強をするべきだね。

マイクロソフトの技術は移り変わりが激しく閉鎖的。
ユーザを平気に手前の都合で切り捨てるので、
どこでもいつまでも通用するマイクロソフト
の技術を学べば、若い世代のPGに対しても敗北の味を
知らずにPG人生を歩めるでしょう。

1行目と3行目は矛盾するような？

>>254
C#ならできます。MC++はわかんない。unmanagedな部分は無理みたいだけど。

>>259
意味わからん。ILDasmを使うだけじゃないのか？

ちなみに、NgenでNativeコンパイルされていても、ILDasmで逆アセンブル
することはできるよ。

SunもここまでWindowsが普及してるんだから、バイトコードから
Winのネイティブコード吐くCLRみたいなの作れば良いのに。

もうみんなVisual Studio.net買いましたか？

駄目プログラマーの条件

１）色々な言語に手を出すがどれも中途半端
２）開発環境を一杯持っている

>>264
良いプログラマーの条件もお願い

ｺﾎﾞﾙﾋﾄｽｼﾞ

両手で1023まで数えられる。

>>267　やめてくれ！　新人歓迎会とかで片手で31迄数えますって芸やった先輩の事思い出すから

良いプログラマーの条件

１）言語なんか邪魔しなければ何でも良い
（asm,VC/C++,javaの三段階三つで充分だ）
２）BAT,EXE一筋８０年。開発ツールは便利なら使うかも。
３）個人ライブラリーを一杯持っている。

>>268
裏返しも入れれば64までいけそうだ

>>265
作ることに関する目的意識の高いひと。

>２）BAT,EXE一筋８０年。開発ツールは便利なら使うかも。
>３）個人ライブラリーを一杯持っている。

オタク上がりに多い典型的駄目PGじゃねーか。個人で全部請け負う在宅PGなら
いいかもしれんが、プロジェクトに入ると迷惑極まりないタイプ。

>VC/C++
この辺りがDQN臭いな

１）言語なんか邪魔しなければ何でも良い
（asm,VC/C++,javaの三段階三つで充分だ）
スクリプトのひとつくらい使えるようになっとけ。

>java
そろそろお払い箱だね

>１）言語なんか邪魔しなければ何でも良い
>（asm,VC/C++,javaの三段階三つで充分だ）
それだけ使えれば言語のリファレンスマニュアル見るだけで
新しい言語に対応できるようになってるよ。
perlやRuby pythonだってねー。
関数型言語や論理型言語はつかわんんだろし

ライブラリだけ見ればJavaの方が良く見えるんだけど。。。はぁ。

つうか、普通個人ライブラリくらい自然に溜まっていく。
設計の才能が無い大半のＰＧは個人ライブラリを持っていない。

>>277
今までかっぱらってきたソースコードが2Gほどあります（藁

かっぱらったのかＹＯ！

俺は会社や言語変わる度に１から作りなおしだ。
ドロボーはいかんよ。

>>275
なんで新しい言語に対応しなきゃならんの？
金くれるんなら覚えるけど。只じゃ嫌。

会社名にして20以上、人名にして500は超えてるだろな。
もしかしたらここに書き込んでるやつのソースも家にあるかも（藁
ソースコードは咀嚼したものでないと持ってても意味がないから、
仕事で眺めまくったソースは持ち帰るメリット大です。

>>275
c++（CUI）で充分。
あんな呪文みたいな言語は脳に悪い。

>>282
それはいいが、かっぱらっただけで分析してないのでは？

>>260
あ、逆コンパイルと間違えたわ。スマ。

>>284
ライブラリ、フレームワークに相当する部分は
仕事で沢山見てたので大丈夫です。多数の会社どうしで
仕事をする場合、ライブラリは非公開なこともありますが、
上に、ソースを見せてもらう方が効率がいいことを
直訴しソースを出してもらいます。そしてかっぱらいます。

アプリケーションプログラムの部分はヘタレなものを
持っていても仕方ないので、そんなに沢山はありません。


っていうか完全にスレ違いだな。
仮想マシンの話しよう！（藁

>>237のところにあった単純ループのソースをC#用に書き直して
実行速度を比較したら、リリースビルドでJavaの約半分だったよ。

.NETはILをコンパイルしたプログラムを永続的にキャッシュするような
仕組みとかあるのかな？

>>288
gacutil.exe

>>289
それはデフォルトの設定？
こういったのは終了時に強制的にやってくれるとありがたいね。
起動時にはキャッシュにコンパイル済みのコードがあって、
ILの日付よりも新しかったらキャッシュを使うとかさ。

>>287　　サイズはどの程度で？

>>291
3000000件で。
PenIII-800の512MでJVMで14.551s、CLRで8.472s。
JVMは1.4。
デバックビルドだと、CLRの方が遅くなったけど他に
試した人いない？。

このケースだけで単純に比較は出来ないんだろうけ
ど、大きいね。

>>288
289のは関係ない。CLRにはその機能はない。ngen.exeはインストール時のコンパイルだし。

キャッシュもいいけどコンパイルよりディスクアクセスの方が
遅かったりして

>>281
対応できるという意味だ。

>>292
これって
http://developer.java.sun.com/developer/bugParade/bugs/4490869.html
のバグと関係ないかな？

とりあえず IBMのJIT使えば 8秒、
JDK1.4 HotSpotClient だと 16秒

> これって
> http://developer.java.sun.com/developer/bugParade/bugs/4490869.html
> のバグと関係ないかな？
ベータ版じゃないから、多分関係ないと思うよ。ベータ版でなくてもでるのかな？

> とりあえず IBMのJIT使えば 8秒、
> JDK1.4 HotSpotClient だと 16秒
そうなんだ。IBMのJIT使えばほとんど変わらないってことか。
試してみる。ありがと。

このバグ fix されないままリリースされてるから、
関係あると思います。
ちなみに JDK1.3 でも症状出るらしい。

>> 298
ふ〜ん、そうなんだ。

「Does this problem occur on J2SE 1.3?」
「No」
と書かれているが？

300get!

>>299
それは バグパレードに登録した人の投稿内容でしょ？
その下の他の人のレポートには JDK1.3 でも再現する
って書いてあるよ、

[email protected]
This bug also existed in JDK1.3 and affects any program
that uses "double" local variables.

とか、

Swestin
This is not confined to 1.4; 1.3.1 has the same problem

のことね。

ところで、VS.NET 買った人は MSの許可を得ずして
ベンチマーク公開して良いんですか？

>>303
こまけーことがたがたうるせー、馬鹿！

>>301-302
了解。

>>304
いや .NET Framework SDK とライセンス違うのかなぁ、
と思っただけです。

>>303
ありゃ、使用許諾にあるのね。そういう文章が。
今更、見逃していましたごめんなさい、じゃ済まないか。

>>306
見ていないが同じでしょう。

訴えられたら、笑ってくれ。
つーか削除依頼しとくか。

>>303 ベンチマーク制限してるのはサーバー製品だけという理解です

なるほど。じゃ、ライセンス違うのかも？

http://www.microsoft.com/japan/msdn/netframework/downloads/sdk_eula.asp
から抜粋
4.8 - ベンチマーク テスト お客様は、マイクロソフトの事前の
書面による承諾なくして、本サーバー ソフトウェアまたは本クラ
イアント　ソフトウェアのベンチマーク テストの結果を第三者に
開示することはできません。

まぁ Microsoftの方が有利な結果でてると思うし、
2chのカキコぐらいで訴えるとかそーゆーことはないと思うけど…

完全に再現できるための情報(ソースコード、入力データ、実行条件、etc)
を開示していればかまわんと思うがなあ・・・
まあ思うだけか。

>>309 確かに 7.2　として同じ文言がありますが

　7 略---　MSDNサブスクリプションプログラムのServer製品の・・・　
　と始まっているので、無視しています。　SDKとは違うライセンスと思っています。

　MSDNのServer製品がダメというのは、値段的にそういうものだと理解しています。

というか金払って買った開発ツールでベンチマークして何が悪い！

ベンチマーク結果の公表についての話であって
ベンチマークの実行そのもについては言及していないと思われ

licence.txtとeula.txtに

>5.9 ベンチマーク テスト
>お客様は、マイクロソフトの事前の書面による承諾なくして、
>本サーバー ソフトウェアまたは本クライアント ソフトウェアの
>ベンチマーク テストの結果を第三者に開示することはできません。

という記述があるが、

>4.1 インストールおよびライセンスの許諾
>本サーバー コンポーネントは、サーバー ソフトウェア (以下「本サーバー
>ソフトウェア」といいます。また、本サーバー ソフトウェアを実行する
>コンピュータを以下「本サーバー」といいます) を実行できるコンピュータ上で
>サービスまたは機能を提供するソフトウェア プログラム、および電子デバイス
>(以下「デバイス」といいます) から本サーバー ソフトウェアによって提供される
>サービスまたは機能を呼び出しまたは利用するソフトウェア プログラム
>(以下「本クライアント ソフトウェア」といいます) で構成されています。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
というふうになっているので、自分で作ったアプリのベンチは問題ないような気がする。

age

そんな規約は法律上無効だから気にしないように。

>>315 裁判で判例作って証明してくれ。

でもまぁ、極端に神経質になる必要は無いに 1票

(CLR)<<以外にも、FreeBSDでの開発が一番先だそうです
（雑誌で見た。ネタではない。ただ、その編集者がいいやつかどうか分からない）
でも、言われてみれば・・・
Solarisには、行きづらいだろうし
Linuxも敬遠されそうだし・・・
残るはFreeBSDだとおもたか？
次は、BeOS→超漢字→OSASK
コレいいね

FreeBSD・・・・
久しく触ってない。

486DX4の98に入れて遊んでいた頃が懐かしい。

FreeBSD版出すとかいって最近話全然聞かないな。
早く作れ！＞まいくろそふと

サーバ用途ではFreeBSDはまだ多いだろうからいいんじゃない？
もう殆どLinuxだったりする？

も一度>>1の話に戻って話すけど
Javaがこのまま実行速度や
マシン負荷があまり変わらない
のであれば、Win上ではまちがいなくユーザは.NETアプリ
使うだろうと思う。
ただ、サーバーサイドのお話となると
企業がすぐにシステムを移行するわけがないし
あるいは.NETにJava以上の何か特別なアドバンテージ
がない限りしばらくJavaだろうと思う。

/*余談
SolarisってJava（JVM）が走りやすいらしいけど
Winとかに比べてどうなんだろう
さくさく動くんかな？
Solaris使ったことないから（見たこともないが）わからん
*/

http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml

FreeBSD版age。

>>323
wow!!!!　サンクス子

移植はやっぱりCorelがやったみたいね

土曜の早朝に起きたかいがあったってもんだ。
今週はこれのハックで終わりそうな気配（ｗ

ところで System Requirements に Perl 5.6 とあるのは何でだろ？

ビルドするのにつかうんじゃないかな？

CLIエンジン　インストールするのに Perl使うって事？
　一瞬、ライブラリをPerlの使ってるのかと疑ったよ

$ find . -name "*\.p[lm]" -print
./clr/src/ilasm/extractgrammar.pl
./clr/src/inc/genrops.pl
./clr/src/inc/opcodegen.pl
./palrt/idl/idlstrip.pl
./rotorenv/bin/finddefines.pl
./rotorenv/bin/gencscrsp.pl
./rotorenv/bin/gensr.pl
./rotorenv/bin/getbaseaddress.pl
./rotorenv/bin/keylocationex.pl
./samples/pigui/tk/callconvhack.pl
./tests/dev/bclvmconsistency.pl
./tests/dev/ffitest.pl
./tests/dev/nativedll.pl
./tests/pvtrun.pl
./tests/rrun.pl

あげ！

>>324
Linuxでも動きますか？
FreeBSD用意しないとダメでしょうか？

ttp://www.zdnet.co.jp/enterprise/0203/26/02032602.html

J2EEの学習用サンプルプログラムとして書かれた「Pet Store」のコードを
.Netで書き換えたら大きく性能向上したとマイクロソフトが主張したことも
あったが，グリーン氏は，「リーダブルな学習用プログラムだった」と指摘，
「IBMやオラクルが同様のe-コマースアプリケーションを書き直したところ，
.Netより20倍も速かった」と，会場の拍手を呼んだ。

ほとんどが学習用コードがそのまま使われているという事実

パフォーマンスの話はいいから技術の話しろよ

なるほど、Sun製のJVMがIBMやMSのJVM、CLRより
はるかに劣っている理由が分かったような気がした。

Javaの不幸なところはSunが大きく関わっているところだね。
IBMだったらどれだけ幸せだったことだろう・・・・・・・・・・・。

おマラ！
死滅スレはここではないのでＹＯＲＯＳＨＩＫＯ！

対決スレは死滅へ向かうの法則。

二つともソースコードが出てるんだから
いい加減な理由でなっとくするんじゃなくて
ちゃんと自分で調べる、大事あるね。

JVMの遅さの理由がこのスレでぎろんされていないようにおもうが
簡潔にいってみてくれ

まーはっきりしているのは、こういうチョウチン記事を喜ぶ連中は
そういうチェックをする能力がないってことデスワ
でもよう、サーバー製品を複数接続させてあれやこれややるスイートの
パホーマンステストなんてそうそう簡単にはできないぜよ

ある程度以上の規模のパフォーマンステストは
最初から結果が分かっているというワナ

だからそんなものについて一喜一憂してるんじゃなくて、
もっと内部の知識を深めたりとかそういった地道な
努力をすることが、一エンジニアとして責任ある仕事に
繋がるものと思われ。

ただ、
提灯記事を信じることは有害だけど、それを数多く知っておく
ことは無駄じゃないかもナ。

説明に役立つからな。

どうでもいいがMS!
ソースが消えてなくなるようなmakefile入れて
リリースしてんじゃねぞ！ゴルァ！

JavaPluginが常駐できれば良いと思うんだけどどうよ？

Plugin 常駐さしてどーする気？

>>344
makefileはpmake用に書かれているから書き直すかpmakeをインストールする
必要があります。

いちおうpal部分はやっとこさ解析終わりました。。。
これのインターフェイスもCLIの仕様として含まれているらしいので
移植をする必要が出てきたらここのソースを改造することから
始めると良さそうです。

Java VMを常駐といいたかったんだろ

>>348
どんな感じですか？
monoと比べてもどうなんでしょうか？

あげ

主力言語Eiffelにするか新Pascalにするか迷うなぁ。
Java好きだけどJVMは嫌いだし。。。さよならSUN。
こんにちはMS。

SSCLIをvmware+FreeBSD4.5relに入れるのに2.5時間。
fjitなんとかのコンパイルでは死亡したかと思った。

動作は重いな。やはり。エミュレーションだから余計。
しかしバイナリコンパチってのは結構嬉しい。
Winで作ったバージョン管理システムがそのまま動いたもんな。

>>353
どこが遅い原因なんだろ。
Win32APIのラッパーかませてるからか？

どうでもいいけどソースきたなくね？
なんか間に合わせ的に作った感じだよな。
かなりの部分はCorelが作業したらしいけど
やっぱMSに金だしてもらってやる作業なんて
こんなもんかね。いい加減すぎるような気もしないでもない。

Linuxへの移植に成功した人はいますか？

実用になるかはともかく、楽しそうではあるね。

実用になると思うよ。CLI部分だけでも安定するまであと2年はかかると思うけど。
ところでFreeBSD版は誰がメンテするのかね。マイクロソフトは
これをどうするつもりなんだろう？いっそのことライセンスフリー
にして投げた方がよかったような気もするんだけど。

>>358
Corelでしょ

age

>>358 MacOSXへ移植するという...

>>340
エミュレーションみたいなもんだから遅くなって当たり前。

まだ.NETアプリって無いんだよね？

>>363
フレームワークとSDKがある。
で、アプリがないわけがないと思いませんか？

朝からアホな問答を見てしまった。

VS.NETは.NETアプリですが何か

>>366
Delphiみたいだね。

Del厨うざ

>>368
過剰反応するあなたの方が問題あり。
delphi花粉症ですか（藁

>>367-369
Dで始まる糞言語の話題はやめれ

>>370
Delphiは開発環境の名前。言語はObjectPascal


まぁ、VisualStudioを言語だと思ってる奴は黙ってな（藁

>>371
で？

sscliをいじってた人はどうなりましたか？

[Compiling for the .NET Common Language Runtime]
http://www.amazon.com/exec/obidos/ASIN/0130622966/
よい本、らしい。。

ILの段階でテンプレートを保留にしておくこととか出来ないのかな？
いまのhttp://research.microsoft.com/projects/ilx/
とかだと実行時に引き渡すときにはもちろん今のILになってないと
いけないんだけど。。技術的になにか問題があるかな？

やっぱり実行時コンパイルエラーが出やすくなるから無理か。

おい、お前ら
どうでもいいけど.NETはクロスコンパイルらしいじゃないか
他のプラットフォーム用の無料SDKが出ればいいが
また高いお金だして(例えばLinux用の)VisualStudio
買わないかんとなるとやっかいだな
とくに、シェアウェア作る人にとっちゃぁ・・・
ってことは結局.NETは実質Windows上だけの話となるので
CLRは意味なし。
よってVC++6.0の勝ち

とりあえず腐れシェア作家は逝っていいよ。

>>376
死ね

は？シェアウェアなんて作ったことないけど？

>>376
クロスコンパイルっていってもそれぞれのプラットフォーム向けに
スタブをくっつけないといけないから、今のWindows用のやつが
そのまま動くわけじゃないと思うけど。違うの？

>>380
言ってることは正しいが>>376の言っていることとずれている

つまり、使ってもらう相手にソースコードを渡して
相手の環境でコンパイルしてもらうか
あるいは、開発者が複数のOS用のVSを買って
それぞれ用にコンパイルしてバイナリを配布するか
ということ。
JavaならWin上でコンパイルしたやつはLinuxでも動く

sscliのニュースグループも2ch並にレベルの低い投稿が多いな

思うに。WindowsですらSDKが用意されてるのだから、
別にVS買う必要ないでしょう。monoもあるし。
>>376のような無能ならいざ知らず。

>>381
じゃあバイナリじゃなくてCLRにするメリットって何なん?

>>384
IL、アセンブリ、メタデータを取得した後に
スタブを付けられるような仕組みがあればいいんと違う？
よく分からないから適当なんだけどさｎ。

>>385 など
他の環境で動作するときはスタブを無視すれば済む話だ。すでにXPや
sscliではそうなっている。

>>384
そうなんだよ、そこが落とし穴
MSは他のプラットフォーム用にも開発環境
を売るつもりだな。もちろんSDKが出てくれれば問題ないのだが・・・
まあ、CLRにするメリットはソースを書くのは
一回でいいということぐらいかな

>>387
>>385に書いた通り、バイナリのままでOK。バイナリのファイルフォーマットは
ECMAで標準化済み

Javaだろ。

>>386だった。間違えた。

>>374
注文したので、あげ

メタ情報が多く入る.NETバイナリはJavaほどはクロスプラットフォームでないという罠

CLIのバイナリファイル仕様は決まってるかも知れんが、
ランタイムのAPIは何も決まってないんじゃないのか。
C#のコードとか見るとWIN32のAPIをばしばし呼んでるが、
ああいうのを例えばFreeBSDに持っていってどうやって動かすの？
WIN32SDK for FreeBSDを買わなきゃいけないんじゃないの？

>>387

各プラットフォーム向け×頻繁なバージョンアップ

で、死ぬること必至。もちバージョンそろえないとメタ部分での互換性問題が多発。
ここ数年はCLR自体もダイナミックにかわるかもしれん。　なんせ出始めたとこだし。

さぁ、それでも .Net へ行くのかこのマゾヒストたちは。

オレは書籍や2chで情報追って、安定するの待ちます・・・
新技術追求は大切だけど、仕事だからね。

>>394
なるほど。仕事でしかないのね。

仕事じゃなきゃMSが使ったものになんか近づくもんか。

>>396
なるほど。その程度の知識で会話に入り込もうとしてたのね。

>>392
だからメタデータはプラットフォーム非依存だっての。

>>393
>ランタイムのAPIは何も決まってないんじゃないのか。
ランタイムのAPI？
>C#のコードとか見るとWIN32のAPIをばしばし呼んでるが、
そりゃばしばし呼んでるコードの問題であってCLRの問題じゃない。
移植性とも関係ない。P/Invokeのような機能自体もECMAで仕様化済みなので
あとは各プラットフォームに適切な実装をすればよい。sscli参照。

>で、死ぬること必至。もちバージョンそろえないとメタ部分での互換性問題が多発。
根拠なし。メタデータは標準化済みだって。バージョン関係なし。

あー、正しい情報が必要だねー、みんな。日本には正しい情報ないからなー。
MS日本ですら平気で間違った情報流しまくるからね、ホント。

>>398
正しい情報を与えても能無しは素直に解釈できないよ。(嘲笑激藁

>>398
「ランタイムの外のAPI」だな。すまそ

結局Win上で書くやつらは(J++やJ#でやってたことを見れば分かるとおり)
Win32 APIばしばし使いまくりで書くわけだから(C#の教科書にもそんなコード
しか載ってないしね)、ほとんどすべてのコードはFreeBSDで動かないわけね。

重要なので何度も言います。
.NET に新しい技術など何もない。
面白みも全くない。
何の勉強にもならない。

確かに本当の意味で新しいと言える技術は無いね。

落ち着けよ。何べんも同じことを繰り返すなよ。

C#で書いたプログラムをFreeBSDのSSCLIで動かそうとしているのですが動きません。
FreeBSD用のDirectXはどこで手に入るか教えてくだちい。

なんつーか、Javaも頻繁なバージョンアップしてるし、
ある程度は許容されるんでないの？
慣れてるでしょ、もう。

CLR でクロスプラットフォームなんてただの幻想。Win95 ですら動かんし。
Sun のクソな実装に我慢しながら Java を使うしかない。

アップグレードしないような処理系に魅力はない。

どうせWinでしか動かないならVC++でいいじゃん。

It's commin'━━━━━（ﾟ∀ﾟ）━━━━━!!!!!!

でも、MFC/ATL共に出来ればあまり触りたくないからね。
フレームワーク自体は良く出来てていいと思う。
あれでネイティブアプリ作れればなぁ。

>>408
禿同。CLR に魅力は全くない。

しかし、よく知らない事をいい加減な知識で批判できるものだ・・・
Javaでも良くあったけど、見苦しい

どちらも必死なんだよ

「ECMAで標準化されてる」なんてのは単なるエクスキューズでしかない。
それとクロスプラットフォーム性には全く関係がない。
ECMAScriptがJavaScriptの標準化に役立ったか？

CLRを作ることに興味が沸く人は沢山いるんじゃないの？

例えば、C#で「Hello World!」というダイアログをポップアップ
させるプログラムは、どう書いたらポータブルになるの？

Javaも.NETも両方使えばいいじゃん

>>417
未だにJavaすらできないへっぽこＰＧは
ごろごろいるんだＹＯ！

Javaが出来る人間はC#使えるだろうし、C#出来る人間もJavaできるだろうなぁ。
ライブラリの習熟度が問題になるだろうけど、その程度の違いでしかないよね。

>>416
Javaじゃあるまいし、GUIつかったらポータブルにはできない。

ってか、Ｃ言語が一番ムズイな。
JavaやらＣ＃はそれこそライブラリを覚えてるか否かだけでしょ。

>>414
>ECMAScriptがJavaScriptの標準化に役立ったか？
はー。ECMAScriptの実装がJavaScriptでありJScriptなんですけど？
ECMAScriptは標準であって標準化に役立つものではありませんよ。

標準は生かすも殺すも実装しだい。Netscapeの技術力では長い間まともに
実装できなかったんですな。かわいそうに。

>>419
C#を一から勉強している奴がJavaに移動する必然性(ほぼ同じ言語仕様)
だからわかるが、
JavaからC#へっつう必然性がJavaプログラマにはない
学習目的やWin専用プログラムをつくるのならばあるけどね。

MSやJavaはなんで標準化が存在するのかわかってないよね。
別にいいけど。

固いこと言わず両方やっとけって
どちらもﾀﾀﾞで習得できるんだし
この先どうなるかわからん物に対してくっちゃべってるよりは
今ある沢山の物覚えたほうが損はせんだろ

>>425
同意。
結局は両方学習するほうが無難なんだよね。しょうがないけど現実。
ただ、手放しで「.NETばんざーい」なんていってる輩には
ソフトウェアの進歩を自社のイニシアチブを得るため遅らせているM$の態度
をもちっと考えてほしいよね。

いつでも乗り換えが利くような大差がないものを
両方覚えておくのは無駄。
どっちか極めて他はその差だけ知っていれば良い。

>>427
もっというと、言語なんていう枝葉末節な技術をいくら極めても無駄。
もっと本質的な技術（JVMなりCLRなり、あるいはプラットフォームネイティブでもいいや）
をきわめないと今後も右往左往する羽目になる。

>>423
無いといったり有るといったり忙しいやつだな。

>>426
ソフトウェアの進歩って何だろう。わからないので教えてください。

だからJava使いは
>学習目的やWin専用プログラムをつくるのならばあるけどね。
っていってるじゃん。

>>431
では、C#使いはWin専用プログラムをつくる場合もJavaに乗り換える必然性が
あるということですね？

>>423はJavaに肩入れしすぎてて、対比させるときについ贔屓しちゃったのであろう。

>>430
漠然とした見方だけどね、
昔からソフトはハードウェアにくらべれば進歩してない。
それは多少の覇権争いはあってもハードウェアには標準があって
標準の上で進歩してる。かたやソフトは朝から晩まで覇権争いに
終始して標準を拡張することがよいと思ってる(M$なんか特に)
それ自体いいことか悪いことかはおいといて
我々が迷惑と言えることはソフト屋のマンパワーを分散してるってとこ
ろに大きな間違いがあるとおもうなぁ
M$の今回のWEBサービス祭りでやらなくてはいけなかったことはJ2EE
っつう既存の仕様に乗っかるべきであって自社版Javaを作るべきでは
なかったと思うがいかがなものでしょう。

>>433
肩入れじゃなく。既存のものと新しいものを比べてるだけ。
最終的にどっちにデファクトスタンダードが移っても、どっちでもいい

>>422
揚げ足取るねえ。
そういう揚げ足の取り合いなら「IEのJavaScript(tm)なんて載ってない。
あれはJScriptだ」とでも言えば良いのかな？ （ちなみにNetscapeが実装
したころMS実装なんて無かったよ。）

言いたかったのは
「ECMAScriptのおかげでプラットフォームに依存しないJavaScriptコードを
書けるようになったか？なんの役にも立たなかっただろ？」ってこと。

>>432
だって、一から学習する場合C#もJavaも同じだけの労力つかうんでしょ
だったらどっちを選んでも必然。
C#を完全にマスターした場合、OSがWinだけって条件さえクリアできれば
Javaに頼る必要なし。そう思わん?

余計なことを付け加えるかもしれないが、
昔から俺はVBは嫌いだった。それは非オブジェクト指向だから。
だけどそのおかげで「簡単に」ってことで、社内でVB派がいても
許容してたところがあったけども、今回VB.netとなったことで
オブジェクト指向になった。同時に「簡単に」つう代名詞もとれ
た。オブジェクト指向になったのは正常といえば正常なことだけ
れども、オブジェクト指向を１からはじめるVBプログラマは
「M$にだまされた!!」って声をあげない事が不思議でしょうがない。
そして、素直にC#とかVB.netに移行するのが、かわいいと思う今日この頃。

>>435
CやC++みてもわかるようにプラットフォームに依存しないようになんて
書きようがないのだから標準化なんて無意味だよね
ECMAもANSIもW3Cもいらない
JAVAのようにどこかがイニチアシブを取るしかないね

>>437
なんで騙されたことになるのかよくわからない。
CがC99がメインになると騙されたことになるのかな？
ちなみに、移行する必要が無いという声も・・・うちも多分そのまま。

標準化ってーのは偉いさんが集まって議論をぐだぐだするのいーんじゃねーか。
一般ユーザーはすっこんでろ。

>>439
VB.netはコードをあんまりよくみてないけども、確かにオブジェクト指向
っぽくなってた。非オブジェクト指向な人間にオブジェクト指向を叩き込む
っつうのは並大抵にはいかんと思うが。
だって、GUIから設計してたのに、いきなり「データ構造から考えれ」って
のはしんどいことじゃない?

ちなみに俺は元いた会社の技術アドバイザーをやってる。
最終的に「.NETかJavaか?」つう質問には
「VBからVB.netへの教育コスト」と「マルチプラットフォーム」の
メリット(反してWinの脆弱性)とを比べて、良いと思うほうを選んで
ください。と報告した。

>>441
VB.netでもGUIがあってペタペタ貼り付けて、イベントを記述してって作りかただし。
ライブラリ使うだけの何がそんなに違うの？という感じな気がするけど。
データ構造なんて大抵RDBで済ますだろうし・・・。

>非オブジェクト指向な人間にオブジェクト指向を叩き込む
>っつうのは並大抵にはいかんと思うが。

非オブジェクト指向の何処が難しいのかいつも首を傾げてしまう。
当然、極めるのは難しいのかもしれないが、一般的なプログラマに
必要とされている程度のオブジェクト指向は十二分に理解するのも簡単だと思うのだが････

よくオブジェクト指向を理解できないＣ爺という煽りを見かけるが
構造化プログラミングを本当に理解してれば然程苦労しないでしょ？

こんなふうに思うのはＣ++から入った俺だけなのかなぁ･････
ちなみに仕事でのメインの言語歴
VC++→Java
だけど一番好きな言語はＣ

>>442
そういう意味ではVCだって「非オブジェクト指向」的につくることは
できる。(ボタンを貼り付けて..)
C++だってC言語っぽく書けるし。
さっきも言ったようにVB.netはあんまりみてないから、どれだけVB
っぽく書けるのかがわからんが、結局のところ「オブジェクト指向」
ってのをどれだけ活用するかによって、特に会社なんかでのチーム
プロジェクトにメリットがでてきて企業の差が生じるんだろうね。

結局、VB.netがオブジェクト指向的な考えなしにできるのであれば
VBからVB.netに移行するのはそれなりにメリットがあるのかな。
教育コストの面で。考えを改め。

自分が構築できなくても、ライブラリがオブジェクト指向なものになっていれば
かなり恩恵は受けられると思うな。俺は。

Java使いじゃなくてJava厨

言語の些細な側面に縛られてる人達が集うスレはここですか？

なんでこんな糞ｽﾚが盛り上がってんだYO!

休みだもん。

あれだ
○○は史上最強とか武田騎馬隊×ジオン軍とかそんなスレが好きな人たち

＞武田騎馬隊×ジオン軍
そ、そんなすばらすぃスレはど、どこにあるんでござるか？

>>435
>あれはJScriptだ」とでも言えば良いのかな？ （ちなみにNetscapeが実装
>したころMS実装なんて無かったよ。）
おいおいなんだそういう程度のやつなのか、お前は。相手にして損したよ。
Netscapeが実装したころのはECMAScriptの実装じゃなかっただろうが。
ネスケのJavaScriptをたたいてECMAScript仕様にしてからMSがJSCriptを
実装したんだよ。そんなことも知らんのかい。

>言いたかったのは
>「ECMAScriptのおかげでプラットフォームに依存しないJavaScriptコードを
>書けるようになったか？なんの役にも立たなかっただろ？」ってこと。
わかってるよ。だからそれはNetscapeの技術力のなさが原因であってECMAの
仕様の有効性とは関係ないっていってるんじゃねーか。

ANSI C++が流布しないのもMSの技術力のなさが原因です。

>>451
三国戦国板にあるよ。
武田騎馬軍団ＶＳフリーザとかもある。

>>454
サンクス。それでは俺、逝ってよし。

>>453
それはそう思う。ま、がんばってんだけどね。バージョン上がるたびに
ちょびーっとずつ。

>>452
粘着君だなあ。

ECMAScriptは既存の実装と矛盾しないように曖昧に作ったんだから、
規格ができた瞬間にNetscapeのJavaScriptは準拠処理系になったのさ。
そんなこともしらんのかいこのヴォケが。

んで、まさか「Netscape実装ができた今では互換性問題が解決した」とか
寝惚けたこと言うんじゃないだろうな。

MSもSunもNetscapeも仲良くしてくれてればもっとすみやすくなったのに・・（´ー`）
あ、そしたら.NETなんて無かったのか、そりゃ困る。

>>457
ばかも寝ぼけも粘着もみんなお前に返してやるって。（ｗ
>そんなこともしらんのかい
だって。ﾌﾟ。話にならんわ。

>>452
>ネスケのJavaScriptをたたいてECMAScript仕様にしてからMSがJSCriptを
>実装したんだよ。そんなことも知らんのかい。

こいつウソばっかだなー。

ECMAScriptの標準化作業が始まったのが96年11月、規格化されたのが97年6月だ。
IE3.0にJScript1.0が載ったのはそれより前の96年8月だ。

お前ら雑談はこっちでやってください
http://pc.2ch.net/test/read.cgi/prog/1012818811/

ここはあくまでJVMとCLRに限定したスレです

>>460
だから？ECMAScriptの実装の話じゃネーノ？

0

>>459
反論できないから中身のない煽りで返すことしかできないのか。やれやれ。
じゃあ>>457のどこが間違ってるのか書いてみそ。できるわけないけど。

>>464
スレ違いだし遅レスだしで、
お前逝ってよし。かえってくんな。

http://www.amazon.com/exec/obidos/ASIN/1556229038/
理解できるかどうか分からんけど、とりあえず注文してみた。

CLRマンせー

あげあえふぁｄ

質問スレがないんでここで質問させてください
Visual Studoインストールしようとしたら「インストーラ　パッケージが開けねぇぞ！」って
エラーがでるんだけどこれは何が原因でしょうか？
ヽ（`Д´）ﾉ 　早くはじめたいのにー！　　ちなみに金持ってないんでVS.NETのProです。

>>469
スレ違い

＞470　ああｽﾏｿ　でも質問ｽﾚないよ？

http://pc3.2ch.net/test/read.cgi/tech/1024746501/
ここでじゅうぶんだろ

>>469
> 金持ってないんでVS.NETのProです。

イヤミか(ﾟДﾟ)ｺﾞﾙｧ

.netくらい買えよ。俺はアカデミックを１００ドルでかったよ。
アメリカでだけど。

あふぉ、アカデミックはマジでクソ安なんだよ。

お前社会人だったら学生に土下座して頼めよ。そしたら
生協でかってくれるかもしれないぞ。

どうでもいいけどお前らスレ違い

うるせーよ、馬鹿

sscliもJDKもソースコードはタダで入手できますが？
いったいなんの話をしてるんですか？

Parrotもこのスレでいいのかな？
http://www.parrotcode.org/

http://www.southern-storm.com.au/portable_net.html

本家に入社した新人にJava教える講師が
○通からきた講師なんてなけちゃうぜ＠Java陣営

くそ遅いインタプリタJVMのリークだけはかんべんしてくれよ

なんで今ごろこんなクソスレが上がってんだよ

>>497
sscliは何年も前のふる〜いソースコードですが、
あなたはそんなもんで喜んでいるのですか？
お手軽な人ですね。（ぷ

>>497どこ〜？

>>482
宅配便？

.NET vs JVMが正しいんじゃないのか？
(すくなくともJavaじゃないよね・・・)

ああ、ｽﾏｿ
眠くてうっとりしてしまいますた。。。

結局まともにVMについて語れるやつはいないと。。。

２ちゃんねるには馬鹿しかいないと。。。

>>491 自分もバカだって認めている訳ね。

バカだけだとは思わないけど、あまりに房が増えたので
まともな書き込みがしずらい雰囲気はあるな。
まあここは昔からそうか（ｗ

２ちゃんに何か期待してる奴っているの？

>>494
面白いネタを期待してる。

真面目な方では話よりもリンクに期待してる。

>>494
このスレみてりゃ分るだろ

まあJVM >>>>>> CLRくらいだろうな。
普通に考えると。

Ruby>>>>>>>>>>>>>>>>>>>>>>>>>CLR=JVM>>>>>>>>>>Parrot

Perl>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Python>>>>>>>>>>>>>>>>>>
>>Tcl>>>>>Ruby>>>>>>>>>>>>>>>>>>>>>>>>>CLR=JVM>>>>>>>>>>Parrot

VB >>>+e308 Ruby and Perl