Вы думаете, что функциональный язык хорош для приложений, которые имеют много бизнес-правил, но очень немногих вычисление? [закрытый]

Что такое бизнес-правила, если не функционирует? Приложение правил может быть выражено как применение функции к ряду данных. Это может также быть объединено с полиморфизмом. например, через родовые функции (несколько диспетчеризируют, может быть удобным, также), и наследование.

Код является данными, данные являются кодом, и оба должны быть похожими на воду.

Вы могли бы хотеть проверить iTasks систему, которая является библиотекой для функционального Чистого языка и разработана точно для выражения рабочего процесса и бизнес-процессов.

Я принимаю, когда Вы говорите о большом количестве бизнес-правил, Вы думаете о разработке приложений. Разработка приложений в том смысле, что Вы хотите смоделировать реальный рабочий процесс. В отличие от ванильного программирования, разработка приложений включает более высокие уровни ответственности (особенно для получения требования и тестирования). Если так, я настоятельно рекомендую видеть, могли ли Вы применить управляемую доменом разработку. Естественным выбором для управляемой доменом разработки является объектно-ориентированный подход. Это и то, что много программистов достойно при ориентируемом на объект программировании, являются одной причиной ее популярности в разработке приложений. Однако это не означает, что реальный, проекты большого масштаба всегда пишутся, этот путь (прочитайте http://www.paulgraham.com/avg.html).

Больше чем год назад я копался немного в Haskell и также попробовал несколько вещей, которые я буду рассматривать как типичную бизнес-проблему (Грубо говоря, учитывая многие значения, каков корректный ответ?). Следовательно, я сказал бы, да, необходимо смочь смоделировать много бизнес-проблем с функциональным программированием.

Лично я не мог найти ту же очевидность в Haskell, к которому я могу продвинуть OO + функциональный подход как с C#, но это могло быть то, потому что я не сделал многого с Haskell и намного больше с C#.

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

Так или иначе можно найти мой бизнес-y пример здесь.

Из того, что я видел, Scala похож на него, обрабатывает нормальный Java очень хорошо. Следовательно, что-либо, что Java может обработать для бизнеса, Scala, могло также.

На стороне.NET F# является другим ярким примером функционального языка, который хорошо работает для "бизнес-" приложений. Для помещения его просто F# может сделать все, что C# может сделать, и больше, легче.

Но для обоих из этих языков, "программирование в большой" стороне имеет тенденцию одалживать у ООП. Не то, чтобы существует что-то не так со смешиванием вещей, но возможно это не то, что Вы спросили. Если Вы хотите придерживаться более функционального подхода и сказать, не используют объекты, Вы могли столкнуться с немного большим количеством стычки, потому что поддержка инструментов не будет на том же уровне. С языками, которые легко интегрируются с.NET/Java, это не столь большая проблема.

До "действительно ли это мудро?": Это зависит от проекта, компании и других факторов окружающей среды. Кажется, что общий "шаблон предприятия" то, что код должен быть чрезвычайно dumbed вниз так, чтобы любой мог работать над ним. В этом случае Вы могли бы вовлечь людей, которые будут думать, что использование лямбды делает слишком трудным для других понять.

Но разумно ли использовать функциональное программирование для типичного корпоративного приложения, где есть много бизнес-правил, но мало в сроки расчета?

Бизнес-правила - это просто вычисления, и вы часто можете выразить их более кратко и ясно, используя функциональное программирование.

Все большее количество корпоративных приложений написано на функциональных языках. Citrix XenDesktop и XenServer построены на стеке инструментов, написанном в основном на OCaml. Система поиска людей MyLife написана на OCaml. Мы небольшая компания, но все наше бизнес-программное обеспечение (например, транзакции по кредитным картам, учетные записи, веб-аналитика) написано на F #. В рекламе Microsoft на Bing используется код F #. Возможно, наиболее очевидным примером является использование последних версий C # и .NET, поскольку они почти наверняка используют функциональные концепции (например, делегаты).

Если вы имеете в виду более экзотические функциональные языки, такие как Clojure, Scala и Haskell, то я думаю, что некоторые люди их используют, но у меня нет подробностей.