LispWorks 6.0.1 Personal Edition

> Зато в CL мегакрутые макросы. После лиспа сишные дефайны кажутся унылым говном

Сложно найти что-то, по сравнению с чем сишные дефаны не кажутся унылым говном.

> CL на сервере вполне заменим

На сервере, очевидно, можно использовать любую технологию и именно поэтому наиболее простой способ использования CL это разработка веб-приложений.

нефиг пихать что-то кроме JS в браузер

Если ориентироваться только на открытые стандарты, то и не получится же.

Но, тут ньюанс, что как бы современные подходы стремятся как раз к тому, что бы обеспечить общую кодовую база для сервера и для клиента, что зачастую многократно облегчает разработку подобных приложений.

Что касается интерактивной разработки, то такое встречается еще и в Smalltalk (если мне не изменяет память). Более того, в Smalltalk уже есть достаточно мощные инструменты для разработки web-приложений, такие как Seaside и Aida/Web. Хотелось бы знать, как соотносятся между собой Smalltalk и Lisp, в чем они схожи, в чем разница между ними. А то из обсуждения я понял только, что Lisp годится только для прокачки ЧСВ и отращивания бороды с параллельным пожиранием красной икры. Так в чем таки основной профит от лиспа?

> Так в чем таки основной профит от лиспа?

На нём можно писать программы.

А вообще вот: http://lisper.ru/articles/common-lisp-technologies - статья может не совсем полная, да и не совсем я полностью согласен, но тем не менее.

>На нём можно писать программы.

Это было удивительным в 50-х годах прошлого века, сейчас этим уже никого не удивишь. А реальные преимущества перед Java, C++, Python есть?

archimag, толк от срачей давно закончился. Здесь уже который месяц одни и те же тролли с одними и теми же методами. Скучно. Вот как сейчас помню тот тред два месяца назад, развивающийся по тому же сценарию что и этот.

Анонимусу «вот этим лисп лучше», а он «покажите где используется». Ему «вот здесь используется», а он «так чем же лисп лучше?». И так пока кому-нибудь не надоест.

> А реальные преимущества перед Java, C++, Python есть?

1. Интерактивная разработка
2. CLOS
3. Макросистема
4. Система условий и рестартов
5. Динамические переменные
6. И т.д.

> толк от срачей давно закончился.

Предположим, что аудитория ЛОРа постоянно увеличивается ;)

Можно я угадаю что скажет анонимус?

«Половина есть в других языках, половина - отличная возможность выстрелить себе в ногу. В _реальных_ проектах так не пишут.»

>> полностью интерактивную модель разработки

для тех, кто в танке, можешь пояснить, что это такое? а то гугл не понимает

всё понимает, только ты плохо гуглил. см. внимательнее на google://«evolutionary development».
алсо, ключевые слова: инкрементальная разработка, эволюционная разработка, live update, hot update, метасистемы, метамодель, образ runtime системы, cмоллток, лисп с единым образом, и т.п.

привет граммар клонам эрика наггума, гы.

Если ориентироваться только на открытые стандарты, то и не получится же.

а если не ориентироваться, то можно и Kamen Lisp встроить. в свою модную ынтырпрайз-сборку фаерфокса.

на JS и пофичастее код видали. взять, к примеру, контр-страйк на JS в canvas теге, скучный рейтрейсер на JS или демо-страничку гуглохрома с примерами.

> такие как Seaside и Aida/Web. Хотелось бы знать, как соотносятся между собой Smalltalk и Lisp, в чем они схожи, в чем разница между ними.

ты спрашиваешь не того парня насчёт Seaside. арчмаг его забракует, ибо континуейшны. пол грем как раз на континуейшнах и написал поделие, и вообще — после Seaside таких поделий вагон пруди. но у грэма был CLISP и вообще тормозной, неправильный ынтерпрайз, да.

> на JS и пофичастее код видали.

В каком плане? Это вы вообще это к чему?

к примеру, контр-страйк на JS в canvas теге

Хм, вы вообще понимаете разницу между canvas и SVG. Для canvas, конечно, побольше и покруче кода надо, а с SVG всё намного проще, но контр-страйк на нём, конечно, дело не стоит. Вообщем, разберитесь для начала с базовыми технологиями.

> Хотя, у меня ещё есть и другая теория: чем гуще становится борода, тем лучше живу. Но, может быть, это она от скобок заколосилась, так что не факт, что это не просто другая сторона использования Лиспа.

СКАНДАЛЫ ИНТРИГИ РАССЛЕДОВАНИЯ:
Линус пишет не на Лиспе оттого что бороды у него нет!!!111

а в чём необходимость именно SVG там? там можно ресайзить, масштабировать, афинные преобразования делать?
пофичастее в том плане, что в этом случае вычисления поинтенсивнее требуются, чем простой драг-энд-дроп.

давай лучше макросистему обсудим. макросистема проста, как палка, этим и интересна. но неясен контекст раскрытия макроса, может состояться и при load, и при compile, и при eval. в итоге *могут быть* побочные эффекты и невоспроизводимость, если макросы написаны неаккуратно. про необходимость перекомпиляции форм, использующих макрос, при его переопределении уже сказали. нормальный человек подумает, и напишет свою обёртку над defmacro вроде code walker-a, если уж часто это будет составлять неудобство.
с другой стороны, против лиспового backquote выступает схема с её четким разбиением на модули и порядок отработки компилятора. с третьей, AST макросы, которые позволяют контролировать целостность семантического дерева особо хитрого макроса. вопрос такой, в каких случаях третий вариант будет необходим, то есть, что нельзя описать через backquote или модули.

если хорошенько погуглить, можно найти статью 200-лохматого года про Java и эволюционную разработку. да, там EJB объекты на лету обновляли. автор статьи — тётка, что-то про поколения объектов было. ты бы посмотрел на количество кода, потребного для такого извращения (я уже не помню, переписывали ли там класслоадер или не).

> Анонимусу «вот этим лисп лучше», а он «покажите где используется». Ему «вот здесь используется», а он «так чем же лисп лучше?». И так пока кому-нибудь не надоест.

странный какой-то анонимус пошёл. сказка про белого Bulb-чка.

> а в чём необходимость именно SVG там?

Неправильный вопрос. Правильно спрашивать не про необходимость, а про преимущества.

пофичастее в том плане, что в этом случае вычисления поинтенсивнее

требуются

Безусловно.

Только стремления к «фичастности» вычислений у меня отсутствуют абсолютно. Напротив, я стремлюсь к максимальной простоте. В данном случае в этом плане очень важную роль играет именно SVG. SVG, в отличие от canvas, это формат векторной графики. Для генерации данных в этом формате можно использовать шаблоны. Они и используются. При этом, один и тот же набор шаблонов используется как на сервере, так и на клиенте. Вообще, любая генерация контента на клиенте (а её там много) делается с помощью шаблонов. Так что никакого унылого код по генерации разметки на JS, который можно увидеть во многих JS-библиотеках. JavaScript только рулит этим всем, а всю «грязную» работу выполняют шаблоны. За счёт этого объём рукописного JS относительно мал. Такая техника возможна для SVG, но не для canvas.

кстати. Есть ли REPL на D? даже на C есть, см. google://c-repl или googlocode://ccons

на Go есть репл. на OOC есть REPL. Есть ли REPL на Марсе?

Послушайте, я сейчас могу перечислить вещи, которые не нужны мне лично, хотя мне очень нравится emacs, но вы, судя по вашему настроению, готовы будете оспорить каждую. И, может быть, некоторые вещи из моего списка вам действительно нужны. Если я сейчас опубликую такой список - точно буду троллем. Так что sorry)

> давай лучше макросистему обсудим

Давно уже обсудили и сделали вывод:

Если вам нравится использовать нетривиальное метапрограммирование, то рекомендую избегать такого примитивного в этом отношении языка, как Common Lisp, и использовать современный язык с многостадийной компиляцией и четко определенной семантикой (например, язык модулей PLT Scheme, camlp4 для OCaml, и другие системы, обрабатывающие файлы детерминированным образом). У макросов PLT есть ряд преимуществ: гигеничность, совместимость с отладчиками и другими инструментами и т.п.

Я использую макросы, но не склонен слишком ими увлекаться. В конце концов, я согласен с мнение Страуструпа, что

Практически каждый макрос свидетельствует о недостатке в языке программирования, программе или программисте

К сожалению, существующие сейчас языки, и CL в том числе, - не идеальны, а макросы бывает единственный способ справиться с дублированием кода.

Есть превосходные и вместе с тем сложные примеры использования макросов - например, iterate, но я не занимаюсь разработкой подобных вещей. И изложить действительно осмысленную точку зрения о возможностях нетривиального метапрограммирования с использование макросов не могу, просто не имею соответствующего опыта.

> Хотелось бы знать, как соотносятся между собой Smalltalk и Lisp, в чем они схожи, в чем разница между ними.

схожи они в основном этой самой инкрементальной, эволюционной разработкой — системы с единым образом «системы» во время исполнения. первый смоллток, ЕМНИП, был раскручен из лиспа (также, как и лого, как и дилан). однако, лисп гибче — он более мультипарадигемен. в смоллтоке одна парадигма — объектная, хотя некий gillad bracha (newspeak), поговаривает об функционально-объектной. ну да newspeak не совсем смоллток — там и объекты как модули, и опциональная типизация как объект/модуль, и он более близок к статической типизации.
в лиспе аннотации могут сделать из динамической типизации статическую. а путём операции буханка-троллейбус можно прикрутить ооп систему в любом стиле: посылкой сообщений, как в смоллтоке (FLAVOURS), что-то вроде C++ VTable через defstruct, что-то вроде метатаблиц в lua, и т.п.
заместо этого, в смоллтоке только ооп модель через посылку сообщений. поэтому оптимизации смоллтока производятся в направлении, указанном self: больше информации о типах и инлайна простых методов, PIC (polymorphic-inline cache), кеширование и т.п.
в итоге, не сильно отстаёт от С++ ооп модели (менее чем на 50%) в хорошей реализации.
то, что нормальный рантайм важен, видно на примере libobjc2 из Etoile. там написали свой компилятор смоллтока на LLVM, свой рантайм для Obj-C вместо GNU-сного, померяли, оказалось быстрее (а смоллток на LLVM не сильно медленнее отстаёт). и сюрприз, для простых скриптов интерпретатор оказался быстрее, чем компилятор (которые надо раз выполнить, и забыть).

Разница между языками тоже очевидна: лисп это язык для символьных вычислений. что означает, что в (setf символ) ты можешь хранить свои любимые plist-ы, alist-ы с данными или кодом, или откомпилированным кодом.
в смоллтоке же всё объект, в том числе и класс объект (метакласс), и компилятор, и «метасистема». через словарь объектов можно смотреть/изменять поля и методы объектов. реализовано это навроде питона со словарём всех объектов, всех методов, и т.п.
ну то есть, не натуральные символьные вычисления, а объектные.

Ещё есть такая теория, насчёт бороды. Скобки, как сказал Ларри Уолл, имеют внешний вид обрезков ногтей. Значит, лисперы подсознательно этими ногтями чаше чешутся, расчёсывают бороду. От того и растёт сильнее.

У меня борода не растёт. Примесь бурятской крови. Как не чеши, а ничего толкового не вырастет.

Ха, ну это чисто CLная докука что символ определяется в конкретном контексте. Я уж думал совсем что-то невероятное хочешь сделать. В питоне такой проблемы нет, как я показал func содержит ссылку на код, который можно поменять, то есть сама функция как принадлежала модулю так и будет принадлежать, я просто меняю ее байткод.

> я просто меняю ее байткод.

Только такую технику нельзя использовать для интерактивной разработки, её и не используют для этого. Настоящей интерактивной разработки в Python нет, это как бы факт.

\troll{Покажи в Python apropos и describe :P}

Популяризаторов Лиспа - в топку. Ни к чему хорошему его популяризация не приведет, разве что использовать его будут не по назначению гораздо чаще. Пожалуй, присоединюсь к тем, кто скандирует «лисп не нужен» по этой причине.

это как бы факт.

По факту нет только рестартов. А так ничего не мешает сделать такие же удобные инструменты, по типу выделил C-c C-c и вуаля, новый код уже работает в продакшене.

Нет принципиальных трудностей сделать apropos.

describe это я так понимаю help.

> А так ничего не мешает сделать такие же удобные инструменты

Если бы ничего не мешало, то, очевидно, уже давно бы сделали.

> Популяризаторов Лиспа

Честно говоря, абстрактный лисп мне тоже не особо по душе. Здесь речь идёт о конкретном диалекте - Common Lisp.

его будут не по назначению гораздо чаще.

Не для написания программ? o_O

присоединюсь к тем, кто скандирует «лисп не нужен» по этой причине.

Я правильно понял причину, что вы понимаете область применения CL лучше, чем люди его создававшие?

Если бы ничего не мешало, то, очевидно, уже давно бы сделали.

Очень спорный вопрос. Например для меня интерактивная разработка выглядит совершенно дико. Как можно непротестированный код (ладно юнит тесты еще можно быстро прогнать, но интеграционные остаются за бортом) вставлять в живое приложение?

И еще нюанс, интерактивная разработка полезна в случаях достаточно трудоемкого процесса сборки и деплоя приложения. У питонистов с этим проблем нет совершенно никаких, поэтому не нужно.

> Очень спорный вопрос.

Да нет, не спорный. Нужно только раз попробовать и всё сразу станет ясно. Вообще очень странно слушать подобные рассуждения от python-разработчика. Может вам стоит внимательно посмотреть на Haskell? (вопреки распространённому поверью штангой при этом заниматься необходимости нет)

baverman, на Питоне так не пишут. Фичей нет, потому что для вашего стиля разработки софта они не нужны и хватит пытаться переоборудовать буханку хлеба под троллейбус. Вот, как бы, и подтверждение:

Например для меня интерактивная разработка выглядит совершенно дико.

Питон с интерактивной разработкой будет, может быть, и не _совсем_ другим языком, но сообщества их почти не будут пересекаться.

> Фичей нет, потому что для вашего стиля разработки софта они не нужны

Я несколько лет с разной степенью интенсивности писал на Python (хотя, в течении этого периода основным языком он был всего лишь полгода) и ответственно заявляю, что подобные возможности были бы в Python очень даже кстати. Интерактивная разработки нисколько не противоречит Python-стиля, наоборот, она бы сделал его гораздо мощнее.

Да пробовал и не раз. Порочная практика, развращает сильно.

> Да пробовал и не раз. Порочная практика, развращает сильно.

Это уже очень сильно похоже на позу. Либо вы выбрали не тот язык и Haskell прям таки жаждет вас ))

и ответственно заявляю, что подобные возможности были бы в Python очень даже кстати

А я, программист на питоне средней паршивости, ответственно заявляю, что могу разработать весь стек инструментов для поддержки удаленной интерактивной разработки за день, никаких принципиальных проблем нет.

Поэтому, если была необходимость уже давно бы сделали, знающих людей предостаточно.

> А я, программист на питоне средней паршивости, ответственно заявляю,

что могу разработать весь стек инструментов для поддержки удаленной

интерактивной разработки за день, никаких принципиальных проблем нет.

Хм, и что же вы собираетесь делать с существующими объектами какого-либо класса, если определение класса изменится? Не, ну серьёзно, принципиальных проблем хватает, ещё как.

Или что вы собираетесь делать при изменении базового класса, от которого наследуют остальные? Ведь аналог func_code для классов нет...

А что с ними надо делать? Могу оставить им поведение старого класса. Могу частично старого, частично нового.

Или что вы собираетесь делать при изменении базового класса, от которого наследуют остальные?

Что нужно сделать? То есть изменил я базовый класс и что должно произойти или не произойти.

Кстати можно еще от контекста менять поведение. То есть часть объектов будет со старым поведением, а часть с новым.

> Могу частично старого, частично нового.

Каким образом? В общем, вы несколько поторопились. Если бы в Python были только функции, то ещё можно было бы что-то изобразить, но это ведь ООП язык!

> То есть изменил я базовый класс и что должно произойти

или не произойти.

Должно соответствующим образом поменяться поведения наследников. По-факту, оно просто поломается ведь и будет сыпаться с ошибками.

Каким образом?

Класс это набор функций. Чтобы поменять поведение класса, мне нужно поменять методы. Что как мы видели не представляет трудностей. Плюс можно менять методы у конкретных экземпляров, что и дает широчайшие возможности.

но это ведь ООП язык

Каким образом парадигма языка влияет на возможность подмены рантайма? И не забываем про смолтолк.

Должно соответствующим образом поменяться поведения наследников

Для этого даже делать ничего не нужно.

По-факту, оно просто поломается ведь и будет сыпаться с ошибками.

Я думаю, вы несколько некомпетентны в питоне, чтобы так говорить.

> Для этого даже делать ничего не нужно.

Я думаю, вы несколько некомпетентны в питоне, чтобы так говорить.

Боюсь, что это вы некомпетентны. А я если что-то говорю, то обычно проверяю.