"Функциональное программирование" (ФП) - модный термин.
Автор имеет опыт разработки веб-приложений на Elixir-е (с использованием фреймворка Phoenix). Можно ли Elixir считать функциональным языком? Большинство отвечают, мол, конечно, это один из референтных представителей группы. Тот же JavaScript или Ruby могут назвать "языком с *элементами* ФП", но никому не придёт в голову назвать "полноценным" "функциональным языком".
Мне кажется, точно также, как отсутствие диплома о техническом образовании не делает человека гуманитарием (впрочем, верно и обратное), также и отсутствие на уровне базовых конструкций языка "экземпляров классов" не делает язык "функциональным". В случае Elixir, отсутствие "экземпляров" не делает даже язык "не объектно-ориентированным".
В самом деле, ООП (объектно-ориентированный подход/программирование) зиждется на следующей формуле: "состояние" + "поведение". У нас есть некие автономные чёрные ящики (объекты), у которых в каждый момент времени есть некое внутреннее (не видимое снаружи) состояние и есть возможность получать сообщения.
Сейчас обычно говорят не "получать сообщения", а "вызывать метод". Впрочем, обратите внимание, что в Ruby проверка на то, существует ли у объекта метод, делается с помощью метода `respond_to?`— "отвечает ли?". Наследие Smalltalk, где объекты таки посылали друг другу именно "сообщения". В каком-нибудь Objective C (базовом языке для разработки под iOS) до сих пор официально "посылают сообщения".
Но, простите, а что наши разработанные на Elixir "процессы" делают, когда работают в экосистеме Erlang-а? Посылают друг другу сообщения. И так, Elixir-овский "процесс":
— имеет внутреннее состояние (минимальное разнообразие типовых способов работы с состоянием заложено в стандартную библиотеку, называющуюся OTP);
— отвечают на "сообщения".
QED, господа — Elixir это объектно-ориентированный язык (где роль "классов" играют "модули", роль "объектов" — "процессы", роль "методов" — сообщения и функции).
Отличие Elixir в том, что, когда вы пишете код, язык вас вынуждает явно себе представлять, как ваши объекты "раскладываются" по процессам (параллельным потокам выполнения) — какой объект живёт в каком "домике"-процессе на каком "островке"-сетевом узле. Традиционный объектно-ориентированный язык позволяет инкапсулировать даже сетевой вызов к REST-ресурсу, избаловывая программиста этими непрозрачными стенками абстракций.
#programming #fp #ruby #javascript #elixir
Автор имеет опыт разработки веб-приложений на Elixir-е (с использованием фреймворка Phoenix). Можно ли Elixir считать функциональным языком? Большинство отвечают, мол, конечно, это один из референтных представителей группы. Тот же JavaScript или Ruby могут назвать "языком с *элементами* ФП", но никому не придёт в голову назвать "полноценным" "функциональным языком".
Мне кажется, точно также, как отсутствие диплома о техническом образовании не делает человека гуманитарием (впрочем, верно и обратное), также и отсутствие на уровне базовых конструкций языка "экземпляров классов" не делает язык "функциональным". В случае Elixir, отсутствие "экземпляров" не делает даже язык "не объектно-ориентированным".
В самом деле, ООП (объектно-ориентированный подход/программирование) зиждется на следующей формуле: "состояние" + "поведение". У нас есть некие автономные чёрные ящики (объекты), у которых в каждый момент времени есть некое внутреннее (не видимое снаружи) состояние и есть возможность получать сообщения.
Сейчас обычно говорят не "получать сообщения", а "вызывать метод". Впрочем, обратите внимание, что в Ruby проверка на то, существует ли у объекта метод, делается с помощью метода `respond_to?`— "отвечает ли?". Наследие Smalltalk, где объекты таки посылали друг другу именно "сообщения". В каком-нибудь Objective C (базовом языке для разработки под iOS) до сих пор официально "посылают сообщения".
Но, простите, а что наши разработанные на Elixir "процессы" делают, когда работают в экосистеме Erlang-а? Посылают друг другу сообщения. И так, Elixir-овский "процесс":
— имеет внутреннее состояние (минимальное разнообразие типовых способов работы с состоянием заложено в стандартную библиотеку, называющуюся OTP);
— отвечают на "сообщения".
QED, господа — Elixir это объектно-ориентированный язык (где роль "классов" играют "модули", роль "объектов" — "процессы", роль "методов" — сообщения и функции).
Отличие Elixir в том, что, когда вы пишете код, язык вас вынуждает явно себе представлять, как ваши объекты "раскладываются" по процессам (параллельным потокам выполнения) — какой объект живёт в каком "домике"-процессе на каком "островке"-сетевом узле. Традиционный объектно-ориентированный язык позволяет инкапсулировать даже сетевой вызов к REST-ресурсу, избаловывая программиста этими непрозрачными стенками абстракций.
#programming #fp #ruby #javascript #elixir
Элементы ФП в императивных языках
Мода на "функциональное программирование" задаётся, несомненно, как раз привнесением в более распространённые императивные языки пресловутых "элементов ФП".
Среди всех таких элементов можно (условно — реальная "генеалогия" чуть сложнее) выделить два класса:
1) Элемент LISP: лямбда-функции. В Ruby "лямбды" изначально были заложены в язык в виде "блоков кода" (конечно, в оригинальном LISP это сделано несколько более органично). Вслед за взрывным ростом популярности Ruby и большим признанием удобства использования "лямбд" со стороны прикладных программистов, стали потихоньку добавлять их и в другие языки: кажется, первым среди невымирающих динозавров была Java 8. Ну а теперь даже в C++ вы можете встретить нечто похожее.
2) Элемент LISP: итераторы. Аналогично с итераторами: map, select, reduce, zip, и т. д. и т. п. можно найти в любом уважающем себя современном языке. Популяризирует их в наше время JavaScript, в очередной ревизии которого они наконец появились, чтобы язык не выглядел совсем уж позорно на фоне любительской поделки фанатиков Rails — CoffeScript-а (как раз после появления "лямбд" и итераторов в JS "коффискрипт" и умер).
3) Элемент Haskell: "монады". Мало кто, в сущности, знает хоть что-то о системе категорий, но антураж "матана" привлекает неуверенных в себе программистов. Точно также, как психолог в связи с массовостью профессии и отсутствием профессиональных стандартов считается неполноценным психиатром, и программист на заре развития программирования мог бы считаться неполноценным математиком. В какой-то мере сохраняется подобное смутное чувство и сегодня. Из всего Haskell-а (этакого "языка программирования от математиков") выдёргивают обычно так называемые "монады". Элементарная, в сущности, концепция, которая на языке ООП описывалась бы простым интерфейсом контейнера с 3-8 методами, превращается в жупел, которым неполноценные математики, так и не сумевшие стать программистами, формируют неуверенность в своём интеллекте у программистов, которые не желают становиться математиками.
4) Элемент Haskell: pattern matching. Опять же, JavaScript популяризирует концепцию в наше время, переназвав её как "destructuring". На мой взгляд, впрочем, в таком терминологическом изменении нет ничего страшного: надо быть ближе к народу. Destructuring позволяет, например, прямо в сигнатуре функции (в перечислении аргументов) "выдернуть" ключ хеша или элемент массива из входящего параметра (таким образом "сопоставив", match, входящую структуру некоему "образцу", pattern). Ruby идёт с отставанием: на коленке сделанный
А кроме этих четырёх пунктов, что-то больше ничего и не приходит на ум.
А вам каких "элементов ФП" не хватает в любимых языках?
#programming #fp #ruby #javascript #elixir
Мода на "функциональное программирование" задаётся, несомненно, как раз привнесением в более распространённые императивные языки пресловутых "элементов ФП".
Среди всех таких элементов можно (условно — реальная "генеалогия" чуть сложнее) выделить два класса:
1) Элемент LISP: лямбда-функции. В Ruby "лямбды" изначально были заложены в язык в виде "блоков кода" (конечно, в оригинальном LISP это сделано несколько более органично). Вслед за взрывным ростом популярности Ruby и большим признанием удобства использования "лямбд" со стороны прикладных программистов, стали потихоньку добавлять их и в другие языки: кажется, первым среди невымирающих динозавров была Java 8. Ну а теперь даже в C++ вы можете встретить нечто похожее.
2) Элемент LISP: итераторы. Аналогично с итераторами: map, select, reduce, zip, и т. д. и т. п. можно найти в любом уважающем себя современном языке. Популяризирует их в наше время JavaScript, в очередной ревизии которого они наконец появились, чтобы язык не выглядел совсем уж позорно на фоне любительской поделки фанатиков Rails — CoffeScript-а (как раз после появления "лямбд" и итераторов в JS "коффискрипт" и умер).
3) Элемент Haskell: "монады". Мало кто, в сущности, знает хоть что-то о системе категорий, но антураж "матана" привлекает неуверенных в себе программистов. Точно также, как психолог в связи с массовостью профессии и отсутствием профессиональных стандартов считается неполноценным психиатром, и программист на заре развития программирования мог бы считаться неполноценным математиком. В какой-то мере сохраняется подобное смутное чувство и сегодня. Из всего Haskell-а (этакого "языка программирования от математиков") выдёргивают обычно так называемые "монады". Элементарная, в сущности, концепция, которая на языке ООП описывалась бы простым интерфейсом контейнера с 3-8 методами, превращается в жупел, которым неполноценные математики, так и не сумевшие стать программистами, формируют неуверенность в своём интеллекте у программистов, которые не желают становиться математиками.
4) Элемент Haskell: pattern matching. Опять же, JavaScript популяризирует концепцию в наше время, переназвав её как "destructuring". На мой взгляд, впрочем, в таком терминологическом изменении нет ничего страшного: надо быть ближе к народу. Destructuring позволяет, например, прямо в сигнатуре функции (в перечислении аргументов) "выдернуть" ключ хеша или элемент массива из входящего параметра (таким образом "сопоставив", match, входящую структуру некоему "образцу", pattern). Ruby идёт с отставанием: на коленке сделанный
case... in в свежей версии это хорошо, но мало: даёшь "перегрузку" функций в зависимости от структуры аргумента, как в том же Elixir.А кроме этих четырёх пунктов, что-то больше ничего и не приходит на ум.
А вам каких "элементов ФП" не хватает в любимых языках?
#programming #fp #ruby #javascript #elixir