Чому функціональне програмування ще не прийняте?

Я прочитав кілька текстів про декларативне / функціональне програмування (мови), випробував Haskell, а також написав сам. З того, що я бачив, функціональне програмування має ряд переваг перед класичним імперативним стилем:

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

• Продуктивність зростає (приклад: Erlang)

• Імперативне програмування - це дуже стара парадигма (наскільки я знаю) і, можливо, не підходить для 21 століття

Чому компанії, що використовують або програми, написані на функціональних мовах, все ще такі "рідкісні"?

Чому, дивлячись на переваги функціонального програмування, ми все ще використовуємо імперативні мови програмування?

Може, це було ще рано для цього в 1990 році, але сьогодні?

Тому що всі ці переваги - це і недоліки.

Програми без громадянства; Побічних ефектів немає

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

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

Паралельність; Грає надзвичайно приємно завдяки зростаючій багатоядерній технології

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

Програми зазвичай коротші, а в деяких випадках простіші для читання

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

Продуктивність зростає (приклад: Erlang)

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

І пам’ятайте, ви не хочете викидати робочу систему; більшість програмістів не будують нові системи з нуля, а підтримують існуючі системи, більшість з яких були побудовані на нефункціональних мовах. Уявіть, що намагаєтесь виправдати це акціонерам. Чому ви брухтували існуючу працюючу систему оплати праці, щоб побудувати нову ціною мільйонів доларів? "Тому що функціональне програмування дивовижне" навряд чи порадує акціонерів.

Імперативне програмування - це дуже стара парадигма (наскільки я знаю) і, можливо, не підходить для 21 століття

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

Не зрозумій мене неправильно. Я люблю функціональне програмування, я приєднався до цієї команди, тому що хотів допомогти перенести концепції з функціонального програмування в C #, і я вважаю, що програмування в непорушному стилі - це шлях майбутнього. Але існують величезні витрати на програмування у функціональному стилі, якого не можна просто побажати. Перехід до більш функціонального стилю відбуватиметься повільно і поступово протягом десятиліть. І ось що це буде: перехід до більш функціонального стилю, а не оптова охоплення чистоти та краси Haskell та відмова від C ++.

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

Основні напрямки програмування: розмови з творцями основних мов програмування

[Haskell]

Чому, на вашу думку, жодна функціональна мова програмування не увійшла в мейнстрім?

Джон Х'юз: Поганий маркетинг! Я не маю на увазі пропаганду; у нас було багато цього. Я маю на увазі ретельний вибір цільової ринкової ніші для домінування з подальшими рішучими зусиллями зробити функціональне програмування далеко не найбільш ефективним способом вирішення цієї ніші. У щасливі дні 80-х років ми вважали, що функціональне програмування підходить для всього - але називати нову технологію "корисною для всього" - це те саме, що називати її "особливо хорошою ні за що". Яким повинен бути бренд? Це проблема, яку Джон Лаунберій дуже чітко описав у запрошеній до розмови на ICFP. Galois Connections ледь не піддався, коли їхній бренд був "програмним забезпеченням на функціональних мовах", але вони перейшли від сили до міцності, зосередившись на "програмному забезпеченні високої надійності".

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

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

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

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

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

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

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

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

Чи не так?

Малі розмови були чудовою об'єктно-орієнтованою системою ще в той час. Чому об’єктно-орієнтоване програмування не прийняте? Ну, є. Це просто не схоже на Smalltalk. Основні мови продовжують набирати більше Smalltalk, як C ++, Java, C #, і т. Д. Мода та стиль змінюються повільніше, ніж будь-що, тому, коли OO перейшла в мейнстрім, ми отримали це, склеївши частини OO на старі мови, так що це виглядало досить, як C, щоб проковтнути .

Функціонал - це той самий спосіб. Хаскелл був чудовою функціональною мовою. Але у нас сьогодні ще більше маси основних програмістів, які використовують C-подібний синтаксис, ніж 20 років тому. Отже, він повинен виглядати як C. Зроблено: подивіться будь-який вираз LINQ і скажіть мені, що він не функціональний.

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

Один із плакатів сказав, що імперативний код легше зрозуміти, ніж функціональний код програмування. Це справедливо лише в тому випадку, якщо читач вже бачив імперативний код, особливо якщо попередні приклади є частиною тієї ж "сім'ї" (наприклад, C / C ++, Perl, PHP та Java). Я б не стверджував, що це правда для будь-якої імперативної мови; порівняйте Java та Forth, щоб зробити крайній приклад.

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

Якби ми спочатку навчалися на мові Lisp-y або Haskell-y з самого початку, ми вважали б, що функціональні мови програмування є абсолютно нормальними.

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

По-перше, і (на мій погляд) передусім, процедурні мови отримали велику користь від ступеня спільності. Наприклад, майже будь-хто, хто знає майже будь-яку з основних процедурних (або ОО) мов майже будь-якої мірою може читати більшість інших досить добре. Я активно уникаю роботи в Java, C #, Cobol, Fortran або Basic (лише декілька прикладів), але можу прочитати будь-яку з них досить добре - майже так само, як і люди, які ними користуються щодня.

Щодо функціональної сторони, це набагато менш вірно. Наприклад, я можу також написати схему досить розумно, але це мало користі при читанні Ocaml або Haskell (лише для кількох прикладів). Навіть у межах однієї сім'ї (наприклад, схема проти, звичайний Lisp) знайомство з одним не здається майже таким же перекладним для іншого.

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

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

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

Немає сприйнятої потреби

Я пригадую відповідь мого старого боса Ріка Клайна, коли я показав йому копію лекції "Премія Тюрінга" Джона Бекуса " Чи можна програмування звільнити від стилю фон Неймана?"

Його відповідь: "Можливо, хтось із нас не хоче звільнятися від стилю фон Неймана!"

Чому функціональне програмування ще не прийняте?

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

Програми без громадянства; Побічних ефектів немає

Програми без громадянства простіше перевірити. Зараз це широко цінується і часто використовується в промисловості.

Паралельність; Грає надзвичайно приємно при зростанні багатоядерних технологій Програми зазвичай коротші, а в деяких випадках легше читати Продуктивність зростає (приклад: Erlang)

Ви плутаєте одночасність і паралелізм.

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

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

Чому компанії, що використовують або програми, написані на функціональних мовах, все ще такі "рідкісні"?

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

Чому, дивлячись на переваги функціонального програмування, ми все ще використовуємо імперативні мови програмування?

Суто функціональне програмування має багато серйозних недоліків, тому ми використовуємо чисті функціональні мови, такі як Lisp, Scheme, SML, OCaml, Scala та C #.

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

1. Для отримання всіх переваг функціонального програмування вам потрібна лінь. Так, існують суворі функціональні мови, але реальні переваги функціонального програмування не світяться також у строгому коді. Наприклад, у Haskell легко створити послідовність лінивих операцій у списку та об'єднати їх та застосувати до списку. Напр.op1 $ op2 $ op3 $ op4 $ someList. Я знаю, що це не збирається будувати весь список, і всередині я просто збираюся отримати хороший цикл, який проходить по елементах по одному. Це дозволяє писати дійсно модульний код. Інтерфейс між двома модулями може передбачати передачу потенційно величезних структур даних, але все ж не потрібно мати резидент структури.

2. Але коли у вас лінь, важко міркувати про використання пам'яті. Зміна прапорів компілятора Haskell часто змінює об'єм пам'яті, що використовується алгоритмом з O (N), на O (1), за винятком випадків, коли це не відбувається. Це не дуже прийнятно, якщо у вас є додатки, які повинні максимально використовувати всю наявну пам'ять, і це не чудово навіть для програм, яким не потрібна вся пам'ять.

Дві речі:

1. Це просто потребує часу, незалежно від того, наскільки хороша технологія. Ідеям, що стоять за ФП, близько 70 років. Але його основне використання в інженерії програмного забезпечення (в траншеях, в промисловості), мабуть, менше 10 років. Попросити розробників прийняти нові раціонально налаштовані умови мислення, але це просто потребує часу (багато-багато років). Наприклад, OOP дійсно отримав основне використання на початку 1980-х. Однак вона не отримала спокою до кінця 1990-х.
   
2. Потрібно, щоб люди були змушені стикатися з силою технології, перш ніж вона стане великою . Наразі люди користуються інструментами, які не використовують паралелізм і все працює нормально. Коли програми, які не використовують паралелізм, стають нестерпно повільними; тоді багато людей будуть змушені використовувати паралелізм-інструменти, і FP може набути популярності. Це також може стосуватися інших сильних сторін FP.