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

"Ни для кого не секрет, что Lisp является достаточно популярным языком программирования"

вызывающе неверная информация.

http://newlisp.org/syntax.cgi?code/upload-cgi.txt - мда. Можно хоть до усрачки спорить о том как хороши функциональные языки... на реальных примерах оказывается всё тот-же процедурный подход. Код ну ничем не отличается от того-же, написанного на PHP. Кроме синтаксиса.

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

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

Народ, вы договоритесь между собой наконец - то у вас Lisp мультипарадигменный, то "императищина в чистом виде" :D

> Because newLISP is a functional language, it uses no break or return
> statements to ....

(c) http://www.newlisp.org/downloads/newlisp_manual.html

Значит автор нагло врет.

>functional language,

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

А чем автору sbcl/clisp не устроил?

Даешь очередной диалект? Ну их нафиг.

> Даешь очередной диалект?

Ну это же старая лисповая традиция - каждому хакеру по диалекту Лиспа :)

Как у sbcl/clisp с Win32?

Не надо забывать, что среди Лисповцев newLISP - это что-то вроде расхожей шутки.

> Как у sbcl/clisp с Win32?

Если не считать мультитредности, то хорошо, а что?

> вызывающе неверная информация

Вызывающе тупой ответ. Стабильно в верхней двадцатке по данным TIOBE. Является ли это "достаточным", естественно, определить нельзя, поскольку не указано, для чего "достаточно".

sbcl: Port in progress. clisp: no sign of Win32. Это называется "хорошо"?

>sbcl: Port in progress. clisp: no sign of Win32. Это называется "хорошо"?

а у тебя веб сервер под win32? маргинал, однако.

> sbcl: Port in progress

Основные оставшиеся проблемы - с мультитредностью. Разработчики достаточно критично относятся к своей классификации.

> clisp: no sign of Win32

Не знаю, где вы смотрели. Гляньте тут: http://sourceforge.net/project/showfiles.php?group_id=1355&package_id=1340 Win32 поддерживается где-то с 2001 года.

Собственно, разговоры о том, чтобы продвинуть SBCL/Win32 из port in progress ведутся уже довольно давно, но окончательное решение оставлено за nyef'ом.

>Не знаю, где вы смотрели. Гляньте тут:

А ведь действительно есть. Ну ладно, прибавим clisp один плюс.

И чем это лучше вот этого? http://git.altlinux.ru/people/inger/packages/?p=alterator-fbi.git;a=blob_plai...

Про Лисп (а также Питон). ИМХО, для того, чтобы выйти из каких-то там "ниш" и стать действительно языками общего назначения и широкого распространения, им обоим нужен _правильный_ рантайм. А _самый_ правильный рантайм, из всех которые я видел, ИМХО опять же, у Ocaml, ибо там есть:

1) в чистом виде интерпретатор; 2) компилятор в байт-код, и последующая его интерпретация; 3) компилятор в нативный код

Если не ошибаюсь, у Оcaml по пункту 3) получается настоящий elf, которому кроме libc и ld.so ничего не надо, причем в этом ельфе есть и GC и все прочее. По пункту 2) не хватает только JIT а-ля java - чтобы апплетообразные и вообще распределенные приложения могли исполняемый код дотягивать по сети и выполнять его почти с такой же скоростью, что и из п. 3).

Относительно лиспов 3) вроде бы неплохо сделан в CormanLisp, но оно только под самидогадываетесьчто, и вообще за деньги.

В общем ИМХО правильное направление - не плодить диалекты, а решать "чисто технические" задачи по реализации 1) - 3). Ocaml тут находится ближе всех ИМХО, но он слишком экзотичен для того, чтобы быть массовым. Java (с gcj) немного отстает. Возможно питон или лисп, "посаженный" сверху на java (с уже сделанными неплохими 2) и 3) имеют хорошие перспективы...

> > sbcl: Port in progress. clisp: no sign of Win32. Это называется "хорошо"?

> а у тебя веб сервер под win32? маргинал, однако.

Вежливый Вы, однако...

> 1) в чистом виде интерпретатор; 2) компилятор в байт-код, и последующая его интерпретация; 3) компилятор в нативный код

Откройте для себя ECL. Правда, там других тараканов выше крыши...

> Возможно питон или лисп, "посаженный" сверху на java (с уже сделанными неплохими 2) и 3) имеют хорошие перспективы...

В чистом виде (я про лисп, а ещё точнее - про CL) - будут бешенные тормоза из-за специфики его динамики - ABCL можно посмотреть. А если не брать CL за основу - ... ну будет ещё один NewLisp for JVM :)

А про сам NewLisp - "каждый дро..." т.е. я тоже не понимаю, почему бы не дополнить необходимым cLisp - там (ИМХО) только тредов и не хватает ("только" не в смысле _малости_ данной задачи, а в смысле _единственности_).

Хотя да, числиться автором "нового диалекта" кому-то приятнее, чем, в лучшем случае, соавтором, а то и вообще - "контрибутором"...

Уря! YALD Yet Another Lisp Dialect. 

;; Common Lisp and Scheme
(cons 'a 'b) => (a . b)   ; a dotted pair

[a | b]

;; newLISP
(cons 'a 'b) => (a b)     ; a list

Умудренные опытом основоположники фп икают и переворачиваются в гробах 
:) Что с людми динамическая типизация делает 

>а у тебя веб сервер под win32? маргинал, однако.

А что, lisp - это чисто серверная технология?

> Откройте для себя ECL. Правда, там других тараканов выше крыши...

Почитал. Думаю что:

1) Трансляция лиспа в С - тупиковая технология. Было (сейчас загнулось) такое поделие - CLiCC, работал в связке с clisp. Это писец. Правильный путь - либо CormanLisp, либо а-ля CMUCL с последующей JIT-компиляцией машинно-зависимого .fasl в нативный код.

2) "simple conservative mark & sweep garbage collector" - мало. Что сойдет для емакса, везде не прокатит. В частности, нужен real-time GC, который (возможно) работает потоком параллельно выполняющейся программе.

У clisp есть один большой недостаток - его исходники НЕЧИТАЕМЫ. Товарищ Бруно Хейбл конечно силен, но комментарии на немецком - это писец. Хорошо хоть не на иврите. Потом этот .d который не пойми как препроцессируется в С. Исходники емакса по сравнению с - благодать Божья.

Да, еще ему GUI не хватает. CLX - это анахронизм. Писать на Xlib но на Лиспе - это не просто писец, это вообще невообразимое что-то.

Пых-пыхкапец настал...

Вдогонку, специально для тов. уук посмотрел:

thread-ы в CLISP _есть_. См. src/xthread.d, src/zthread.d. В зависимости от OS, будут использованы либо POSIX threads, либо native SUN threads (cthreads), либо native Win32 threads.

Однако в impnotes.html написано:

* Both AllegroServe and CL-HTTP require multithreading and do not work with CLISP yet.

На основании этого думаю, что хоть они и есть, но того-с, не вполне кондиционные.

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

С точечными парами - это не диалект, это позор. Кроме того, пробежав по диагонали http://newlisp.org/MemoryManagement.html, насторожился. Есть предположение, что аффтар не читал даже "Uniprocessor Garbage Collection Techniques" Paul Wilson'а (кто не в курсе - это Библия писателей GC) и изобрел какой-то невнятный велосипедик... Впрочем, надо посмотреть поглубже.

> _самый_ правильный рантайм, из всех которые я видел, ИМХО опять же, у Ocaml, ибо там есть

логика охренительная - даже и возразить нечего

> 1) в чистом виде интерпретатор

а это что за бред? а не "в чистом виде" эти как?

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

при чем тут апплеты, "распределенные приложения" и jit?

> общем ИМХО правильное направление - не плодить диалекты, а решать "чисто технические" задачи по реализации 1) - 3)

"апрельские тезисы" т. анонимуса. всем "решать 1) - 3)", на!!!

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

> 1) Трансляция лиспа в С - тупиковая технология.

Скорее "да", чем нет. Но у него ядро не в пример sbcl-у :)

> Правильный путь - либо CormanLisp,

мультиплатформенность? открытость? (исходники самого лиспа открыты, но не свободны)

> либо а-ля CMUCL с последующей JIT-компиляцией машинно-зависимого .fasl в нативный код.

Хм, с CMUCL не знаком, но его "родственник" - sbcl - сразу компилит в натив, хоть и в fasl.

И, имхо, компиляция (с оптимизацией) машинонезависимого байт-кода в натив - не дело языка. Там своих подводных камней до чёртиков. Берите LLVM или ещё чего - и вперёд! :)

И я говорил - у ECL своих тараканов очень много.

> У clisp есть один большой недостаток - его исходники НЕЧИТАЕМЫ.

Прекрасный образчик действительно переносимого C-кода с втиснутой в него динамикой :) Хотя читать таки можно. Сложно, но можно.

> Да, еще ему GUI не хватает.

В одинаковой мере, в которой его "не хватает" всем CL.

Правильные веб-приложения на Лиспе (не функциональщина - там есть continuations):

http://siscweb.sf.net/

А NewLisp - пионерская поделка.

> thread-ы в CLISP _есть_.

Нет их там. Это зародыши для его воплощения.

clisp в mingw32 сборке уже сто лет как живёт и каши не просит.

А зачем языку (вообще любому) становиться языком общего назначения? Языков общего назначения нет, быть не может и не должно. Есть только языки, принимаемые по скудоумию толпами леммингов за "языки общего назначения". Ну любят лемминги гвозди микроскопами заколачивать и жопы наждачкой вытирать, такие они от природы.

P.S. Посмотри на F# и Nemerle. Ну и на Scala, есть так в жабу тянет.

Интересно, а можно ли забанить анонимуса ? Конкретно 20.04.2007 17:34:43 ? Мало того что туп, так еще и нагл безмерно.

> логика охренительная - даже и возразить нечего

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

> а это что за бред? а не "в чистом виде" эти как?

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

> при чем тут апплеты, "распределенные приложения" и jit ?

Пример. Зашли вы на сайт, а браузер вам пишет: для работы нужна мега-фича XYZ, у вас ее не найдено (например, плагин к браузеру не установлен). Правильное решение такое: предоставить браузеру возможность скачать XYZ в виде платформно-независимого байт-кода, чтобы потом у себя выполнить либо этот байт-код, либо для ускорения перекомпилировать его в машинный код (отдельной фазой либо в процессе исполнения из расчета на то, что еще раз понадобится, т.е. JIT). Это похоже на апплет.

Пример 2. В университете А кластер из 100 машин, а в Б - из 200. Однажды А попросил у Б вычислительные мощности для решения некоей мега-задачи. Б не мог отказать коллегам, но проблема в том, что в А кластер на x86 (подешевле), a в Б на Power5 (подороже). Следовательно, А должен для своих коллег свой софт по крайней мере перекомпилировать. А зачем ? Пусть Б скачает байткод, конвертирует его в машинный и работает как часть кластера А с минимальным вмешательством сисадминов. Это распределенные приложения.

Из функциональных языковых черт в CL - только полноценные замыкания.

Но никто не запрещает раелизовать ее с помощью макросов :-)

> Из функциональных языковых черт в CL - только полноценные замыкания.

а лямбды - это не "функциональная черта"?

> Возможно питон или лисп, "посаженный" сверху на java (с уже сделанными неплохими 2) и 3) имеют хорошие перспективы...

Поверх жабы уже есть гораздо более прогрессивный CAL

А я о чем толкую?

> А я о чем толкую?

Ээээ... не понял. Это был ответ "да" или "нет"? :)

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

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

А куда из CL пропала возможность типизации?

Карринга нет в синтаксисе - а так кто вам запрещает городить огород из кучи вызываем-возвращаемых лямбд?

> А куда из CL пропала возможность типизации?

Это не типизация. Отсутствует функциональный тип.

> Карринга нет в синтаксисе - а так кто вам запрещает городить огород из кучи вызываем-возвращаемых лямбд?

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

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

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

Хм - и в чём принципиальная разница - перекомпилировать свой код или конвертировать байт-код в машинный? К тому-же sbcl, если ему не запретить, "влёт" компилирует всё, что ему подсовывают, и только потом выполняет. Опять-же, из-за платформо-зависимых различий во многих переносимых лисп-программах используется условная компиляция. Т.е. существующий стандарт CL не очень подходит для формирования платформо-независимого байт-кода.

Вы хотите расширить стандарт? Ха, вспоминая историю принятия CL боюсь это случится очень не скоро...

> Это не типизация. Отсутствует функциональный тип.

Как отсутсвует? Я не могу задать тип как функцию с определённым набором параметров и определённым типом возвращаемого значения? :)

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

Qi? :)

> Относительно лиспов 3) вроде бы неплохо сделан в CormanLisp, но оно только под самидогадываетесьчто, и вообще за деньги.

Ещё и в gcl (GNU common lisp). Тоже генерирует бинарник, которому ничего больше не нужно. Только в нём что-то из стандарта не доделано по-моему - не всё под ним идёт.

> Хм - и в чём принципиальная разница - перекомпилировать свой код или конвертировать байт-код в машинный?

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

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

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

(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"))

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

> Вы хотите расширить стандарт?

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

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

> А зачем языку (вообще любому) становиться языком общего назначения ?

Это вопрос философский. Задача "а как бы нам пересадить всех юзеров с винды на линукс ?" тоже технической не является. Ну на 1% технической, все остальное - вопросы привычки, идеологии, инертности мышления и прочее.

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

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