Комментарии 12
Большое спасибо за перевод.
Я один из тех, кто разрабатывает веб-приложения на hunchentoot вместо использования лучшего. Теперь присмотрюсь к Clack. Собственно ушел смотреть :)
Я один из тех, кто разрабатывает веб-приложения на hunchentoot вместо использования лучшего. Теперь присмотрюсь к Clack. Собственно ушел смотреть :)
0
А вот скажите, чем Common Lisp лучше того-же Clojure? Не холивар, серьезно интересно.
+2
Они очень разные, Common Lisp это самостоятельный, полноценный, мультипарадигменный язык с составлявшимся годами стандартом. Clojure сложно назвать самостоятельным. Насколько мне известно, например в нем нет собственной реализации объектной системы, используется доступная в JVM, в нем нельзя управлять стеком вызовов и сделать аналог condition-restart из Common Lisp, даже хвостовая рекурсия поддерживается только через специальный оператор recur. Вобщем все ограничения (и плюсы) JVM так или иначе отражаются на нем.
Common Lisp в противовес определяется стандартом, а не идеями одного человека и ограничениями платформы, так он не позиционируется как функциональный с точки зрения иммутабельности данных (это есть в библиотеках), дает контроль над ридером благодаря ридер-макросам (в кложуре появилось что-то отдаленно похожее для определения текущей платформы, clojure или clojurescript) и тд.
По-моему Clojure это больше скриптовый язык для Java-приложений, а Common Lisp для написания на нем всего что может быть нужно, вплоть до ассемблерного кода.
Common Lisp в противовес определяется стандартом, а не идеями одного человека и ограничениями платформы, так он не позиционируется как функциональный с точки зрения иммутабельности данных (это есть в библиотеках), дает контроль над ридером благодаря ридер-макросам (в кложуре появилось что-то отдаленно похожее для определения текущей платформы, clojure или clojurescript) и тд.
По-моему Clojure это больше скриптовый язык для Java-приложений, а Common Lisp для написания на нем всего что может быть нужно, вплоть до ассемблерного кода.
0
Спасибо за ответ. Со стороны Clojure люди говорят, что другие лиспы для современных (читай, многопоточных) приложений подходят слабо, было интересно мнение другой стороны.
0
Например, в кложуре стандартные джавные исключения из-за ограничений платформы. И крайне неинформативные трейсы на 100 уровней.
0
БОЛЬШОЕ СПАСИБО за Вашу статью!!! Пошел смотреть на CommonQT… Меня очень радует тот факт, что такой классный язык как Common Lisp развивается, появляются новые библиотеки и фреймворки. Это — КРУТО!!!
+2
А как насчет Racket? Может быть кто-нибудь использова и то и другое? Я сейчас как раз вибираю между ними.
0
Я пробовал года 3 назад, написал модуль с кастомной авторизацией толи для апача, толи нгинкса и веб интерфейс к сканеру через sane. Собственно с обоими задачами хорошо справился, у Racket из коробки огромная стандартная библиотека (в CL все это тоже есть, только отдельным пакетами), и подробная документация, так что начать с ним проще. Но количество библиотек в CL значительно больше, и, так скажем они более production ready. Хотя это субъективно и может на текущий момент что-то да изменилось.
Порекомендую CL как более практичный вариант.
Порекомендую CL как более практичный вариант.
+1
здравствуйте, в каком состоянии на сегодня Lisp направления? А то некоторые из ссылок выглядят полумертвыми без какой либо свежей информации. Что то еще развивается?
Очень заинтересован языком и его реализациями
Очень заинтересован языком и его реализациями
0
Насчёт статей не знаю, но списки библиотек есть:
http://lisp-lang.org/wiki/article/recommended-libraries
https://github.com/CodyReichert/awesome-cl
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Состояние экосистемы Common Lisp на 2015 год