Что такое функциональный язык программирования

Функциональный язык программирования

В языках функционального программирования основным конструктивным элементом является математическое понятие функции. Существует различия в понимании функции в математике и функции в программировании, в следствии чего нельзя отнести Си-подобные языки к функциональным, использующим менее строгое понятие. Функция в математике не может изменить вызывающее её окружение и запомнить результаты своей работы, а только предоставляет результат вычисления функции. Программирование с использованием математического понятия функции вызывает некоторые трудности, поэтому функциональные языки, в той или иной степени предоставляют и императивные возможности, что ухудшает дизайн программы (например возможность безболезненных дальнейших изменений). Дополнительное отличие от императивных языков программирования заключается в декларативности описаний функций. Тексты программ на функциональных языках программирования описывают «как решить задачу», но не предписывают последовательность действий для решения. Первым, спроектированным функциональным языком стал Лисп. Вариант данного языка широко используется в системе автоматизированного проектирования AutoLISP

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

Некоторые языки функционального программирования

Ссылки

Смотреть что такое «Функциональный язык программирования» в других словарях:

Функциональный язык программирования — язык программирования, позволяющий задавать программу в виде совокупности определений функций. В функциональных языках программирования: функции обмениваются между собой данными без использования промежуточных переменных и присваиваний;… … Финансовый словарь

функциональный язык — Язык программирования, в котором действия над данными выражаются в виде обращений к функциональным процедурам. [ГОСТ 19781 90] Тематики обеспеч. систем обраб. информ. программное EN functional language … Справочник технического переводчика

Язык программирования Рубин — Ruby Семантика: мультипарадигмальный Тип исполнения: интерпретатор Появился в: 1995 г. Автор(ы): Юкихиро Мацумото Последняя версия: 1.9.1 … Википедия

Функциональный язык — 37. Функциональный язык Functional language Язык программирования, в котором действия над данными выражаются в виде обращений к функциональным процедурам Источник: ГОСТ 19781 90: Обеспечение систем обработки информации программное. Термины и… … Словарь-справочник терминов нормативно-технической документации

Эрланг (язык программирования) — Erlang Файл:Erlang logo.png Семантика: мультипарадигмальный: конкурентное, функциональное программирование Появился в: 1987 г. Автор(ы): Типизация данных: строгая, динамическая Основные реализации: E … Википедия

Scheme (язык программирования) — Scheme Семантика: функциональный Тип исполнения: интерпретатор или компилятор Появился в: 1970 г. Автор(ы): Гай Стил и Джеральд Сассмен Типизация данных … Википедия

Миранда (язык программирования) — У этого термина существуют и другие значения, см. Миранда. Miranda функциональный язык программирования, созданный в 1985 году Дэвидом Тёрнером в качестве стандартного функционального языка. Имеет строгую полиморфную систему типов,… … Википедия

Hope (язык программирования) — Hope функциональный язык программирования, разработанный в начале 1980 х годов; является предшественником языков Miranda и Haskell. В журнале Byte за август 1985 впервые опубликовано руководство по языку Hope. Пример программы вычисления… … Википедия

SASL (язык программирования) — У этого термина существуют и другие значения, см. SASL. SASL полностью функциональный язык программирования, разработанный Дэвидом Тёрнером в Сент Эндрюсском университете в 1972 году, на базе аппликативного подмножества ISWIM. В 1976 году… … Википедия

Scala (язык программирования) — У этого термина существуют и другие значения, см. Scala. Scala Класс языка: Мультипарадигмальный: функ … Википедия

Источник

Что такое функциональное программирование

В про­грам­ми­ро­ва­нии есть два боль­ших под­хо­да — импе­ра­тив­ное и функ­ци­о­наль­ное. Они суще­ствен­но отли­ча­ют­ся логи­кой рабо­ты, ещё и созда­ют пута­ни­цу в назва­ни­ях. Сей­час объясним.

🤔 Функциональное — это про функции?

❌ Нет. Функ­ци­о­наль­ное — это не про функ­ции. Функ­ции есть почти в любых язы­ках про­грам­ми­ро­ва­ния: и в функ­ци­о­наль­ных, и в импе­ра­тив­ных. Отли­чие функ­ци­о­наль­но­го про­грам­ми­ро­ва­ния от импе­ра­тив­но­го — в общем подходе.

Метафора: инструкция или книга правил

Пред­ставь­те, что вы откры­ва­е­те кафе-столовую. Сей­час у вас там два типа сотруд­ни­ков: пова­ра и администраторы.

Для пова­ров вы пише­те чёт­кие поша­го­вые инструк­ции для каж­до­го блю­да. Например:

Повар дол­жен сле­до­вать этим инструк­ци­ям ров­но в той после­до­ва­тель­но­сти, в кото­рой вы их напи­са­ли. Нель­зя сна­ча­ла почи­стить свёк­лу, а потом взять её. Нель­зя посо­лить кастрю­лю, в кото­рой нет воды. Поря­док дей­ствий важен и опре­де­ля­ет­ся вами. Это при­мер импе­ра­тив­но­го про­грам­ми­ро­ва­ния. Вы пове­ле­ва­е­те испол­ни­те­лем. Мож­но ска­зать, что испол­ни­те­ли выпол­ня­ют ваши задания.

Для адми­ни­стра­то­ра вы пише­те не инструк­цию, а как бы кни­гу правил:

Это тоже коман­ды, но испол­нять их адми­ни­стра­тор будет не в этой после­до­ва­тель­но­сти, а в любой на своё усмот­ре­ние. Мож­но ска­зать, что зада­ча это­го чело­ве­ка — испол­нять функ­ции адми­ни­стра­то­ра, и мы опи­са­ли пра­ви­ла, по кото­рым эти функ­ции испол­нять. Это при­мер функ­ци­о­наль­но­го программирования.

❌ Про­грам­ми­сты, не бомбите

Конеч­но же, это упро­ще­но для пони­ма­ния. Вы сами попро­буй­те это нор­маль­но объ­яс­нить (мож­но пря­мо в комментах).

Императивное программирование

При­ме­ры язы­ков: C, С++, Go, Pascal, Java, Python, Ruby

Импе­ра­тив­ное про­грам­ми­ро­ва­ние устро­е­но так:

В язы­ке есть коман­ды, кото­рые этот язык может выпол­нять. Эти коман­ды мож­но собрать в под­про­грам­мы, что­бы авто­ма­ти­зи­ро­вать неко­то­рые одно­тип­ные вычис­ле­ния. В каком поряд­ке запи­са­ны коман­ды внут­ри под­про­грам­мы, в том же поряд­ке они и будут выполняться.

Есть пере­мен­ные, кото­рые могут хра­нить дан­ные и изме­нять­ся во вре­мя рабо­ты про­грам­мы. Пере­мен­ная — это ячей­ка для дан­ных. Мы можем создать пере­мен­ную нуж­но­го нам типа, поло­жить туда какое-то зна­че­ние, а потом поме­нять его на другое.

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

Полу­ча­ет­ся, что в раз­ные дни функ­ция полу­ча­ет на вход 1000 ₽, но воз­вра­ща­ет раз­ные зна­че­ния — так рабо­та­ет импе­ра­тив­ное про­грам­ми­ро­ва­ние, когда всё зави­сит от дру­гих переменных.

После­до­ва­тель­ность выпол­не­ния под­про­грамм регу­ли­ру­ет­ся про­грам­ми­стом. Он зада­ёт нуж­ные усло­вия, по кото­рым дви­жет­ся про­грам­ма. Вся логи­ка пол­но­стью про­ду­мы­ва­ет­ся про­грам­ми­стом — как он ска­жет, так и будет. Это зна­чит, что раз­ра­бот­чик может точ­но пред­ска­зать, в какой момент какой кусок кода выпол­нит­ся — код полу­ча­ет­ся пред­ска­зу­е­мым, с понят­ной логи­кой работы.

Если у нас код, кото­рый счи­та­ет скид­ку, дол­жен вызы­вать­ся толь­ко при финаль­ном оформ­ле­нии зака­за, то он выпол­нит­ся имен­но в этот момент. Он не посчи­та­ет скид­ку зара­нее и не про­пу­стит момент оформления.

👉 Суть импе­ра­тив­но­го про­грам­ми­ро­ва­ния в том, что про­грам­мист опи­сы­ва­ет чёт­кие шаги, кото­рые долж­ны при­ве­сти код к нуж­ной цели.

Зву­чит логич­но, и боль­шин­ство про­грам­ми­стов при­вык­ли имен­но к тако­му пове­де­нию кода. Но функ­ци­о­наль­ное про­грам­ми­ро­ва­ние рабо­та­ет совер­шен­но иначе.

Функциональное программирование

При­ме­ры язы­ков: Haskell, Lisp, Erlang, Clojure, F#

Смысл функ­ци­о­наль­но­го про­грам­ми­ро­ва­ния в том, что мы зада­ём не после­до­ва­тель­ность нуж­ных нам команд, а опи­сы­ва­ем вза­и­мо­дей­ствие меж­ду ними и под­про­грам­ма­ми. Это похо­же на то, как рабо­та­ют объ­ек­ты в объектно-ориентированном про­грам­ми­ро­ва­нии, толь­ко здесь это реа­ли­зу­ет­ся на уровне всей программы.

Напри­мер, в ООП нуж­но задать объ­ек­ты и пра­ви­ла их вза­и­мо­дей­ствия меж­ду собой, но так­же мож­но и напи­сать про­сто код, кото­рый не при­вя­зан к объ­ек­там. Он как бы сто­ит в сто­роне и вли­я­ет на рабо­ту про­грам­мы в целом — отправ­ля­ет одни объ­ек­ты вза­и­мо­дей­ство­вать с дру­ги­ми, обра­ба­ты­ва­ет какие-то резуль­та­ты и так далее.

Функ­ци­о­наль­ное про­грам­ми­ро­ва­ние здесь идёт ещё даль­ше. В нём весь код — это пра­ви­ла рабо­ты с дан­ны­ми. Вы про­сто зада­ё­те нуж­ные пра­ви­ла, а код сам раз­би­ра­ет­ся, как их применять.

Если мы срав­ним прин­ци­пы функ­ци­о­наль­но­го под­хо­да с импе­ра­тив­ным, то един­ствен­ное, что сов­па­дёт, — и там, и там есть коман­ды, кото­рые язык может выпол­нять. Всё осталь­ное — разное.

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

Пере­мен­ных нет. Вер­нее, они есть, но не в том виде, к кото­ро­му мы при­вык­ли. В функ­ци­о­наль­ном язы­ке мы можем объ­явить пере­мен­ную толь­ко один раз, и после это­го зна­че­ние пере­мен­ной изме­нить­ся не может. Это как кон­стан­ты — запи­са­ли и всё, теперь мож­но толь­ко про­чи­тать. Сами же про­ме­жу­точ­ные резуль­та­ты хра­нят­ся в функ­ци­ях — обра­тив­шись к нуж­ной, вы все­гда полу­чи­те иско­мый результат.

Функ­ции все­гда воз­вра­ща­ют одно и то же зна­че­ние, если на вход посту­па­ют одни и те же дан­ные. Если в про­шлом при­ме­ре мы отда­ва­ли в функ­цию сум­му в 1000 ₽, а на выхо­де полу­ча­ли скид­ку в зави­си­мо­сти от дня неде­ли, то в функ­ци­о­наль­ном про­грам­ми­ро­ва­нии если функ­ция полу­чит в каче­стве пара­мет­ра 1000 ₽, то она все­гда вер­нёт одну и ту же скид­ку неза­ви­си­мо от дру­гих переменных.

Мож­но про­ве­сти ана­ло­гию с мате­ма­ти­кой и сину­са­ми: синус 90 гра­ду­сов все­гда равен еди­ни­це, в какой бы момент мы его ни посчи­та­ли или какие бы углы у нас ещё ни были в зада­че. То же самое и здесь — всё пред­ска­зу­е­мо и зави­сит толь­ко от вход­ных параметров.

После­до­ва­тель­ность выпол­не­ния под­про­грамм опре­де­ля­ет сам код и ком­пи­ля­тор, а не про­грам­мист. Каж­дая коман­да — это какое-то пра­ви­ло, поэто­му нет раз­ни­цы, когда мы запи­шем это пра­ви­ло, в нача­ле или в кон­це кода. Глав­ное, что­бы у нас это пра­ви­ло было, а ком­пи­ля­тор сам раз­бе­рёт­ся, в какой момент его применять.

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

👉 Полу­ча­ет­ся, что смысл функ­ци­о­наль­но­го про­грам­ми­ро­ва­ния в том, что­бы опи­сать не сами чёт­кие шаги к цели, а пра­ви­ла, по кото­рым ком­пи­ля­тор сам дол­жен дой­ти до нуж­но­го результата.

Источник

Современные языки программирования, которые заставят вас страдать: Часть 2, функциональные языки

Современные языки программирования, которые заставят вас страдать: Часть 2, функциональные языки

Прим. ред. Это перевод статьи Ильи Суздальницкого. Мнение редакции может не совпадать с мнением автора оригинала.

Это вторая и финальная часть перевода статьи про современные язки программирования. В первой части — «Современные языки программирования, которые заставят вас страдать: Часть 1, ООП», рассматривались объектноориентированные языки. В этой части автор подробно разбирает функциональные языки программирования которые принадлежат семейству ML ( и некоторые С-подобные).

Функциональные языки программирования

Haskell

Типизация: нет более мощной системы типов, чем в Haskell. Он поддерживает, как алгебраические типы данных, так и классы типов. Язык способен вывести почти любой тип.

Сложность изучения: чтобы продуктивно использовать Haskell нужно изучить теорию категорий. Даже для того, чтобы написать hello world, нужно понимать монады.

Сообщество: больше заинтересовано в академических дискуссиях, чем в решении реальных проблем.

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

Конечно в языке есть обходные пути, для взаимодействия с внешним миром. Для этого используется набор инструкций (монад ввода-вывода). Это могут быть такие инструкции: получить строку с клавиатуры, использовать её в некой функции, напечатать результат в консоль. Среда выполнения делает это за нас. Мы никогда не выполняем код взаимодействующий с внешним миром напрямую.

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

Поддержка NULL: как и в Rust, Haskell не поддерживает нулевые ссылки. Вместо этого в нём есть Optional, на случай, если значения может не быть.

Обработка ошибок: некоторые функции могут выбрасывать ошибки, но более свойственный для языка подход похож на Result в Rust.

Иммутабельность: язык имеет первоклассную поддержку иммутабельных структур данных.

Сопоставление с образцом: поддерживается.

Экосистема: стандартная библиотека неорганизованна. По умолчанию, в Haskell используются функции выбрасывающие исключение, вместо возврата Option (золотой стандарт для функционального программирования). В довершение всего, у Haskell есть два менеджера пакетов — Cabal и Stack.

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

OCaml

Типизация: не поддерживает классы типов, но есть функторы (модули высшего порядка). Язык статически типизирован и выводит типы почти также хорошо, как Haskell.

Экосистема: имеет небольшое сообщество и страдает от недостатка библиотек. Языку не хватает достойного веб-фреймворка. Документация хуже чем других языков.

Инструментарий: инструменты языка неорганизованны. Имеет три менеджера пакетов: Opam, Dune, и Esy. Язык известен некачественными сообщениями об ошибках компилятора. Это не критично, но снижает производительность программистов.

Параллелизм: разработчики годами ждут поддержки многоядерности, но её пока что не предвидится.

Поддержка NULL: нет нулевых ссылок, использует Option для неуказанных значений.

Обработка ошибок: нативный подход — использование типа Result.

Иммутабельность: язык имеет первоклассную поддержку иммутабельных структур данных.

Сопоставление с образцом: поддерживается.

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

Scala

Экосистема: Scala — это язык из семейства Си, который выполняется на виртуальной машине Java. Это значит, что у вас есть доступ к огромной экосистеме библиотек Java.

Типизация: язык плохо справляется с приведением типов. Однако Scala поддерживает Higher-Kinded типы и типы классов.

Немногословность/читаемость: хотя программы на Scala и отличаются лаконичностью (особенно по сравнению с Java), читаемость страдает. Scala — один из немногих функциональных языков, принадлежащих к семейству Си. Си-подобные языки были предназначены для императивного программирования, а ML для функционального. Поэтому функциональный код на Scala может иногда выглядеть странно.

Синтаксис для алгебраических типов данных оставляет желать лучшего:

Этот же код на языке ReasonML:

Скорость: hello world на языке Scala может компилироваться до 10 секунд, на слабом железе. Компиляция производится только на одном ядре процессора, что отрицательно влияет на скорость.

Из-за того, что Scala работает на виртуальной машине Java, программы запускаются дольше.

Сложность изучения: один из самых сложных функциональных языков. Scala, как и C++ обладает множеством функций, которые, однако, усложняют его изучение.

Иммутабельность: Scala обладает первоклассной поддержкой неизменяемых структур данных (с использованием классов образцов).

Поддержка NULL: с одной стороны, Scala поддерживает нулевые ссылки. С другой стороны, характерный для языка способ обработки отсутствующих значений — паттерн Option.

Обработка ошибок: нативный подход — использование типа Result.

Параллелизм: можно использовать отличный инструмент — Akka.

Сопоставление с образцом: поддерживается.

Вердикт: Scala пытается делать слишком многое. Его разработчикам пришлось пойти на множество компромиссов, чтобы поддерживать как ООП, так и функциональное программирование.

Сообщения об ошибках: компилятор выдаёт самые понятные сообщения об ошибках, что я когда-либо видел.

Обработка ошибок: в языке нет ошибок выполнения и исключений. Как и другие функциональные языки, использует тип Result для обработки ошибок.

Функциональная чистота: как и Haskell, Elm — чисто функциональный язык. И в данном случае это скорее минус, потому что любой рефакторинг превращается в кошмар.

Слишком строгий:

Скриншот с сайта https://www.reddit.com/r/ProgrammerHumor/comments/8we9zh/im_learning_elm_and_it_immediately_declared_war/

Elm настолько строгий, что использование табуляций считается синтаксической ошибкой.

Сосредоточенность на отсутствии ошибок убивает язык. В версии 0.19, взаимодействие с JS библиотеками сделали практически невозможным. Конечно для того, чтобы стимулировать людей писать свои библиотеки на Elm. Но компаний, у которых есть для этого достаточно ресурсов, крайне мало.

Поддержка React: Elm создаёт свою собственную виртуальную модель DOM и не использует React. Это лишает разработчиков доступа к обширной экосистеме библиотек и компонентов, созданных для React.

Состояние языка: с каждым новым релизом в языке происходят сильные изменения, которые могут лишить вас возможности использовать его.

К сожалению, прошло уже больше года с тех пор, как была выпущена новая версия Elm (0.19.1). О состоянии разработки ничего не известно. Возможно, что она вообще больше не ведётся.

Сопоставление с образцом: поддерживается.

Иммутабельность: обладает первоклассной поддержкой неизменяемых структур данных.

Поддержка NULL: нет нулевых ссылок, использует Option для неуказанных значений.

Вердикт: Elm — отличный язык, но к сожалению у него нет будущего.

Типизация: единственный минус его системы типов — отсутствие Higher-Kinded типов. Тем не менее система типов очень надежна, компилятор способен вывести практически все что угодно. F# имеет надлежащую поддержку алгебраических типов данных.

Не полностью функциональный: в отличие от Haskell/Elm, F# очень прагматичен и не обеспечивает функциональную чистоту.

Обучающие ресурсы: есть действительно хорошие учебные ресурсы.

Сложность изучения: F# — один из самых простых функциональных языков.

Экосистема: имеет довольно небольшое сообщество и в отличие от таких языков как Elixir, оно не имеет таких же замечательных библиотек.

Параллелизм: работает поверх CLR, который не имеет такой же превосходной поддержки параллелизма, как Elixir на виртуальной машине Erlang.

Поддержка NULL: NULL-значения обычно не используются. Неуказанные значения обрабатываются с помощью паттерна Option.

Обработка ошибок: ошибки обрабатываются с помощью паттерна Result.

Иммутабельность: обладает первоклассной поддержкой неизменяемых структур данных.

Сопоставление с образцом: поддерживается.

Вердикт: F# — очень надежный язык программирования с действительно хорошей системой типов. Он почти так же хорош, как Elixir для разработки Web API (подробнее об этом далее). Однако проблема F# заключается не в том, что у него есть, а в том, чего у него нет. Если сравнить его с Elixir, его функционал параллелизма, богатая экосистема и удивительное сообщество перевешивают любые преимущества статической типизации, которые предоставляет F#.

Однако F# — лучший язык для финтеха. Также язык отлично подойдёт для энтерпрайз разработки. Его мощная система типов позволяет моделировать сложную бизнес логику. Очень рекомендую прочитать эту книгу — «Domain Modeling Made Functional».

ReasonML

Не является надмножеством JavaScript: синтаксис ReasonML похож на JavaScript, что делает его более доступным для всех, кто имеет опыт работы с JavaScript. Однако, в отличие от TypeScript, ReasonML даже не пытается быть надмножеством JavaScript. ReasonML не должен был унаследовать плохие дизайнерские решения, десятилетиями принимаемые в JavaScript.

Сложность изучения: ReasonML является одним из самых простых функциональных языков.

Не полностью функциональный: ReasonML очень прагматичен, ориентирован на производительность разработчиков и быстрое достижение результатов.

Типизация: его система типов почти так же хороша, как у Haskell. Самым большим недостатком является отсутствие классов типов, но он поддерживает функторы (модули высшего порядка).

ReasonML статически типизирован и выводит типы почти так же хорошо, как и Haskell.

Экосистема: как и TypeScript, ReasonML имеет доступ ко всей экосистеме JavaScript.

Взаимодействие с JavaScript/TypeScript: компилируется в обычный JavaScript. Поэтому, в одном проекте можно использовать как ReasonML, так и JavaScript/TypeScript.

ReasonML and React — отличное сочетание: поскольку ReasonML статически типизирован, нет необходимости беспокоиться о PropTypes. В отличие от JavaScript, при использовании ReasonML ничто не перерисовывается без необходимости — вы получаете отличную производительность React из коробки!

Инструменты: язык далеко не такой зрелый, как его альтернативы, так что могут возникнуть некоторые проблемы с инструментами. Например, официально рекомендуемое расширение VSCode — reason-language-server в настоящее время не работает.

ReasonML использует компилятор OCaml под капотом, а OCaml известен посредственными сообщениями об ошибках компилятора. Это не критично, но может повлиять на производительность разработчиков.

Поддержка NULL: нет нулевых ссылок, использует Option для неуказанных значений.

Иммутабельность: обладает первоклассной поддержкой неизменяемых структур данных.

Сопоставление с образцом: поддерживается.

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

Elixir

Экосистема: это сильная сторона языка. Автор языка также разрабатывает крутые библиотеки: Phoenix и Ecto. В отличие от других языков, у Elixir нет множества библиотек с дублирующимся функционалом, а существующие — очень хороши.

Имеет хорошую документацию, даже к стандартной библиотеке.

Фреймворк Phoenix: поддерживает из коробки: вебсокеты, routing, HTML templating language, internationalization, JSON encoders/decoders, seamless ORM integration(Ecto), sessions, SPA toolkit и многое другое. Также фреймворк известен своей производительностью — способен обрабатывать миллионы одновременных подключений на одной машине.

Фуллстек Elixir: Phoenix недавно представил LiveView, который позволяет создавать насыщенные веб-интерфейсы реального времени прямо в Elixir. LiveView даже заботится о синхронизации состояния клиента и сервера, а это значит, что нам не нужно беспокоиться о разработке и обслуживании REST/GraphQL API.

Обработка данных: Elixir может быть надежной альтернативой Python для многих задач связанных с обработкой данных. Скрепер есть как у Python, так и у Elixir, и последний предлагает гораздо лучшее решение и экосистему для этой задачи.

Такие инструменты, как Broadway, позволяют строить конвейеры приема/обработки данных в Elixir.

Типизация: на мой взгляд, отсутствие корректной статической типизации — самый большой недостаток Elixir.

Скорость: компилятор Elixir является многопоточным и обеспечивает невероятно высокую скорость компиляции. В отличие от JVM, виртуальная машина Erlang запускается быстро. Производительность во время выполнения очень хороша.

Надёжность: код на Elixir выполняется поверх Erlang, который использовался более 30 лет для создания самого надежного программного обеспечения в мире. Некоторые программы, работающие на виртуальной машине Erlang, смогли достичь надежности 99,9999999%. Ни одна другая платформа в мире не может похвастаться таким же уровнем надежности.

Параллелизм: язык использует альтернативный подход к параллелизму — модель акторов. При таком подходе, у акторов (процессов) нет ничего общего. Единственный способ общения между различными процессами — отправка сообщений.

Elixir, в отличие от Go, убивает только тот процесс в котором произошла ошибка, а не всю программу. Более того, этот процесс будет автоматически перезапущен его супервизором.

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

Процессы в Elixir очень легковесны, их можно запускать тысячами на одной машине.

Масштабирование: параллельные вычисления в Go быстрее чем в Elixir, если это происходит на одной машине. Но при масштабировании происходит обратное. Elixir легко справляется с такими вещами как: кластеризация, RPC и сетевые взаимодействия. В некотором смысле, виртуальная машина Erlang работала с микросервисами за десятилетия до того, как они вошли в обиход. Каждый процесс можно рассматривать как микросервис — как и микросервисы, процессы независимы друг от друга. Микросервисы без сложностей Kubernetes? Именно для этого и был создан Elixir.

Обработка ошибок: язык использует уникальный подход к обработке ошибок. В то время как чисто функциональные языки (Haskell/Elm) предназначены для минимизации вероятности появления ошибок, Elixir предполагает, что ошибки неизбежно произойдут.

Выбрасывать исключения в Elixir — правильно, в то время как обрабатывать исключения обычно не рекомендуется. Вместо этого супервизор процесса автоматически перезапустит неудачный процесс, чтобы программа продолжила работать.

Сложность изучения: язык можно освоить за пару месяцев. Однако освоение OTP может занять некоторое время. OTP — киллер фича языка. OTP — это набор инструментов и библиотек от Erlang, на которых строится Elixir. Это секретный ингредиент, который значительно упрощает построение параллельных и распределенных программ.

Обучающие ресурсы: их существует огромное количество. И почти все из них подойдут для новичков.

Сопоставление с образцом: поддерживается.

Вычисления: язык не справляется с задачами в которых требуется большое количество вычислений.

Вердикт: Elixir, вероятно, является самым зрелым из всех функциональных языков. Он работает на виртуальной машине, созданной для функционального программирования. Язык был разработан с нуля для параллельных вычислений, и идеально подходит для современной эры многоядерных процессоров. Это лучший язык для Web API. OTP и модель акторов делают язык лучшим решением для параллельных и распределённых программ.

Подходящий инструмент

Точно также, как не стоит пытаться забить гвоздь отвёрткой, не нужно использовать один язык программирования повсюду. Каждый из них имеет свою область применения.

Go — лучший язык для системного программирования. Для фронтенда несомненно стоит выбрать ReasonML. Абсолютный лидер для разработки Web API — Elixir. Как и для любых задач связанных с параллельными и распределёнными программами. Python, это к сожалению единственный адекватный вариант для data science.

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

Источник