Функціональне програмування на підйомі?

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

І це вже досить давно. Функціональне програмування просто не набуло такої популярності, як інші моделі (тобто об'єктно-орієнтоване програмування).

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

Я з великим інтересом бачу той факт, що, незважаючи на відсутність значного сприйняття громадою, все більше і більше мов такого роду продовжують з'являтися. Clojure (2007), Scala (2003), F # (2002) - лише три приклади останнього останнього десятиліття.

Я сам був, вкладаючи певний час, вивчаючи Хаскелл і Скалу. І я знаходжу великий потенціал у парадигмі, яка для мене була новою, незважаючи на те, що я існував так довго.

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

Я хочу запитати:

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

Будь-які рекомендації щодо подальших досліджень будуть більш ніж вітаються.

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

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

Спасибі заздалегідь!

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

Все, що включає створення послідовності похідних елементів даних, використовуючи ряд етапів перетворення.

По суті, "проблема електронних таблиць". У вас є деякі початкові дані та набір обчислень по рядках, які слід застосувати до цих даних.

Наші виробничі додатки роблять ряд статистичних підсумків даних; це все найкраще підходить функціонально.

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

Додаток написано Python, але написане у функціональному стилі, використовуючи функції генератора та незмінні названі кортежі. Це композиція функцій нижчого рівня.

Ось конкретний приклад функціональної композиції.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

Це один із способів функціонального програмування впливати на такі мови, як Python.

Іноді така штука пишеться як:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

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

Незмінні предмети - це найважча перешкода.

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

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

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

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

Я читав на Haskell просто для того, щоб зрозуміти, чого не вистачає Python.

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

Незмінюваність

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

Функціонує як типи першого класу

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

Можливість складання функцій (наприклад, перетворення Action<T>в просто також Actionє досить корисним у деяких сценаріях).

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

Монади

Справді, це моє слабке місце, але я розумію, що обчислювальні робочі процеси в F #, такі як asyncробочий процес, є монадою. Це тонка, але дуже потужна конструкція. Це так само потужно, як yieldключове слово, яке використовується для створення IEnumerableкласів у C #. По суті це будувати державну машину для вас під прикриттями, але ваша логіка виглядає лінійною.

Ледача оцінка та рекурсія

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

S-вирази

Я думаю, я не впевнений, куди це поставити, але можливість розглянути некомпільований код як об’єкт (і перевірити / змінити його), наприклад, Lisp S-вирази або LINQ вирази, є певним чином, найпотужніший інструмент функціонального програмування. Більшість нових "плавних" інтерфейсів .NET та DSL використовують комбінацію симфаксису лямбда та LINQ вирази для створення дуже стислих API. Не кажучи вже про Linq2Sql / Linq2Nhibernate, де ваш C # код "магічно" виконується як SQL, а не як C # код.

Це була довга відповідь на першу частину вашого питання ... зараз ...

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

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

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

Якщо ви знайомі з .NET, я настійно пропоную F #. З іншого боку, якщо ви більше знайомі з JVM, завжди є Clojure . Якщо ви більше академічний, ніж практичний, тоді я б поїхав із загальним Lisp чи Scheme. Якщо ви вже знаєте Python, я вважаю, що там уже доступно багато функціональних конструкцій.

І це вже досить давно. Функціональне програмування просто не набуло такої популярності, як інші моделі (тобто об'єктно-орієнтоване програмування).

Це вірно, якщо ви рахуєте програми, розроблені професійними програмістами (або принаймні люди, які бачать себе такими). Якщо ви поширюєте свою мережу ширше, включаючи програми, розроблені людьми, які не вважають себе такими, FP (або принаймні програмування у функціональному стилі) досить близький до OO (Excel, Mathematica, Matlab, R ... навіть «сучасний» JavaScript ).

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

Моя особиста думка полягає в тому, що багатоядерність не є вбивчою особливістю FP (принаймні, доки компілятори Haskell, Scala, Clojure, F # не вирішать питання локалізації кешу). Функція вбивця map, filter, foldі друзі , які дозволяють більш лаконічне вираження великої групи алгоритмів. До цього додаються мови FP, які мають більш стислий синтаксис, ніж більшість популярних аналогів OO.

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

Крім того, коли вам особливо важко задовольнити вимоги "правильності" - у формі, яку важко перевірити (поширена в науковому обчисленні / великому аналізі даних, де мета - отримати раніше невідомі, і як такі не визначені результати) може запропонувати FP переваги.

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

• відсутність підтримки інструментів (F # і деякі Lisps є винятком, Scala знаходиться в дорозі)
• важче видавити останній шматочок продуктивності зі свого обладнання
• громади часто зосереджуються на різних питаннях, ніж ті, з якими стикається велика група проектів розвитку комерційних програм
• дуже мало розробників, які мають досвід використання ПП в промислових умовах, і якщо ви можете їх знайти, вам, ймовірно, доведеться конкурувати з зарплатою та вигодами, які може запропонувати фінансова галузь
• функціональний стиль програмування має тенденцію до налагодження; тобто спостерігати між результатами довгий ланцюжок складених функцій, як правило, неможливо у більшості (всіх?) налагоджувачів

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

• Скільки ваших проблем можна вирішити, вже виходячи з бібліотек / рамок на якій платформі (наприклад, JVM або .Net), скільки нових -? Чи існують мовні конструкції, здатні безпосередньо висловити ці проблеми?

• Скільки потрібно низького рівня контролю над простором та часом роботи програми?

• Наскільки суворі ваші вимоги щодо "коректності"?

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

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

Якщо припустити, що ви розробник C ++ / C # / Java в галузі ...

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

Якщо ви веб-програміст, то найбільшим підводним каменем, ймовірно, будуть ваші волосся.

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

Я б почав з платформи:

• OCaml чудово підходить для Linux і жахливо для Windows.
• F # чудово підходить для Windows і жахливо в Linux.
• Scala і Clojure чудово підходять до JVM.

З точки зору цього питання (можна визнати необ’єктивним), ви можете ознайомитись із блогом Боба Харпера, Екзистенціальний тип . Карнегі Меллон нещодавно переробив свою навчальну програму CS, щоб спочатку викладати функціональне програмування, а інші парадигми викладаються лише після того, як буде встановлено міцне обґрунтування функціонального програмування, і Гарпер наділяє ударом, коли нова навчальна програма впроваджується на практиці .

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

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

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

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

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

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

Серед мов програмування, про які я знаю, я б сказав, що лише Haskell і Clean можна назвати функціональними мовами. Усі інші з них дозволяють побічні ефекти, не роблячи явних ефектів у системі типів. Тож якщо ви збираєтесь приділяти час вивченню функціонального програмування, то Haskell - це, мабуть, єдиний, який відповідає законопроекту. Усі інші, які я знаю, Ерланг, Скала, Клуджур та ін., Просто забезпечують функціональні абстракції на додаток до необхідної мови. Тож якщо ви хочете підійти до функціональної парадигми в бітах, то я б рекомендував Scala або Erlang, і якщо ви хочете вирішити все відразу і, можливо, відмовитися від розладу, тоді вам слід піти з Haskell.

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

EDIT: оскільки це не очевидно для всіх.

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

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

Кілька прикладів ПП, використовуваних для паралелізму:

• CouchDB - будуйте на Erlang
• Чат у Facebook - будуйте на Erlang
• Twitter - значна частина побудована на Scala