Вибір функціональної мови програмування [закрито]

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

Останній [курс] семестр мене ввели до схеми. Я любив це. Любила надзвичайну простоту синтаксису, принцип гомонічності , макроси ( гігієнічні та негігієнічні), n-арність процедур тощо.

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

Деякі думки щодо деяких інших функціональних мов, які я ще розглядав:

• Clojure: Це звучить чудово, тому що він може отримати доступ до світу Java, орієнтований на масштабованість та одночасність, але чи не зараз світ Яви на краю? Я вже добре знаю Java, але чи було б розумно додати ще більше енергії залежно від JVM?
• Haskell: Схоже, дуже цінується мова, але з того, що я прочитав, це також більше академічна мова.
• Лісп: Це вже назавжди. Здається, найбільше мені подобається у схемі. У ньому є велика громада. З того, що я [думаю, що я знаю], це, мабуть, найбільш широко використовується функціональна мова програмування в галузі (?).
• F #: Не дуже врахував. Я не великий шанувальник речей MS. У мене немає грошей, щоб заплатити за їх програмне забезпечення (я міг би їх звільнити від університетських альянсів, але я більше схильний працювати з рішеннями, орієнтованими на громаду). Хоча ... я думаю, це був би найкращий вибір, орієнтований на кар'єру.

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

Оскільки ви хочете практичну  мову:

Зауважте, що Haskell і Lisp використовуються більше, ніж інші в промисловості, хоча останнім часом є інтерес до Clojure і F #.

Але подивіться, що станеться, коли ми додамо схему до суміші:

Хм, зараз це не схоже на академічну мову, чи не так?

Насправді, наведений графік, мабуть, брехня; слово "схема" може відображатися в довідкових оголошеннях в інших контекстах, окрім мов програмування. :)

Ось ось ще один графік, який, мабуть, трохи репрезентативніший:

Якщо ви хочете вивчити справді діалект схеми, подивіться на Ракетку.

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

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

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

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

Якби ви брали інтерв'ю в магазині "blub", і розробники просто думали, що ви дивні через ваше знання в Scheme або Haskell або F #, ви, ймовірно, не хотіли б там працювати. У більшості випадків грамотні розробники отримують свій вибір концертів, тому не пильнуйте "практичність", якщо єдині варіанти, які ви можете уявити собі у майбутньому, не є корпоративними. Працюйте над тим, щоб бути компетентними, гнучкими та вирішувати проблеми.

Коледж не в практичності. Йдеться про створення безпечного середовища для вивчення та навчання. Це насправді корисно, навіть якщо ви закінчите писати звичайне програмне забезпечення до кінця своєї кар’єри.

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

Я написав декілька в Scheme, F #, Emacs Lisp та Common Lisp і прочитав принаймні трохи Haskell, принаймні періодично, протягом останніх кількох років. Я не можу сказати, що я фахівець у будь-якому з них, але кожна екскурсія цими мовами принесла мені користь у всіх інших мовах, якими я професійно працюю (C #, Java, Ruby, а іноді і Boo, Perl та Python). Цікавість створить вам більш витривалий, виконуючий кар'єру, ніж будь-що інше.

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

Я робив схему в коледжі. Можливо, це банально, але всі парени насправді відволікають / дратують. Важко повернутися до цього після використання таких мов, як Python.

Останнім часом я досліджував F #. Він функціональний, але також може бути імперативним та об’єктно-орієнтованим, коли ви цього хочете. Це, поряд з можливістю використовувати будь-які бібліотеки .NET, дозволяє легко змішувати чисті функціональні частини з більш практичними речами, такими як GUI, IO та мережеві роботи. Ви можете отримати окрему версію F #.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=effc5bc4-c3df-4172-ad1c-bc62935861c5&displaylang=en

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

Я закінчив збирати Clojure , який згодом виявився відмінним вибором.

Основними причинами були:

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

• Макрометапрограмування - Цей аспект Lisp мені завжди сподобався, тим більше, що я очікував зробити трохи створення коду. Я дуже високо оцінив аргументи, викладені в короткому нарисі Пола Грема " Побиття середніх ". Тут усі сильно набрали різні Ліпси.

• Продуктивність була "досить хорошою" - Clojure завжди збирається і отримує переваги оптимізатора JIT JIT та відмінного GC. Як завжди, є деяке навантаження на використання функціональної мови, але з Clojure було зрозуміло, що ви можете трохи наблизитись до швидкості Java (Clojure підтримує примітивні Java та додаткове статичне введення для тих ситуацій, коли вам це потрібно). Моя оцінка полягає в тому, що Clojure проходить на 2-5 разів повільніше, ніж ви могли досягти за допомогою оптимізованого коду Java або C ++, що відповідає тому, що ви бачите в хибних орієнтирах , і з часом я очікую, що цей розрив ще більше скоротиться. Крім того, досить просто просто написати особливо чутливий до продуктивності код на чистій Java і викликати його з Clojure.

• Паралельність - Clojure має досить унікальний і потужний підхід до паралельності, особливо для багатоядерних. Це трохи важко пояснити, але це відео відмінно, щоб дати смак принципам. Я думаю, що зараз Clojure має найкращу відповідь на хитре запитання "як слід керувати спільним, одночасним та змінним станом у функціональній мові програмування?".

• Мовний дизайн - Clojure - це IMO - дуже продуманий дизайн мови. Прикладами є вектор [] та карта {} літерали на додаток до звичайних дужок Lisp, використання незмінних стійких структур даних, що підтримують лінь у мові через абстракцію послідовностей, а також надають програмісту різноманітні ортогональні функції для вирішення різних проблем . Побачити мистецтво абстрагування та просто зробити це легко .

• Спільнота - завжди суб'єктивна, але мені сподобалось те, що я побачив у громаді Clojure. Ставлення було дуже корисним, конструктивним та прагматичним. Існує сильний наголос на "виконайте справи", можливо, це відображає той факт, що багато людей Clojure (в тому числі сам Річ Хікі) походять з фону побудови складних корпоративних систем. Той факт, що громада Clojure має міцні зв’язки і з спільнотою Java, був важливим, щоб переконати мене, що Clojure не ризикує застрягнути в «ніші».

Якби мені довелося назвати пару незначних недоліків Clojure, це:

• Динамічне введення тексту - часто це є перевагою з точки зору продуктивності, але в середньому я думаю, що я б торгував цим для більш сильної перевірки типу та висновку. Здебільшого це полегшується за допомогою гарного автоматизованого тестового набору, але якщо вам подобається, що ваші типи статично підтверджені компілятором, то Haskell або Scala можуть бути вашою чашкою чаю.

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

В цілому, я не думаю, що ви можете помилитися з Clojure, якщо хочете відмінну та прагматичну сучасну функціональну мову!

Схоже, ви виконали домашнє завдання, тому ви, мабуть, це вже знаєте, але схема - це діалект Ліспа, як і звичайний Лисп. Якщо вам подобається багато речей про схему, але вам не подобається її академічний характер, спробуйте Common Lisp. За індексом TIOBE , це 13-та найпопулярніша мова проти схеми на позиції 26.

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