Зачем Вы спорите с очевидными вещами? То, что внутреннее состояние 1 равно 1, видно без каких-либо сообщений. То же самое с null, true и false.
Вообще идея и реализация — это всегда разные вещи. Реализация может демонстрировать идею, но не ограничивать. Да и есть цепляться за эти 6 пунктов, то они не выполняются вообще нигде, даже в Smalltalk:
Apparently, «everything isn't an object» afterall — some things are primitives.
Помогает тем, что с Integer-объектом я общаюсь ровно так же, как с любым другим объектом в системе — через сообщения.
Так а Integer-объект то зачем? Был у нас обычный всем понятный числовой литерал, а стал «объект», у которого внутреннее состояние выставлено наружу. Почему никто не пишет 1.getValue()? Почему возникают проблемы с boxing/unboxing? Потому что нет тут никакого единообразия. Потому что число — это число, а не объект. Вот и получается, что в теории хотели упростить, а на практике только усложнили.
ваше определение объектности не совпадает с Кэйевским — факт: убран первый пункт.
Насколько я понимаю, Вы ссылаетесь на Early History Of Smalltalk. Но там нигде не написано, что список идей для реализации интерпретаторов Smalltalk, является определением ООП. Не всё, что обязательно для Smalltalk, является обязательным для ООП. Иначе мы подменяем общую идею конкретной реализацией.
Почему не честно? На уровне архитектуры всё и остаётся объектами, а как там эти объекты внутри реализованы уже другой вопрос. Контрпродуктивным этот тезис стал, когда спустился на уровень примитивных типов и простых структур данных. Там он никогда простоте не служил.
Как Вам помогает в проектировании системы то, что 1 — это не 1, а экземпляр класса Integer с внутренним состоянием равным 1, к которому никто по идее не должен иметь доступ напрямую?
Да, всё верно. Предельно позднее связывание в действии :-)
Если Вы хотите, чтобы процесс не падал в таких ситуациях, можно определить catch-all обработчики сообщений, которые просто проигнорируют «левые» сообщения. Но с учётом того, что подобное может произойти только из-за ошибки/опечатки в коде, лучше пусть падает.
Я думаю, это в-первую очередь связано с тем, что Elixir поддерживает опциональные параметры.
Ну и как по мне, это логичнее, когда, допустим, функции для работы со списками принимают список в качестве первого аргумента, а не последнего.
Заметок о дизайне на эту тему я не встречал, но можно почитать в дискуссии в google-группе, например эту.
Вы неправильно поняли посыл статьи. Не надо всё делать объектами… Это ошибка проектирования. На нижнем уровне объекты только мешают, там гораздо удобнее работать с примитивными типами данных и структурами. В мейнстрим реализациях ООП начинается с идеи переноса объектов реального в программирование, а в итоге сводится к имитации, что строка общается с числами и т.п.
По поводу состояния, в Elixir оно надёжно спрятано в процессе, никакой рефлексией и уж тем более прямыми присваиваниями до него не достать. Только отправкой сообщений можно опосредованно влиять на состояние. Ну и как в любом функциональном языке все данные неизменяемы. Т.о. ситуация, когда вы получили часть состояния объекта по ссылке, передали в другой метод, а он взял его и изменил, тоже невозможны by design.
Процесс с этим 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». Поэтому чуть что не так — процесс падает и перезапускается с чистого листа одним из супервизоров.
Вы почему-то исходите из того, что текущий уровень языков программирования очень низок. Но по факту нам и правда надо хорошенько осмыслить то, что придумали за предыдущие 60 лет. На тех компьютерах, которые у нас сейчас есть, крайне сложно придумать что-то новое в области программирования. Более того CPU уже упёрлись в физические пределы производства. И даже на случай, если дальнейший рост пойдёт через увеличение кол-ва ядер на порядки, уже всё придумано.
застрявшими в цифровой эпохе электрических компьютеров на 1000 лет.
В том то и дело, что придумывать новые компьютеры в компетенции программистов не входит, это будут делать физики.
А если Вы реально хотите придумать что-то новое в плане программирования, смотрите в сторону появляющихся вариантов, типа квантовых компьютеров. Там прогресс будет, но это уже совсем другая история. Не имеющая отношения к написанию 100500 примерно одинаковых фреймворков/библиотек для одной и той же задачи.
Ну, если верить indeed.com, то разница на уровне Senior всего 6-7% в пользу Node.js. Т.е. по факту всё будет зависеть от выбора компании и проекта, а не от выбора между этими двумя вариантами.
Так речь то не о том, чтобы запрещать что-то придумывать, речь о том, что за предыдущие, допустим, 10 лет практически ничего нового не придумали. На первый взгляд кажется, что это бред, вон же каждую неделю что-то новое появляется. Но если задуматься, то по сути то реально ничего нового, просто небольшие плюшки, аля синтаксический сахар.
Вообще идея и реализация — это всегда разные вещи. Реализация может демонстрировать идею, но не ограничивать. Да и есть цепляться за эти 6 пунктов, то они не выполняются вообще нигде, даже в Smalltalk:
© Heart Of Smalltalk
Ничто не ново под Луною…
Насколько я понимаю, Вы ссылаетесь на Early History Of Smalltalk. Но там нигде не написано, что список идей для реализации интерпретаторов Smalltalk, является определением ООП. Не всё, что обязательно для Smalltalk, является обязательным для ООП. Иначе мы подменяем общую идею конкретной реализацией.
Как Вам помогает в проектировании системы то, что 1 — это не 1, а экземпляр класса Integer с внутренним состоянием равным 1, к которому никто по идее не должен иметь доступ напрямую?
Если Вы хотите, чтобы процесс не падал в таких ситуациях, можно определить catch-all обработчики сообщений, которые просто проигнорируют «левые» сообщения. Но с учётом того, что подобное может произойти только из-за ошибки/опечатки в коде, лучше пусть падает.
Ну и как по мне, это логичнее, когда, допустим, функции для работы со списками принимают список в качестве первого аргумента, а не последнего.
Заметок о дизайне на эту тему я не встречал, но можно почитать в дискуссии в google-группе, например эту.
По поводу состояния, в Elixir оно надёжно спрятано в процессе, никакой рефлексией и уж тем более прямыми присваиваниями до него не достать. Только отправкой сообщений можно опосредованно влиять на состояние. Ну и как в любом функциональном языке все данные неизменяемы. Т.о. ситуация, когда вы получили часть состояния объекта по ссылке, передали в другой метод, а он взял его и изменил, тоже невозможны by design.
(FunctionClauseError) no function clause matching in Airplane.handle_cast/2
airplane.ex:38: Airplane.handle_cast({:add, "Aimee", 2}, %{})
Вообще Erlang и Elixir стимулирует разработку по принципу «Let it crash». Поэтому чуть что не так — процесс падает и перезапускается с чистого листа одним из супервизоров.
Полный текст интереснее.
В том то и дело, что придумывать новые компьютеры в компетенции программистов не входит, это будут делать физики.
А если Вы реально хотите придумать что-то новое в плане программирования, смотрите в сторону появляющихся вариантов, типа квантовых компьютеров. Там прогресс будет, но это уже совсем другая история. Не имеющая отношения к написанию 100500 примерно одинаковых фреймворков/библиотек для одной и той же задачи.