Как будут затронуты .NET приложения Python и Ruby? - PullRequest
5 голосов
/ 21 января 2009

Мне интересно, как .NET повлияет на приложения Python и Ruby.

Будут ли приложения, написанные на IronPython / IronRuby, настолько специфичны для среды .NET, что по существу станут специфичными для платформы?

Если они не используют какие-либо функции .NET, то в чем преимущество IronPython / IronRuby по сравнению с аналогами .NET?

Ответы [ 7 ]

5 голосов
/ 24 января 2009

Я ничего не могу сказать о IronRuby, но большинство реализаций Python (таких как IronPython, Jython и PyPy) стараются быть максимально верными реализации CPython. IronPython быстро становится одним из лучших в этом отношении, и на Planet Python много трафика по этому поводу.

Главное, что побудит разработчиков писать код, отличный от написанного на CPython, - это отсутствие модулей расширения C, таких как NumPy (это проблема и в Jython и PyPy).

Интересным проектом, на который стоит обратить внимание, является IronClad, который позволит вам вызывать модули расширения C изнутри IronPython. В конечном итоге это должно означать, что вы можете разрабатывать код под CPython, используя любые модули, которые вам нравятся, и он будет работать без изменений на IronPython.

http://www.resolversystems.com/documentation/index.php/Ironclad

Итак, чтобы ответить на ваши вопросы:

Должно быть достаточно просто написать приложения IronPython, которые также работают на CPython, но я бы, вероятно, стремился пойти другим путем: программы CPython, которые также работают на IronPython. Таким образом, если это не сработает, то, скорее всего, это будет известная ошибка с известным обходным путем.

Преимущество IronPython и других , существующих , заключается в том, что они предоставляют альтернативные реализации языка, которые иногда полезны для выявления ошибок в CPython. Они также предоставляют альтернативные методы для развертывания ваших приложений Python, если по какой-то причине вы попали в ситуацию (например, silverlight), когда распространение реализации CPython с вашим приложением не подходит.

2 голосов
/ 17 августа 2009

Будут ли приложения, написанные на IronPython / IronRuby, настолько специфичны для среды .NET, что по существу станут специфичными для платформы?

В настоящее время IronRuby поставляется с большей частью базовой стандартной библиотеки ruby ​​и поддержкой драгоценных камней ruby.

Это означает, что он будет поддерживать практически любое родное приложение ruby, которое не зависит от расширений C.
Обратной стороной является то, что в IronRuby можно будет написать собственные приложения ruby, которые не зависят от CLR, и которые будут переносимы на MRI.

Вопрос о том, будут ли люди создавать или использовать расширения для своих приложений с помощью CLR, - это тот же вопрос, что и люди, создающие или использующие расширения C для MRI - одно не более портативное, чем другое.

Есть побочный вопрос : «так как намного проще создавать расширения IronRuby в C #, чем создавать расширения CRuby в C, будут ли люди создавать расширения там, где они должны придерживаться нативного кода ruby? ", но это совершенно субъективно.

В целом, я думаю, все, что облегчает создание расширений, является большой победой.


Если они не используют какие-либо функции .NET, то в чем преимущество IronPython / IronRuby по сравнению с аналогами, отличными от .NET?

  1. Производительность: IronRuby уже по большей части быстрее, чем MRI 1.8, и не далеко от MRI 1.9, и в будущем ситуация только улучшится. Я думаю, что Python похож в этом отношении.

  2. Развертывание. Как уже упоминалось, запуск собственного приложения кроссплатформенных рельс ruby ​​в IIS является привлекательным предложением для некоторых разработчиков на базе Windows, поскольку позволяет им лучше интегрироваться с существующими серверами / инфраструктурой управления / и т. Д.

  3. Стабильность: хотя MRI 1.9 намного лучше, чем 1.8, я не думаю, что кто-то может не согласиться с тем, что CLR имеет гораздо лучший сборщик мусора и базовое время выполнения, чем C ruby.

1 голос
/ 22 января 2009

Согласно странице Mono, IronPython совместим с реализацией Mono среды выполнения .Net, поэтому исполняемые файлы должны работать как в Windows, так и в Linux.

1 голос
/ 22 января 2009

Если вы создаете библиотеку или инфраструктуру, люди могут использовать ее в .NET со своим кодом .NET. Это очень круто для них и для вас!

При разработке приложения, если вы отказываетесь от использования средств .NET, вы теряете "кросс-платформенность", что не всегда является проблемой.

Если обернуть эти варианты использования внутренним API, вы можете позже заменить .NET на чистый Python, обернутый C (для CPython) или Java (для Jython).

1 голос
/ 21 января 2009

IronPython / IronRuby созданы для работы на виртуальной машине .net, поэтому они, как вы говорите, в основном зависят от платформы.

По-видимому, они совместимы с Python и Ruby, если вы не используете в своих программах .NET Framework.

0 голосов
/ 22 января 2009

Было бы здорово запустить Rails / Django под IIS, а не с решениями типа Apache / Mongrel

0 голосов
/ 22 января 2009

Вы отвечаете на свой первый вопрос вторым, если вы не используете ничего из .Net только оригинальные библиотеки, предоставляемые реализацией языка, вы можете интерпретировать ваш файл * .py или * .rb с другой реализацией. и это должно работать.

Преимущество будет в том, что если в вашем .Net-магазине вы обычно позаботитесь о том, чтобы на клиентском компьютере была установлена ​​правильная среда, и т.д. распределите установку, позаботьтесь о проблемах с версией и т. д. Итак, есть два преимущества: использование возможностей .Net framework на другом языке + упрощение распространения / обслуживания.

...