Аргументы в пользу IronRuby и IronPython
Думаю, все уже слышали новости о некоторых ключевых разработчиках, покидающих команду Dynamic Languages из-за того, что они воспринимают как ослабление поддержки динамических языков в Microsoft.
Я очень люблю Python и стараюсь часто его использовать. Итак, я забочусь о IronPython и хотел бы, чтобы он продолжал развиваться. Я уверен, что многие люди испытывают то же самое к IronRuby. Но я все еще не могу понять , почему разработчики .NET должны заботиться о IronRuby и IronPython?
Если бы вы написали письмо в Microsoft с просьбой продолжить поддержку и разработку DLR и «Железные языки», какие аргументы вы бы использовали?
Если бы вы убедили своего работодателя посвятить время разработчикам работе над еще не созданными поддерживаемыми сообществом версиями IronPython или IronRuby, как бы вы рационализировали это в с точки зрения стоимости бизнеса?
Вот несколько интересных вариантов использования, которые я мог бы придумать, но если бы я был менеджером, размышляющим над вышеуказанным вопросом, я бы, вероятно, не нашел их , которые убедительными:
- Встроенные языки сценариев в больших приложениях: Допустимый вариант использования, но он кажется нишевым сценарием для большинства разработчиков.
- Тестирование и автоматизация тестирования: Ruby, в частности, имеет богатый выбор прекрасных инструментов и библиотек для тестирования, и было бы неплохо использовать их в .NET через IronRuby. Но похоже, что эквивалентные библиотеки .NET заполняют этот пробел, такие как SpecFlow и Selenium's WebDriver .
- Запуск существующих фреймворков в стеке Microsoft: Если IronRuby позволит Ruby on Rails работать в Windows с IIS и MS SQL, это может побудить магазины, которые стандартизировали стек Microsoft, принять RoR.
Кто-нибудь может придумать что-нибудь получше?
3 ответа
То, что вы там написали, верно, и я добавлю еще несколько пунктов:
- Использование интерактивной консоли для быстрого просмотра / тестирования методов.
- Поскольку разработка в IronRuby / IronPython выполняется быстрее, вы можете использовать его для написания POC, а затем реализовать реальное приложение на C # или на том, что вы используете.
- Реализуйте DSL в IronRuby и используйте их из статических языков.
- Добавление динамических возможностей (например, консоли REPL) в приложения со статическим языком.
- Гештальт.
- Для рубистов: написание WPF и Silverlight (возможно, приложений WP7) на IronRuby.
Я бы не стал недооценивать ценность встраивания одного из них в большое приложение. Я использовал возможности метапрограммирования Ruby для изменения внутренних компонентов приложения на лету, чтобы подключаться к вещам, к которым обычно трудно получить доступ (это особенно верно для событий; я легко могу добавить временный внешний крючок, чтобы вручную вызвать событие для тестирование вместо фактического изменения и перекомпиляции исходного кода C #). Это позволило мне выявлять ошибки и легче воспроизводить сложные сценарии. Это также позволило мне прототипировать различный код, который позже я преобразовал бы в модульный тест или новые классы.
Кроме того, это может быть полезно для тестировщиков, выполняющих ручной тест. Общие задачи могут быть включены в автоматизированные сценарии, которые они могут запускать.
Облегченные сценарии - это очень веская причина иметь динамические встроенные языки в наборе инструментов .Net.
Моя компания занимается разработкой программного обеспечения для научных приборов. Сбор и анализ данных выполняются с помощью сценариев в рамочном приложении. Это позволяет нам очень быстро реагировать на различные потребности наших клиентов.
Мы оцениваем технологии для обновления нашего программного обеспечения, поэтому нам не нужно поддерживать собственный язык сценариев. Я посмотрел на Qt / PyQt, но меня не хватило, когда его продали Nokia. Я решил подождать, чтобы увидеть, насколько созреет IronPython. Я решил использовать IronPython после выхода .Net4 и C # 4.
Сейчас я думаю, что, возможно, принял неправильное решение и подумываю вернуться к Qt / PyQt. Как тебе это по веской причине?