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

Question

Я убежден, что функциональное программирование является отличным выбором, когда речь идет о приложениях, требующих большого объема вычислений (интеллектуальный анализ данных, AI, nlp и т. Д.).

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

Пожалуйста, не обращайте внимания на тот факт, что очень мало людей используют функциональное программирование, и это довольно сложно.

Спасибо

Answer 1

Функциональные языки программирования, такие как Clojure и Scala, хороши практически для всего. Что касается Haskell, опытный программист на Haskell, вероятно, сможет заменить Haskell любым языком для любой проблемы - эффективной или нет. Я не знаю, есть ли функциональный язык программирования, который можно было бы считать / лучшим / из всех языков для этой конкретной проблемы, но будьте уверены, будет работать и очень хорошо.

Также в JVM реализованы Clojure и Scala. Так что технически они / находятся / на платформе предприятия.

Answer 2

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

В любом случае, вы можете найти мой бизнес-пример здесь .

Answer 5

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

Код - это данные, данные - это код, и оба должны быть похожи на воду.

Answer 6

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

Answer 7

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