Elixir: Как выглядит ООП в функциональном языке?

Да, всё верно. Предельно позднее связывание в действии :-)
Если Вы хотите, чтобы процесс не падал в таких ситуациях, можно определить catch-all обработчики сообщений, которые просто проигнорируют «левые» сообщения. Но с учётом того, что подобное может произойти только из-за ошибки/опечатки в коде, лучше пусть падает.

Elixir: Как выглядит ООП в функциональном языке?

Об этом написано в статье. В четвёртом с конца абзаце.

Elixir: Как выглядит ООП в функциональном языке?

Я думаю, это в-первую очередь связано с тем, что Elixir поддерживает опциональные параметры.
Ну и как по мне, это логичнее, когда, допустим, функции для работы со списками принимают список в качестве первого аргумента, а не последнего.
Заметок о дизайне на эту тему я не встречал, но можно почитать в дискуссии в google-группе, например эту.

Elixir: Как выглядит ООП в функциональном языке?

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

По поводу состояния, в Elixir оно надёжно спрятано в процессе, никакой рефлексией и уж тем более прямыми присваиваниями до него не достать. Только отправкой сообщений можно опосредованно влиять на состояние. Ну и как в любом функциональном языке все данные неизменяемы. Т.о. ситуация, когда вы получили часть состояния объекта по ссылке, передали в другой метод, а он взял его и изменил, тоже невозможны by design.

Elixir: Как выглядит ООП в функциональном языке?

Процесс с этим pid упадёт с ошибкой типа
(FunctionClauseError) no function clause matching in Airplane.handle_cast/2
airplane.ex:38: Airplane.handle_cast({:add, "Aimee", 2}, %{})

Вообще Erlang и Elixir стимулирует разработку по принципу «Let it crash». Поэтому чуть что не так — процесс падает и перезапускается с чистого листа одним из супервизоров.

Elixir: Как выглядит ООП в функциональном языке?

Пайпы — это не каррирование, а синтаксический сахар для инверсии записи вложенных функций.

c(b(a))) 
# эквивалентно
a |> b |> c

c(b(a1, a2), b2, b3)) 
# эквивалентно
a1 |> b(a2) |> c(b2, b3)

Elixir: Как выглядит ООП в функциональном языке?

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

import School, only: [add_student: 3, students_by_grade: 1, students_by_grade: 2]

Прощай, объектно-ориентированное программирование

Добавлю ссылку на первоисточник цитаты из сообщения IIvana: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
Полный текст интереснее.

Рейтинг языков программирования в 2016 году

По-моему такое уточнение *ML вообще с другими языками ассоциируется: https://ru.wikipedia.org/wiki/ML, которые тоже в этих рейтингах фигурируют )))

Маслобойка

Ну, каждому кулику своё болото понятнее… Хотя я Вашу идею понял, на Node.js у Вас просто меньше достойных конкурентов )

Маслобойка

Спасибо. Это действительно аргумент.

Маслобойка

stdlib вроде просто причёсана для пайпов, чтобы основной параметр всегда шёл первым… на что там гневаться то?

Маслобойка

Да ну, ассемблер же — это синтаксический сахар для машинных кодов )))

Маслобойка

Вы почему-то исходите из того, что текущий уровень языков программирования очень низок. Но по факту нам и правда надо хорошенько осмыслить то, что придумали за предыдущие 60 лет. На тех компьютерах, которые у нас сейчас есть, крайне сложно придумать что-то новое в области программирования. Более того CPU уже упёрлись в физические пределы производства. И даже на случай, если дальнейший рост пойдёт через увеличение кол-ва ядер на порядки, уже всё придумано.

застрявшими в цифровой эпохе электрических компьютеров на 1000 лет.

В том то и дело, что придумывать новые компьютеры в компетенции программистов не входит, это будут делать физики.
А если Вы реально хотите придумать что-то новое в плане программирования, смотрите в сторону появляющихся вариантов, типа квантовых компьютеров. Там прогресс будет, но это уже совсем другая история. Не имеющая отношения к написанию 100500 примерно одинаковых фреймворков/библиотек для одной и той же задачи.

Маслобойка

Ну, если верить indeed.com, то разница на уровне Senior всего 6-7% в пользу Node.js. Т.е. по факту всё будет зависеть от выбора компании и проекта, а не от выбора между этими двумя вариантами.

Маслобойка

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

Маслобойка

Ну да, я в том числе подразумевал вопрос: что такого может дать Node.js чего не может дать Java?

Маслобойка

Если Вы JavaScript для client-side используете, а Java — для backend, то это всё-таки 1 поезд, просто с двумя вагонами, можно ещё 3-й вагон SQL прицепить )
А вот если и то и то для backend, то интересно было бы послушать каким образом Вы это совмещаете.

Маслобойка

Ok, я его не изучал, поэтому на достоверность не претендую :)

Маслобойка

До Rust и Go уже был написан D. Если с C++ понятно, что ломать обратную совместимость никто не хочет, то вот почему не захотели вкладываться в D непонятно…