public int max(int a, int b) {
return new If(
new GreaterThan(a, b),
a, b
);
}
Такие примеры кода просто показывают полное непонимание сути ООП и для чего вообще нужна эта парадигма. Недавно обсуждали ООП вдоль и поперёк, начиная от самых истоков и заканчивая практической пользой в настоящем, не охота повторяться…
Вот тут дело было.
Когда нужен максимальный охват, проще взять какой-нибудь jQuery 1.9.1 с CDN, и он с большой вероятностью в кеше браузера окажется даже при первом запросе.
Просто REPL'ом сейчас никого уже не удивишь. Мощь Lisp в том, что это метаязык с неограниченными возможностями (ну или ограниченными возможностями виртуальной машины, как в случае с Clojure). За счёт этого можно более изящно выражать свои намерения в коде. Проблема в том, что при переходе с мейнстрим-языков приходится долго въезжать в тему. И поначалу код получается похож на то, что было в привычном ЯП, только со странным синтаксисом. Примеры такого кода обычно отталкивают читателей от идеи изучить Lisp :-)
Вы говорите: эта сложность ей присуща по природе, мы с ней ничего сделать не можем кроме как отразить в неизменном в виде в наших инструментах и дальше мучится с ней всегда.
Не совсем. Мы считаем, что A есть A, B есть B, C есть C, и что это вообще не сложность, наоборот просто до тривиальности.
Сложность — это пытаться интерпретировать A, B, C как A.
И именно необходимость постоянно сталкиваться с неизбежными противоречиями умозрительной модели и реальности мы считаем мучением.
Тут как и со всеми униформными концепциями возникает путаница в понятиях. Обычно под списком понимают структуру данных, а тут это способ записи программы, в котором первым элементом списка всегда идёт имя функции.
Поэтому если нужен список, как структура данных, а не как «управляющая конструкция», то вызываем функцию list, ну или какой-нибудь генератор списков. Это и есть униформность, мать её xD
Давайте пример с пояснением, почему нет ничего общего.
Да у вас с 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)
А вопрос — в простоте исходных положений. Вам это не интересно, а я считаю, что именно оттуда «растут ноги» у избыточной сложности.
Это всё очень субъективно… Краткость исходных положений не означает простоту. На мой взгляд «всё есть объект» — это очень сложное исходное положение, как в реализации, так и в следовании ему и главное — не отражающее реальное положение дел ни концептуально, ни технически. Т.е. если пытаться следовать этому тезису абсолютно, то вся система будет построена вокруг этой идеи, а не с её помощью.
Вот тут дело было.
Подбор цитат к статье вообще жжёт… из всех процитированных, по-моему, только 1 человек использует PHP и это Расмус :-)
Сложность — это пытаться интерпретировать A, B, C как A.
И именно необходимость постоянно сталкиваться с неизбежными противоречиями умозрительной модели и реальности мы считаем мучением.
Поэтому если нужен список, как структура данных, а не как «управляющая конструкция», то вызываем функцию list, ну или какой-нибудь генератор списков. Это и есть униформность, мать её xD
Всё это приводит к созданию довольно монструозных объектных обёрток над простыми сущностями. Все мы видели эти вырожденные объекты для представления лямбда-функции, DTO и т.д.
Вот и получается, что система в которой есть объекты, данные и
функции выглядит гораздо изящнее и реалистичнее, чем система, в которой есть только объекты.
С чего вдруг это должно быть единое взаимодействие? Даже в физике пока его не нашли, аж целых 4 разных до сих пор :-)
Определение функции — это вызов функции define.
А вот любой вызов функции — это уже список )))
Тут по факту всё действительно униформно, т.к. для большинства интерпретаторов/компиляторов (вне зависимости от ЯП) программа — это AST, а тут мы упрощаем работу парсеру, по сути сразу записывая всё в виде AST.
Также очевидно, что по мощности этот подход мощнее любого другого варианта высокоуровневого языка, т.к. в других концепциях мы можем получить только подмножество возможных AST, разрешенное языком, а тут полное множество.
Всё равно подгоним их под общность?
Там есть синтаксический сахар, позволяющий записать
но это эквивалент
Просто список, не являющийся вызовом функции, записать нельзя.
Понятно, что Smalltalk в этом не виноват, но сейчас = для сравнения редко, где используется.
А абстракция действительно протекает… SmallInteger и LargePositiveInteger ведут себя совсем по-разному и при этом между ними есть неявное приведение типов.
А по поводу доступности для новичков я бы ещё Вам попенял за название "->>keys", которое для новичка выглядит как-будто вариант использования "->>", лучше было бы банальное «send-key» или «press-key»
Хотя я нашёл всё-таки метод сравнения по значению:
Это лишь для большей понятности. По факту, любой список — это вызов функции, т.е. это не разные понятия, а одно и то же разными словами. Даже «списки-литералы» записываются как вызов функции list:
Это всё очень субъективно… Краткость исходных положений не означает простоту. На мой взгляд «всё есть объект» — это очень сложное исходное положение, как в реализации, так и в следовании ему и главное — не отражающее реальное положение дел ни концептуально, ни технически. Т.е. если пытаться следовать этому тезису абсолютно, то вся система будет построена вокруг этой идеи, а не с её помощью.