Чи збільшує функціональне програмування «представницький розрив» між проблемами та рішеннями? [зачинено]

Оскільки машинна мова (наприклад, 0110101000110101) комп'ютерні мови, як правило, переросла у вищі форми абстрагування, загалом полегшуючи розуміння коду при застосуванні до проблеми. Assembler - це абстракція над машинним кодом, C - абстракція над асемблером тощо.

Об'єктно-орієнтований дизайн здається дуже хорошим, що дозволяє нам моделювати проблему з точки зору об'єктів, наприклад, проблема системи реєстрації університетських курсів може моделюватися з Courseкласом, Studentкласом тощо. Потім, коли ми пишемо рішення мовою ОО, ми маємо подібні класи, які несуть відповідальність, і це, як правило, корисно для проектування, особливо для модуляції коду. Якщо я даю цю проблему 10 незалежним командам, які вирішують її методом ОО, загалом 10 рішень матимуть спільні класи, що стосуються проблеми. Коли ви починаєте зв'язуватися та взаємодіяти між цими класами, може виникнути велика різниця, тому немає такого поняття, як "нульовий розрив у репрезентації".

Мій досвід функціонального програмування дуже обмежений (використання в реальному світі не використовується, лише програми типу Hello World). Я не бачу, як такі мови дозволяють легко відображати рішення FP для проблем (з низьким представницьким розривом), як це роблять мови OO.

Я розумію переваги FP щодо одночасного програмування. Але я щось пропускаю, чи FP не про зменшення представницького розриву (полегшення розуміння рішень)?

Ще один спосіб запитати це: чи має FP-код 10 різних команд, що вирішують ту саму проблему в реальному світі, багато спільного?

З Вікіпедії з абстракції (інформатика) (моє наголос):

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

Представницький розрив може бути потенційно збільшений, оскільки [деякі] проблеми в реальному світі не моделюються легко за допомогою таких абстракцій.

Інший спосіб, який я бачу, зменшується представницький розрив, - це відшукати елементи рішення до проблеми. У машинному коді 0'і 1s ' дуже важко відстежити, тоді як Studentклас легко простежити назад. Не всі класи OO легко простежують проблемний простір, але багато хто робить.

Чи не потрібно абстракціям ПЗ завжди пояснювати, щоб з’ясувати, яку частину проблемного простору вони вирішують (крім математичних задач)?Гаразд - я добре в цій частині. Переглянувши ще багато прикладів, я бачу, як абстракції FP дуже зрозумілі для частини проблеми, яка виражається при обробці даних.

Прийнята відповідь на пов’язане питання Чи можна використовувати UML для моделювання функціональної програми? - говорить: "Функціональні програмісти не мають великої користі для діаграм". Мені справді все одно, чи це UML, але це змушує мене замислитись про те, як абстракції FP легко зрозуміти / спілкуватися, якщо немає діаграм, які широко використовуються (якщо вважати, що ця відповідь є правильною). Знову ж таки, мій рівень використання / розуміння ПС є тривіальним, тому я не розумію потреби в діаграмах для простих програм FP.

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

Багато відповідей говорять про те, як аналіз і проектування робляться в ПП аналогічно OO, але поки що ніхто не цитує нічого високого рівня (Паул цитував якісь цікаві речі, але це низький рівень). Я вчора багато зробив Google, і знайшов цікаву дискусію. Далі - з функціональних програм Refactoring від Simon Thompson (2004 )

При проектуванні об'єктно-орієнтованої системи, це само собою зрозуміло, що дизайн буде передувати програмуванню. Дизайн буде написано за допомогою системи типу UML, яка підтримується в таких інструментах, як Eclipse. Починаючі програмісти цілком можуть вивчити підхід до візуального дизайну за допомогою таких систем, як BlueJ. Про роботу над аналогічною методологією функціонального програмування повідомляється у FAD: Функціональний аналіз та проектування , але мало інших робіт існує. Для цього може бути ряд причин.

• Існуючі функціональні програми мають масштаб, який не потребує розробки. Багато функціональних програм є невеликими, але інші, наприклад, Glasgow Haskell Compiler, є суттєвими.

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

• Функціональні програми будуються як розвивається серія прототипів.

У цитованій кандидатській дисертації переваги використання методів аналізу та проектування (ADM) окреслені незалежно від парадигм. Але зроблено аргумент, що ADM повинні узгоджуватися з парадигмою реалізації. Тобто OOADM найкраще працює для програмування OO і недостатньо застосовується до іншої парадигми, такої як FP. Ось чудова цитата, на яку я думаю, перефразовуючи те, що я називаю представницьким розривом:

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

Ось набір діаграм, запропонованих FAD:

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

У розділі 5.1 дисертації FAD є тематичне дослідження, яке є системою автоматизації виробництва даних, що стосуються футбольної (футбольної) ліги. Вимоги є на 100% функціональними, наприклад, введення футбольних результатів, виготовлення таблиць ліг, таблиць заліку, таблиць відвідуваності, передачі гравців між командами, оновлення даних після нових результатів тощо. Не згадується, як FAD працює на вирішення нефункціональних вимог. окрім того, що "нову функціональність слід дозволити за мінімальних витрат", що майже неможливо перевірити.

На жаль, окрім FAD, я не бачу жодних сучасних посилань на мови моделювання (візуальні), які пропонуються для FP. UML - це ще одна парадигма, тому ми повинні забути про це.

Основні дані структуровані однаково у майже будь-якій парадигмі. Ви будете мати a Student, a Courseтощо, будь то об'єкт, структура, запис чи інше. Різниця з OOP полягає не в тому, як структуруються дані, а в тому, як структуруються функції.

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

Раптом не так зрозуміло, який клас повинен створити і зберігати всі ці списки. Навіть менше, коли у вас складні комбінації цих списків. Однак ви повинні вибрати один клас.

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

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

Коли я брав свій клас Java років тому, від нас очікували показати свої рішення всьому класі, тому я мусив побачити, як думають люди; як вони логічно вирішують проблеми. Я повністю очікував, що рішення складатимуться навколо трьох-чотирьох загальних рішень. Натомість я спостерігав, як 30 студентів вирішували проблему 30 абсолютно різними способами.

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

Технічною мовою, яка лежить в основі функціонального програмування, є математика . Відповідно, проблеми, які найбільш підходять для вирішення за допомогою функціонального програмування, по суті є математичними проблемами. Під математикою я не маю на увазі таку математику, яку ви б бачили у бізнес-рішеннях, як додавання та віднімання. Я, скоріше, кажу про математику, яку ви можете бачити в Math Overflow, або про математику, яку ви бачили в пошуковій системі Orbitz (це написано в Lisp).

Ця орієнтація має деякі важливі наслідки для функціональних програмістів, які намагаються вирішити проблеми програмування в реальному світі:

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

2. Об'єктно-орієнтовані програми часто будуються зверху вниз. Створюється дизайн класу, і деталі заповнюються. Функціональні програми часто будуються знизу вгору, починаючи з невеликих детальних функцій, об'єднаних у функції вищого рівня.

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

4. Об'єктно-орієнтовані програми можуть бути більш підходящими для бізнес-доменів, оскільки класи, повідомлення між об’єктами та моделями програмного забезпечення - це структура, яка відображає бізнес-домен, фіксує його бізнес-аналітику та документує її.

5. Оскільки все практичне програмне забезпечення виробляє побічні ефекти (I / O), чисто функціональні мови програмування потребують механізму для створення цих побічних ефектів, залишаючись математично чистими (монадами).

6. Функціональні програми можна легше перевірити, зважаючи на їх математичну природу. Система типу Haskell під час компіляції може знаходити речі, які більшість мов OO не може.

І так далі. Як і в багатьох випадках в обчислювальній техніці, об'єктно-орієнтовані мови та функціональні мови мають різні переваги.

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

Я хотів би наголосити на аспекті, який я вважаю важливим і який не висвітлювався в інших відповідях.

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

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

Одним з важливих аспектів, якими вони відрізняються, є спосіб, яким вони дозволяють розширити ваше програмне забезпечення.

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

Функціональне програмування полегшує додавання нових операцій у ваше програмне забезпечення: вам потрібна лише локальна зміна коду, а саме ви додаєте нову функцію, яка обробляє різні формати вхідних даних. З іншого боку, більше додає нові формати: вам потрібно змінити всі функції, які ви вже реалізували (не локальні зміни).

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

Цей різний підхід до розширення є однією з причин, чому OOP є більш підходящим для певних проблем, коли набір операцій змінюється рідше, ніж набір типів даних, над якими ці операції працюють. Типовим прикладом є ДПІ: у вас є фіксований набір операцій , які все віджети повинні реалізувати ( paint, resize, move, і т.д.) , і набір віджетів , які ви хочете розширити.

Отже, відповідно до цього виміру, OOP та FP - це лише два виразні способи організації вашого коду. Див. SICP , зокрема Розділ 2.4.3, Таблицю 2.22 та пункт Повідомлення, що передаються .

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

Більшість функціональних мов не орієнтовані на об'єкти. Це не означає, що у них немає об'єктів (у сенсі складних типів, які мають з ними специфічну функціональність). У Haskell, як і в Java, є списки, карти, масиви, всі види дерев та багато інших складних типів. Якщо ви подивитесь на модуль списку Haskell або Map, ви побачите набір функцій, дуже подібних до методів у більшості еквівалентних модулів бібліотеки на мові OO. Якщо ви вивчите код, ви навіть знайдете подібне капсулювання з деякими типами (або, якщо точніше, їх конструкторами) та функціями, які можна використовувати лише за допомогою інших функцій модуля.

Спосіб роботи з цими типами в Haskell часто майже не відрізняється від способу OO. У Haskell кажу

  null xs
  length xs

а на Яві ви кажете

  xs.isEmpty
  xs.length

Помідор, помідор. Функції Haskell не прив’язані до об'єкта, але вони тісно пов'язані з його типом. "Ах, але , - ви кажете," в Java він називає, який метод будь-якої довжини є відповідним фактичному класу цього об'єкта ". Несподіванка - Хаскелл теж робить поліморфізм із класами типів (та іншими речами).

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

  fmap (* 2) is

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

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

Там є важливими і суттєвими відмінностями між функціональним і ГО стилі , але я не думаю , що ця відповідь має мати справу з ними. Ви запитали, чи функціональні мови перешкоджають (або перешкоджають) інтуїтивному моделюванню проблем та завдань. Відповідь - Ні.

ПП дійсно прагне скорочення представницького розриву:

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

Частина (якщо не все) того, що дозволяє цю здатність, - це більш гнучкість та виразність у межах самої основної мови; з функціями першого класу, функціями вищого порядку, складом функцій, а в деяких мовах - алгебраїчними типами даних (дискримінаційними союзами AKA) та можливістю визначати оператори *, є більше гнучкості для того, як виражати речі, ніж у OOP, який є означає, що ви, мабуть, знайдете більш природні способи висловити речі зі своєї проблемної області. (Слід сказати, що багато мов OOP останнім часом переймають багато цих функцій, якщо не починати з них.)

_{* Так, у багатьох мовах OOP ви можете перекрити стандартні оператори, але в Haskell ви можете визначити нові!}

З мого досвіду роботи з функціональними мовами (переважно F # і Haskell, деякі Clojure, а також трохи Lisp та Erlang), я маю простіший час відображення проблемного простору вниз мовою, ніж у OOP - особливо з алгебраїчними типами даних, що я вважаю більш гнучким, ніж заняття. Щось, що підштовхувало мене до циклу, коли починався з FP, особливо з Haskell, - це те, що мені довелося думати / працювати на трохи вищому рівні, ніж я звик в імперативних мовах або мовах OOP; Ви, можливо, також в цьому зіткнетеся.

Як заявив Ніклаус Вірт, "Алгоритми + структури даних = програми". Функціональне програмування - це спосіб організації алгоритмів, і воно не дуже багато розповідає про способи впорядкування структур даних. Дійсно, існують мови FP як із змінними (Lisp), так і з незмінними (Haskell, Erlang) змінними. Якщо ви хочете порівняти та порівняти FP з чимось, вам слід вибрати імперативне (C, Java) та декларативне (Prolog) програмування.

З іншого боку, OOP - це спосіб побудови структур даних та приєднання до них алгоритмів. FP не заважає будувати структури даних, подібні до OOP. Якщо ви мені не вірите, перегляньте декларації типу Haskell. Однак більшість мов FP погоджуються, що функції не належать до структур даних і повинні скоріше знаходитися в одному просторі імен. Це робиться для спрощення побудови нових алгоритмів за допомогою функції функції. Дійсно, якщо ви знаєте, який вхід приймає функція і який результат вона виробляє, чому це має мати значення, до якої структури даних вона теж належить? Наприклад, чому addфункція повинна викликатися в екземплярі типу Integer і передавати аргумент, а не просто передавати два аргументи Integer?

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