Давайте пример с пояснением, почему нет ничего общего.
Да у вас с lair уже была дискуссия на тему может ли сообщение быть объектом, не хочется повторяться… Но по сути у них как раз нет ничего общего. Также как у любых данных нет ничего общего с объектами, так же как у функций нет ничего общего с объектами.
Всё это приводит к созданию довольно монструозных объектных обёрток над простыми сущностями. Все мы видели эти вырожденные объекты для представления лямбда-функции, DTO и т.д.
Вот и получается, что система в которой есть объекты, данные и
функции выглядит гораздо изящнее и реалистичнее, чем система, в которой есть только объекты.
Необходимость этого самого взаимодействия — и есть то самое общее.
С чего вдруг это должно быть единое взаимодействие? Даже в физике пока его не нашли, аж целых 4 разных до сих пор :-)
Нет, (list 1 2 3) — это вызов функции list.
Определение функции — это вызов функции define.
А вот любой вызов функции — это уже список )))
Тут по факту всё действительно униформно, т.к. для большинства интерпретаторов/компиляторов (вне зависимости от ЯП) программа — это AST, а тут мы упрощаем работу парсеру, по сути сразу записывая всё в виде AST.
Также очевидно, что по мощности этот подход мощнее любого другого варианта высокоуровневого языка, т.к. в других концепциях мы можем получить только подмножество возможных AST, разрешенное языком, а тут полное множество.
Само утверждение «все сущности в системе являются A» делает систему простой
Нет. Простой она станет, если все сущности действительно являются А. Но по факту мы имеем систему «Давайте будем считать, что все сущности являются А».
Я был не в курсе как это в Smalltalk реализовано )))
Понятно, что Smalltalk в этом не виноват, но сейчас = для сравнения редко, где используется.
А абстракция действительно протекает… SmallInteger и LargePositiveInteger ведут себя совсем по-разному и при этом между ними есть неявное приведение типов.
Да не, дико, что разные алгоритмы сравнения для однотипных типов используются, на мой взгляд LargePositiveInteger тоже должен быть value-type. Впрочем, одинарное = частично решает эту несостыковку.
Спасибо, так лучше, но всё ещё осталось управление потоком выполнения через исключения.
А по поводу доступности для новичков я бы ещё Вам попенял за название "->>keys", которое для новичка выглядит как-будто вариант использования "->>", лучше было бы банальное «send-key» или «press-key»
Бага — неожиданное (для разработчика) поведение системы. Нет?
Необязательно, большинство багов встречаются в бизнес-логике или в логике самого программиста (алгоритмов, которые он реализует). В общем, только часть багов связана с неожиданным поведением языка и его стандартной библиотеки.
Но вот списки и функции — они «униформность» ведь не нарушают? Я так понимаю, для вас несколько «параллельных» терминов/понятий в рамках одной концепции — это ОК?
Это лишь для большей понятности. По факту, любой список — это вызов функции, т.е. это не разные понятия, а одно и то же разными словами. Даже «списки-литералы» записываются как вызов функции list:
(list 1 2 3)
А вопрос — в простоте исходных положений. Вам это не интересно, а я считаю, что именно оттуда «растут ноги» у избыточной сложности.
Это всё очень субъективно… Краткость исходных положений не означает простоту. На мой взгляд «всё есть объект» — это очень сложное исходное положение, как в реализации, так и в следовании ему и главное — не отражающее реальное положение дел ни концептуально, ни технически. Т.е. если пытаться следовать этому тезису абсолютно, то вся система будет построена вокруг этой идеи, а не с её помощью.
Все существующие символы тоже никто не хранит, только те, которые в программе используются. Но это не суть.
Я правильно понял, что привычные «операторы» сравнения никогда не сравнивают по значению в Smalltalk? А иллюзия сравнения по значению возникает только в случаях, когда по факту имеется один объект для обеих сторон сравнения.
гарантирует второе (отсутствие неожиданного поведения)? В программах на Scheme не бывает багов?
А как отсутствие неожиданного поведения связано с отсутствием багов? С неожиданным поведением только часть багов связана, причём чаще меньшая, т.к. программисты привыкают к «особенностям» используемого языка.
Функция — это тоже список? Да, она задается списком, но это же объект другого рода?
Определение функции — это список с вызовом функции define. Да, разумеется, есть с десяток функций, которые реализуются внутри интерпретатора, но для программиста они ведут они себя точно так же, как и все остальные функции.
тут тоже есть примитивные конструкции, которые не совсем соответствуют исходной концепции?
да вроде нет, можно пример?
Ваша позиция понятна, но всё-таки заметно что Вы ей следуете, исходя из того, что неравнодушны к Smalltalk. Это создаёт некоторую предвзятость.
Концепция, в которую вовлечено два компонента (объект и сообщение) скорее всего проще, чем та, в которой присутствует большее количество.
Вот это не факт. Простота применения ЯП на практике с количеством компонентов в концепции слабо коррелирует.
Есть, например, концепция с нулём компонент — «всё есть ничто» и даже соответствующий ЯП. А вот решить на нём практическую задачу совсем не просто :-D
по моим ощущениям ООП не менее мощная, чем ФП, так как в объектах можно смоделировать любую концепцию ФП
OMFG, зачем? Эти парадигмы совершенно ортогональны. Моя позиция в том, что они должны применяться комплементарно на разных уровнях абстракции. ООП можно применять и в Erlang/Elixir и в диалектах Lisp, но там, где оно реально имеет смысл и пользу. А протаскивание идей ООП через все уровни абстракции вплоть до самых примитивных типов ведёт к излишнему и неоправданному усложнению системы.
Собственно изначальная статья посвящена тому, что «Здравствуй ФП» не обозначает «Прощай ООП», оно означает «Здравствуй нормальное ООП, теперь ты будешь работать для меня, а не наоборот»
Просто в одном случае (с дробями) в ответ на сообщения возвращается один и тот же объект (что логично: число 1/5 как объект существует в единственном экземпляре)
Было бы логично, только в том то и фишка, что возвращаются разные.
Обратите внимание, что 1/5 не равна 1/5 в Smalltalk, несмотря на то, что в данном случае это рациональные дроби, а не десятичные.
Нет, конечно. Какие-то WAT есть практически в любом ЯП, но больше всего их от сайд-эффектов и от неявного приведения типов.
ключевые слова: «позднее связывание»
Так позднее связывание сейчас очень во многих ЯП есть. И возможность «обработать сообщение, для которого у объекта метода нет вообще». Точнее метод то есть, он просто работает как fallback, в Ruby он method_missing называется. А в целом это обычный dynamic dispatch.
Я ожидал от Smalltalk гораздо большего в этом плане…
Всё это приводит к созданию довольно монструозных объектных обёрток над простыми сущностями. Все мы видели эти вырожденные объекты для представления лямбда-функции, DTO и т.д.
Вот и получается, что система в которой есть объекты, данные и
функции выглядит гораздо изящнее и реалистичнее, чем система, в которой есть только объекты.
С чего вдруг это должно быть единое взаимодействие? Даже в физике пока его не нашли, аж целых 4 разных до сих пор :-)
Определение функции — это вызов функции define.
А вот любой вызов функции — это уже список )))
Тут по факту всё действительно униформно, т.к. для большинства интерпретаторов/компиляторов (вне зависимости от ЯП) программа — это AST, а тут мы упрощаем работу парсеру, по сути сразу записывая всё в виде AST.
Также очевидно, что по мощности этот подход мощнее любого другого варианта высокоуровневого языка, т.к. в других концепциях мы можем получить только подмножество возможных AST, разрешенное языком, а тут полное множество.
Всё равно подгоним их под общность?
Там есть синтаксический сахар, позволяющий записать
но это эквивалент
Просто список, не являющийся вызовом функции, записать нельзя.
Понятно, что Smalltalk в этом не виноват, но сейчас = для сравнения редко, где используется.
А абстракция действительно протекает… SmallInteger и LargePositiveInteger ведут себя совсем по-разному и при этом между ними есть неявное приведение типов.
А по поводу доступности для новичков я бы ещё Вам попенял за название "->>keys", которое для новичка выглядит как-будто вариант использования "->>", лучше было бы банальное «send-key» или «press-key»
Хотя я нашёл всё-таки метод сравнения по значению:
Это лишь для большей понятности. По факту, любой список — это вызов функции, т.е. это не разные понятия, а одно и то же разными словами. Даже «списки-литералы» записываются как вызов функции list:
Это всё очень субъективно… Краткость исходных положений не означает простоту. На мой взгляд «всё есть объект» — это очень сложное исходное положение, как в реализации, так и в следовании ему и главное — не отражающее реальное положение дел ни концептуально, ни технически. Т.е. если пытаться следовать этому тезису абсолютно, то вся система будет построена вокруг этой идеи, а не с её помощью.
кажется, я совсем запутался с == в Smalltalk :facepalm:
Я правильно понял, что привычные «операторы» сравнения никогда не сравнивают по значению в Smalltalk? А иллюзия сравнения по значению возникает только в случаях, когда по факту имеется один объект для обеих сторон сравнения.
В остальном согласен, действительно весьма прогрессивная платформа разработки.
Определение функции — это список с вызовом функции define. Да, разумеется, есть с десяток функций, которые реализуются внутри интерпретатора, но для программиста они ведут они себя точно так же, как и все остальные функции.
да вроде нет, можно пример?
Ваша позиция понятна, но всё-таки заметно что Вы ей следуете, исходя из того, что неравнодушны к Smalltalk. Это создаёт некоторую предвзятость.
Вот это не факт. Простота применения ЯП на практике с количеством компонентов в концепции слабо коррелирует.
Есть, например, концепция с нулём компонент — «всё есть ничто» и даже соответствующий ЯП. А вот решить на нём практическую задачу совсем не просто :-D
OMFG, зачем? Эти парадигмы совершенно ортогональны. Моя позиция в том, что они должны применяться комплементарно на разных уровнях абстракции. ООП можно применять и в Erlang/Elixir и в диалектах Lisp, но там, где оно реально имеет смысл и пользу. А протаскивание идей ООП через все уровни абстракции вплоть до самых примитивных типов ведёт к излишнему и неоправданному усложнению системы.
Собственно изначальная статья посвящена тому, что «Здравствуй ФП» не обозначает «Прощай ООП», оно означает «Здравствуй нормальное ООП, теперь ты будешь работать для меня, а не наоборот»
Обратите внимание, что 1/5 не равна 1/5 в Smalltalk, несмотря на то, что в данном случае это рациональные дроби, а не десятичные.
Так позднее связывание сейчас очень во многих ЯП есть. И возможность «обработать сообщение, для которого у объекта метода нет вообще». Точнее метод то есть, он просто работает как fallback, в Ruby он method_missing называется. А в целом это обычный dynamic dispatch.
Я ожидал от Smalltalk гораздо большего в этом плане…