Для яких загальних проблем функціональне програмування не підходить? [зачинено]

22

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

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

functional-programming  paradigms 
— Йонас
джерело
Вау! На якусь мить я подумав, що ти сказав, що "є дефектною парадигмою". Потім я повернувся і перевірив.
— Марк C
1
Я думаю, що точніше сказати, що побічні ефекти є ізольованими (у Haskell все одно), ніж уникнути. Монади дозволяють змінити державу, і навіть її називають "державою".
— Ларрі Коулман
Як пояснив Ларрі Коулман, це неправда, що функціональне програмування дозволяє уникнути побічних ефектів, але те, що це перешкоджає їх використанню і, в деяких мовах, чітко їх ізолює. Прочитайте, наприклад, Розділ 7 дослідження.microsoft.com/
— Giorgio

Відповіді:

17

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

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

(Як зауваження, деякі проблеми в іграх дуже добре підходять для функціонального програмування, наприклад, AI. Гібридна функціональна / імперативна мова була б чудовою для цих випадків.)

— Метт Оленік
джерело
9
Стаття Наступні основні мови програмування: Перспектива розробника ігор стверджує, що саме стосується розробки ігор, де суто функціональна поведінка за замовчуванням, а зміна стану відстежується через типи, щоб уникнути помилок. Тому не всі вважають, що функціональна парадигма за своєю суттю непридатна для програмування ігор.
— sepp2k
1
@ sepp2k, дякую за посилання. Я радий бачити перспективу, яку стверджує хтось, хто створив справжні ігри.
— Метт Оленік
3
@ sepp2k зачекайте, я щось пропустив? Після більш детального ознайомлення з презентацією, схоже, Sweeney сперечався, щоб більшість основних двигунів було написано з чисто функціональним кодом, а більшість логічних ігор потрібно писати імперативно (або принаймні дозволяти) та використовувати STM, щоб допомогти з паралельністю . Це здається мені дуже розумним.
— Метт Оленик
@Matt: Ні, ти маєш рацію, він каже, що логічна частина гри буде містити стан, що змінюється. Однак це не перешкоджає мові відстежувати змінність через типи (що він пропонує у розділі "musings"). Звичайно, "стан відстеження за типами" не відповідає "функціональному", тому я міг би занадто оптимістично сформулювати свій попередній коментар.
— sepp2k
@ sepp2k правильно, я бачу, що ти маєш на увазі.
— Метт Оленік
17

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

— AShelly
джерело
3
Ну, якщо ви просто маєте на увазі апаратний інтерфейс, я сумніваюся, що крім C / C ++, це хороший вибір. Однак на шарі поверх таких мов, як Erlang використовується іноді, особливо в телекомунікаційних системах. Erlang - це функціональна мова, розроблена для критичних та стійких до відмов вбудованих систем у режимі реального часу.
— Йонас
@Jonas: Ерланг може мінімізувати мутацію, але це сильно залежить від IO, щоб передавати повідомлення, що, звичайно, є побічним ефектом.
— Джон Харроп
11

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

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

— міпаді
джерело
-1: Ви говорите про чистоту та ігноруєте використання першокласних функцій, наприклад, зворотні дзвінки в коді GUI набагато простіші з нечистими мовами FP, ніж з мовами OOP.
— Джон Харроп
4
@Jon Harrop: Першокласні функції не характерні лише для функціональних мов програмування. Я все ще стверджую, що стиль FP не дуже підходить для графічних інтерфейсів.
— mipadi
1
Залежить, кого ви запитаєте. Для більшості функціональних програмістів першокласні функції - це саме визначення функціонального програмування.
— Джон Харроп
@Jon Harrop: Більшість функціональних програмістів сказали б, що функціональне програмування - це метод опису програм як складу та оцінки математичних функцій. Функції першого класу є важливою частиною цієї парадигми, але самі функції першого класу не є функціональною мовою програмування (або функціональної програми). Парадигма функціонального програмування прагне мінімізувати використання державних та змінних структур даних, і навіть нечисті мови FP заохочують цей стиль. FP - стільки про стиль програмування, скільки на індивідуальні особливості, такі як функції першого класу, і ...
— mipadi
... Я не вважаю, що ця парадигма особливо піддається програмуванню графічного інтерфейсу - об'єктно-орієнтовані мови краще підходять для графічних інтерфейсів, взагалі кажучи.
— mipadi
5

Бізнес-додатки, керовані даними. Інтерфейс користувача та прості операції з передачею даних не потребують FP.

— Бранімір
джерело
2
І будь-яка інша програма для перегляду даних / перегляду, насправді. Більшість ігор стосуються стану та зміни його, тому не перекладайте добре функціональний стиль.
— Джон Перді
18
Дійсно? Я завжди думав, що ПП буде для цього спеціально хорошим . Чи не так, як 99% того, що ці програми роблять для вибору, агрегування та проектування даних? В основному filter, reduceі map. Киньте в деяких sort, partition, groupBy. Зрештою, найбільш широко використовуваною мовою програмування для написання таких додатків є Excel, яка є функціональною мовою.
— Йорг W Міттаг
3
Бізнес-програми та програми, керовані даними, що мають прості операції з передачею даних, здаються дуже зручними для FP, і я чув, що FP популярний для таких речей. Наприклад, дивіться функціональний програміст Пригоди на Уолл-стріт
— Йонас
1
-1: Ви перерахували якусь програму, на якій перевершує FP.
— Джон Харроп
2

Ви не можете легко відхилити будь-яку проблему, яка сама по собі не підходить для функціонального програмування.

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

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

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

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

Зовсім немає необхідності в таких довільних побічних ефектах, як глобальні змінні.

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

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

— Peer Stritzinger
джерело
Державні додатки, такі як програми GUI, насправді важко зробити функціонально, чи є якісь рекомендації?
— Йонас
Якщо у вас є якась абстракція процесу / потоку (наприклад, наприклад, у Erlang), ви можете передавати свій стан у процесі.
— Peer Stritzinger
3
GUI-програми зазвичай побудовані навколо циклу подій. Ви можете досить добре записати цикл подій на функціональній мові. Якщо його складніше, ви, мабуть, додасте кілька потоків / процесів для фонової обробки. Але якщо у вас є якась абстракція процесу / потоку (наприклад, як у Erlang), ви можете легко передати свій стан навколо процесу. Продовження також може стати в нагоді. Я думаю, що його просто звикають робити речі функціонально, щоб навіть отримати обробку на GUI. Однією з причин програмування GUI вважається важким сьогодні те, що більшість наборів інструментів не призначені для функціонального використання.
— Peer Stritzinger
1
@Jonas: у Haskell ви б використовували або монаду IO, монадію штату, або комбінацію.
— Ларрі Коулман
1
@ Jonas: це залежить від вашого визначення корисного. У прикладі wikibook використовується wxHaskell, тоді як Real World Haskell використовує gtk2hs. Я ще не пробував, оскільки моя програма Haskell заснована на командному рядку.
— Ларрі Коулман
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.