newLisp для программистов

Статья хорошая, но зачем было создавать ещё один нестандартный диалект Лиспа? Хаоса и так предостаточно.

Пока только бегло просмотел.

1. "Большинство языков программирования (за исключением BASICа ;-) разрабатывались с целью упрощения решения определенных задач" - вызывающе неверная информация (по части BASIC - ср. brainfuck, whitespace, unlambda, intercal).

2. (setq a "test") -> "test" Афигенная функциональщина...

3. (define (down moves) (inc 'y moves)) ; аналогично
(define (left moves) (dec 'x moves))
(define (right moves) (inc 'x moves))

я так понимаю в newLisp динамическая область видимости? Так об этом надо написать. А вообще динамическая видисомть (без возможнсти статической) - отстой.

3. Фактически, следующие два выражения идентичны:

(define (up moves) (dec 'y moves))
(setq up '(lambda (moves) (dec 'y moves)))

Присваивание неописанной переменной? А интерпретатор хоть warning выдаст по этому поводу?

3. Однако в ЛИСПе использование кода как данных является "повседневной" практикой, применяемой при любой необходимости (а также и вовсе без оной ;-).

Угу вот только через макры, и очень редко через eval. А apply в нормальных лиспах вообще никакого отношения к этому не имеет.

> Статья хорошая, но зачем было создавать ещё один нестандартный диалект Лиспа? Хаоса и так предостаточно.

Этот экземпляр имеет самостоятельную ценность за счет кросс-платформенности (Win* + *nix), миниатюрности, простоты и возможностей.
Его надо сравнивать, скорее не с CL, а с Perl.

самый любимый интерпретато Лиспа - muLISP!!! скока лаб на нем было сделано-переделано... эх... :-)

>1. "Большинство языков программирования (за исключением BASICа ;-) разрабатывались с целью упрощения решения определенных задач" - вызывающе неверная информация (по части BASIC - ср. brainfuck, whitespace, unlambda, intercal).

:-) и что, на кто-то пытался "решать задачи"? А на Васике - до сих пор.

>2. (setq a "test") -> "test" Афигенная функциональщина... Рассматривай в контексте примеров. Кроме того, не было цели показать "чистый функциональный стиль" - скорее акцент на возможностях, имеющих практический интерес для "процедурщиков" - про академический и так достаточно написано.

>я так понимаю в newLisp динамическая область видимости? Так об этом надо написать. А вообще динамическая видисомть (без возможнсти статической) - отстой.

Динамическая. Статическая реализована через контексты. Жить можно, многие, говорят, плакали, когда в CL ее нормально не включили ;-) Описание нюансов newLISP - не цель статьи.

>Присваивание неописанной переменной? А интерпретатор хоть warning выдаст по этому поводу? не выдаст. они вообще не описываются.

>3. Однако в ЛИСПе использование кода как данных является "повседневной" практикой, применяемой при любой необходимости (а также и вовсе без оной ;-).

>Угу вот только через макры, и очень редко через eval. А apply в нормальных лиспах вообще никакого отношения к этому не имеет.

В нормальных лиспах будет примерно то же, но с "funcall", насколько я понимаю. Углубляться в сравнение с CL - слишком много надо еще приплести. Кто им заинтересуется - найдет нормальную документацию.

(язык ((просто) ("супер"))):

(define (average) (div (apply add (args)) (length (args))))
  -> (lambda () (div (apply add (args)) (length (args))))


(apply +
  (map (fn (x) (int (x 3) 10))
       (filter (fn (x) (and (> (length x) 3) (regex "^[0-9]+$" (x 3))))
               (map (fn (x) (parse x " *\\| *" 0))
                    (parse (read-file "report.txt") "\n")))))

>(язык ((просто) ("супер"))):

ну, ты бы хоть написал, как это делают настоящие специалисты...

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

> Статья хорошая, но зачем было создавать ещё один нестандартный диалект Лиспа? Хаоса и так предостаточно.

Наверное некоторых объём CLHS в ступор вгоняет... ;) Но для таких есть схема.

С одной стороны, это может быть "распылением сил". С другой стороны, это может снижать "порог вхождения" в CL :) Смотря с какой стороны посмотреть :)

8-Е

Лучше бы добавили треды в cLisp и в виндовый порт sbcl (прошу прощения за офтопик ;)

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

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

Есть ли какие-то фреймоворки под Веб?

> Но вот если взять чисто с прагматической точки зрения. В сравнении с тем же перлом/питоном/руби (подставить кому что нравится), есть ли реальный прирост в скорости написания мелких и средних задачах?

Для этого нужен человек, активно использующий и то, и другое.

> Есть ли какие-то фреймоворки под Веб?

goto www.cliki.net

> В сравнении с тем же перлом/питоном/руби (подставить кому что нравится), есть ли реальный прирост в скорости написания мелких и средних задачах?

Угу, по скорости рвёт как @ грелку.

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=sbcl...

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=sbcl...

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=sbcl...

Блин, не заметил "скорости _написания_". А так. хз зависит от наличия библиотек, тут лиспу конечно с перлом сложно тягаться.

> Блин, не заметил "скорости _написания_".

Сорри, за оффтопик. Пит, а это не ты написал для emacs'а рельсовый плагин? :) Там в копирайтах CrazyPit значится :).

Угу. Я и Дима.

>Но вот если взять чисто с прагматической точки зрения. В сравнении с тем же перлом/питоном/руби (подставить кому что нравится), есть ли реальный прирост в скорости написания мелких и средних задачах?

За ЛИСП не скажу - только документацию читал :-) На newLISP длина скриптов выходит сравнимая с Perl (+-10%). Зато код прозрачнее и писать субъективно приятнее.

Есть библиотека для CGI (не такая навороченная, как у Perl), есть HTTP функции get-url, put-url, post-url, есть CMS (на ней newlisp.org работает).

> есть CMS (на ней newlisp.org работает)

при всех замечательностях newlisp, расхваливаемых hello world'ами, форум у них -- на phpBB. :)

поэтому newLisp для демагогов. программисты уже выбрали php. :)

скорее, php выбрали админы, которым нужен нормальный форум, а не поделки программистов :-)

Язык приятный по многим параметрам, но сколько я не читал комментариев,
не понял, как реализовать в нём наследование в стиле ООП. Контексты
позволяют создавать объекты, но этого явно мало. Если нет наследования,
то чем его можно заменить? В доке "Design Patterns in newLISP" ничего
похожего не нашёл.

Давно я смотрел доку по нему...

Судя по твоим словам, решение одно - выкинуть этот "приятный по многим параметрам" язык и взять нормальный CL :)

>> Есть ли какие-то фреймоворки под Веб?
> goto www.cliki.net

Не туда послал человека. newlisp-wiki тут:
http://www.newlisp.org/wiki/

> и взять нормальный CL :)

Увы, "нормальный CL" никогда не сможет стать массовым прикладным языком.
А newlisp может. Пока ещё может.

> Не туда послал человека.

Дык, в его письме было просто "Лисп", а не newLisp. Хотя каюсь, в любом случае поступил некорректно, ибо это в моём сугубо личном понимании определения "лисп" и CL совпадают практически всегда :)

Пусть человек к хорошему привыкает.

> Увы, "нормальный CL" никогда не сможет стать массовым прикладным языком. А newlisp может. Пока ещё может.

Схема не стала, а этот станет? "Не верю". Да и не будут многие останавливаться "на пол пути" :)

>Угу, по скорости рвёт как @ грелку.
>http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=sbcl...

Кому ви таки впариваете!?
Вот вам квота с http://sbcl.sourceforge.net/
"Steel Bank Common Lisp (SBCL) is an open source (free software) compiler and runtime system for ANSI Common Lisp."

А раз "compiler" то будте любезны сравнит так:
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=sbcl...

Как и предсказывалось вал лисп в глуууууубокой Ж.. _заднице_ :)

Дык нашкрябай тестов для cLisp-а и сравни (лиспникам это, по-видимому, нафиг не нужно :)

правда, что в newLisp аргументы всегда передаются по значению?

>Дык нашкрябай тестов для cLisp-а и сравни (лиспникам это, по-видимому, нафиг не нужно :) >yyk * (*) (13.09.2006 18:22:03) С-шникам - тем более :)

>как реализовать в нём наследование в стиле ООП

например, так:

(context 'parent) ; создаем класс-родителя
(define (var-value v) (if v (setq var v) var))
(context MAIN)

(context 'child) ; создаем класс-потомка
(new 'parent) ; копируем в него родителя
(setq var-value-parent var-value) ; сохраняем метод
(define (var-value) ; переопределяем
  (unless (int? v)
    (throw-error "only integer allowed")
    (var-value-parent v)))

(context MAIN)
(new child 'object) ; создаем экземпляр

На самом деле - parent, child и object - просто разные контексты.
Теоретически, можно придумать макрос для некоторой автоматизации...

> С-шникам - тем более :)

Дык просили срвнение с интерпретируемыми языками :)

О, спасибо за пример. Значит можно реализовать наследование.

Если говорить о Common Lisp, то

> Можно, без особого преувеличения, сказать, что список в ЛИСПе - единственный структурный тип данных. Записей - аналогов struct или record в ЛИСПе нет.

А тогда что такое defstruct?

http://www.lispworks.com/documentation/HyperSpec/Body/m_defstr.htm

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

Как ни удивительно, при разработке в 1988-м году очередной своей Лисп-машины сотрудники LMI пришли к прямо противоположному выводу --- в общей массе данных списки занимают далеко не первое место, более того, их доля была сочтена настолько незначительной, что из аппаратуры выкинули поддержку CDR coding (заявленный в свое время, как одна из отличительных особенностей Лисп-машин).

--

Lisp Hobbyist

Наверное можно сказать так: списков достаточно, всё остальное можно вывести. Но если захотите эффективности... :)

А про лисп машину - банально: посчитали, что софтовая реализация CDR выгоднее аппаратной :)

>правда, что в newLisp аргументы всегда передаются по значению? Правда. Это такой способ забить на garbage collection :-)

Аргумент автора - "скорость копирования областей памяти на нынешних процах это позволяет". Я пол-года пытался его уличить в том, что со ссылками быстрее - но ни один мой тест этого не показал (по крайней мере на уровне _данного_ интерпретатора).

При обработке больших объемов данных (мег 50-150) приходится иногда брать в голову, что они могут _временно_ дублироваться.

С другой стороны - в newLISP динамическая область видимости, т.е., если в функции не переопределять символ (через let или список аргументов), то всегда виден последний определенный из стека. Т.е., его не обязательно передавать в функцию явно и работа с ним не вызывает копирования. Возможность спорная, но до CL она была и в ЛИСПе и многие ее любили...

> А про лисп машину - банально: посчитали, что софтовая реализация CDR выгоднее аппаратной :)

Ну, вообще-то cdr coding просто выкинули, даже без программной эмуляции. Ибо экономия памяти, которую он дает, оказалась мизерной. В данном же контексте интересно не это следствие, а его мотив:

Analysis of the storage on existing Lisp Machines indicated that only about 20 percent of the storage was actually stored in lists (the rest being vectors, structures, or classes)

(когда-то это лежало по адресу fare.tunes.org/tmp/emergent/kmachine.htm)

Это к вопросу о том, что в Лиспе список --- далеко не самая популярная структура данных. Да, так было в 1959-м, но кое-что изменилось.

--

Lisp Hobbyist

> Угу. Я и Дима.

За это большой респект и уважуха :).

Я раньше пользовался онли вимом и считал, что круче него редактора быть не может. Но когда начал учить РоР, решил попробовать емакс (типа чтобы самому поюзать, а потом смело его обсырать и говорить, что вим круто =]). Сначала не хватало очень многих вещей. Но были ништяки вроде авто-дополняющихся скобок и кавычек.

Потом поставил себе ваш rails-плагин и тебе под РоР только емаксом :). Особенно понравился набор снипетов и хот-кеи для быстрого перехода по каталогам.

А вот мне больше это понравилось:

vs. OCaml http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=sbcl...

vs. ML

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=sbcl...

Я вам непредвзято скажу: НЕ может, НЕ станет, потому что код НЕ читаем и писать его НЕ удобно, именно по этим причинам он НЕ популярен.

>поэтому newLisp для демагогов. программисты уже выбрали php. :)

Ерунда. В отличии от PHP (на котором я в основном и пишу сейчас), newLisp замечателен тем, что умеет создавать компактные бинари, которые собираются под любую платформу + не требуют сторонних библиотек). Плюс newlisp-tk - очень легко писать кроссплатформенные ГУИ приложения. PHP тут вообще никаким боком... Да и еще во многих местах newLISP поудобнее PHP... а вещи типа net-eval? (выполнение кода на remote newLISP серверах) - что нам может PHP предложить аналогичного?

> (context 'parent) ; создаем класс-родителя
> (define (var-value v) (if v (setq var v) var))
> (context MAIN)
>
> (context 'child) ; создаем класс-потомка
> (new 'parent) ; копируем в него родителя
> (setq var-value-parent var-value) ; сохраняем метод
> (define (var-value) ; переопределяем
>  (unless (int? v)
>    (throw-error "only integer allowed")
>    (var-value-parent v)))

если это - ооп, то я уж лучше улицы подметать пойду

> Ну, вообще-то cdr coding просто выкинули, даже без программной эмуляции. Ибо экономия памяти, которую он дает, оказалась мизерной. В данном же контексте интересно не это следствие, а его мотив:

> Analysis of the storage on existing Lisp Machines indicated that only about 20 percent of the storage was actually stored in lists (the rest being vectors, structures, or classes)

Может у них лисп был другой? :)

Да одних только &rest &body хренова туча - это то, что первое приходит мне "на ум" :)

> Я вам непредвзято скажу: НЕ может, НЕ станет, потому что код НЕ читаем и писать его НЕ удобно, именно по этим причинам он НЕ популярен.

Угу. Только ты перед каждым "НЕ" забыл "МНЕ/ДЛЯ МЕНЯ" поставить :)))

> потому что код НЕ читаем и писать его НЕ удобно

Я согласен, если имеется в виду "при первом взгляде" для тех, кто раньше
ничего подобного не видел. Но выгоды налицо, а привыкнуть можно. Есть
ведь человеческие языки, которые читают справа налево или сверху вниз!
И ничего, проблем не вызывают.

Lisp уродлив и бесполезен. Зачем вы его используете?

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

Т.е. два новых языка в месяц? Для кого? Зачем?

может еще и ссылкой кинешь, где можно посмотреть на твои чудо-newlisp-tk приложения? если -- нет -- в топку эти недотехнологии! =)

зы: http://www.newlisp.org/index.cgi?page=Code_Snippets

;; Get the current working directory on Win32 or UNIX
;;
;; by Sam Cox
;;
;; example:
;;  (cwd) => "C:\\newlisp" ; on Win32
;; 
;;  (cwd) => "/home/newlisp" ; on Unix
;;

(if (= (& 0xF (last (sys-info))) 6)
  (import "kernel32.dll" "GetCurrentDirectoryA"))

(define (cwd , buff)
   (if (= (& 0xF (last (sys-info))) 6) 
       (begin
         (setq buff (dup "\000" 260))
         (GetCurrentDirectoryA 259 buff)
         (trim buff))
         ;else for UNIX
         (first (exec "pwd"))))

если так пишут "кроссплатформенные приложения" на newLisp'е, то php, 
по сравнению с "этим", -- само совершенство, удобство и переносимость:
<?php getcwd(); ?> :)

>(if (= (& 0xF (last (sys-info))) 6)
>  (import "kernel32.dll" "GetCurrentDirectoryA"))

>если так пишут "кроссплатформенные приложения" на newLisp'е, то php, 
>по сравнению с "этим", -- само совершенство, удобство и переносимость

Так пишут вызовы к библиотекам. А на php их не пишут никак.
Это старый код, сейчас можно говорить: (real-path ".")

Для примера newlisp-tk приложения запусти newlisp-tk - это оно.

>Не компилятор. Нет статической видимости. Говняные макры. Втопку. Я компилятор любого лиспообразного языка под любую заданную платформу за две недели пишу под ключ

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

Не надо писать, хотя бы скажи, где взять такой :-)