> В lisp как в язык кроме car и cdr вообще мало что входит :).
Так было 50 лет назад.
> CLOS и прочие радости жизни — это уже как бы «библиотеки», нэ?
Нет.
> Которые будут разные в common lisp, emacs lisp, autocad lisp, iron bank что-то-там
> lisp и прочих
Разные лиспы очень сильно между собой отличаются, схожесть между ними в основном за счёт «скобочек», да старых унаследованных команда. Они похожи между собой не больше, чем C/C++/Java/C#.
Отвечу только на это (не хочу сильно увлекаться дискуссией) — нет. То, что в CL делается легко и изящно в С++ приходится решать через боль и мучения. Вообще, аргументация про то, что «хватает», она ущербна по своей сути. Хватает для всех зада и ассемблера, ведь все языки тьюринг-полные.
> Большинство практических применений мультиметодов
> в C++ решаются шаблонам
Нет. Нормальной реализации мультиметодов для С++ даже Александреску не смог сделать.
> Если для контроля ошибок и отладки, то как бы в C++ есть исключения.
Рестарты намного круче исключений.
>> динамических переменных
> Если очень надо, то есть QVariant / boost::variant
Это вообще не из той области.
> Но практика показывает, что для большинства прикладных
> задач это не так уж и важно :(.
Я больше 7 лет писал C++ и около 3 на Python, плюс были ещё разные другие языки в меньших масштабах. Сейчас я пишу только на двух — JavaScript и Common Lisp. И по моим ощущения преимущества CL совершенно не оспоримые.
Во-первых, то его приложение было гвоздями прибито к CLisp, медленной реализации.
Во-вторых, оно использовало «продолжения», т.е. просто не было масштабируемым.
Естественно, когда встал вопрос о другой нагрузке, то приложение надо было переписывать фактически полностью. На чём переписывать? Поскольку Грэма уже не было, то язык выбирали заново. Выбрали что знали лучше и что знали, что будет работать.
Ну, конечно, Грэм подаёт эту историю несколько по другому.
Я когда писал lisper.ru, то дизайнера у меня не было и я сначала делал именно на встроенном языке. По результатам этого опыта и я пришел к шаблонам, как к оптимальному решению )
У генерации контента с помощью встроенного eDSL фактически вообще нет никаких преимущества. Я только для демонстрационных приложений объёмом в 10 строк использую cl-who.
> больше нескольких часов.
Я вас умаляю, вот код, который считает колличество разных тэгов на этой странице:
(html:with-parse-html (doc #U"http://habrahabr.ru/blogs/lisp/114981/") (let ((map (make-hash-table :test 'equal))) (iter (for node in-xpath-result "//*" on doc) (incf (gethash (xtree:local-name node) map 0))) map))Так было 50 лет назад.
> CLOS и прочие радости жизни — это уже как бы «библиотеки», нэ?
Нет.
> Которые будут разные в common lisp, emacs lisp, autocad lisp, iron bank что-то-там
> lisp и прочих
Разные лиспы очень сильно между собой отличаются, схожесть между ними в основном за счёт «скобочек», да старых унаследованных команда. Они похожи между собой не больше, чем C/C++/Java/C#.
Ну что-то вы совсем просто предложили ))
Нет, спасибо, я такой ерундой не занимаюсь. Если что, то мой открытый код на CL здесь: github.com/archimag
Если бы не работал, то вообще бы ничего не говорил на эту тему.
Отвечу только на это (не хочу сильно увлекаться дискуссией) — нет. То, что в CL делается легко и изящно в С++ приходится решать через боль и мучения. Вообще, аргументация про то, что «хватает», она ущербна по своей сути. Хватает для всех зада и ассемблера, ведь все языки тьюринг-полные.
На эту тему могу порекомендовать вот эту статью: www.nestor.minsk.by/sr/2003/07/30710.html, там где про парадокса Блаба.
> Большинство практических применений мультиметодов
> в C++ решаются шаблонам
Нет. Нормальной реализации мультиметодов для С++ даже Александреску не смог сделать.
> Если для контроля ошибок и отладки, то как бы в C++ есть исключения.
Рестарты намного круче исключений.
>> динамических переменных
> Если очень надо, то есть QVariant / boost::variant
Это вообще не из той области.
> Но практика показывает, что для большинства прикладных
> задач это не так уж и важно :(.
Я больше 7 лет писал C++ и около 3 на Python, плюс были ещё разные другие языки в меньших масштабах. Сейчас я пишу только на двух — JavaScript и Common Lisp. И по моим ощущения преимущества CL совершенно не оспоримые.
> DSL писать так же удобно как на LISP
А при чём тут DSL?
> Если очень надо, то есть QVariant / boost::variant
> Но практика показывает, что для большинства прикладных
> задач это не так уж и важно :(.
Нет, макросы всего лишь один из элементов CL. Это делают жизнь лучше. Но даже без них CL был бы лучше больше современных языков.
> знанием других языков программирования
А у вас кажется не хватает знаний о CL ))
> динственное отличие современного C++ от Lisp в плане встроенных в язык
> функций — это отсутствие доступа к AST.
Ну что вы такое говорите. Как насчёт мультиметодов, рестартов, динамических переменных, MOP? Поверьте, разница огромна.
Ну да пустой разговор. Вряд ли кто-либо из программистов на CL согласится с тем, что Clojure хоть что-нибудь исправляет.
О чем речь?
Во-первых, то его приложение было гвоздями прибито к CLisp, медленной реализации.
Во-вторых, оно использовало «продолжения», т.е. просто не было масштабируемым.
Естественно, когда встал вопрос о другой нагрузке, то приложение надо было переписывать фактически полностью. На чём переписывать? Поскольку Грэма уже не было, то язык выбирали заново. Выбрали что знали лучше и что знали, что будет работать.
Ну, конечно, Грэм подаёт эту историю несколько по другому.
У генерации контента с помощью встроенного eDSL фактически вообще нет никаких преимущества. Я только для демонстрационных приложений объёмом в 10 строк использую cl-who.