Відповіді:
Одна з головних проблем полягає в тому, що якщо ви почнете з такої мови, як Haskell, все інше здасться просто нестандартним.
Чесно кажучи, я думаю, що починати з такої мови, як Haskell чи схема, було б чудовою ідеєю.
(Зізнаюся, я функціональний мовний наркоман) EDIT:
Добре, що мені подобається в обох мовах:
Схема займає дуже просту мову і вибудовує з неї напрочуд надійну мову для розвитку. Також SICP написано про схему, завдяки якій варто вчитися саме там. Схема - це найпростіша річ, яку ви могли уявити, що це могла бути повною мовою.
Haskell Те, що насправді зростає, - це система типів. Так багато помилок, які я бачу в інших мовах, пов’язані з неправильним типом, який десь з’являється. У Хаскеллі це майже неможливо. Крім того, ідея про ледачу мову просто випадає з цього класних речей. Наприклад, ви можете створити нескінченні структури даних в Haskell, а потім створити лише ту частину, яка вам потрібна.
Найбільшим плюсом вивчення функціональної мови перед вивченням мови OOP є те, що ваші навички програмування спочатку розвиваються, а потім ви можете легко зрозуміти концепції OOP. Якщо ви почнете з мови OOP, вам доведеться одночасно вивчити дві речі: "думати про код" та "думати про OOD". Це може відволікати. Спочатку практикуйте функціональну мову та розвивайте свої навички програмування. Потім вивчіть ООП та інші парадигми. Оскільки OOP вирішив компенсувати недоліки в структурному програмуванні, то буде простіше зрозуміти, чому. Саме тому курси CS починаються з C, а потім переходять до C ++.
На питання, як навчитися програмуванню, починаючи з функціонального програмування, дві класичні рекомендації:
Перший і очевидний - це класична структура та інтерпретація комп’ютерних програм Абельсона та Суссмана, яка залишається одним з найкращих вступів до CS там, і викладається з функціональної точки зору, використовуючи схему. Він доступний повністю в Інтернеті . Якщо ви не починаєте тут, ви повинні потрапити сюди як деякий момент.
Більш свіжий текст, що охоплює більшу частину того ж ґрунту більш ніжними темпами та з більш сильним фокусом на інженерії програмного забезпечення - це як конструювати програми , Меттью Феллейзен та купу інших з команди Racket / PLT, яка використовує діалект Racket з Схема. Він також доступний в Інтернеті , як і друге видання, що не працює . Ця книга має перевагу в тому, що вона розроблена для використання в середовищі програмування DrRacket, який забезпечує дуже дружній інтерфейс для початківців і експертів, які експериментують з кодом.
На питання, чому починати з функціонального програмування, я хотів би вказати на Блог Боба Гарпера . Карнегі Меллон нещодавно переробив свою навчальну програму CS, щоб спочатку викладати функціональне програмування, а Гарпер висвітлює їхній прогрес у своєму блозі. Як один із хлопців, що стоять за визначенням Standard ML, очевидно, що він за цей крок, і він добре аргументує причини цього.
Нарешті, я застеріг би спочатку не вивчати Haskell, хоча інші можуть не погодитися. Хоча чистий підхід Haskell до FP, безумовно, породжує хороші звички, мовна орієнтація на ліниві обчислення не обов'язково підходить для початківця; одна з перших і найважливіших речей, яку вам потрібно буде навчитися робити як програміст, - це міркувати про те, що саме робить ваша програма, дивлячись на джерело, і про відносну вартість різних підходів до однієї проблеми. Я переживаю, що лінь Хаскелла робить обидві ці заходи дещо викликом навіть досвідченим програмістам, хоча Твій пробіг може відрізнятися.
Основна перевага (або, що є недоліком) починати з FP, полягає в тому, що більшість концепцій може застосовуватися і до імперативного програмування. Realm of Racket використовує аналогії відеоігор для викладання як функціональних, так і імперативних концепцій, а завзятим студентам залишається не тільки функціональна гра (npi), але і чітке розуміння умов, рекурсії, циклів, ADT та дизайну, керованого подіями. Ці поняття практично є всюдисущими в сучасному програмуванні і використовуються постійно.
Ще важливішим є те, як навчитися кодувати абстракції , те, в чому перевершує FP, використовуючи функції вищого порядку та типи даних. Як розробляти програми, існує унікальний підхід до цього, навчаючи через індукцію. Наприклад, студенти дізнаються, як fold
працює, переглядаючи код для взяття як суми, так і добутку списку, знаходячи, що у них є спільного, та самостійно отримуючи реалізацію.
Еквівалент OOP із перерахованого вище, ймовірно, передбачає одне або декілька з наступного: інтерфейси, абстрактні класи, дженерики, функтори або (якщо ви робите це неправильно) синглтон. Хоча це цілком прийнятні моделі дизайну на Java, IMHO вони не належать до вступної навчальної програми і служать лише для придушення основних принципів. Навіть як хтось, хто знайомився з мовами FP «пізно», можу сказати, що орієнтуватися в морі OOP, що постійно змінюється, було значно спрощено, маючи сильний функціональний якор.
RACKETEERS
. Не впевнений, коли він закінчується, вибачте.
Функціональне програмування значно спрощує справи. У мовах OOP вам доведеться мати управління державою в декількох потоках, не руйнуючи цей стан. У функціональних мовах, коли більшість робіт, які виконуються, виконуються чистими функціями, вам не доведеться турбуватися про це.
Що стосується швидкості / продуктивності, то я не є жокеєм справжньої продуктивності, але бути функціональним - це не означає повільно, а структура функціональних мов має мало спільного з їх швидкістю. Синтаксис функціональних мов сильно відрізняється, наприклад, відмінності між Clojure та Haskell. Clojure дуже швидкий, як є, і може досягти (а іноді і перевищувати) швидкості Java за допомогою оптимізації за фактом.
Отже, все насправді залежить від того, що ви шукаєте
Я вважаю, що доступність навчального матеріалу, хороших зразків коду та наставників дуже важливі при вивченні мов програмування. Залежно від вашої ситуації, у вас може бути наставник, який може навчити вас і т.д., але я думаю, що функціональних мовних ресурсів дуже мало в порівнянні з основними мовами. Це означає, що ви будете прогресувати повільніше порівняно з вивченням основних мов. Але якщо ви не поспішаєте, то це не проблема.
Мабуть, найбільш важливою причиною розгляду вивчення функціональних мов програмування є розуміння алгебраїчних типів даних. Розумне відображення допоможе моделювати відносини класів OO і навіть проектувати бази даних.
Зосередження уваги на багатоядерних / багатопроцесорних системах підкреслює використання паралельних алгоритмів, які можуть бути виражені чіткіше і стисліше у FP. Ламбда гілка мов, швидше за все, побачить сильне зростання використання в наступні один-два десятиліття.
Але є і деякі загальні підводні камені. Повірити FP простіше - це велика помилка, оскільки обчислення простору та часу складності, а також надання доказів зупинки може бути набагато складнішим для обчислення лямбда, особливо на мовах, які підтримують ледачу оцінку.
Отже, вчимось обох! Або, можливо, краще: спочатку вивчіть мову, яка охоплює обох, наприклад, Scala. Якщо ви не заперечуєте проти футболок з краваткою і легким голландським акцентом, можливо, вам корисні будуть лекції доктора Еріка Мейєра , які є на MSDN.