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

Я только начинаю изучать функциональное программирование (FP). Я из мира ООП, где все являются объектами, и большинство из них изменчивы. Мне трудно обойти идею, что у функций нет побочных эффектов.

Если что-то не является изменчивым, то как общие объекты, такие как Employee или Person, представлены в FP.

Можно ли использовать FP для создания полноценного корпоративного приложения?

Вопрос не в том, можно ли использовать FP на предприятии? но должны ли мы использовать FP в Enteprise?

Конечно вы можете. Вы можете разработать любое приложение с любым языком программирования, поэтому они называются «Тьюринг завершен».

Теперь к вопросу «Нужно ли использовать его на предприятии?» Это зависит от вас или ваших работодателей, FP может быть действительно полезным в некоторых приложениях, и на самом деле, он используется довольно часто: Haskell в отрасли

Теперь вы можете спросить: «Так почему же не используется больше?» главным образом потому, что другие языки Imperative / OO более распространены, и компании отказываются переходить на более «экзотический» язык, потому что они привыкли к Java или C ++.

Я начал изучать языки FP пару лет назад (Haskell, Scala, Scheme) и, хотя я далек от того, чтобы быть экспертом, я обнаружил, что они могут сделать меня чрезвычайно продуктивным, для определенных задач больше, чем C ++ или Java ,

ИМО, некоторые сильные стороны языков FP:

• Они, как правило, очень лаконичны, но сохраняют четкую семантику.
• Вы можете использовать декларативный стиль и вам не нужно слишком много думать о деталях реализации.
• Система с богатыми типами, такая как Haskell, может улавливать множество логических ошибок очень рано (во время компиляции). Насколько я знаю (на самом деле не очень), SML и Ocaml предлагают аналогичные преимущества.

До сих пор я находил переход к парадигме FP довольно захватывающим и не слишком сложным, если вы потратите на него достаточно времени. (Но сколько времени я потратил на изучение C или C ++? Довольно много!)

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

К сожалению, эта парадигма не является основной: большинство компаний склонны использовать только проверенные технологии, поэтому они будут держаться подальше от FP, пока у них не будет достаточно доказательств того, что она действительно работает, что имеется достаточно разработчиков, инструментов, библиотек, сред. Поэтому (намного) труднее найти работу, в которой вы можете заниматься программированием на ПП прямо сейчас.

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

Кроме того, существует тенденция вводить некоторые функции FP в основные нефункциональные языки, такие как C #, C ++, чтобы программисты могли использовать некоторые FP без необходимости полного переключения парадигмы. Возможно, через десять лет эти языки будут охватывать достаточное количество функций FP, так что переключиться на чисто функциональный язык будет намного проще.

Я не думаю, что это обязательно лучшая идея. Но это зависит от характера конкретного применения.

Я очень верю в философию Эрика Эванса, описанную в его книге « Проектирование на основе предметной области» , в том, что вы должны создать модель предметной области, которая представляет проблему, которая может помочь вам решить вашу проблему. Эванс предлагает найти язык программирования, подходящий для конкретной проблемы, например, он упоминает Фортран как способ решения задач математического характера. Или даже создание специализированных предметно-ориентированных языков для решения проблемы.

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

Теперь дело с корпоративными приложениями состоит в том, что этот тип приложений (если вы можете обобщить о корпоративных приложениях) часто включает в себя изменение состояния объектов, идентификация которых важна, и сохранение измененных объектов в базе данных. Этот очень обобщенный тип проблемы ИМХО гораздо лучше решается с помощью объектно-ориентированной модели, чем функциональной модели.

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

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

редактировать

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

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

Что касается вашего вопроса о бизнес-объектах, я думаю, что ваша настоящая проблема с неизменяемостью. В этом случае учтите, что вы возвращаете нового «Человека» каждый раз, когда вы изменили бы его, если бы использовали императивный язык.

Обратите внимание, что эта техника также может быть реализована с использованием императивных языков!

Функциональное программирование (FP), как и объектно-ориентированное программирование (OOP), являются парадигмами. Они представляют разные модели или подходы к проблемам программирования. Эти различные подходы не лишают возможности создавать масштабируемое, обслуживаемое и расширяемое программное обеспечение. Это не значит, что подходы эквивалентны для всех типов проблем; они не. Некоторые проблемы лучше (или хуже) приводятся в соответствие с конкретными парадигмами, например, FP не будет моим первым выбором для программы, которая имеет зависимую последовательность операций с побочными эффектами. Однако такие программы могут и были написаны, и написаны хорошо.

Да, FP можно использовать в корпоративных приложениях. Clojure является одним из примеров языка FP с успехом на предприятии: http://cognitect.com/clojure#successstories

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

Короче говоря, государственное представительство может быть очень похоже на ОО. Это изменение состояния, которое очень отличается. Так, например, в состоянии FP могут быть представлены списки и карты. Список сотрудников может выглядеть так:

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

Есть два способа обработки состояний в FP. Одним из них является что-то вроде функционально-реактивного программирования. В этой парадигме все состояния обрабатываются только на самом высоком уровне ... например, HTML-представление вашего приложения имеет состояние в представлении (например, имя человека, адрес и т. Д.). Теперь, когда вы нажимаете «обновить имя», вызывается функция, которая обрабатывает все, что касается обновления имени, за исключением фактического изменения имени. Это может звучать странно ... но терпите меня. Затем измененное имя будет возвращено функцией, и представление (или постоянное хранилище данных и т. Д.) Покажет новое имя. Или, в качестве альтернативы, будет возвращена вся новая структура с обновленным именем. Так что же делает функция? Он проверяет имя и возвращает новое имя, если оно действительно, и ошибку, если это не так, и, возможно, новый вид или навигационная ссылка для подражания. Для чего-то более сложного, чем изменение имени, это может сделать намного больше.

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

С помощью этой парадигмы контейнер или инфраструктура должны обрабатывать обновление дисплея, базы данных или чего-либо еще, нуждающегося в обновлении из нового состояния. Таким образом, вы можете представить себе структуру, которая рисует приложение на экране. Когда пользователь нажимает что-то, функции вызываются и возвращается новое состояние. Структура затем обновляет экран, либо перерисовывая все, либо разумно перерисовывая части дисплея. См. Http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

Clojure использует вторую парадигму, с которой я столкнулся, и которая заключается в том, чтобы изолировать изменения состояния, но не обязательно ограничивать их до самого высокого уровня. С Clojure все изменяемые состояния должны быть «сохранены» (если вы не используете объекты Java для состояния) атомом, агентом или ссылкой. То, как это работает, заключается в том, что объект, который удерживается или на который указывает или на который ссылается (как бы вы ни хотели его вызвать), атом / агент / ref является неизменным, но атом / агент / ref может измениться, чтобы указывать на новый объект. В этом случае вы используете специальные методы для atom / agent / ref, которые говорят «обновите объект, выполнив то-то и то-то и переназначив атом / agent / ref новому объекту».

Почему это полезно, спросите вы? Поскольку неизменяемый объект, на который ссылаются эти конструкции Clojure, может быть передан функции, которая что-то делает, и во время выполнения этой функции его ссылка на объект гарантированно не изменится. То есть atom / agent / ref не передается в функцию, но неизменный объект, на который они указывают, передается. Атомы, агенты и ссылки имеют специальные свойства, которые обрабатывают обновления и параллелизм безопасными и частью языка. Смотрите http://clojure.org/state

Надеюсь, это поможет. Я предлагаю прочитать больше о Clojure State и FRP, чтобы лучше понять, как сотрудники и лица могут быть представлены в FP. Хотя фактическое представление будет похоже на объектно-ориентированное программирование ... это изменчивость, которая действительно отличается.