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

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

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

Я б сказав, що однією з причин того, що функціональне програмування не є більш поширеним, є відсутність бази знань. Мій досвід полягає в тому, що корпорації дуже протистоять ризику з точки зору впровадження технологій, які не є основним потоком, і скоріше інвестують у перевірені та справжні рамки (java, c ++, c #). Нові парадигми розглядаються лише тоді, коли є потреба в бізнесі (як, наприклад, в Ericsson). Але навіть у випадку Ericsson я почув, що керівництво вимагало використовувати c ++, і Джо Армстронг був змушений кодувати виклики erlang в c ++ !! Це повинно показати, наскільки корпорації неохоче впроваджують нові технології!

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

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

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

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

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

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

Наприклад, запуск, який я будую, використовує функціональну мову (Clojure) як основну мову розробки з наступних причин:

• Продуктивність - вивчити FP важко, але як тільки ти зможеш його обіграти, дуже важко перемогти з точки зору сили та виразності. Я, мабуть, пишу про 1/10 числа рядків для реалізації будь-якого фрагмента функціональності порівняно з тим, що мені знадобилося б у C # або Java

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

• Паралельність - функціональні мови підкреслюють незмінність, яка має величезні переваги для одночасних застосувань, ніж потрібно ефективно працювати на декількох ядрах. Хоче чи ні, біг на декілька ядер - це майбутнє. Дивіться http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey для яскравого пояснення того, чому це так важливо

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

EDIT : У відповідь на коментар Деспертара, прикладом "випадкової складності" систем OOP, що обмежує модульність, є проблеми з глибоким клонуванням проти мілкого клонування: ви не можете складати об'єкти разом і передавати їх навколо як складені структури без дуже ретельний аналіз семантики клонування та мутації. У невеликих випадках це піддається управлінню, але у складних системах це швидко стає значною проблемою. Ця проблема не буде існувати в першу чергу, якщо ви покладаєтесь на чисті функціональні структури даних.

Відсутність програми-вбивці

Гей, ця тут виглядає свіжою. (копати копати копати)

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

Ось мій не дуже точний погляд на те, яка ніша спричинила прийняття деяких мов, якими ми сьогодні володіємо:

• С: Працює скрізь (Це було наприкінці 70-х та 80-х)
• C ++: рамки GUI (початок 90-х)
• Java: аплети та сервлети (наприкінці 90-х)
• Objective-C: програми для iOS (до цього додатки OS X)
• Ruby: Рейки
• C #: ASP.NET, WinForms
• PHP: Wordpress тощо.
• Javascript: AJAX, особливо через рамки
• lua: Сценарії ігор, особливо WoW

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

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

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

• Emacs Lisp: Постійне використання розробниками з 80-х років у Emacs. ( Навряд чи колись використовується деінде.)
• Ерланг: Куди завгодно багато супутніх агентів.
• Схема: Освіта
• APL / J / K: Фінанси (Назвемо ці функціональні, заради аргументу)
• Звичайний Лісп: "AI" - Це те, що люди схильні говорити, що це використовується, що є благом і прокляттям.

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

З цього можу сказати, які функціональні мови, на мою думку , зростають:

• Clojure: Веб-програмування, особливо через Хероку
• Scala: Lift (або, можливо, Play сьогодні) - JVM без Java

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

З тієї ж причини, по якій Лісп ніколи насправді не прижився (нехай починаються полум'я!). Функціональне програмування - це дуже чужа парадигма порівняно з імперативним та об'єктно-орієнтованим програмуванням. Якщо, як і переважна більшість студентів CS, ви починали з C та перейшли до C ++ / Java, ви, як правило, не хочете вчитися думати таким чином, що є абсолютно ортогональним, як ви зазвичай думаєте.

Розглянемо бізнес та програмування.

Є підприємства, які використовують своє програмне забезпечення як стратегічний актив. Це не типово. Для більшості підприємств ІТ - це те, що підтримує реальний бізнес компанії. Це необхідні витрати. Вони консервативні, оскільки знають, що за $ X вони можуть отримати необхідні ІТ, тоді як якщо вони перейдуть на щось інше, вони заощадять менше, ніж $ X, якщо все піде добре, і втратять справжній великий, якщо все піде погано.

Більше того, в бізнесі найдешевша річ - це те, що вони робили вчора. Зміни, однак, бажано, коштують дорого. Якби компанія перейшла з, скажімо, на рішення C # /. NET, навіть на F #, вони мали б проблеми. Їхні програмісти (які, ймовірно, не найгостріші програмісти там), повинні були б вивчити нову мову та володіти обома та використовувати обидва часто. Існували б рутини, написані в обох давно. Якби вони перейшли на щось на зразок Haskell, або якщо б вони в першу чергу використовували C ++ / MFC, вони змінили б набагато більше, і це було б набагато дорожче.

Крім того, надовго буде поставлятися програма програмістів на C # та тривала підтримка Microsoft. На існуючі ІТ-практики можна розраховувати. Існує не той самий рівень інституційної підтримки або гарантії постійної доступності програмістів.

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

Ви вже пишете код у функціональному стилі, просто його не знаєте.

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

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

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

Ось:

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

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

Справжня проблема - держава.

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

Але ми використовуємо код на архітектурних машинах Von-Neuman, які за своєю суттю є повноцінними. Таким чином, ми фактично не позбулися держави, функціональні мови просто приховують складність держави від розробника. Це означає, що мова / компілятор має мати справу зі станом поза кадром та керувати ним.

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

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

Дивлячись на це з боку апаратних засобів

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

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

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

Дивлячись з боку галузі:

Промисловість має багато неефективних повноправних державних програмістів.

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

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

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

З точки зору найму

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

Це питання має трохи неправильну передумову. З наступних причин:

1. Функціональне програмування насправді досить поширене в галузі. Але він використовується лише там, де доступні досвідчені програмісти. Початківців не можна очікувати, що це знають. Майже всі великі проекти програмування використовують його, але вони просто зберігають його в областях, якими займаються досвідчені програмісти. Початківці розбиратимуться з простими модулями, які не потребують функціонального програмування.
2. Враховуючи цю реальність, компанії, які наймають людей (як правило, молодих людей, які приїжджають з університету), насправді не можуть просити досвіду функціонального програмування. Будь-хто в проектах, які потребують функціонального програмування, вже в цій компанії вже 15 років.
3. Університети починають це викладати, бо вже зараз знають, що знання функціонального програмування будуть дуже корисними через 30 років. Їх часовий діапазон становить 30 років, а не нормальний півріччя, як у компаній.
4. Ці моменти є причиною, чому люди розчаровуються, коли вступають до робочої сили і бачать, що речі, які вони вивчили в університеті, не використовуються. Але вони розраховані на 30-річний проміжок часу, і в кінцевому підсумку це стане в нагоді - це просто те, що компанії використовують прості речі - речі, на які вони можуть розраховувати, що люди знають.
5. Крім того, ви були б зухвалими, якщо думаєте, що через кілька років університету ви знаєте функціональне програмування досить добре, щоб використовувати його в реальних програмних проектах. Почніть спочатку з простих речей. Вам не потрібно робити найскладніший фрагмент програмного забезпечення як перше завдання, коли ви починаєте працювати. Ви зрештою дістанетесь до складних речей, але це потребує часу.

Тому що важче налагодити FP.