Так ты не понял всей тонкости вброса? «V.S.» это «ветеринарный врач». Т.е. автор предлагает более чётко выяснить какой из представленных языков является представителем интеллигенции, а какой относится к быдлу (к коровам).
Т.е. автор предлагает более чётко выяснить какой из представленных языков является представителем интеллигенции, а какой относится к быдлу (к коровам).
> из-за чего читателю начинает казаться, что CL отличается от остальных «традиционных» языков только обилием скобок.
Imho, в этом был хитрый план. Вместо обычной подачи информации о лиспе в стиле «вот вам car,cons,cdr и defmacro, а теперь давайте с этой фигнёй реализуем искуственный интеллект» людей заманивают обыденностью лиспа, показывают что он совсем как привычные языки, только с CLOS, перезапусками и прочими батарейками. А вот когда человек убедится, что программировать на КЛ совсем не страшно, тогда уже и можно бить по его голове макро-молотом.
Схема однозначно лучше. И макросы там нормальные, а не как в коммон лиспе. В CL макросы вообще хз когда раскрываются, и еще вся это по*ботня с gensym... Прямо как перекладывание битиков с сишке: вместо того, чтоб код писать, проггер следит чтоб оверфлова у него не было.
loop есть на макросах, tiny-clos/soop вместо CLOS и норм (которые, кстати, в кампайл тайме раскрываются). Есть нормальные реализации для JVM и native, для CLR тоже что-то было.
Common Lisp - инновационный язык, намного определивший своё время. Впечатляющие заложенные возможности, мощный фундамент, высокоинтеллектуальное сообщество делают его непревзойдённым инструментом для решения широкого круга задач. Выбор CL в качестве основного языка обеспечивает огромное конкурентное преимущество и быстрый возврат вложенных средств. А сочетание мощи, гибкости и эффективности послужат мощным источником инноваций в любой предметной области.
Академический ским может использоваться для обучения первокурсников в учебных заведениях, претендующих на элитарность, но профессионалы отрасли выбирают CL как наиболее удобный и практичный инструмент.
Коммон слова от пользователя Общего Лиспа, ничего больше.
(R)SR может быть и был академической игрушкой, но не R5RS. Конкретные предъявы я привел, а в ответ получил только стандартный бред КЛ-сектанта (которые еще к тому же против макросов и продолжений, бугага. Не зря кл выбрал)
Вы совершенно не умете вести дискуссию. Посмотрите какие аргументы за CL привёл я, и какие за ским привели вы:
За Common Lisp:
* Инновации (залог процветания вашего бизнеса)
* Мощные возможности (сможете решить любую проблему)
* Высоколобое сообществу (все ваши сотрудники будут очень умными)
* Конкурентные преимущества (конкуренты будут повержены)
* Лучший выбор профессионалов (что подтверждает выше сказанное)
За Scheme
* Какой-то R5RS (который даже студентам не преподают)
* недо-макросы
* недо-CLOS
* недо-loop
Понимаете разницу? Ваш Scheme какой-то детсад, не способный бросить даже лёгкую тень на величие CL. Возможно его стоит использовать для обучения программированию детей младшего школьного возраста, но не более того.
> Понимаете разницу? Ваш Scheme какой-то детсад, не способный бросить даже лёгкую тень на величие CL. Возможно его стоит использовать для обучения программированию детей младшего школьного возраста, но не более того.
Scheme и Common Lisp это разные сорта одного и того же. И там и там синтаксис вызова функций и подстановки макросов идентичен, что многократно усложняет поддержку кода и вынуждает работать в стиле «работает - не трогай». Нет единого стандарта по подключению модулей, библиотек и прочего стороннего кода. Каждая реализация использует собственный велонабор. Переносимости кода между различными реализациями никакой.
Вот собственно основное, что надо знать про лиспы :)
Вроде нет. Правда это не смоллток быстрее, а Objective C. Про смоллток что-то в бложике было, тоже примерно 20% от Objective C с LLVM компилятором и speculative inlining. А интерпретатор смоллтока быстрее конпелятора оказался.
А R(6)RS? А SRFI? В последнем есть вещи которых до сих пор нет в библиотеках CL общего назначения - момент который ещё нужно восполнить, очевидно.
недо-макросы
Я бы сказал, что они там просто другие, в чём-то даже более «крутые».
недо-CLOS
Ну и пусть :) Настоящие схемеры вольны выбирать ООП фреймворк под задачу - благ их у них несколько штук. Да и вообще, «замыкания и состояния» заруливают любое ООП, если верить SICP (но сливают в эффективности).
недо-loop
Вот и пусть :) В самом CL можно без loop обойтись - есть map*/filter/reduce, let+dolist, the ultimate collect macro, iterate в конце концов.
изначально неполиткоерректное сравнение. это как «чем негр лучше/хуже белого?». оба-два хороши, все зависит от уровня владения языка и прикладной части.
Ну и пусть :) Настоящие схемеры вольны выбирать ООП фреймворк под задачу - благ их у них несколько штук
Ты сам-то пробовал эти штуки? Сплошные недоделки и произведения в стиле proof of concept. Даже в этом вашем tiny-clos опечатка, в результате которой нативные типы не считаются за классы, да и вообще без адаптации под конкретную реализацию не работает. Да и вообще, в большинстве реализаций запилены собственные, ни с чем больше не совместимые ООП фреймворки.
Вобщем-то, в мире scheme стандарт скоро перестанет играть какую-то особую роль и фактическим стандартом станет одна из реализаций (ну ты понел).
>Тех, кто решит изучать это ваш хвалёный лисп, и столкнётся с необходимостью выбора IDE. Нормальной бесплатной IDE, как уже говорил, нет, а ваш хвалёный емакс, который в каждую дыру суют, обладает удобностью управления, как у угольного паровоза.
Отлично сказал! Станиславский стучит о крышку гроба и орет: «Верю!». :)
Я помимо SICP, 6-ого рапорта и сам знаешь какой реализации ничего там не пробовал (разве что по мелочи), просто часто замечал как схемеры хвастаются наличием нескольких ООП реализаций (это было что-то вроде кивка в сторону).
Даже в этом вашем tiny-clos опечатка, в результате которой нативные типы не считаются за классы, да и вообще без адаптации под конкретную реализацию не работает.
Ничего себе «опечатка». Разве в CL не так же? В CL эти самые «опечатки» по отображению типов в классы занимают несколько тысяч строк кода, если что, и при этом полностью отображение не реализуется (filtred functions из closer-mop - уже дальнейшее движение в эту сторону).
>и при этом полностью отображение не реализуется
А вот это поподробнее. В каком месте не классы? Ну да, от них наследоваться нельзя, но это другой вопрос. Диспатч на них работает.