Я нахожусь в той же лодке, что и вы, и занимаюсь множеством приложений типа «бизнес», ничего более «забавного», чем игры, компиляторы или поисковые системы.
Ваш пробег будет варьироваться, но, по крайней мере, по моему собственному опыту, многие команды разработчиков не хотят прыгать прямо в F #, потому что никто в команде не знает и даже не слышал об этом. И сразу же вы должны ответить на такие вопросы, как "что это делает в отличие от C #?" Если вы можете убедить своего босса позволить вам написать с ним несколько демонстрационных приложений, сделайте это!
Итак, сказав это, я обнаружил, что C # не очень хорош в бизнес-правилах, но обрабатывает GUI как чемпион; Неизменность F # делает разработку GUI неудобной, но бизнес-правила и рабочие процессы кажутся естественными. Таким образом, эти два языка имеют свои сильные стороны и дополняют слабые стороны друг друга.
В моих собственных LOB-приложениях F # вращает вокруг C # в нескольких областях:
Асинхронные рабочие процессы F # и процессоры почтовых ящиков на порядки легче работать с нативными потоками и даже параллельной библиотекой задач. Поскольку я использую процессоры почтовых ящиков для межпотокового взаимодействия, я даже не помню, когда мне в последний раз приходилось блокировать или выполнять thread.join () вообще для синхронизации.
Определение механизмов бизнес-правил и DSL с профсоюзами FTW! Каждое нетривиальное LOB-приложение, над которым я когда-либо работал, имеет свой собственный полуиспеченный язык правил и интерпретатор, и оно почти всегда основано на рекурсивном переключении перечисления для просмотра правил и поиска соответствия. Текущий проект, который у меня есть, теперь содержит более 1300 открытых классов, 900 или около того - простые контейнерные классы, представляющие правило Я думаю, что представление правил в виде объединения F # существенно уменьшит раздувание кода и улучшит механизм.
Неизменяемый код просто работает лучше - если вы получаете новый объект с недопустимым состоянием, вам не нужно далеко искать, чтобы найти строку кода, вызывающую ошибку, все, что вам нужно знать находится в стеке вызовов. Если у вас есть изменяемый объект с недопустимым состоянием, иногда вам приходится тратить много времени на его отслеживание. Вы можете писать неизменный код на C #, но действительно трудно не отступить от изменчивости, особенно когда вы модифицируете объект в цикле.
Я ненавижу ноль. Я не могу дать точную оценку, но такое ощущение, что половина ошибок, которые мы получаем в работе, являются исключениями из нулевых ссылок - объект неправильно инициализирован, и вы не узнаете об этом, пока в коде не будет 30 кадров стека. Я думаю, что F # поможет нам написать больше кода без ошибок в первый раз.
C # обычно хорошо работает, когда:
Вы пишете код графического интерфейса или работаете с изначально изменяемыми системами.
Предоставление DLL или веб-службы множеству разных клиентов.
Ваш босс не позволит вам использовать инструменты, которые вы хотите;)
Так что, если вы можете преодолеть «почему мы хотим использовать новый языковой барьер», я думаю, F # действительно облегчит вашу жизнь.