Это во многом миф, удобство чтения кода в большей мере зависит от автора кода, чем от ЯП. При этом чем выше уровень автора кода, тем бессмысленные ограничения выразительности.
Да про многие так нельзя сказать… Дальше всех к дзен продвинулись Lisp и SQL.
Кроме них, на мой взгляд, хорошо сбалансированы Ruby, Elixir, Smalltalk, F#… Да даже C# тут Java явно обходит, начиная с 3-й версии.
Это не проблемы. Это та самая неограниченная выразительность, позволяющая хотя бы теоретически писать код, который идеально отражает намерения программиста.
Ну а если код получился трудночитаемым даже на нём, то это уже «разруха в головах» (с).
Многим программистам нравится, когда выразительность искусственно ограничена, это помогает им структурировать свои мысли. Дальше всего по этому пути пошёл Go.
Это уже есть, посмотрите на Erlang или Elixir, там это процессами называется, но по сути это и есть настоящие объекты.
Я уверен, что через 20 лет все актуальные ЯП (кроме самых low-level) будут придерживаться аналогичных подходов, потому что это позволит эффективно использовать все 1024 ядра (ну или сколько тысяч их там будет к тому времени) и управлять сотнями компонентов умного дома из одной программы.
Улучшат языки, которые перестанут тянуть идею «всё есть объект» куда не надо… Объектами останутся только те части программы, которые действительно обладают своим поведением и полностью изолированы от остальной программы. Между собой они будут общаться исключительно отправкой сообщений. А само поведение объекта будет реализовываться декларативно (в функциональном и/или логическом стиле).
Не думаю, что можно выделить что-то одно. Весь язык заслоняет собой программу и чтобы увидеть смысл написанного приходится продираться через бесконечные нагромождения синтаксиса, неуместных абстракций и т.д.
Конечно, к этому можно привыкнуть и даже начать считать удобным, если достаточно долго себя в этом убеждать… только какой в этом смысл?
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, разрешенное языком, а тут полное множество.
Кроме них, на мой взгляд, хорошо сбалансированы Ruby, Elixir, Smalltalk, F#… Да даже C# тут Java явно обходит, начиная с 3-й версии.
Ну а если код получился трудночитаемым даже на нём, то это уже «разруха в головах» (с).
Многим программистам нравится, когда выразительность искусственно ограничена, это помогает им структурировать свои мысли. Дальше всего по этому пути пошёл Go.
Я уверен, что через 20 лет все актуальные ЯП (кроме самых low-level) будут придерживаться аналогичных подходов, потому что это позволит эффективно использовать все 1024 ядра (ну или сколько тысяч их там будет к тому времени) и управлять сотнями компонентов умного дома из одной программы.
Конечно, к этому можно привыкнуть и даже начать считать удобным, если достаточно долго себя в этом убеждать… только какой в этом смысл?
“If Java had true garbage collection, most programs would delete themselves upon execution.”
— Robert Sewell
Вот тут дело было.
Подбор цитат к статье вообще жжёт… из всех процитированных, по-моему, только 1 человек использует PHP и это Расмус :-)
Сложность — это пытаться интерпретировать A, B, C как A.
И именно необходимость постоянно сталкиваться с неизбежными противоречиями умозрительной модели и реальности мы считаем мучением.
Поэтому если нужен список, как структура данных, а не как «управляющая конструкция», то вызываем функцию list, ну или какой-нибудь генератор списков. Это и есть униформность, мать её xD
Всё это приводит к созданию довольно монструозных объектных обёрток над простыми сущностями. Все мы видели эти вырожденные объекты для представления лямбда-функции, DTO и т.д.
Вот и получается, что система в которой есть объекты, данные и
функции выглядит гораздо изящнее и реалистичнее, чем система, в которой есть только объекты.
С чего вдруг это должно быть единое взаимодействие? Даже в физике пока его не нашли, аж целых 4 разных до сих пор :-)
Определение функции — это вызов функции define.
А вот любой вызов функции — это уже список )))
Тут по факту всё действительно униформно, т.к. для большинства интерпретаторов/компиляторов (вне зависимости от ЯП) программа — это AST, а тут мы упрощаем работу парсеру, по сути сразу записывая всё в виде AST.
Также очевидно, что по мощности этот подход мощнее любого другого варианта высокоуровневого языка, т.к. в других концепциях мы можем получить только подмножество возможных AST, разрешенное языком, а тут полное множество.
Всё равно подгоним их под общность?