Таким образом, вопрос сводится к следующему: есть ли какие-либо причины, помимо предпочтения одной парадигмы другой или какой-либо команды или корпоративных предпочтений, которые заставили бы вас выбирать F #, а не IronPython или наоборот?Предполагая, что вы одинаково уверены в обоих?Или они абсолютно эквивалентны для всех практических целей?
Как обычно, «это зависит от того, что вы делаете». Но поскольку вы спросили, начните здесь:
Разнообразие наборов инструментов
На мой взгляд, IronPython, по сути, такой же, как C #, с немного другим синтаксисом - я знаю, это обобщение для двух языков с совершенно разными системами типов, ноони больше ничего не могут сказать о еще одном императиве, ооо языке.Будь то C #, или Java, или C ++, или Python, вы решаете языки, используя примерно одинаковые методы, идиомы, стратегии, стиль и т. Д. Если вы являетесь разработчиком .NET, вы почти наверняка работали с C # или VB.NET, и вы уже писали код в императивном стиле до тех пор, пока вы используете языки.
Самым большим преимуществом F # является то, что он поощряет более функциональные стили программирования, даунлайпыабстракции через OO-наследование в пользу композиции функций, неизменяемость как значение по умолчанию, а не как запоздалая мысль, и так далее.Если вы хотите написать функциональный код, вам нужно использовать функциональный язык.
Конечно, вы можете написать функциональный стиль в C # и Python, но функциональные возможности привиты в качестве запоздалой мысли.В Python отсутствуют многострочные лямбды, а C # слишком многословен, и время от времени глючит , чтобы использовать функциональный стиль в тех местах, где вы хотите его использовать, в частности, C # имеет целую массу загруженных ошибок Что касается делегатов и захвата локальных переменных, то оба языка испытывают недостаток в оптимизации хвостовых вызовов почти везде, где вы бы хотели их использовать, вывод типа C # - шутка по сравнению с F #.Я пытался использовать C # в качестве функционального языка с очень плохими результатами:)
Теперь большинство людей могут признать, что проблемы затрудняют, но не делают невозможным программирование в функциональном стиле с использованием C # или Python.Однако, по моему опыту, это не языки, которые делают это невозможным, это программисты в вашей команде.Если у вас есть 10 или 12 человек, пишущих код на императивном языке, вы не сможете долго применять функциональный стиль - языки не делают ничего, чтобы препятствовать императивному стилю.И поскольку программисты уже пишут в этом стиле, это то, что вы получаете.Если у вас в команде нет действительно сильных и немного мазохистских энтузиастов FP, я не думаю, что они могли бы долго реализовывать чисто функциональный стиль программирования на императивном языке.
Лучший аргумент в пользу F # isn 'Не обязательно само функциональное программирование, но действительно разнообразие вашего инструментария.Вы получаете больший ROI, соединяющий F # и C # (другую парадигму программирования и аналогичную систему типов), чем пара IronPython и C # (та же парадигма программирования и другая система типов).
Пример моей компании
Хорошо, с учетом вышесказанного, я пытался настаивать на F # в моей компании.Я не буду вдаваться в подробности того, что мы делаем, но по сути моя команда ведет пользователей через процесс заказа кабельных и телефонных услуг для таких компаний, как Time Warner, ComCast и других кабельных провайдеров.
Это действительно более сложный процесс, чем кажется.Для начала, существует сложный механизм правил, который определяет доступность продуктов, зависимостей и исключений между продуктами и т. Д. Мы проходим график механизма правил и строим из него дерево решений, затем передаем дерево клиенту, чтобы они моглиотображать его пользователю и собирать пользовательский ввод, клиент отображает графический интерфейс обратно в нашу структуру дерева решений, мы проходим дерево и проверяем все на соответствие механизму правил и т. д.
Я бы сказал, что 95% нашего кода - это простая навигация, манипулирование и обработка древовидных структур данных. Прямо сейчас все, что мы пишем, - это C # и его беспорядок. Кстати, одной из сильных сторон F # является манипулирование AST и символьная обработка (см. Сравнение C # и F # кода для обработки AST ), и все это возможно, потому что сопоставление с образцом - это круто.
Сопоставление с образцом - это настоящая убийственная особенность, именно то, что нужно нашему C # коду для его очистки, и поэтому нам нужен F #. У нас нет никакой пользы для IronPython, потому что он не лучше в символьной обработке, чем C #.
Резюме
Парадигма функционального программирования и сопоставление с образцом - две убойные функции, которыми я наслаждаюсь с F # каждый день. Я мог бы рассказать о async поточной модели F #, примитивах параллелизма передачи сообщений, поддержке монад, новых функциях, таких как активные шаблоны и т. Д., Но это все пулевые комментарии. Для меня это те две убойные возможности, которые делают аргумент в пользу F # поверх Python - по крайней мере, для моих собственных проектов.