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

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

В прошлом семестре [курс] я познакомился со Схемой. Я люблю это. Мне очень понравилась крайняя простота синтаксиса, принцип гомойконичности , макросы ( гигиенические и негигиенические), множество процедур и т. Д.

Проблема со Схемой в том, что это академический язык. Я не думаю, что это действительно используется в производственных средах. Я тоже не верю, что это особенно хорошо иметь в нашем резюме. Итак, я искал альтернативы. Их много, и все они, похоже, имеют одинаковый уровень популярности.

Некоторые мысли о некоторых других функциональных языках, которые я уже рассмотрел:

• Clojure: Звучит замечательно, потому что он может получить доступ к миру Java, он ориентирован на масштабируемость и параллелизм, но разве сейчас мир Java не на грани? Я уже достаточно хорошо знаю Java, но было бы разумно добавить еще больше энергии в зависимости от JVM?
• Хаскелл: Похоже, очень ценится язык, но из того, что я прочитал, это также больше академический язык.
• Лисп: Это было вокруг с незапамятных времен. Кажется, есть большая часть того, что мне нравится в Схеме. У него большое сообщество. Насколько я знаю, это, пожалуй, самый широко используемый в промышленности язык функционального программирования (?).
• F #: действительно не учел это. Я не большой поклонник MS. У меня нет денег, чтобы заплатить за их программное обеспечение (я мог бы освободить их от университетских альянсов, но я более склонен использовать решения, основанные на сообществах). Хотя ... я думаю, это будет лучший выбор для карьеры.

Сегодня вечером я склоняюсь к Лиспу. Неделю назад это был Хаскелл. До этого это был Clojure. В прошлом году я занимался какой-то Схемой для удовольствия, а не продвигал ее по той причине, которую вы знаете. Теперь я хотел бы серьезно (об изучении одного, о выполнении реальных проектов с ним, о, возможно, в конечном итоге профессионально работать с ним). Моя проблема в том, что мне нужно изучить их все подробно, прежде чем я смогу выбрать один.

Так как вы хотите практический  язык:

Обратите внимание, что Haskell и Lisp используются больше, чем другие в промышленности, хотя в последнее время наблюдается некоторый интерес к Clojure и F #.

Но посмотрите, что произойдет, когда мы добавим Scheme в смесь:

Хм, не похоже ли это на академический язык сейчас, не так ли?

На самом деле, приведенный выше график, вероятно, является ложью; Слово «схема» может появляться в объявлениях о поиске помощи в других контекстах, кроме языков программирования. :)

Итак, вот еще один график, который, вероятно, (немного) более представительный:

Если вы хотите изучить по-настоящему крутой диалект схемы, взгляните на Racket.

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

После написания вашей программы на Haskell у вас будут инструменты, такие как монады, и методы, такие как бессмысленное кодирование, для перевода на язык по вашему выбору. Концепции, кажется, особенно хорошо соответствуют Схеме.

На самом деле, если бы вы смогли внедрить достаточно сложную систему в Scheme, вы бы были весьма желательны в компаниях, где вы, вероятно, хотели бы работать. Ранее в моей карьере я столкнулся с несколькими студентами, которые проделали значительную работу в Схеме, и единственным недостатком было то, что они не могли объяснить свою работу или не понимали ее достаточно хорошо для реализации базовых данных. структуры и алгоритмы в разумные сроки. Я всегда позволяю кандидатам отвечать на такие вопросы на их предпочитаемом языке; Я столкнулся с некоторыми людьми, которые думали, что они лучшие в Схеме, и которые сумели немало потрудиться с такими легкими вещами, как добавление элемента в связанный список, что меня озадачило.

Но если бы вы смогли «схватить» Scheme достаточно хорошо, чтобы написать даже обычное веб-приложение, это было бы неплохим аргументом в пользу большинства серьезных компаний-разработчиков программного обеспечения.

Если вы брали интервью в магазине "blub" и разработчики просто подумали, что вы странные из-за вашего мастерства в Scheme, Haskell или F #, вы, вероятно, не захотите работать там. В большинстве случаев компетентные разработчики выбирают свои концерты, поэтому не отказывайтесь от «практичности», если только в будущем вы не представите единственные варианты, которые вы можете себе представить. Работайте над тем, чтобы быть компетентным, гибким и устранять проблемы.

Колледж не о практичности. Речь идет о создании безопасной среды для изучения и изучения. Это, на самом деле, полезно, даже если вы закончите писать обычное программное обеспечение до конца своей карьеры.

При этом я не понимаю, почему вы хотите ограничиться одним из этих вариантов так скоро. Вы можете легко понять все четыре языка примерно за 4 недели, а затем выбрать один, чтобы сконцентрироваться на том, что лучше всего соответствует вашим текущим прихотям. Затем вернитесь к другому варианту и попробуйте реализовать нечто подобное. Перейдите к чему-то более сложному и снова обдумайте ваши варианты. Эксперименты это хорошо. Если вы не пытаетесь зарабатывать на жизнь в следующем месяце, вам еще не нужно становиться специалистом.

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

Я на некоторое время погрузился в Хаскелл, но пришел к выводу, что это было слишком академично. Было очень сложно сделать что-нибудь практичное. На чистом функциональном языке такие вещи, как IO, просто не вписываются в модель, поэтому вам приходится иметь дело с монадами. Я решил, что мне придется потратить огромное количество времени, чтобы быть едва компетентным, поэтому я пошел дальше.

Я делал схемы в колледже. Звучит банально, но все парни действительно отвлекают / раздражают. Трудно вернуться к этому после использования таких языков, как Python.

Недавно я изучал F #. Это функционально, но также может быть обязательным и объектно-ориентированным, когда вы хотите. Это, наряду с возможностью использования любых библиотек .NET, позволяет легко смешивать ваши чисто функциональные части с более практичными вещами, такими как графический интерфейс, ввод-вывод и работа в сети. Вы можете получить автономную версию F #.

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

Год или два назад я оценил все основные функциональные языки с точки зрения необходимости практического универсального языка функционального программирования.

В итоге я выбрал Clojure , который впоследствии оказался отличным выбором.

Вообще говоря, основными причинами были:

• Библиотечная экосистема - для того, чтобы язык был полезным, вам нужен доступ к хорошим библиотекам. Участие в JVM означает, что у вас есть легкий доступ к крупнейшей общедоступной библиотеке и инструментальной экосистеме, поэтому с прагматической точки зрения переходить на язык JVM было не сложно. Скала также очень высоко ценится здесь.

• Макро-метапрограммирование. Этот аспект Lisp всегда привлекал меня, особенно потому, что я ожидал довольно много времени для генерации кода. Я очень высоко оценил аргументы, приведенные в коротком эссе Пола Грэма " Beating The Averages ". Все лиспы здесь сильно забили.

• Производительность была «достаточно хорошей» - Clojure всегда компилируется и получает преимущества оптимизатора JIT JVM и превосходного GC. Как всегда, есть некоторые издержки при использовании функционального языка, но с Clojure было ясно, что вы можете немного приблизиться к скорости Java, приложив немного усилий (Clojure поддерживает примитивы Java и необязательную статическую типизацию для тех ситуаций, где вам это нужно). По моим оценкам, Clojure примерно в 2-5 раз медленнее, чем вы могли бы достичь с помощью оптимизированного кода Java или C ++, что согласуется с тем, что вы видите в некорректных тестах , и со временем я ожидаю, что этот разрыв будет сокращаться и дальше. Также достаточно просто написать особенно чувствительный к производительности код на чистой Java и вызвать его из Clojure.

• Параллелизм - Clojure имеет довольно уникальный и мощный подход к параллелизму, особенно для многоядерного параллелизма. Это немного сложно объяснить, но это видео отлично, чтобы дать представление о принципах. Я думаю, что Clojure в настоящее время имеет лучший ответ на хитрый вопрос «как вам следует управлять общим, одновременным и изменяемым состоянием в функциональном языке программирования?».

• Языковой дизайн - Clojure IMO - очень хорошо продуманный языковой дизайн. В качестве примеров можно привести литералы vector [] и map {} в дополнение к обычным скобкам Lisp, использование неизменяемых постоянных структур данных, поддержку ленивости по всему языку с помощью абстракции последовательности и предоставление программисту разнообразных ортогональных функций для решения различных задач. , Увидеть искусство абстракции и просто сделано легко .

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

Если бы мне пришлось назвать пару незначительных недостатков Clojure, это было бы:

• Динамическая типизация - часто это преимущество с точки зрения производительности, но в среднем, я думаю, я бы обменял это на более строгую проверку типов и вывод. Главным образом это можно избежать, имея хороший автоматизированный набор тестов, но если вам нравятся ваши типы, статически проверенные компилятором, тогда Haskell или Scala могут быть больше вашей чашкой чая.

• Ультрасовременный - Clojure развивается очень быстро и происходит много инноваций - недостатком этого является то, что существует множество экспериментов, некоторые библиотеки и инструменты все еще незрелые, и между основными версиями Clojure иногда возникают серьезные изменения, которые вы нужно следить за.

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

Похоже, вы сделали свою домашнюю работу, так что вы, вероятно, уже знаете это, но Scheme - это диалект Lisp, как Common Lisp. Если вам нравится Схема, но вам не нравится ее академическая природа, попробуйте Common Lisp. Согласно индексу TIOBE , это 13-й по популярности язык против Scheme на позиции 26.

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