Вопрос

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

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

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

Это было полезно?

Решение

Я ничего не могу сказать о 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 с вашим приложением не подходит.

Другие советы

Будут ли приложения, написанные на 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 Rails внутри IIS является привлекательным предложением для некоторых разработчиков Windows, поскольку оно позволяет им лучше интегрироваться с существующими серверами/инфраструктурой управления и т. д.

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

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

Очевидно, они совместимы с Python и Ruby, если вы не используете в своих программах какие-либо из .net framework.

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

Если вы разрабатываете приложение, если вы используете средства .NET без использования ресурсов, вы теряете & кросс-платформенность " это не всегда проблема.

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

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

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

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

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

scroll top