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

Я тільки починаю вивчати функціональне програмування (FP). Я родом із світу ООП, де все є предметами, і більшість з них є змінними. Мені важко обгортати поняття, що функції не мають побічних ефектів.

Якщо щось неможливо змінити, як предмети, представлені звичайними предметами, такими як Співробітник або Особа, представлені на ПП.

Чи можна використовувати ПП для створення повноцінного корпоративного додатку?

Питання: Чи не можна використовувати ПП на підприємстві? але чи варто використовувати FP в Enteprise?

Звичайно, ви можете. Ви можете розробити будь-який додаток з будь-якою мовою програмування, тому їх називають "Turing complete".

Тепер до питання "Чи варто використовувати його на Підприємстві?" Це залежить від вас або ваших роботодавців, FP може бути дуже корисним у деяких програмах, а насправді він використовується досить багато: Haskell у галузі

Тепер ви можете запитати "Так чому б більше не використовувались?" головним чином тому, що інші мови імперативів / OO є більш поширеними, і компанії відмовляються переходити на більш "екзотичну" мову, оскільки вони звикли до Java або C ++.

Я почав вивчати мови FP пару років тому (Haskell, Scala, Scheme), і, хоча я далеко не фахівець, я виявив, що вони можуть зробити мене надзвичайно продуктивним, для певних завдань більше, ніж C ++ або Java .

ІМО, деякі з сильних мов FP:

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

Досі я вважав перехід на парадигму FP досить захоплюючим і не надто складним, коли ви витрачаєте на це достатньо часу. (Але скільки часу я витратив на вивчення C або C ++? Досить багато!)

Тому я вважаю, що з технічної точки зору є цілком доцільним розробити повне корпоративне додаток, використовуючи функціональну мову програмування.

На жаль, ця парадигма не є мейнстрімом: більшість компаній прагнуть використовувати лише перевірені технології, тому вони будуть триматися подалі від ПП, поки не матимуть достатньо доказів того, що це насправді працює, що є достатньо розробників, інструментів, бібліотек, рамок. Тому знайти (набагато складніше) знайти роботу, в якій зараз можна займатися програмуванням FP повноцінно.

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

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

Я не думаю, що це обов'язково найкраща ідея. Але це залежить від характеру конкретного застосування.

Я дуже вірю у філософію Еріка Еванса, описану в його книзі « Дизайн , керований доменом» , що ви повинні створити доменну модель, яка представляє проблему, яка може допомогти вам вирішити вашу проблему. Еванс пропонує знайти мову програмування, яка сидить, з конкретною проблемою, наприклад, він згадує Фортран як спосіб вирішення завдань математичного характеру. Або навіть створення спеціалізованих мов, специфічних для домену, для проблеми.

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

Тепер справа в застосуванні для підприємств полягає в тому, що цей тип додатків (якщо ви можете узагальнити інформацію про додатки підприємств) часто включає зміни стану сутностей, ідентичність яких має важливе значення, та збереження модифікованих об'єктів у базі даних. Ця дуже узагальнена проблема проблеми IMHO набагато краще вирішується за допомогою об'єктно-орієнтованої моделі, ніж функціональної моделі.

Це не означає, що є області програми для підприємств, які не можна було б краще вирішити за допомогою функціональної парадигми. Наприклад, модуль аналізу ризику банківської програми або модуль планування маршруту в додатку доставки. І, можливо, деякі корпоративні програми можуть бути реалізовані повністю з використанням функціональної парадигми.

Але в цілому, я думаю, що об'єктно-орієнтована парадигма дозволяє створювати більш корисні моделі доменів для більшості корпоративних програм.

Редагувати

У зв'язку з деякими обґрунтуваннями, на цю відповідь була звернена моя увага - і оскільки я її написав, я дізнався багато більше про ПП - і я не зовсім впевнений, що більше згоден з власною відповіддю. Деякі функціональні мови можуть дуже добре описати випадки використання. Але вам потрібно вивчити зовсім інший настрій розуму.

Так, це може. 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"]]

Я знаю два способи обробляти модифікацію стану в ПП. Одне - це щось на зразок функціонального реактивного програмування. У цій парадигмі всі стани обробляються лише на найвищому рівні ... наприклад, перегляд 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, які говорять "оновіть об'єкт тут, роблячи таке і таке, і перепризначивши atom / agent / ref на новий об'єкт".

Чому це корисне ви можете запитати? Оскільки незмінний об'єкт, на який посилаються ці конструкції Clojure, може бути переданий функції, яка щось робить, і поки ця функція працює, її посилання на об'єкт гарантовано не зміниться. Тобто, атом / агент / ref не передається функції, але незмінний об'єкт, на який вказують, передається. Atoms, агенти та refs мають особливі властивості, які обробляють оновлення та паралельність безпечними та частинами мови. Дивіться http://clojure.org/state

Я сподіваюся, що це допомагає. Я пропоную прочитати докладніше про штат Clojure та FRP, щоб краще зрозуміти, як можуть бути представлені працівники та особи у FP. Хоча фактичне представлення було б подібне до об’єктно-орієнтованого програмування ... саме ця мутаційність справді відрізняється.