Яка ваша найсильніша думка щодо функціонального програмування? [зачинено]

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

Яка ваша найсильніша думка щодо функціонального програмування?

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

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

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

Одним із результатів є невдача для компромісів. Це призводить (серед іншого) до приблизно 10 000 мов та діалектів, які досить різні для роздратування, але лише рідко досить різні, щоб один мав справді значну перевагу перед іншими. Багато людей також дивляться на реальний світ і вирішують, що оскільки він не дуже добре відповідає функціональній моделі, це в основному просто неправильно і найкраще ігнорується.

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

Це призводить до низки проблем. Перш за все, вивчення "функціонального програмування" здебільшого має філософське значення. У більшості інших типів мов знання однієї мови певного жанру є суттєвою допомогою у вивченні іншого. Якщо мій проект використовує мову XI, зазвичай можна найняти когось, хто знає мову Y (але не X) досить безпечно. Що стосується функціональних мов, це набагато менш вірно. Ви, можливо, знаєте Ерланга досить добре, але все ж вважаєте монади Хаскелла абсолютно чужими та незрозумілими.

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

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

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

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

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

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

Час на ринок

Складно позбутися повного ІТ-пейзажу процесуального кодексу та мантр.

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

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

я вважаю, що моя відповідь відображає мене як фан-фпі. Я пропоную надати справжній мові fp, як haskell, серйозний спін, перш ніж турбуватися про пошук причин, чому ви не повинні.

Я великий фанат і прихильник функціонального програмування. Але ось мої моменти:

• легко вивчити
  Мови програмування, такі як python та ruby ​​(та багато інших мов), легко вивчити. Розширене функціональне програмування з такими мовами, як Haskell, Agda, Coq, ATS тощо, досить важко вивчити. Деякі використовують термін "математичне структуроване програмування". Це легко, якщо ви знайомі з теорією категорій та абстрактною математикою, але досить добре працюєте, якщо у вас немає поняття, що таке "монади".

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

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

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

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

Я не проти FP як корисної парадигми, але я проти цього як єдиної парадигми, доступної мовою програмування.

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

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

Функціонал з'явиться, коли у нас є сотні ядер і вдасться зрозуміти, що замки не змінюються. Тоді вкладені паралельні дані стануть єдиним способом перейти до «великих залізних» програм, і функціональні відмінності при цьому.

FP - це круто в академічних колах, тому що класно писати хороші короткі програми, ігноруючи продуктивність. Немає змови проти цього в реальному світі. Наприклад, наприклад, реалізація деяких речей (наприклад, сортування radix) здається загальним болем у FP. Ох і створений код IMHExperience sloooooooooooooooooooowow.

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

Навіть незважаючи на те, що я почав отримувати функціональне програмування (приїжджаючи з Java і переходячи до Clojure), мені все ще досить складно. Схоже, що спільнота не пише код настільки виразним, як Java.

Здається, є невелика втрата виразності та невелике збільшення складності.

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

Єдиною сферою, в якій я маю серйозні сумніви щодо ефективності ПС, є те, як він може мати справу зі складними структурами даних, які не можна визначити індуктивно, наприклад, графіками. Наприклад, якщо мені доведеться реалізувати алгоритм, який працює над великим графіком, можливо, проходжуючи графік і вносячи невеликі локальні зміни, мені цікаво, чи підхід FP може відповідати імперативному підходу, в якому програмі дозволяється переміщатися з вузла до вузол за допомогою покажчиків.