LINUX.ORG.RU

Посоветуйте «lisp»

 ,


3

5

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

ЗЫ Капелька бояна http://imgs.xkcd.com/comics/lisp.jpg

Перемещено mono из talks

★★★

Последнее исправление: nerfur (всего исправлений: 1)

Ответ на: комментарий от monk

В CL ровно та же проблема: в любой более-менее крупной системе разработчикам приходится причесать код для единообразия и уменьшения количества «странных ошибок» (когда изменения в одном месте ломают всё в совсем другом). Теперь у нас есть фреймворк hu.dwim.*, нестыкующиеся cl-containers и https://github.com/fare/lisp-interface-library, cffi и uffi, 100500 пакетов с «утилитами», сотни попыток сделать «стандартную библиотеку Common Lisp»... Около 10 интерфейсов к GTK и полдюжины надстроек над CLOS.

О да. Это правда :)

deadlock
()
Ответ на: комментарий от NaN

Мне непонятно, чем обычный лисп не устраивает.

Наверное тем, что обычный лисп (в смысле Common) под JVM и так есть: Armed Bear Common Lisp.

А Clojure по отношению к CL примерно то же, что Python по отношению к PERL: выкинули всё, что не поняли, добавили пачку модных фич и очень усиленно пиарят.

Сложно сказать, насколько удачно, но по github'у (http://adambard.com/blog/top-github-languages-for-2013-so-far/): за 2013 год создано на clojure 4904 проекта, на Common Lisp — 1153, на Racket — 610

monk ★★★★★
()
Ответ на: комментарий от monk

Python по отношению к PERL: выкинули всё, что не поняли, добавили пачку модных фич и очень усиленно пиарят

В квотезы.

no-such-file ★★★★★
()

Зачем тебе тратить время на говно? В 21м веке от лиспа ты ничему полезному не научишься. Все, что в нем было ценного, давно уже перенесли в мейнстрим, причем не напрямую даже, а через Smalltalk. Все, что осталось, является абсолютно бесполезным и уродливым говном. Не трать свое время. Хочешь изучить полезный и «другой» язык - изучай XSLT.

anonymous
()
Ответ на: комментарий от deadlock

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

anonymous
()
Ответ на: комментарий от monk

Можно вопрос: перечисленные пункты специфичны именно для Racket, или это общие черты всех реализаций Scheme?

runtime ★★★★
()
Ответ на: комментарий от anonymous

а через Smalltalk

Че ты городишь, эксперт, из смолтока ничего не взяли в мейнстрим, разве что объектную систему в жабаскрипте. Почитай что ли Кея, для приличия, его мнение по поводу ООП.

“Я придумал термин ‘объектно-ориентированный’, и вот что я вам скажу: я не имел в виду C++.”

anonymous
()
Ответ на: комментарий от anonymous

из смолтока ничего не взяли в мейнстрим

А ничего, что HotSpot почти целиком и почти без изменений родом из SmallTalk? А кроме GC и JIT в около-лиспах ничего хорошего и не было никогда.

anonymous
()
Ответ на: комментарий от runtime

перечисленные пункты специфичны именно для Racket, или это общие черты всех реализаций Scheme?

Специфичны для Racket. Если брать «Scheme вообще», то из списка останутся continuations и макросы.

Также для Sсheme в целом характерен более академический подход в библиотеках (полнота и логичность важней простоты).

В Scheme всегда предпочитают функции (высшего порядка) макросам. Например, в CL with-open-file, unwind-protect — макросы, в Scheme аналогичные with-input-from-file, with-output-to-file, dynamic-wind — функции, последний аргумент которых — функция-тело.

Ещё один нюанс: в Scheme гарантируется tail-call optimization. В CL по факту оптимизация тоже есть, то для совместимости с ANSI CL необходимо писать циклы через do, а не через хвостовую рекурсию (также как в Си: gcc умеет TCO, но на другом компиляторе можно сломать стек, если напишешь что-то вроде void mainloop() { ... mainloop(); })

monk ★★★★★
()
Ответ на: комментарий от anonymous

кроме GC и JIT в около-лиспах ничего хорошего и не было никогда

Какая красивая иллюстрация парадокса blub :-)

monk ★★★★★
()
Ответ на: комментарий от antares0

https://github.com/deliciousrobots/cl-future

НЕт в том смысле что cl-cont оно тоже не использует.

Смотрим https://github.com/deliciousrobots/cl-future/blob/master/cl-future.asd

(defsystem cl-future
  :version "0.1"
  :author "Stephen A. Goss"
  :license "Modified BSD"
  :depends-on (:cl-cont
               :alexandria
               :fset)
   ...)

Обрати внимание на cl-cont.

Смотрим примеры

(register-action
  (lambda ()
    (with-call/cc
      (let ((f2 (make-future)))
        (princ "Hello, ")
        (setf *f2* f2)
        (wait-for *f1*)
        (wait-for f2)
        (princ "World.")
        nil))))

Обрати внимание на with-call/cc

monk ★★★★★
()
Ответ на: комментарий от antares0

Это у общелисперов так плохо с фантазией, что даже те 3.5 проектов что есть - называются одинаково? :)

anonymous
()
Ответ на: комментарий от necromant

Меньше оптимизаций, немного меньше библиотек - SBCL в этом смысле более православен. Быстрее компилирует, размер образа в несколько раз менще. Общий подход веселее и молодежнее, но не могу сказать что бы это что-то особо улучшало. Никак с старыми 32-битниками, иногда глючно с «новыми». 64 само собой присуствует. Нативные яблочные интефейсы если кому надо. Была сборка под ARM/Android но ей по моему никто не пользовался. Вобщем все почти тоже самое.

antares0 ★★★★
()
Последнее исправление: antares0 (всего исправлений: 4)
Ответ на: комментарий от antares0

Была сборка под ARM/Android но ей по моему никто не пользовался.

не запустилась, разбираться было лень - вот и не пользовался

yyk ★★★★★
()

Emasc Lisp.

anonymous
()

lisp
чтобы можно было хоть что-нибудь полезное сделать

Ты не понял, лисп не предназначен для этого, лисп работает по-другому.

anonymous
()
Ответ на: комментарий от Norgat

Clojure + Leiningen + LightTable

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

ovk48 ★★★
()
Ответ на: комментарий от NaN

Что такого есть в Clojure, чего нет в обычном нормальном лиспе?

- очеловеченный синтаксис;

- тру-иммутабельность по дефолту;

- правильные механизмы тред-безопасной мутабельности;

- все коллекции ленивые;

- нормально организованная стандартная библиотека;

- хорошая и стройная инфраструктура;

- правильный интероп с ява-миром.

ovk48 ★★★
()
Ответ на: комментарий от rogerw

а в ракете как?

В ракете разработка идёт от API и документации. Кроме того стандартная библиотека не вызывает постоянного желания всё переделать, чтобы стало удобнее. Да и наличие в требованиях к описанию пакета указания файлов документации и тестов приводит к тому, что документация и тесты есть в 90% программ, а не в 10% как в CL.

monk ★★★★★
()
Ответ на: комментарий от anonymous

не нужно, не нужно...

Если не знаешь, так разумеется «не нужно» :-)

monk ★★★★★
()
Ответ на: комментарий от monk

Кроме того стандартная библиотека не вызывает постоянного желания всё переделать, чтобы стало удобнее.

В своё время расстроило, что в command-line нельзя задать обязательность параметра.

Или всё-таки можно?

DarkEld3r ★★★★★
()
Ответ на: комментарий от monk

А нормальный FFI есть? А биндинги к Qt и GTK?

Вообще это конечно под JVM не нужно, но на яве вроде есть что-то, значит и в кложуре есть.

ovk48 ★★★
()
Ответ на: комментарий от anonymous

правильный интероп с ява-миром.

Ну не надо.

Шотакое? По крайней мере все, что под яву есть, можно использовать без лишних городулин. В обратную сторону сложнее, афаик, надо освоить магию :gen-class.

ovk48 ★★★
()
Ответ на: комментарий от ovk48

все, что под яву есть, можно использовать без лишних городулин. В обратную сторону сложнее, афаик, надо освоить магию :gen-class.

Можно подумать, :gen-class — такая сложная магия.

feofan ★★★★★
()
Ответ на: комментарий от anonymous

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

feofan ★★★★★
()
Ответ на: комментарий от feofan

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

Не понял, гц уже отменили?

anonymous
()
Ответ на: комментарий от ovk48

Например, в кложуре нет необходимости в аналогах defcfun / foreign-funcall.

Чем jna/invoke отличается от foreign-funcall ? Или ты про java? Так я тоже могу сказать, что в Racket для Swindle или Datalog мне «нет необходимости в аналогах defcfun / foreign-funcall».

monk ★★★★★
()
Ответ на: комментарий от feofan

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

В Racket она таки доступна для FFI. При сборе указателя через GC вызывается указанный финализатор для FFI объекта.

monk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.