компилятор байткода Java 5

Довольно занятно.

А сравнение с clojure есть?

интерпритатор

скорее всего в abcl не такая гладкая интероперабельность, как в clojure

вообще интересно будет глянуть abcl vs. clojure в сравнении: как покажут себя на одних и тех же наборах задач и жаба-библиотек
ну и о насущном — swank'а для него еще нет?

Да это просто радость какая-то! Хвостовую рекурсию не запилили?

Да это просто радость какая-то! Хвостовую рекурсию не запилили?

Ты наверное имеешь ввиду оптимизацию хвостовой рекурсии?

неделя лиспов на ЛОРе

Да это просто радость какая-то!

И не говори! А если еще адепты CL скинутся на выпил Рича Хики...

Уже вторая или даже третья подряд.

Парад трупов на главной.

И плакал я тихонечко И напивался в дым. Меня за за тягу к скобочкам Считали голубым.

Употребление этого термина в другом контексте было бы бессмысленным :)

Ты, наверное, не ведаешь, сколько языков пережил лисп, даже таких могучих как ПЛ/1 и алгол.

эти трупы вы будете созерцать время от времени на протяжении всей вашей короткой жизни.

Парад трупов на главной.

Анонимусы оригинальничают последнее время.

И плакал я тихонечко И напивался в дым. Меня за за тягу к скобочкам Считали голубым.

=)

Употребление этого термина в другом контексте было бы бессмысленным :)

Употребление Лиспа вообще бессмысленно. И беспощадно не менее.

и ты, Брут!

то есть может быть скриптовым движком в любом приложении, написанном на Java

ужосс... Не хотел бы я поддерживать скриптовый код на Lisp. Есть же искоробочный JS, и гораздо более читабельные Beanshell,Groovy,Python. Scala вроде тоже может работать в режиме интерпретатора.

А зачем его выпиливать то?

swank'а для него еще нет?

Есть, причем давно уже.

Я понимаю, когда говорят C89 и C99. Я понимаю, когда говорят Python2 и Python3. Я еще многое могу понять и простить. Но когда говорят, что появился очередной диалект Лиспа... У меня в очередной раз отпадает желание хоть когда-нибудь чего-нибудь на нем написать.

Так новость не про очередной диалект, а про очередную реализацию.

Это не диалект, а все тот же стандартный Common Lisp, только на jvm платформе. Для тех, кто работал с sbcl, clisp, ecl, ccl, нет никакого труда использовать abcl.

Анонимусы

Это один. Спроси макскома.

гораздо более читабельные Beanshell,Groovy,Python. Scala...

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

OH NOES. Опять этот флуд?

А чо, давайте я буду новости про каждый новый релиз PGI FORTRAN писать. И про Интелевский тоже. И про PathScale с Ораклом до кучи.

Фортран и то живее скобчатого поноса будет. А, главное, значительно полезнее. Потому что на нем реальную математику считают, а на лиспе — одни динамические опердени и анафорические лямбды с фибоначчами.

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

Что не так с читабельностью у Scala? Может, Вы просто не овладели языком? Дело в том, что освоение Scala требует определенных интеллектуальных усилий.

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

на лиспе... фибоначчи

Лол, числа Фибоначчи на лиспе? Ты это всерьёз?

LISP:

(defparameter *fibs-2*
  (reclet 
      ((fibs (seq->stream
              (seq-cons
               1 (seq-cons
                  1 (seq-map
                     (lambda (x)
                       (+ (first x) (second x)))
                     (seq-zip
                      (delay-seq fibs)
                      (delay-seq (seq-cdr fibs)))))))))
    fibs))

Haskell:

fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

Лол, числа Фибоначчи на лиспе? Ты это всерьёз?

А теперь попробуй рассчитать Фибоначчи в промышленных масштабах. Конкретно *это* решение на хаскеле слегка соснет.

рассчитать Фибоначчи в промышленных масштабах

Лол, так вот каково истинное предназначение лиспохаскелей.

Только наркоман будет так реализовывать числа Фибоначчи на CL.

Нет. Вы не совсем правы...

... Это не очередной диалект Lisp. Это просто версия этого... «бурно развивающегося» языка.

Впрочем, отчасти Вы правы. Если про другие языки можно сказать «смотрите, чего только не понаписано на языке *», то про Lisp можно точно сказать — «смотрите, на чем только не понаписан Lisp». )))

А! Да не волнуйтесь...

... это в преддверии планируемого на 21.12 какого-то Конца Света некрофи... эээ... некроманты балуются. )))

Но-но-но...

... Милейший, я бы Вас попросил не сеять панику. Анонимусы на ЛОРе пока еще не являются вымирающим видом.

А слабó ему в лицо сказать? http://dsorokin.blogspot.ru/2012/12/blog-post_10.html

то-то с лиспа уже 40 лет тягают идеи все кому не лень

то-то с лиспа уже 40 лет тягают идеи все кому не лень

Мейнстрим сразу же стырил хорошие вещи, а уже в 70х лишпы бесконечно отстали от полноценных ЯП, и всё, что делается на скобочном говне с того времени - это неудачные попытки стырить концепции из полноценных ЯП, оканчивающиеся многословными, глючными, неудобными, несовместимыми скобочными недо-dslчиками.

Третий вариант (оттуда, откуда ты взял) эффективнее хаскелевского.

Числа Фибиноччи - это всего лишь тест на то, правильно ли реализованы потоки и последовательности. За деревьями нужно уметь видеть лес. Или ты так для красного словца?

Только наркоман будет так реализовывать числа Фибоначчи на CL.

Правильно. Третий вариант (не приведенный здесь) через make-seq эффективнее хаскелевского (старые вычисленные значения тут же забываются) и много проще для восприятия (аналогия с составлением cons-ячеек).

Кстати, можно упростить (но все равно гораздо лучше делать через make-seq):

(defparameter *fibs-2*
  (reclet 
      ((fibs (seq->stream
              (seq-cons
               1 (seq-cons
                  1 (seq-map #'+    
                             (delay-seq fibs)
                             (delay-seq (seq-cdr fibs))))))))
    fibs))

Вот, этот вариант эффективнее хаскелевского (если нужен именно ленивый поток, то добавь seq->stream перед make-seq), и он не такой мозгодробительный. Если разобраться, то все примитивно до невозможного:

(defparameter *fibs-3*
  (make-seq
   (labels ((traverse (a b)
              (enum-cons a (traverse b (+ a b)))))
     (traverse 1 1))))

Боюсь...

... оттуда уже нечего таскать. Все уже утащено до нас.

В качестве квеста попробуйте написать на Scala или F# такое же решение через ленивый поток. Не думаю, что будет короче, чем на лиспе. А хаскель останется чемпионом по числам Фибоначчи - тут не спорю.

Теперь объясняю.

Тест на числа Фибоначчи показывает, что можно работать с ленивыми последовательностями и потоками. А это означает, что открывается возможность использовать эффективные алгоритмы по работе c (чаще всего, иммутабельными) структурами данных.

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

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

Тест на числа Фибоначчи показывает, что можно работать с ленивыми последовательностями и потоками. А это означает, что открывается возможность использовать эффективные алгоритмы по работе c (чаще всего, иммутабельными) структурами данных.

Но ведь иммутабельность не нужна. Это — своеобразный карго-культ в теоретическом программировании; божок, на которого молятся функциональщики.

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

http://www.flyingmachinestudios.com/programming/the-unofficial-guide-to-rich-... - почитай, прежде чем позориться, клоун.

а уже в 70х лишпы бесконечно отстали от полноценных ЯП

ты про ML?

Необоснованные утверждения и подмена понятий. От иммутабельности проку большого нет при программировании на Си или Си++, поскольку там нет автоматической сборки мусора (а та, что есть в виде библиотек, - медленная, некрасивая, неэффективная и т.п.). Тут могу согласиться, что иммутабельность не очень-то и нужна конкретно для этих языков, поскольку там она не дает бенефитов, а скорее, усложняет код.

Но уже на уровне C# (а я - профессиональный разработчик C#, т.е. получаю деньгу за свой труд) иммутабельность становится полезной, и я ее применяю в нашем проекте, также как и Linq (кстати, Linq и clojure были источниками вдохновения для generic sequences). В функциональных же языках иммутабельность - это просто кладезь хороших практичных решений, особенно если есть хороший REPL как в лиспе, когда можно проектировать снизу-вверх, сразу же тестируя код. Если программа не использует функциональный стиль, то тестировать будет тяжелее.

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

Наконец, иммутабельные объекты существую даже в Си. Например, это - обычные числа.