.NET が Python および Ruby アプリケーションにどのような影響を与えるか、興味があります。
IronPython/IronRuby で記述されたアプリケーションは .NET 環境に非常に固有であり、本質的にプラットフォーム固有になるのでしょうか?
.NET 機能をまったく使用しない場合、IronPython/IronRuby には、.NET 以外の機能よりも優れている点は何ですか?
.NET が Python および Ruby アプリケーションにどのような影響を与えるか、興味があります。
IronPython/IronRuby で記述されたアプリケーションは .NET 環境に非常に固有であり、本質的にプラットフォーム固有になるのでしょうか?
.NET 機能をまったく使用しない場合、IronPython/IronRuby には、.NET 以外の機能よりも優れている点は何ですか?
IronRuby については何も言えませんが、ほとんどの Python 実装 (IronPython、Jython、PyPy など) は、可能な限り CPython 実装に忠実であるように努めています。ただし、IronPython はこの点で急速に最高のものの 1 つになりつつあり、Planet Python にはそれに関するトラフィックがたくさんあります。
開発者が CPython で書くものとは異なるコードを書くことを奨励する主な理由は、NumPy のような C 拡張モジュールがないことです (これは Jython と PyPy でも同様の問題です)。
注目すべき興味深いプロジェクトは、IronClad です。これにより、IronPython 内から C 拡張モジュールを呼び出せるようになります。これは最終的に、好きなモジュールを使用して CPython でコードを開発できることを意味するはずであり、変更せずに IronPython で実行できます。
http://www.resolversystems.com/documentation/index.php/Ironclad
だからあなたの質問に答えるために:
CPython でも動作する IronPython アプリケーションを作成するのは十分に簡単なはずですが、私はおそらくその逆を目指しているでしょう。IronPython でも動作する CPython プログラムです。そうすれば、うまくいかない場合は、既知の回避策がある既知のバグである可能性が高くなります。
IronPython などの既存の利点は、言語の代替実装を提供することです。これは、CPython のバグを見つけるのに役立つ場合があります。また、何らかの理由で (Silverlight のように) アプリケーションと共に CPython 実装を配布することが適切でない場合に、Python アプリケーションをデプロイするための代替方法も提供します。
IronPython/IronRuby で記述されたアプリケーションは .NET 環境に非常に固有であり、本質的にプラットフォーム固有になるのでしょうか?
IronRuby は現在、ほとんどの主要な ruby 標準ライブラリと ruby gem のサポートを同梱しています。
これは、C 拡張機能に依存しないほとんどすべてのネイティブ Ruby アプリをサポートすることを意味します。
反対に、CLR に依存しないネイティブ Ruby アプリを IronRuby で作成することが可能になり、それらは MRI に移植可能になります。
人々が CLR を使用してアプリの拡張機能を作成または使用することを選択するかどうかは、MRI 用の C 拡張機能を作成または使用するかどうかと同じ問題です。
「C で CRuby 拡張機能を作成するよりも、C# で IronRuby 拡張機能を作成する方がはるかに簡単なので、ネイティブの Ruby コードに固執する必要がある拡張機能を作成する人はいますか?」という副次的な質問があります。、しかしそれは完全に主観的です。
全体として、拡張機能の作成を容易にすることは大きなメリットだと思います。
.NET 機能をまったく使用しない場合、IronPython/IronRuby には、.NET 以外の機能よりも優れている点は何ですか?
パフォーマンス: IronRuby はすでに大部分で MRI 1.8 よりも高速であり、MRI 1.9 に遠く及ばず、将来的に改善されるだけです。この点ではpythonも似ていると思います。
展開: 人々が言及したように、IIS 内でネイティブの Ruby クロスプラットフォーム Rails アプリを実行することは、一部の Windows ベースの開発者にとって魅力的な提案です。これにより、既存のサーバー/管理インフラストラクチャなどとの統合が向上するためです。
安定性: MRI 1.9 は 1.8 よりもはるかに優れていますが、CLR のガベージ コレクターとベース ランタイムが C ruby よりもはるかに優れていることに異論を唱える人はいないと思います。
IronPython/IronRuby は .net 仮想マシンで動作するように構築されているため、本質的にプラットフォーム固有であると言えます。
プログラムで .net フレームワークを使用しない限り、これらは Python および Ruby と互換性があるようです。
Mono ページによると、IronPython は Mono の .Net ランタイムの実装と互換性があるため、実行可能ファイルは Windows と Linux の両方で動作するはずです。
ライブラリまたはフレームワークを作成すると、人々はそれを .NET コードで .NET 上で使用できます。それは彼らにとってもあなたにとってもとてもクールです!
アプリケーションを開発するとき、.NET の機能を放棄して使用すると、「クロスプラットフォーム性」が失われますが、これは必ずしも問題ではありません。
これらの使用を内部 API でラップすると、後で .NET 実装を純粋な Python、ラップされた C (CPython の場合)、または Java (Jython の場合) に置き換えることができます。
最初の質問には 2 番目の質問で答えます。.Net から何も使用せず、言語の実装によって提供される元のライブラリのみを使用する場合、*.py または *.rb ファイルを別の実装で解釈できます。仕事。
利点は、.Net ショップが通常、適切なフレームワークをクライアント マシンにインストールするなどの面倒を見る場合です。Python または Ruby コードが必要な場合は、インストールを配布するために別の「フレームワーク」の必要性をサポートする必要があります。バージョンの問題などに対処してください...したがって、別の言語内で.Netフレームワークの力を使用する+配布/メンテナンスを可能な限りシンプルに保つという2つの利点があります。
Apache/Mongrel タイプのソリューションではなく IIS で Rails/Django を実行するのはクールだろう