Я бачу тут багато розмов про функціональні мови та інше. Чому б ви використовували її на "традиційній" мові? Що вони роблять краще? Чим вони гірші? Який ідеальний додаток для функціонального програмування?
Відповіді:
Функціональні мови використовують іншу парадигму, ніж імперативні та об'єктно-орієнтовані мови. Вони використовують функції, що не мають побічних ефектів, як основний будівельний блок в мові. Це дозволяє багато речей і ускладнює багато речей (або в більшості випадків відрізняється від тих, що звикли люди).
Однією з найбільших переваг функціонального програмування є те, що порядок виконання функцій без побічних ефектів не важливий. Наприклад, в Erlang це використовується для забезпечення можливості одночасності одночасності. А оскільки функції у функціональних мовах ведуть себе дуже схоже на математичні функції, їх легко перекласти на функціональні мови. У деяких випадках це може зробити код читабельнішим.
Традиційно одним з великих недоліків функціонального програмування була також відсутність побічних ефектів. Дуже складно написати корисне програмне забезпечення без IO, але IO важко реалізувати без побічних ефектів у функціях. Тому більшість людей ніколи не отримували більше функціонального програмування, ніж обчислення одного виходу з одного входу. У сучасних мовах змішаної парадигми на зразок F # або Scala це простіше.
Багато сучасних мов мають елементи з функціональних мов програмування. C # 3.0 має багато функціональних функцій програмування, і ви можете робити функціональне програмування і в Python. Я думаю, що причини популярності функціонального програмування здебільшого пояснюються двома причинами: паралельність стає справжньою проблемою у звичайному програмуванні, оскільки у нас стає все більше багатопроцесорних комп'ютерів; а мови стають доступнішими.
Я не думаю, що питання щодо функціонального підходу до програмування "наздоганяє", не виникає, оскільки він використовується (як стиль програмування) вже близько 40 років. Щоразу, коли програміст OO пише чистий код, який надає перевагу незмінним об'єктам, цей код запозичує функціональні поняття.
Однак мови, які застосовують функціональний стиль, отримують багато віртуальної фарби в наші дні, і чи стануть ці мови в майбутньому домінуючими - питання відкрите. Моє власне підозру полягає в тому, що гібридні, багатопарадигмічні мови, такі як Scala або OCaml , ймовірно, будуть домінувати над "пуристичними" функціональними мовами так само, як чиста мова OO (Smalltalk, Beta тощо) вплинула на основне програмування, але не закінчилася як найпоширеніші позначення.
Нарешті, я не можу втриматися, зазначивши, що ваші коментарі щодо ПП є дуже паралельними зауваженням, які я чула від процедурних програмістів не так багато років тому:
Так само, як графічні інтерфейси користувачів та "код як модель бізнесу" були поняттями, які допомогли OO отримати більш широку оцінку, я вважаю, що розширене використання незмінності та простіший (масовий) паралелізм допоможуть більшості програмістів побачити переваги, які пропонує функціональний підхід . Але стільки, скільки ми дізналися за останні 50 років, які складають всю історію цифрового комп'ютерного програмування, я думаю, що нам ще багато чому навчитися. Через двадцять років програмісти з подивом дивляться на примітивний характер інструментів, якими ми зараз користуємося, включаючи популярні зараз мови OO та FP.
Основним плюсом для мене є притаманний йому паралелізм, тим більше, що ми зараз відходимо від більшої частоти МГц і все більше ядер.
Я не думаю, що це стане наступною парадигмою програмування і повністю замінить методи типу OO, але я думаю, що ми дістанемося до того, що нам потрібно або написати якийсь наш код на функціональній мові, або наші мови загального призначення зростати, включаючи більш функціональні конструкції.
Навіть якщо ви ніколи не працюєте на функціональній мові професійно, розуміння функціонального програмування зробить вас кращим розробником. Це дасть вам новий погляд на ваш код та програмування загалом.
Я кажу, що немає причин не вчитися цьому.
Я думаю, що мови, які добре поєднують функціональний та імперативний стиль, є найцікавішими та є найбільш імовірними.
Я завжди скептично ставлюсь до наступної великої речі. Багато разів наступна велика річ - це чиста випадкова історія, перебуваючи там у потрібному місці в потрібний час, незалежно від того, хороша технологія чи ні. Приклади: C ++, Tcl / Tk, Perl. Усі недосконалі технології, які були надзвичайно успішними, оскільки вони сприймалися або вирішувати проблеми сучасності, або були майже ідентичними закріпленим стандартам, або обом. Функціональне програмування дійсно може бути чудовим, але це не означає, що воно буде прийняте.
Але я можу вам сказати, чому люди в захваті від функціонального програмування: багато, багато програмістів мали певний "досвід перетворення", коли вони виявляють, що використання функціональної мови робить їх вдвічі продуктивнішими (а може, і в десять разів продуктивнішими) під час виробництва код, який є більш стійким до змін і має менше помилок. Ці люди вважають функціональне програмування таємною зброєю; Хорошим прикладом такого мислення є Пол Грем Побиття Averages . О, і його заява? Веб-програми електронної комерції.
З початку 2006 року також спостерігається певний шум щодо функціонального програмування та паралелізму. Оскільки такі люди, як Саймон Пейтон Джонс , турбуються про паралелізм і з принаймні з 1984 року, я не затримую дихання, поки функціональні мови не вирішать проблему багатоядерності. Але це пояснює деякі додаткові шуми прямо зараз.
Взагалі американські університети роблять погану роботу, навчаючи функціональному програмуванню. Існує сильне ядро підтримки викладання програмного введення з використанням схеми , і Haskell також користується певною підтримкою, але в навчанні передовій техніці функціонального програміста дуже мало. Я викладав такий курс у Гарварді і зроблю це знову цієї весни в Туфті. Бенджамін Пірс викладав такий курс у Пенні. Я не знаю, чи зробив Пол Худак щось в Єлі. Європейські університети роблять набагато кращу роботу; наприклад, функціональне програмування підкреслюється у важливих місцях Данії, Нідерландів, Швеції та Великобританії. У мене менше розуміння того, що відбувається в Австралазії.
Я не бачу, щоб хтось згадував про слона в кімнаті, тому я думаю, що це залежить від мене :)
JavaScript - це функціональна мова. Оскільки все більше і більше людей займаються більш вдосконаленими справами з JS, особливо використовуючи більш точні моменти jQuery, Dojo та інших фреймворків, FP буде запроваджено задніми дверима веб-розробника.
У поєднанні із закриттями, FP робить код JS дійсно легким, але все ще читабельним.
Ура, ПС
Більшість застосунків є досить простими, щоб вирішити звичайними способами OO
Способи ОО не завжди були "нормальними". Стандарт цього десятиліття був маргіналізованою концепцією минулого десятиліття.
Функціональне програмування - математика. Пол Грехем на Lisp (замінить функціональне програмування для Lisp):
Отже, коротке пояснення того, чому мова 1950-х років не застаріла, полягає в тому, що це була не технологія, а математика, а математика не застаріла. Правильне порівняння Lisp - це не апаратне забезпечення 1950-х років, а, скажімо, алгоритм Quicksort, який був виявлений у 1960 році і досі є найшвидшим загальним призначенням.
Б'юсь об заклад, що ви не знали, що ви функціонували програмуванням, коли використовували:
Середній корпоративний програміст, наприклад, більшість людей, з якими я працюю, не зрозуміє цього, і більшість робочих середовищ не дасть вам програмувати в ньому
Однак, це лише питання часу. Ваш середньостатистичний корпоративний програміст дізнається, що б там не було. 15 років тому вони не розуміли ООП. ЯКЩО FP зачепить, ваші "середні корпоративні програмісти" будуть слідувати.
Її насправді не викладають у університетах (чи це зараз?)
Варіюється дуже багато. У моєму університеті SML - це перша мова студентів, на якій знайомляться. Я вважаю, що MIT викладає LISP як курс першого курсу. Ці два приклади, звичайно, можуть не бути репрезентативними, але я вважаю, що більшість університетів принаймні пропонують деякі факультативні курси з ПС, навіть якщо вони не вважають його обов'язковою частиною навчальної програми.
Більшість застосунків є досить простими, щоб вирішити звичайними способами OO
Це насправді не питання "досить простого". Чи було б рішення простішим (чи більш читабельним, надійним, елегантним, ефективним) у FP? Багато речей "досить прості, щоб вирішити на Java", але для цього все ж потрібна богата кількість коду.
У будь-якому випадку, майте на увазі, що прихильники ПП заявляють, що це наступна велика річ вже кілька десятиліть. Можливо, вони праві, але майте на увазі, що вони не були, коли вони пред'являли ту саму претензію 5, 10 чи 15 років тому.
Одне, що, безумовно, рахується на їх користь, - це те, що останнім часом C # різко повернувся до FP, настільки, що практично перетворює ціле покоління програмістів на програмістів FP, навіть не помічаючи їх . Це може просто прокласти шлях для FP "революції". Можливо. ;)
Людина не може зрозуміти досконалість та недосконалості обраного мистецтва, якщо він не може бачити цінності в інших мистецтвах. Дотримання правил дозволяє лише розвиватись до певної точки техніки, і тоді студент і художник повинні навчитися більше і шукати далі. Має сенс вивчати і інші мистецтва, а також стратегічні.
Хто не дізнався щось більше про себе, спостерігаючи за діяльністю інших? Щоб навчитися мечу вивчати гітару. Щоб навчитися кулаку вивчати комерцію. Просто вивчення меча зробить вас обмеженим та не дозволить вам рости назовні.
- Міямото Мусаші, "Книга з п'яти перснів"
Однією з ключових особливостей функціональної мови є концепція функцій першого класу. Ідея полягає в тому, що ви можете передавати функції як параметри іншим функціям і повертати їх як значення.
Функціональне програмування передбачає написання коду, який не змінює стан. Основна причина цього полягає в тому, що послідовні виклики функції дають такий же результат. Ви можете написати функціональний код будь-якою мовою, яка підтримує функції першого класу, але є деякі мови, наприклад Haskell, які не дозволяють змінювати стан. Насправді, вам не слід взагалі робити жодних побічних ефектів (як, наприклад, друк тексту) - що здається, що це може бути абсолютно марним.
Натомість Haskell використовує інший підхід до IO: монади. Це об'єкти, які містять бажану операцію вводу-виводу, яку слід виконати рівнем вашого перекладача. На будь-якому іншому рівні вони просто об'єкти в системі.
Які переваги забезпечує функціональне програмування? Функціональне програмування дозволяє кодувати меншу кількість потенціалів для помилок, оскільки кожен компонент повністю ізольований. Крім того, використання рекурсійних та першокласних функцій дозволяє отримати прості докази коректності, які, як правило, відображають структуру коду.
Я не думаю, що більшість реалістичних людей думають, що функціональне програмування наздожене (стає основною парадигмою на зразок ОО). Зрештою, більшість бізнес-проблем - це не дуже математичні проблеми, а волохаті імперативні правила переміщення даних та їх відображення різними способами, а це означає, що це не дуже підходить для чистої функціональної парадигми програмування (крива навчання монади набагато перевищує ОО).
OTOH, функціональне програмування - це те, що робить програмування цікавим. Це змушує вас цінувати властиву, позачасову красу стислих виразів основної математики Всесвіту. Люди кажуть, що вивчення функціонального програмування зробить вас кращим програмістом. Звичайно, це дуже суб'єктивно. Я також особисто не думаю, що це абсолютно правда.
Це робить вас кращою чуттєвою істотою.
Я повинен бути щільним, але все одно не розумію. Чи є фактичні приклади невеликих додатків, написаних на такій функціональній мові, як F #, де ви можете подивитися вихідний код і побачити, як і чому краще використовувати такий підхід, ніж, скажімо, C #?
Я зазначу, що все, що ви говорили про функціональні мови, більшість людей говорили про об’єктно-орієнтовані мови 20 років тому. Тоді дуже часто було чути про ОО:
* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
Зміни повинні відбуватися звідкись. Змістовна і важлива зміна відбудеться незалежно від того, чи вважають люди, які навчалися за попередніми технологіями, що зміни не потрібні. Як ви вважаєте, зміни в ОО були хорошими, незважаючи на всіх людей, які були проти цього часу?
F # може наздогнати, тому що Microsoft наполягає на цьому.
Про:
Контраст:
Отже, я даю 50:50 шанс F # стати важливим. Інші функціональні мови не збираються це робити найближчим часом.
Я думаю, одна з причин - це те, що деякі люди вважають, що найважливішою частиною того, чи буде прийнята мова, є те, наскільки хороша мова . На жаль, речі рідко бувають такими простими. Наприклад, я заперечую, що найбільшим фактором, що сприймає Python, є не сама мова (хоча це досить важливо). Найбільшою причиною, чому Python настільки популярний, є його величезна стандартна бібліотека та ще більша спільнота сторонніх бібліотек.
Такі мови, як Clojure або F #, можуть бути винятком з цього правила, враховуючи, що вони побудовані на JVM / CLR. Як результат, у мене немає відповіді на них.
Більшість застосунків можна вирішити в [вставте сюди улюблену мову, парадигму тощо].
Хоча це правда, для вирішення різних проблем можна використовувати різні інструменти. Функціональний просто дозволяє ще одну високу (більш високу?) Абстракцію, яка дозволяє виконувати нашу роботу більш ефективно при правильному використанні.
Мені здається, що ті люди, які ніколи не вивчали Лісп або Схеми як бакалавра, зараз це відкривають. Як і в багатьох сферах у цій галузі, є тенденція до ажіотажу та створення великих очікувань ...
Це пройде.
Функціональне програмування чудово. Однак він не захопить світ. C, C ++, Java, C # тощо все ще будуть навколо.
Що з цього вийде, я думаю, що це більше мовна мова - наприклад, реалізація речей на функціональній мові, а потім надання доступу до цих матеріалів іншими мовами.
Читаючи "Наступна мова основного програмування: Перспектива розробника ігор" Тіма Свіні, "Епічні ігри", моя перша думка була - я повинен навчитися Haskell.
Речі певний час рухалися у функціональному напрямку. Двоє крутих нових дітей останніх років, Рубі та Пітон, докорінно ближче до функціональних мов, ніж те, що було перед ними, - настільки, що деякі Лісперс почали підтримувати ту чи іншу, як "достатньо близько".
І з масовим паралельним обладнанням, що чинить еволюційний тиск на кожного - і функціональні мови найкраще справляються зі змінами - це не такий стрибок, як колись було думати, що Haskell або F # стане наступною великою справою.
Ви останнім часом стежите за еволюцією мов програмування? З кожним новим випуском усіх основних мов програмування здається, що функціональне програмування все більше функцій.
Закриття, анонімні функції, функції передачі та повернення як значення, які раніше були екзотичними особливостями, відомими лише хакерам Lisp та ML. Але поступово C #, Delphi, Python, Perl, Javascript додали підтримку закриттів. Неможливо будь-яку нову мову сприймати серйозно без закриття.
Кілька мов, зокрема Python, C # і Ruby, мають вбудовану підтримку для розуміння списків та генераторів списків.
ML започаткувала загальне програмування в 1973 р., Але підтримка генерики ("параметричний поліморфізм") стала лише галузевим стандартом протягом останніх 5 років. Якщо я правильно пам’ятаю, Fortran підтримував генеричні засоби в 2003 році, а потім Java 2004, C # в 2005 році, Delphi в 2008 році. (Я знаю, що C ++ підтримує шаблони з 1979 року, але 90% дискусій про STL C ++ починаються з "тут будуть демони" .)
Що робить ці функції привабливими для програмістів? Це повинно бути очевидно: це допомагає програмістам писати коротший код . Усі мови в майбутньому будуть підтримувати - як мінімум - закриття, якщо вони хочуть залишатися конкурентоспроможними. У цьому відношенні функціональне програмування вже є в основному.
Більшість застосунків є досить простими, щоб вирішити звичайними способами OO
Хто каже, що не можна використовувати функціональне програмування і для простих речей? Не кожна функціональна програма повинна бути компілятором, підтвердженням теореми або масово паралельним комутатором зв'язку. Я регулярно використовую F # для спеціальних сценаріїв викидів, крім моїх складніших проектів.
Це приваблює, тому що це найкращий інструмент для контролю складності. Дивіться:
- слайди 109-116 Саймона Пейтона-Джонса говорять "Смак Хаскелла"
- "Наступна основна мова програмування: Перспектива розробника ігор" Тіма Свіні
Ознайомтеся з тим, чому важливо функціональне програмування
Я погоджуюся з першим пунктом, але часи змінюються. Корпорації реагують, навіть якщо вони запізнюються, якщо вони побачать, що є переваги. Життя динамічне.
Вони викладали Haskell та ML в Стенфорді наприкінці 90-х. Я впевнений, що такі місця, як Карнегі Меллон, MIT, Стенфорд та інші хороші школи, представляють його студентам.
Я погоджуюсь, що більшість додатків "відкрити реляційні бази даних в Інтернеті" триватимуть у цій галузі ще довго. Java EE, .NET, RoR і PHP розробили деякі непогані рішення цієї проблеми.
Ви натрапили на щось важливе: це може бути проблема, яку неможливо легко вирішити іншими засобами, що сприятиме підвищенню функціонального програмування. Що це було б?
Чи підштовхне їх масове багатоядерне обладнання та хмарні обчислення?
Тому що ПП має значні переваги з точки зору продуктивності, надійності та ремонту. Багатоядерний може бути вбивчим додатком, який нарешті змушує великі корпорації переходити, незважаючи на великі обсяги застарілого коду. Крім того, навіть великі комерційні мови, такі як C #, набувають виразного функціонального аромату в результаті багатопрофільних проблем - побічні ефекти просто не вписуються в паралельність і паралелізм.
Я не згоден, що "нормальні" програмісти цього не зрозуміють. Вони будуть так само, як вони врешті-решт зрозуміли ООП (що так само загадково і дивно, якщо не більше).
Крім того, більшість університетів викладають FP, багато хто навіть викладають це як перший курс програмування.
Нічого собі - це цікава дискусія. Мої власні думки з цього приводу:
FP робить деякі завдання порівняно простими (порівняно з мовами, що не мають FP). Мови, які не мають FP, вже починають брати ідеї від FP, тому я підозрюю, що ця тенденція буде продовжуватися, і ми побачимо більше злиття, яке повинно допомогти людям полегшити стрибок до FP.
Я не знаю, буде це чи ні, але з моїх досліджень, функціональну мову майже напевно варто вивчити, і зробить вас кращим програмістом. Просто розуміння референтної прозорості значно спрощує багато дизайнерських рішень, а отримані програми набагато простіше міркувати. В основному, якщо ви зіткнулися з проблемою, то вона, як правило, є лише проблемою з виведенням однієї функції, а не проблемою з непостоянним станом, яка могла бути викликана будь-яким із сотень класів / методів / функцій мовою інтерактивності з побічними ефектами.
Природа FP без громадянства більш природно відображає характер без громадянства в Інтернеті, і, таким чином, функціональні мови легше піддаються більш елегантним, РЕЗУЛЬТАТНІМ веб-картам. На противагу фреймворкам JAVA та .NET, яким потрібно вдаватися до жахливих потворних ключів, таких як клавіші VIEWSTATE та SESSION, щоб підтримувати стан програми, а також підтримувати (зрідка досить протікаюче) абстрагування значущої імперативної мови на фактично функціональній платформі без громадянства, як Інтернет.
А також, чим більше ваша програма без стану, тим легше вона може піддаватися паралельній обробці. Страшенно важливо для Інтернету, якщо ваш веб-сайт стає популярним. Не завжди просто додати більше обладнання на сайт, щоб досягти кращої продуктивності.
На мою думку, зараз він причепиться до того, що Microsoft просунула його набагато далі в мейнстрім. Для мене це привабливо через те, що він може зробити для нас, тому що це новий виклик і через можливості роботи, які йому обурюються на майбутнє.
Після освоєння це буде ще одним інструментом для подальшого сприяння зробити нас більш продуктивними як програмісти.
Під час обговорення пропущено пункт про те, що системи найкращого типу є сучасними мовами FP. Більше того, компілятори можуть автоматично робити всі (або принаймні більшість) типів.
Цікаво, що при програмуванні Java витрачається половина часу на написання імен типів, але Java на сьогоднішній день не є безпечною. Хоча ви ніколи не можете писати типи в програмі Haskell (за винятком як перевіреної документацією компілятора), і код на 100% безпечний.
На додаток до інших відповідей, розкидання рішення в чистому функціональному плані змушує зрозуміти проблему краще. І навпаки, мислення у функціональному стилі розвиватиме краще навички вирішення проблем.
* Або тому, що функціональна парадигма краща, або тому, що вона надасть додатковий кут атаки.