.NET互換環境のMONO、Beta2リリース 43
ストーリー by GetSet
ゆっくりと、着実に前へ 部門より
ゆっくりと、着実に前へ 部門より
Average曰く、".Net互換環境を目指すMONOのMONO Beta2がリリースされました。
公式サイトを日本語化したサイトをみると、
MSのCLI(仮想マシンのアセンブラのよーなもの)と完全互換で、コンパイラ、JITインタプリタは全て出来ている。
現在はMSの提供する膨大なクラスライブラリと完全互換でフリーなクラスライブラリの整備中で、GUI関連以外はほぼ完成とか。
問題はP/Invokeと呼ばれるWin32なAPIをダイレクトに呼ぶ機能を使った部分の互換性をどうとるか、という事で、これはWineを使って解消するつもりらしい。
なんか見る限りだと結構よさげなのですが、実際に試用されている方はいらっしゃるのでしょうか。"
HelloWorldだけ… (スコア:2, 参考になる)
コンパイルしたら exe が出来てびっくりした。
その exe が Windows で実行できてまたびっくり。
# レベル低くてスマソ
Re:HelloWorldだけ… (スコア:1)
勉強になりました(笑)
#更なる低空飛行なレベル
##むしろ、墜落しているか…
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:HelloWorldだけ… (スコア:2, 参考になる)
-----------------
#そんなワタシはOS/2ユーザー:-)
monoの可能性 (スコア:2, 参考になる)
Re:monoの可能性 (スコア:1, 参考になる)
ちなみにMonoDevelopではデバッグもできます。でもGUIデザインはgladeでやって下さい。
猛烈なでじゃう゛ (スコア:0)
Re:猛烈なでじゃう゛ (スコア:1)
Beta2だし、私はローカル記事でも構わないかと思ったのですけれど。
Re:猛烈なでじゃう゛ (スコア:1)
βとはいえ、そろそろ使い物になるレベルにはなってきているらしい。(隣の部屋の人談)
Re:猛烈なでじゃう゛ (スコア:1)
貴方にとっては「便利」なのかも知れないが、
脳が貴方と繋がってるわけではない他人にとっては、
形が変われば「混乱」するんよ。
#「つかいやすくなったでしょ」症候群を発症してる人を目にするのは辛いのでG7
これが動くと、 (スコア:0)
# もちろん IE なんて普段は使わないのだが、
# 検証用とか、IE しか使えないサイトとか、
# 使い出はいっぱいある。
Re:これが動くと、 (スコア:3, 興味深い)
.NET の行き着く理想は要するに、現在の アプリケーション/Windows/ハードウェア というレイヤーを サービス/.NET/ネットワーク に置換しましょって事ですよね。中期的には Office も .NET アプリケーションになり ASP 的に提供されるとか、即効性のある話では web サービスによる異なるサイト間のサービスリレーションなど、色んな話があった。
で、MS の理想は素晴らしいがそれが囲い込まれた世界にならないように MONO がある、と。そういう話だったのでは。.NET で盛り上がっていた頃のインターネットマガジンに MONO プロジェクトのインタビューがあったと思うので探して読んでみるといいかも。
# ついでに MONO があれば .NET の資産価値が高まるワケで
# MS と MONO は win-win になれる、という話もどこかで聞いたような。
Re:これが動くと、 (スコア:2, すばらしい洞察)
それでセキュリティを確保できるから、次世代Win描画システムはhttp越しにWin32なAPIを通すのを狙っていると思うんですよね。
だから、将来のIEって、X-WindowsみたいにWindowsの画面コンポーネントが(HTMLの部品でなく)直接描画出来るようになるのを狙っていると思うんすよ。
で、こうなるとサーバーとクライアントは必ずWindowsじゃないと駄目、というイヤンな世の中になる・・・・かもです。
で、それじゃぁ困るからMONOを作るんだ、という勢いらしいですね。
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:これが動くと、 (スコア:0)
「X」もしくは「X Window System」です。
Re:これが動くと、 (スコア:0)
Re:これが動くと、 (スコア:1)
Ruby(あくまで一例ですが)みたいな設計の言語だと、それも無いわけですよね。
#しかも 31 bit 以内だと軽く動くように最適化されてるらしい。>ruby
CPUパワーって、そういうところに使うべきもんだと思うなあ。
>(メモリ確保をオーバーフローした結果に基づいて行われた場合を考えてみて下さい)。
古典的な「メモリ確保」なんて、もはややらないのでは?
確保すべきメモリの寸法なんて、人間様(アプリ開発者のコード)が直接計算しないんじゃないかな?
#てゆーかメモリなんてObjectの中に隠蔽されるじゃん。
配列系のObjectに、要素を、「ADD」する、という使い方をしていれば、
(メモリ不足にならない限り)溢れようがないわけで。
そして不足したら例外が挙がるわけで。
そういや例外ってのも強烈な仕掛ですよね。
やばいことが起きたら、起きた側から能動的に「やばいよ」って教えてくれる。
こっちが「意図」しなかった問題が生じたときでも、向こうから教えてくれる。
Cの返し値チェックみたいに、こっちから調べてあげない限り永遠に判らなかったり、
最悪、うまく調べる方法すら無かったり、という心配から、解放されるわけだ。
え?意図しない例外で落ちたらウザイだろって?
そりゃ、Processがやばくなったら落ちるのと、同じですって。
例外は、Processと(そういう意味で)似た防護機能を、
Process単位じゃなくもっと細かいソース上のBlock単位に対し、提供してくれる。
Re:これが動くと、 (スコア:1)
> # MS と MONO は win-win になれる、という話もどこかで聞いたような。
MSに、.NET開発者の拡大というメリットがあるうちは黙認されるでしょうけど、
フリーの互換実装の完成度が高まってMSの利益を脅かすようになったら、
特許紛争もしくは非互換なバージョンアップを仕掛けられて
駆逐されるのではないかという危惧があります。
生殺与奪をMSが握っている状況下での繁栄を、
はたしてwin-winと呼んでいいのかどうか、ちょっと怪しい。
Re:これが動くと、 (スコア:1)
Win-winと呼ぶのでしょうね。
Re:これが動くと、 (スコア:2, 参考になる)
IE が .NET アプリになれば、そういうこともありうるかもしれませんが、それは遠い先の話かと。
Java の場合は一つの言語でポータブルな実行バイナリが作られますが、.NET の場合はそれが複数の言語でできる、というだけなので。
IE を使うだけなら Wine だけでできますので、別に MONO は必要ではありません。
# 以前 Wine を使って Windows バイナリを動かしたときは X forward されなくて悲しかったけど、今はできるのかな?
Re:これが動くと、 (スコア:1, すばらしい洞察)
Javaは言語の名前で、その実行環境はJavaVMです。.NETのCLIと同様にJava以外の言語もJavaVMで動作させることは可能です。具体例はぐぐってみてください。(すぐには見つからなかった...)
よーするに設計思想は似たようなものだけど、作ったところが違うと。MS vs SUNのいつもの(かつての、かな??)構図。
Re:これが動くと、 (スコア:1)
こいつを使えば最終的にJavaをMONO環境に持っていけるという。
これでJavaVMを使う言語もちゃんとMONO環境に行ける?
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:これが動くと、 (スコア:0)
Re:これが動くと、 (スコア:0)
Re:これが動くと、 (スコア:2)
パッチ入れないといけないので、普通に開発するよりも面倒な要素が
1つ増えますし、開発側でも実行時のパフォーマンスはどうなのか
とか、新規の開発環境入れることがトータルで得になるのかとか、
そういうことを考えるとエロゲーで.Net使うメリットはあまりない
ような気がします。
Re:これが動くと、 (スコア:2, 参考になる)
.NET アプリだと .NET Framework 再配布パッケージ (98/Me も対応) で適合バージョンを配布できますし、多少実行速度を犠牲にしても、バグが少なく安定して動作するバイナリを配布してもらえれば、ユーザは .NET だろうがネイティブだろうが、あまり気にしないと思います。
ちなみに、VC++.NET 辺りで開発されていれば、ターゲットを変更するだけで、とりあえずマネージドコードにすることはできます。(MS 公称/とてもできるように見えないのですが……)
そもそもエロゲでカリカリに速度向けチューニングしたコードを書いてるようなところ、今ってどれくらいあるのでしょうか。そこらに転がってるスクリプトプレイヤ程度の物であれば、多少の小細工よりも設計見直したほうが余程速くなると思いますが。;)
Re:これが動くと、 (スコア:0)
それ以外は特に問題ないような。
アプリの速度も問題になりませんし、開発効率は遙かに上。
同じようなのでJavaもありますが、こっちはJREを
インストー
Re:これが動くと、 (スコア:2, おもしろおかしい)
>速度的な問題はもはやでないです。
それ以前に2Dではなくて3Dの普通の方に興味を持てと言いたい。
Re:これが動くと、 (スコア:0)
3Dの普通の方を調教したり陵辱したりしろということですか?
Re:これが動くと、 (スコア:0)
普通の方は、そんな欲望は持たないのです。
自分自身の腕を磨くのに精一杯で。
Re:これが動くと、 (スコア:0)
エロゲーって開発作業のかなりの部分がシナリオやら絵やら音に掛かる
と思うんですけど、.net で効率が上がる部分てそんなに大きいですか?
Re:これが動くと、 (スコア:0)
すでにパッチがあがってるとか、品質は後問題でとにかく
コスト重視といったところも多いですよね。
プログラマを社内で雇うというよりは同人界やそれなりに
有名な個人に頼むケースも多かったり。
だいたいこういった人は職人気質で言語にはCを選ぶ場合が
ほとんどですが、ある操
Re:これが動くと、 (スコア:2, すばらしい洞察)
> ほとんどですが、ある操作ではバッファオーバーフロー
> おこしてたり、へんなポインタ操作していたりあるわけで。
そんな人に「職人」を名乗って欲しくないな。
Re:これが動くと、 (スコア:1)
どこにとって不要かという問題は有る。
たとえばいわゆるドライバとかはC(の職人)のほうが良いだろうし、
内部的にヘビーなことをやってない所謂「アプリ」なら、Cの必要性は殆ど無いだろう。
#RubyがVBに置き換わって欲しいと結構思ってるのでG7
それにしても、ListだのなんだののマトモなData構造をマジメに使おうとすればするほど、
CみたいにIntrospectionも無ければGCも無い環境だと、辛いですね。
Re:これが動くと、 (スコア:0)
.net Frameworkが必要なえろげーはあったかと。
Re:これが動くと、 (スコア:1, すばらしい洞察)
それは分かりませんが、
・Visual Studioを使って、Windows以外の環境で動くアプリケーションが書けるようになる (VBでLinuxアプリケーションが!)
・ASP.NETを使ったWebサービスを書いて、Windows以外の環境で動かすことができる (Apache+FreeBSDでホスティング!)
・Windows系のネットワーク管理システムに、Windows以外の環境で参加 (SMSでMacを管理!)
とか?
書くのは楽だけど、実現するのは簡単ではない。
Re:これが動くと、 (スコア:0)
この為だけにApache2を導入するのに不安がある。
あとVBでLinuxアプリを作れるとかってのは幻想に近い、
むしろVBでLinuxアプリを作る事に無理がある為にLinux側のアプリは
やはり普
Re:これが動くと、 (スコア:1, すばらしい洞察)
Re:これが動くと、 (スコア:1, 興味深い)
これは全く違っていると思いますけど。
特に「ぶちぎれて」の部分は完全に間違ってます、「つけこんで」に置き換えてください。
あと、目指すところの基本路線はJavaと全く違います、
何が違うのかと言えば、将来のWindowsでは、.NETアプリはWindowsにとってのネイティブなプログラムと同一です、
これにより、より確実にWindowsへの呪縛を強める事が可能となると云うメリットがMSにとってあるだけです。
意味合いとして正しいのは .NETはやはりWinFXの序章であり、
次期Windowsの以降作業をスムーズに行えるように今の.NETは存在していると言って良いのでは?
monoは、全く別路線ですけど、結果的にファイルの扱いや色々な部分でJavaと同様に理想の世界にはたどり着けません。
(Cygwin必須の環境では使い勝手も保守性も悪すぎる)
Re:これが動くと、 (スコア:1, 参考になる)
これは違います。Mono on Windowsはcygwinなしで動作します。cygwinが必要なのはmonoをビルドするときだけです。試しにWindowsインストーラでインストールしてみて下さい。cygwin1.dllは入っていません(し、もちろん使いません)。
リソースの無駄 (スコア:0)
UNIXだったら、もっと良いものがいくらでもあるだろうに。
特にASP.NETなんて最低。
FORMやjavascriptは使いづらいし、
<TR>1個書くためにインスタンスを作るなんて馬鹿としか思えん。
「作って地獄」ver2 (スコア:1)
なんか不味いんでしょうかそれ?
かつて、もしかして同じ事を考えていたかも知れない人々が居ますよね。
デスクトップってゆーかクライアントのStandaloneの「GUI」プログラムを、
C言語(や古典Pascal)で書いてた人たちが、おそらくソレなんじゃないかと思います。
その結果何が起きたかってーと、「使って天国、作って地獄」という
GUI開発に対する往年の悪評、です。
悪評はそれ自体は正解なんだけど、欠けてる視点は、
「不適切な環境(言語)で書いてるんだもん、そりゃそうだろ」という点です。
いろんなものをObjectでラップすると、
これが俄然、開発が楽になるんですよね。
----
で、翻って今。
同じ事がwebアプリに起きているような気がしています。
いろんなものをObject[*]でラップすることで、開発が楽になる。
[*]救済手段が前回と同じ「Object」であるのは、単に偶然だと思って構わないと思います。
で、今の(乱暴にいえば)JSP主体の開発って、OOP未満です。
ここが味噌だと思います。
JSPについては、画面とか窓とかWidgetとかいう単位をInstanceとして捉えず
JSPという「Instance(じゃないけどさ)を生成する奴」を主体に据えちゃったんで、
しかもそれを「Page」という概念で我々は捉えちゃってるんで(PはPageのPだからSun本家からして同罪だ)
話がややこしくなってるんだと感じています。
GUI環境じゃ、同じ窓Classの別Instanceを複数作って使う、っていうことは、頻繁にあります。
じゃあJSPも、同じJSPだけど「別Instance」を複数作ることは、考慮されて良さそうなもの。
ところがどういうわけか、我々は「Page遷移」という単位で捉えてる。
せめてPageのInstance単位で「遷移」を考えればいいのに、そうしてない。
あー。そんなわけで、
Tiki本家:webアプリの作り方 [todo.org]の一番下あたりみたいな感じかなーと。
いやー。画面なりWidgetなりを独立したObjectと考えたとたんに、
話が簡単になるなる。驚きです。
Re:リソースの無駄 (スコア:0)
# /. での大なり小なり扱いがよーわからんので[]化
少なくとも、技術的に ASP.Net + WEB Forms が JSP などより劣る部分はないと思いますよ。
両方を真面目に使えばわかると思いますが。
そもそも ASP.Net と WEB Forms を混同していませんか?
Re:リソースの無駄 (スコア:1)
ただし WEB Forms は Java のカスタムタグと根本的に思想が違い、サーバサイド HTML という概念を取り入れています。
これが便利かどうかは別として、各ブラウザでの HTML タグの解釈の違いをフレームワークで吸収し、 開発者は抽象的なタグを書き、フレームワークがブラウザに合った HTML を生成するという発想は良いと思います。
なお、ASP.Net だからと言って WEB Forms を使う必要はありません。
自分でタグを書きたければお好きにどうぞ。
# 私は MS のエバンゲリストじゃありませんが、こうゆう FUD は見兼ねるので・・・