Создание корпуса для IronRuby и IronPython

Question

Я думаю, что все уже слышали новости о some key developers leaving the Dynamic Languages team из-за того, что они воспринимают как ослабление поддержки динамических языков в Microsoft.

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

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

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

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

1. Embedded сценариев Языки в более крупных приложениях: Допустимый вариант использования, но для большинства разработчиков он кажется нишевым сценарием.
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.
• Для рубистов: написание WPF и Silverlight (приложения WP7 тоже, возможно) в IronRuby.

Answer 2

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

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

Answer 3

Легкий сценарий - очень веская причина иметь динамические, встроенные языки в наборе инструментов .Net.

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

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

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