Интервью с разработчиком языка NewLisp

anonymous (*) (20.04.2007 21:25:35)

- Вы умный человек, даже не ожидал что такие на ЛОР'е еще остались :)

А что лучше: newLisp или LispWorks?

> В "минимальном вмешательстве сисадминов". В вышеуказанном примере перекомпилировать возможно несложно, а в подлинно гетерогенной среде для каждой кофеварки перекомпилировать руками неохота.

Зачем руками? asdf-install сделает всё за вас :)

> Вы имеете ввиду конструкции наподобие:

> (defun foo () #+allegro (do-one-thing) #+sbcl (do-another-thing) #+clisp (something-else) #+cmu (yet-another-version) #-(or allegro sbcl clisp cmu) (error "Not implemented"))

Да, но даже в пределах одной реализации есть #+unix #+darwin #-win32 и т.д.

> Да, это неприятно. По возможности от этого надо избавляться. Но, пока лиспы делают несколько вендоров, совсем избавиться от этого не получится. С Питоном в этом смысле проще :-).

Дело не только в вендорах, но и в различиях платформ: полная унификация приводит к унылой серости. А так есть варианты...

С Питоном проще в том смысле, что у него очень много "батареек из каробки". У CL не меньше, но не в одном флаконе и в нескольких вариантах. В этом есть плюсы, но есть и минусы, один из которых - "повышение порога вхождения" - надо знать где что и как искать и выбирать.

> Не знаю. Так далеко я пока не заглядываю. История развивается по спирали, на текущем витке в моде Java :-(.

У Java есть один большой плюс (для этой самой спирали) - она низводит написание кода до такой рутины, что так и напрашивается автоматизировать это дело... ;) Но для этого надо использовать несколько другие инструменты... :)

> Тредов в clisp действительно нет - пара недописанных функций и кучка stubs. Недоглядел. А все потому что .d нечитаем. Хотя если вы знаете немецкий, то вам проще :-()...

Нет, немецкий не знаю, хотя за месяц пребывания в Германии почти начал на нём слегка изъясняться. Да читаем .d - просто надо "продраться" через его синтаксис, как в лиспе через скобки - и начинаешь его просто не замечать. Было-бы желание. А в качестве многоплатформенного скрипта среди прочих CL, имхо, наилучший.

мы об одном говорим :-) синтаксис лямбда-выражений при наличии замыканий легко реализовать как синтаксический сахар

> Насчет языка я думаю, что чем язык универсальнее, тем больше людей работают с ним и над ним, тем больше...

Да, количество имеет свои неоспоримые преимущества.

Но у CL есть несколько "врождённых" недостатков (которые, вероятно, было не легко предусмотреть во время его утверждения, либо реализация исправлений которых стоила бы слишком дорого), преодолеть которые в рамках стандарта, имхо, очень не просто, если не невозможно.

Кое-что "новое" можно найти хотя-бы в том-же Nemerle (там тоже полно своих ограничений).

Иногда посещает мысль :), что имея возможность из тела кода самой программы управлять всеми стадиями компилятора (парсер, "лексер", генератор obj/байт/натив-кода) + линкером (если он нужен) и средой выполнения в случае VM, причём "управлять" - вплоть до задания совершенно новых "правил поведения" для локальных участков кода - я бы наконец получил "идеальный ЯП" :) Но подозреваю, что идея слишком бредовая ;)

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

DSL? :)

> А что лучше: newLisp или LispWorks?

Это почти "тёплое с мягким", ибо общего только слово Lisp и скобки в синтаксисе :)

> За вами пока вообще наблюдаются только нечленоразндельные вопли.

сложно спорить с бредом - бессмыслица тем и "хороша", что возразить что-либо в принципе не возможно

> Пример. Когда вы в емаксе (надеюсь, вы знаете что это такое ?) делаете M-x eval-expression, это в "чистом виде" - что набрали, то и интерпретируется. Когда вы грузите файл .elc - это интерпретируется байт-код

"мам, смотри - у него емакс есть!"

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

> Зашли вы на сайт, а браузер вам пишет...

абстрактно мыслить в школе не учат? все на палочках надо.

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

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

начали с емаксов и докатились до сисадминов. даже и предположить боюсь, что пойдет в ход дальше.

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

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

Давайте не будем играть в терминологию. Можно заявить, что С и нативный X86 код - это одно и то же, просто "записанное с использованием разных словарей". Кроме того, байткод и исходный текст - почти никогда не то же самое. Например, если вы заглянете в емаксовый bytecomp.el, то в комментариях можете прочитать, какие оптимизации делаются при компиляции в байткод.

> абстрактно мыслить в школе не учат? все на палочках надо.

Основной принцип педагогики - от простого к сложному, от конкретного к абстрактному. С вами по-другому нельзя, не осилите.

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

На "возможность удаленной загрузки" - никак. А на скорость исполнения - очень даже.

Давайте критику/вопросы/предложения по существу. Если вы не понимаете, что такое "по существу", посмотрите что пишет тов. yyk. Не засоряйте наше общее информационное пространство.

> Зачем руками? asdf-install сделает всё за вас :)

В "подлинно гетерогенной" сети 50% вычислительных устройств может и не знать, что такое asdf-install :-).

> Дело не только в вендорах, но и в различиях платформ: полная унификация приводит к унылой серости

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

> С Питоном проще в том смысле, что у него очень много "батареек из каробки"

Тоже согласен. По моему опыту, писать небольшой скрипт в ситуации, где шелла недостаточно, а на С - некогда и неохота, на питоне почти всегда быстрее, удобнее и приятнее, чем на лиспах. Ибо стандартная библиотека правильная - там есть почти все. Думаю newlisp'у еще несколько лет надо развиваться до того же уровня.

А .d будем читать. В конце концов, учиться читать не поздно в любом возрасте. "Мыши плакали и кололись, но продолжали жевать кактус" (С)...

> В "подлинно гетерогенной" сети 50% вычислительных устройств может и не знать, что такое asdf-install :-).

Тогда это не CL-среда. В "подлинно гетерогенной" среде вообще без единых правил мы ничего не сможем сделать. Если говорить о CL-среде, то asdf-install - практически стандарт. Гораздо "больший", чем мифический (на данный момент) унифицированный CL-байткод.

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

Из того, что я видел, если не пользоваться только унифицированными интерфейсами - фактически писать платформозависимые куски отдельно для каждой из платформ. Разве может быть что-то другое? Ну, можно ещё дождаться, пока кто-то напишет необходимый функционал за нас ;)

> Думаю newlisp'у еще несколько лет надо развиваться до того же уровня.

Не думаю, что догонит. Ибо, если его будут развивать думающие и не фанатичные люди, они скорее всего либо приведут его к стандарту, либо уйдут из него. А недумающие или фанатики много не сделают :)

> А .d будем читать. В конце концов, учиться читать не поздно в любом возрасте. "Мыши плакали и кололись, но продолжали жевать кактус" (С)...

Читать то можно, была бы цель...

Интересно а чем отличается от brl.sourceforge.net. P.S. пока лазил по инету параллельно наткнулся на новую тему для флейма http://slideaware.typepad.com/slideaware/2007/04/from_python_to_.html кратко питон фуу:)

> аффтар не читал даже "Uniprocessor Garbage Collection Techniques" Paul Wilson'а (кто не в курсе - это Библия писателей GC) и изобрел какой-то невнятный велосипедик... Впрочем, надо посмотреть поглубже.

Единственное достойное утверждение в последних двух словах. Конечно, смотрите глуже, прежде чем рассуждать. Аффтар, возможно, чего-то и не читал, он просто придумал и реализовал на практике один из из самых эффективных на сегодняшний день механизмов GC. Возможно, вопрреки всем известным теориям. Что с того? Может ему извиниться за это?

> Аффтар, возможно, чего-то и не читал, он просто придумал и реализовал на практике один из из самых эффективных на сегодняшний день механизмов GC.

Доказательства эффективности? Желательно в сравнении с другими. И в равных условиях.

> Интерпретаторы не рулят. В наше время даже скриптовые языки обязаны быть компилируемыми

Во-первых, никто никому ничего не обязан. Во-вторых, что имеется в виду под компиляцией? Компиляция в байт-код подходит? Или только в натив? А если байт-код с опциональной JIT? Кстати, нельзя ли пару примеров скриптовых языков "нашего времени" с нативной компиляцией?

> Иногда посещает мысль :), что имея возможность из тела кода самой программы управлять всеми стадиями компилятора (парсер, "лексер", генератор obj/байт/натив-кода) + линкером (если он нужен) и средой выполнения в случае VM, причём "управлять" - вплоть до задания совершенно новых "правил поведения" для локальных участков кода - я бы наконец получил "идеальный ЯП" :) Но подозреваю, что идея слишком бредовая ;)

Вообще-то нет. Это довольно давно реализовано в Pliant (http://en.wikipedia.org/wiki/Pliant).

> Доказательства эффективности? Желательно в сравнении с другими. И в равных условиях.

А разве гугл уже отменили?

Бенчмарки можно посмотреть тут: http://newlisp.org/benchmarks/ Надо только учесть, что не все примеры грамотно оптимизированы. К примеру, "count words" написан плохо, и потому показал очень плохие результаты. Его правильная версия тут: http://newlisper.blogspot.com/2007/03/and-counting.html. Она быстрее perl'a.

>>А с каких пор лисп стал функциональным языком? Это ж императищина в чистом виде

Мужик, ты что обкурился. Лисп - был первый в мире функциональный язык.

>>Нет там нормальной лямбды. Нормальная лябмда - это типизированная лямбда с каррингом.

Солнышко моё красноглазое. Лямбда впервые появилась в лиспе, не надо тут свой поганый ML проталкивать.

> Вообще-то нет. Это довольно давно реализовано в Pliant (http://en.wikipedia.org/wiki/Pliant).

Ох ма... Такого "стройотряда" я давно уже не видел... Попробуем разобраться.

> Бенчмарки можно посмотреть тут: http://newlisp.org/benchmarks/

И как эта пенисомерка с загрузкой рантайма доказывает "создание одного из самых эффективных на сегодняшний день механизмов GC"? Где именно работа GC? И если речь о лиспах - то хотябы в сравнении с cLisp-ом (ладно, про компилируемые в натив помолчим... ;)

> Мужик, ты что обкурился. Лисп - был первый в мире функциональный язык.

Многие говоря "лисп" подразумевают CL, а это императивщина если не в первую, то не в последнюю очередь точно :)

Дитятя, лямбда впервые появилась в ранних работах А. Чёрча в конце 30х годов прошлого века. Никаких лиспов тогда не было и в проекте. А то, что потом в 51м году появилось в Лиспе, было просто закосом на мотив лямбды. Примерно как SQL - простенький закос по мотивам реляционной алгебры.

> в 51м году появилось в Лиспе

"Originally specified in 1958, Lisp is the second-oldest high-level programming language in widespread use today"

Опечатался, бывает. Вообще, первая реализация живая только в 61-м появилась. То есть, через более чем 30 лет после того, как лямбду придумали. Кароче, не лисперам тут на право первой ночи претендовать. Хаскеллисты же на SK-исчисление не претендуют.

> не лисперам тут на право первой ночи претендовать.

Из языков программирования, лямбда и в самом деле впервые появилась в Лиспе.

Лямбда-исчисление, так же, как и SK-логика и логика предикатов - сами по себе языки программирования. Идеальные. А реальные языки - это только разные степени приближения к ним.

И ещё раз: то, что было в Лиспе, это не лямбда. Так же как и то, что в SQL - это не реляционная алгебра.

> И как эта пенисомерка с загрузкой рантайма доказывает "создание одного из самых эффективных на сегодняшний день механизмов GC"?

Да о чем вообще тут говорить, какая эффективность GC. С ужасом узнал, что cons cell занимает 32 байта (на 32-битной машине с 4-Гб адресуемым пространством памяти). Автор newlisp явно не знает не только что такое GC, но даже что такое tagged pointer.

Уже после этого об эффективной реализации чего бы то ни было говорить просто смешно - если самый важный лисповский тип сделан _так_, то как же сделано все остальное ? Окончательно меня добили строки фиксированной длины (по умолчанию 2048). Автору лень сделать realloc() или он не знает что это такое ?

Вывод: для сколь-нибудь серьезного применения newlisp непригоден. Зачем тогда он нужен ?

--

В учебных целях (посмотреть как может быть устроен интерпретатор лиспа изнутри) можно использовать SLisp (http://www.sigala.it/sandro/download.php) - самый маленький лисп на С, который мне известен.

К предыдущему: ашипка, cons cell в newlisp занимает 16 байт. Само собой разумеется, в Emacs и clisp - 8.

> > Вообще-то нет. Это довольно давно реализовано в Pliant (http://en.wikipedia.org/wiki/Pliant).

> Ох ма... Такого "стройотряда" я давно уже не видел... Попробуем разобраться.

"Не вынесла душа поэта..." Нет, спасибо. Может там внутри и что-то революционное, но мне хватило траха с обычным запуском... И файлы для сборки топорные - под одну конфигурацию автора. Бинари вообще не запускаются. В сад.

P.S. И эти люди жалуются на качество кода cLisp? Да он как часы собирается где угодно и работает точно так-же...

> И как эта пенисомерка с загрузкой рантайма доказывает "создание одного из самых эффективных

Ух, как сильно сказано. Я аж пригнулся ;)