Какой из лиспов лучше взять?

В Racket они прибиты гвоздями

Что прибито, куда прибито?

=== твой друг

В Racket они прибиты гвоздями — это не батарейки

1. В clojure гвоздями прибита вся Java, которая многократно тяжелее всего Racket.

2. В Racket, начиная с 5.92 можно ставить не все системные библиотеки (если точнее, то необходима base, остальное добровольно)

3. В Racket всегда при формировании дистрибутива остаются только используемые библиотеки (опять же, в отличие от clojure+весь Java runtime).

А тебе зачем? Велосипеды писать? Racket посовременней и поприятней чем CL, но он тоже норм. Макросы упарывать? Racket /трад Писать продакшн код? Кложур. Потому что библиотеки от джавы. Потому что он практичнее ракеты и поживее общелиспа, не говоря уже о всяких других схемах.

В clojure гвоздями прибита вся Java, которая многократно тяжелее всего Racket.

Нет, я точно не хотел сказать, что Racket не нужен, есть Clojure :)

В Racket, начиная с 5.92 можно ставить не все системные библиотеки

Хм, не знал, хорошо.

JavaScript'ом теперь можно троллить кого-угодно. Даже ассемблерщиков (asm.js)

Какой из лиспов лучше взять?

Можно подумать их много.

Если вы предлагаете Clojure

Секта, которая Христа не видела, не знает, думает что верит и бубнит что-то похожее. Wanna this? Go ahead.

Собственно меня интересуют батарейки

А вообще ты еще не просветлился. Пойди в магазин и купи батареек.

Lisp-2 это крест на написании в функциональном стиле.

Во-первых, это не правда, ибо адекватные элементы ФП присутствуют в CL в должной степени

Это какие элементы, функол что ли? :)

А во-вторых, написание «в функциональном стиле» (чистом)

Баззворд.

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

Конечно же нет. Пишешь все в функциональном стиле с persistent data structures, и в _местах_ где это действительно необходимо - немного изменяемых состояний.

Очень похоже на python-коммунити, только более продвинутое.

Ох. Python community известна своей ущербностью

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

и фактически является днищем

Жену увел питонщик? :) Не удивительно - даже в нашей деревне в мировом масштабе python-сеньоры получают от 5К баксов.

даже Perl community грамотнее

Охлол. Теперь ясно откуда корни растут. Вам перл кажется лучше питона, да?

Надеюсь, что обрыганы из python не повалят в Clojure. Они и не осилят, как бы.

Та вы шо. Весь научный софт это python и java, вебня и стартапы исключая мобильные платформы и байтодрочерство - python, ruby, scala, js. Обожемой, даже FPGA это теперь python (myhdl), и современный лисп (clojure) вобрал в себя элементы синтаксиса питона! Но «перл-коммуните» бесспорно сильно грамотней - в написании однострочников, вестимо.

так же как для обработки больших объемов данных (ленивые коллекции рулят).

Хм. С какого это перепуга? Написанный в лоб код будет эффективнее по памяти и не более того.

Вы ленивые структуры перепутали с persistent data structures, ай-ай-ай!

Это какие элементы, функол что ли?

map*, reduce, ...

В Racket они прибиты гвоздями

В смысле?

Мне уже объяснили, что это с некоторых пор не так. Я имел в виду, что неотключаемые батарейки — это не батарейки.

map*, reduce, ...

Ну так они и в питоне есть, python функциональный язык? :)

Ну так они и в питоне есть, python функциональный язык? :)

Речь шла об элементах ФП, читай внимательнее. Ну и конечно CL значительно адекватнее в плане ФП, чем гвидобейсик.

Ну так они и в питоне есть, python функциональный язык? :)

Речь шла об элементах ФП, читай внимательнее.

Да я внимательно читаю - в исходном сообщении функциональные возможности CL сопоставлялись с соответствующими в clojure.

Ну и конечно CL значительно адекватнее в плане ФП, чем гвидобейсик.

Естественно, но речь ведь о CL vs clojure в данном контексте.

Розовый бери.

Это какие элементы, функол что ли? :)

Какие-то проблемы с funcall?

Конечно же нет. Пишешь все в функциональном стиле с persistent data structures, и в _местах_ где это действительно необходимо - немного изменяемых состояний.

Оукей. И чем же CL мешает такому подходу?

Python-коммунити известно наличием вкуса и своей дружелюбностью.

Сомневаюсь, что ты имел дело с python community, иначе бы такой ерунды не говорил.

Вам перл кажется лучше питона, да?

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

современный лисп (clojure) вобрал в себя элементы синтаксиса питона!

Да? И что же это за элементы синтаксиса такие? :)

А там никогда не было неотключаемых батареек. Не «с некоторых пор» - вообще никогда.

И чем же CL мешает такому подходу?

Тем, что в lisp-2 функциональный код ужасен и нечитабелен.

Естественно, но речь ведь о CL vs clojure в данном контексте.

Ну, в смысле ФП, Clojure значительно технологичнее, чем CL, только вот куда хуже, чем, например, Haskell. Lisp ведь практически никогда не позиционировался как функциональный язык (разве что только на заре). Сейчас же принято за ФЯП-ы полагать как минимум языки со строгой типизацией, ATD и автовыводилкой, а в Clojure этого нет. Lisp сильно развит касательно интерактивной разработки, метапрограммирования. Хорош в прототипировании, исследованиях. А если взять CL, то ещё и ООП на высочайшем уровне. По мне так эти вещи куда более практичны, чем стремление к чистому ФП.

Какие-то проблемы с funcall?

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

все в функциональном стиле с persistent data structures, и в _местах_ где это действительно необходимо - немного изменяемых состояний.

И чем же CL мешает такому подходу?

Все тем же, что и раньше - отсутствием таких структур, лени, иммутабельности.

Вам перл кажется лучше питона, да?

Мне не кажется, я знаю и могу это аргументировать

А, ну все понятно, я так и знал. Это диагноз.

современный лисп (clojure) вобрал в себя элементы синтаксиса питона!

Да? И что же это за элементы синтаксиса такие? :)

Зайди на сайт кложуры и посмотри, что ли.

Тем, что в lisp-2 функциональный код ужасен и нечитабелен.

Преувеличение. Немного избыточен, но зато даёт приятные бенефиты.

в смысле ФП, Clojure значительно технологичнее, чем CL

Ok.

только вот куда хуже, чем, например, Haskell

Хаскель - игрушка для борщехлебов.

Lisp ведь практически никогда не позиционировался как функциональный язык (разве что только на заре)

Что за маркетинговый булшит «позиционировался»? На лиспе _всегда_ было удобнее писать в функциональном стиле, чем на чем-либо другом, возможно, кроме *ML.

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

Сейчас ФЯП - это баззворд.

а в Clojure этого нет

Кложура динамический язык программирования - какая там может быть выводилка типов и ADT? Строгая типизация есть и в питоне :)

Lisp сильно развит касательно интерактивной разработки, метапрограммирования

Ну, еще один плюс в пользу лиспов.

А если взять CL, то ещё и ООП на высочайшем уровне.

CLOS - мощная, но не всегда уместная объектная система. Иногда объектная система вообще не нужна. Или даже вредна.

По мне так эти вещи куда более практичны, чем стремление к чистому ФП.

Чистое ФП в виде кложуры (хотя, мы-то знаем, что никакого чистого фп не бывает, а бывает только заметание под ковер) дает бонусы в виде STM, гарантий иммутабельности, бОльшую декларативность (а следовательно и выразительность) кода.

Строгая типизация есть и в питоне :)

Прошу прощения. Имел ввиду строгую статическую типизацию.

Ну, еще один плюс в пользу лиспов.

Это даже не плюс. Это мощнейшая особенность выделяющая Lisp.

CLOS - мощная, но не всегда уместная объектная система. Иногда объектная система вообще не нужна. Или даже вредна.

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

Хочу заметить, что тут говорили про преимущества Clojure и как-то не правильно при этом не упоминать про исключительные преимущества CL. А это: макросистема (с макросами ридера и компилер-макросами), CLOS, сигнальный протокол, развитая система типов, практичная и продуманная стандартная библиотека и наличие отличных компиляторов CL, интерактивная разработка в лице slime. Всего этого нет в Clojure и практически нет нигде.

Зайди на сайт кложуры и посмотри, что ли.

Зашёл на викушечку, и глаз зацепился за:

Influenced by Common Lisp, Erlang, Haskell, ML, Prolog, Scheme, Java, Ruby

Питон обнаружен не был. Ткни что-ли мне балбесу в каком именно месте Python повлиял на Clojure. Объясни.

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

Тем же были какие-то defadt, match и core.typed? Сами по себе ADT ортогональны типизации (вот параметрические — уже нет).

А это: макросистема

Макросистема является недостатком общелиспа, а не его достоинством.

Преувеличение. Немного избыточен

Немного?? Ты сравни y-комбинатор на общелиспе и на схеме.

но зато даёт приятные бенефиты

Хоть парочку назови.

Все тем же, что и раньше - отсутствием таких структур, лени, иммутабельности.

Лень не является обязательной особенностью ФП. Если ты внимательно полистаешь стандартную библиотеку CL, то заметишь, что функции, в большинстве своём делятся на разрушающие и безопасные. Да и сам дизайн языка вполне способствует программированию без состояний при крайней на то необходимости.

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

ЛОР такой ЛОР.

В толксах обсуждают эфиродинамику и передачу энергии через земной шар; в Development — какой лисп лучше выбрать.

Какой из лиспов лучше взять?

А разве есть разница?

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

Всего этого нет в Clojure и практически нет нигде

Да почему же? Аналог slime есть, вполне приличный. Стандартная библиотека тоже ok. Компилятор - jvm, плюс это или недостаток зависит от задач.

ридермакросы, CLOS, сигнальный протокол, компиляторы в нейти

Да, этого нет. Но на то есть и *очевидные* причины.

Питон обнаружен не был. Ткни что-ли мне балбесу в каком именно месте Python повлиял на Clojure. Объясни.

Синтаксис для основных структур данных - кортежи, словари, векторы итд.

Хоть парочку назови.

Я смотрю ты и lisp in small pieces не прочёл, но почему-то считаешь правым высовываться? Я же могу ещё и от себя добавить того, чего нет в lisp in small pieces, касательно преимуществ Lisp 2. Но не буду тут бисер метать.

Я смотрю ты и lisp in small pieces не прочёл, но почему-то считаешь правым высовываться? Я же могу ещё и от себя добавить того, чего нет в lisp in small pieces, касательно преимуществ Lisp 2. Но не буду тут бисер метать.

Ты следующий раз когда соберешься кинуть пару баззвордов или на что-нибудь сослаться - то учти, что можешь попасть на человека, который и ссылку и смысл баззвордов знает. И в курсе, что в lisp in small pieces не указано ни одного преимущества lisp-2.

Скажем так, не было дистрибутива без батареек.

Ну никто не мешал взять и выкинуть все «лишнее» руками.

Весь научный софт это python и java

Ты где таких шишек нанюхался?

возьми форт, и пиши чего-нибудь на Qt

Тем же были какие-то defadt, match и core.typed? Сами по себе ADT ортогональны типизации (вот параметрические — уже нет).

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

И в курсе, что в lisp in small pieces не указано ни одного преимущества lisp-2.

Из русского перевода «Lisp in Small Pieces»:

В программах на Lisp 2 функции чётко отделены от остальных вычислений.

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

От себя добавлю, что разделение пространств имён — удобная вещь в метапрограммирование, когда необходимо отобразить идентификаторы как на lisp-переменные, так и во внешний мир, не заботясь при этом, что мы затронем идентификаторы из пространства функций, например (код не промышленный, быстренько набросал, как proof of concept):

(defun normalize (s)
  (substitute #\_ #\- s))

(defun binding->ident (binding)
  (etypecase binding
    (symbol
     (normalize
      (let ((s (string binding)))
        (if (some #'lower-case-p s)
            s
            (string-downcase s)))))
    ((cons symbol (cons string null))
     (second binding))))

(defun binding->symbol (binding)
  (etypecase binding
    (symbol
     binding)
    ((cons symbol (cons string null))
     (first binding))))

(defun sql-select (fields table)
  (format nil
          "SELECT ~{~a~^, ~} FROM ~a"
          fields
          table))

(defmacro do-select ((bindings table) &body body)
  (let* ((syms (mapcar #'binding->symbol bindings))
         (fields (mapcar #'binding->ident bindings))
         (query-string (sql-select fields (binding->ident table))))
    (with-gensyms (row)
      `(with-rows (,row ,query-string)
         (destructuring-bind ,syms ,row
           ,@body)))))

(do-select ((id
             foo-bar
             (baz "xyz")
             list)
            :table)
    (do-something id foo-bar baz list))

;; macroexpand:
;; (WITH-ROWS (#:ROW832 "SELECT id, foo_bar, xyz, list FROM table")
;;   (DESTRUCTURING-BIND
;;       (ID FOO-BAR BAZ LIST)
;;       #:ROW832
;;     (DO-SOMETHING ID FOO-BAR BAZ LIST)))

Вот так то, Мань. Обоссал тебя.

Лень не является обязательной особенностью ФП

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

Если ты внимательно полистаешь стандартную библиотеку CL, то заметишь, что функции, в большинстве своём делятся на разрушающие и безопасные

Я в курсе. Но этого мало для того чтобы использовать ФП IRL, а не только в прототипа - потому что без тех же persistent data structures - будет избыточное копирование => огромный оверхед по памяти и время на само копирование. Без лени в некоторых случаях будут тяжеловесные вычисления там, где их можно было бы избежать. А некоторые конструкции (те же бесконечные типы и генераторы типов) просто невозможны.

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

Любой бесконечный тип, даже простенькие примеры из офдоки http://clojuredocs.org/clojure_core/clojure.core/lazy-seq

Ну, а то что стандарт CL не гарантирует оптимизацию хвостовой рекурсии, мы вообще не говорим, да? :)

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

А ML, OCaml, F#, Erlang не принято считать функциональными? :)

Ну, а то что стандарт CL не гарантирует оптимизацию хвостовой рекурсии, мы вообще не говорим, да? :)

Конечно не говорим, ибо любой современный компилятор CL может TCO, а то что в стандарте это не указано — nobody cares, как бы.

любой бесконечный тип, даже простенькие примеры из офдоки http://clojuredocs.org/clojure_core/clojure.core/lazy-seq/

Да как бы все подобные вычисления можно сделать энергичным образом, взяв, например, iterate и совершенно не проиграть в читаемости (а возможно и выиграть).

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

А ML, OCaml, F#, Erlang не принято считать функциональными? :)

Ну, я же написал - *современные*. *ML - трупики, erlang используется в такой нише, что там лень/нелень побоку вообще, это узкоспециализированное решение с OTP-батарейками. А F# кому вообще нужен?

все подобные вычисления можно сделать энергичным образом, взяв, например, iterate

Кто спорит. На CL вообще почти все можно сделать. Вопрос в другом - какими усилиями. И напомню, мы не говорили о _принципиальной_ невозможности сделать нечто каким угодно способом (на ассемблере вообще все можно сделать), а о выразительной поддержке функциональной концепции в современном ее понимании.

iterate и совершенно не проиграть в читаемости (а возможно и выиграть).

Ну, я тебе скидываю примеры в паттернматчингом и ленивыми коллекциями - ты мне за итерейт начинаешь говорить, зойчем? Мы ж ФП хотим, а не iterate.

Ну, а то что стандарт CL не гарантирует оптимизацию хвостовой рекурсии, мы вообще не говорим, да? :)

Конечно не говорим, ибо любой современный компилятор CL может TCO, а то что в стандарте это не указано — nobody cares, как бы.

Смотри, основная разница между CL и clojure: CL «все можно сделать», clojure - «все сделано искаробки бери и пользуйся» + определенная направленность на конкретные ниши. Допустим, писать игры на clojure я бы не взялся. О чем спор тогда вообще?

В программах на Lisp 2 функции чётко отделены от остальных вычислений.

Это содержательный смысл lisp-2. А преимущество в чем?

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

Это, очевидно, недостаток. Только идиот будет делать руками то, что вполне может сделать компилятор, автоматически.

От себя добавлю, что разделение пространств имён — удобная вещь в метапрограммирование, когда необходимо отобразить идентификаторы как на lisp-переменные, так и во внешний мир, не заботясь при этом, что мы затронем идентификаторы из пространства функций

Но такое нам никогда не нужно. Точнее, нам обычно нужно обратное - перекрыть _все_ идентификаторы. И с зоопарком binding-форм в lisp-n - начинается ад.

Что в итоге нам даст:

Ну так что? В каком тут месте преимущество lisp-2 укажешь?

В F# вроде как есть и ленивые вычисления и ленивые последовательности, кстати. Но нужнее от этого он не становится.