Создание аргумента для IronRuby и IronPython

Question

Полагаю, что все уже слышали новости о , когда некоторые ключевые разработчики покидают команду Dynamic Languages ​​ из-за того, что они считают ослабевающей поддержкой Dynamic Languages ​​в Microsoft.

Я очень люблю Python и стараюсь использовать его часто. Поэтому, в общем, я забочусь о IronPython и хотел бы, чтобы он продолжал развиваться. Я уверен, что многие люди чувствуют то же самое для IronRuby. Но вещь, которую я до сих пор не могу понять, это , почему разработчики .NET должны заботиться о IronRuby и IronPython?

Если бы вы написали письмо в Microsoft с просьбой продолжать поддерживать и развивать языки DLR и Iron, какие аргументы вы бы использовали?

Если бы вы убедили своего работодателя выделить время разработчиков на внесение вклада в еще не готовые к выпуску версии IronPython или IronRuby, поддерживаемые сообществом, как бы вы рационализировали его с точки зрения коммерческой ценности?

Вот несколько интересных вариантов использования, которые я мог бы придумать, но если бы я, когда менеджер размышлял над вопросом выше, я, вероятно, не нашел бы их , что убедительно:

1. Встроенные языки сценариев в больших приложениях: Допустимый вариант использования, но для большинства разработчиков он выглядит как нишевый сценарий.
2. Тестирование и автоматизация тестирования: В частности, в Ruby имеется богатый выбор инструментов и библиотек для тонкого тестирования, и было бы неплохо использовать их в .NET через IronRuby. Но кажется, что эквивалентные библиотеки .NET заполняют этот пробел, такие как SpecFlow и Selenium's WebDriver .
3. Запуск существующих сред в стеке Microsoft: Если IronRuby разрешит Ruby on Rails работать в Windows с IIS и MS SQL, это может побудить магазины, которые стандартизировали в стеке Microsoft, принять RoR.

Кто-нибудь может придумать что-нибудь получше?

Answer 1

То, что вы написали, верно, и я добавлю еще несколько маркеров:

• Использование интерактивной консоли для быстрого просмотра / тестирования методов.
• Со времени разработки в IronRuby /IronPython работает быстрее, вы можете использовать его для написания POC, а затем реализовать реальное приложение на C # или что бы вы ни использовали.
• Реализация DSL в IronRuby и использование их из статических языков.
• Добавление динамических возможностей (например, консолей REPL) в приложения на статическом языке.
• Gestalt.
• Для Rubyists: написание WPF и Silverlight (возможно, и приложений WP7) в IronRuby.

Answer 2

Я бы не стал недооценивать ценность встраивания одного из них в большое приложение.Я использовал возможности метапрограммирования Ruby для изменения внутренних компонентов приложения, чтобы подключиться к вещам, к которым обычно было бы трудно получить доступ (это особенно верно для событий; я могу легко добавить временный внешний хук, чтобы вручную вызвать событие длятестирование вместо изменения и перекомпиляции исходного кода C #).Это позволило мне легче выявлять ошибки и воспроизводить сложные сценарии.Он также позволил мне создать прототип различного кода, который я позже превратил бы в модульный тест или новые классы.

Кроме того, он может быть полезен для ручных тестировщиков QA.Общие задачи могут быть включены в автоматизированные сценарии, которые они могут запускать.

Answer 3

Облегченные сценарии - это очень веская причина для включения динамических встроенных языков в набор инструментов .Net.

Моя компания занимается разработкой программного обеспечения для научных приборов. Сбор и анализ данных выполняются с помощью сценариев в каркасном приложении. Это позволяет нам быстро реагировать на меняющиеся потребности наших клиентов.

Мы проводим оценку технологий для обновления нашего программного обеспечения, поэтому нам не нужно поддерживать собственный язык сценариев. Я посмотрел на Qt / PyQt, но замерз, когда он был продан Nokia. Я решил подождать, чтобы увидеть, как IronPython созрел. Я решил использовать IronPython после выхода .Net4 и C # 4.

Думаю, теперь я мог принять неправильное решение и думаю вернуться к Qt / PyQt. Как это по веской причине?