Комментарии 53
метод с ошибкой не корректен. Т.к. надо разделять production и не production окружения. А когда разработка идет на production окружение сразу… За это, в приличных местах, кандилябром по лицу бьют!
Лисп немного другой :)
Я согласен, что нужно разделять окружения, но метод с ошибкой совершенно ортогонален. NASA «Deep Space 1» был вполне себе production, но и в production бывают ошибки, требующие исправления на живой системе. В этом отношении подход лиспа в том, чтобы не превращать production в застывший монолит, расчитывая что он будет более или меннее совершенным, а оставлять его пластичным и чуточку сырым, чтобы при случае можно было внести изменения. Впрочем, я еще не настоящий джедай и возможно чего-то не понимаю :)
Я согласен, что нужно разделять окружения, но метод с ошибкой совершенно ортогонален. NASA «Deep Space 1» был вполне себе production, но и в production бывают ошибки, требующие исправления на живой системе. В этом отношении подход лиспа в том, чтобы не превращать production в застывший монолит, расчитывая что он будет более или меннее совершенным, а оставлять его пластичным и чуточку сырым, чтобы при случае можно было внести изменения. Впрочем, я еще не настоящий джедай и возможно чего-то не понимаю :)
отличная статья, еще раз доказывает то, что не главное на чем написано, а как написано!
Не увидел ни одного из 9 общеанных шагов. «Запускаем имакс, настраиваем SLIME и SWANK», конечно, относятся к веб-сайту, но с таким же успехом можно было написать «покупаем ПеКа для учебы и ставим на нем линукс» — вроде бы тоже имеет отношение, но как-то слабо раскрывает тему.
слишком много сраных скобок
НЛО прилетело и опубликовало эту надпись здесь
Лисп смеётся мне в лицо!
Но на самом деле, имхо, код достаточно приятен. И эти смайлики только поднимают настроение.
Но на самом деле, имхо, код достаточно приятен. И эти смайлики только поднимают настроение.
Как будто религия запрещает скобки развернуть
(defmethod hunchentoot:acceptor-request-dispatcher ((acceptor debuggable-acceptor))
(if *catch-errors-p*
(call-next-method)
(let
(
(dispatcher
(handler-bind
((error #'invoke-debugger))
(call-next-method)
)
)
)
(lambda (request)
(handler-bind ((error #'invoke-debugger))
(funcall dispatcher request)
)
)
)
)
)
ЛИСП всегда иронично называли кучей дурацких скобок, а уж когда ты пишешь, не «трех строчный код», а программы, это превращается в целый ужас — вспомнить где что. Вспоминая карточную игру с «аи», которую заставляли писать в качестве ДЗ на нем, аж слезятся глаза.
fat0troll, о чем с тобой говорить, если ты думаешь что он чисто академический?
fat0troll, о чем с тобой говорить, если ты думаешь что он чисто академический?
«На любом языке можно писать как на Фортране» Ⓒ
В следующих постах будет много примеров кода — как понятных, так и запутанных и все их можно будет обсудить как с точки зрения читабельности, так с точки зрения архитектуры.
Мне кажется, что я смогу показать, что лисп — читабельный, понятный и выразительный язык
В следующих постах будет много примеров кода — как понятных, так и запутанных и все их можно будет обсудить как с точки зрения читабельности, так с точки зрения архитектуры.
Мне кажется, что я смогу показать, что лисп — читабельный, понятный и выразительный язык
НЛО прилетело и опубликовало эту надпись здесь
«В данный момент я разворачиваю его вместе с вами… и в конце статьи вы сможете убедиться в том, что по крайней мере у меня все заработало.»
Минимум один внимательный читатель, спасибо :)
89.108.75.126/
89.108.75.126/
Ошибка многих статей про Common Lisp — это сваливать в одну кучу ASDF и ASDF-Install/Quicklisp/clbuild/…. Надо понимать, что это инструменты разного класса:
- ASDF загружает код из файлов в «живой» образ лиспа. Он не является пакетным менеджером.
- ASDF-Install/Quicklisp/clbuild и прочие используются для доставки кода на жесткий диск, после чего ASDF загружает код с жесткого диска.
<? print «Hello»; ?>
:))
:))
Как то не вяжется описанный метод установки с аватаркой вначале поста. Этот человек не будет устанавливать лисп как трус: сначала с пакетного менеджера, а потом компилить. Я вообще не уверен что его пакетный менеджер сразу бинарные пакеты устанавливает.
Позвольте полюбопытствовать: чем обусловлен выбор Common Lisp? Я имею ввиду именно этот диалект.
- Распространенность
- Хорошая поддержка юникода — было важным доводом в сравнении с php, например :)
- Cтабильность, в сочетании с частыми минорными релизами
- Кроссплатформенность (в том числе и в среде разработки — Емакс есть везде) вместе с быстродействием моей реализации — SBCL компилирует в машинный код
- Значительное количество библиотек (см. CLiki)
- Обширное лисп-комьюнити, в том числе множество квалифицированных рускоязычных пользователей(archimag dmitry_vk swizard.livejournal.com и другие)
- Множество вменяемых руководств (Practical Common Lisp, OnLisp, Мир Лиспа)
- Мощность макросов
- Развитая объектная подсистема (CLOS)
- Репутация языка
Я сейчас на перепутье какой из трех диалектов лиспа учить — Scheme, Common Lisp или Clojure. Scheme мне почему-то очень нравится + сейчас смотрю SICP где он используется.
Clojure сравнительно молодой и динамино развивающийся, он есть для JVM и CLR.
Common Lisp очень старый и умеет все, но чем-то он мне не нравится (cкорее всего словом defun).
Clojure сравнительно молодой и динамино развивающийся, он есть для JVM и CLR.
Common Lisp очень старый и умеет все, но чем-то он мне не нравится (cкорее всего словом defun).
В таком случае при прочих равных стоит брать Common Lisp как наиболее зрелый и содержащий большее количество интересных идей.
Аналогично. Плюс лично мне дико не нравятся
-убогие макросы
-два неймспейса (привет, функол)
-стрёмные названия функций
В свою очередь, мне сильно нравится тамошний for. Но его можно переписать на какой угодно макросистеме при желании.
Только тогда уж не Scheme, а Racket. Для него тоже есть веб-фреймворки, причём один из них «из коробки».
-убогие макросы
-два неймспейса (привет, функол)
-стрёмные названия функций
В свою очередь, мне сильно нравится тамошний for. Но его можно переписать на какой угодно макросистеме при желании.
Только тогда уж не Scheme, а Racket. Для него тоже есть веб-фреймворки, причём один из них «из коробки».
Собственно у меня Racket и стоит, хотя от изменения названия в нем меньше Scheme не стало (при #lang racket он все равно поддерживает R6RS).
В убогости макросов CL их сила. В сложности макросов Racket их слабость.
Два неймспейса — это спорный момент. Но практика показала что проблемы LISP-1 принципиальные, а LISP-2 — эстетические, как и название defun.
Идей действительно интересных много, но, похоже, кроме PLT они никому не нужны… к сожалению.
Два неймспейса — это спорный момент. Но практика показала что проблемы LISP-1 принципиальные, а LISP-2 — эстетические, как и название defun.
Идей действительно интересных много, но, похоже, кроме PLT они никому не нужны… к сожалению.
>В убогости макросов CL их сила. В сложности макросов Racket их слабость.
1) Макросы Racket вполне себе простые. Что вообще может быть проще паттерн-матчинга?
2) Само утверждение напоминает приснопамятное «Война — это мир. Свобода — это рабство. Незнание — сила».
>проблемы LISP-1 принципиальные
Например?
1) Макросы Racket вполне себе простые. Что вообще может быть проще паттерн-матчинга?
2) Само утверждение напоминает приснопамятное «Война — это мир. Свобода — это рабство. Незнание — сила».
>проблемы LISP-1 принципиальные
Например?
> Что вообще может быть проще паттерн-матчинга?
Жонглирование символьными выражениями. В нетривиальных случаях оказывается куда проще.
> Например?
Вы правы, недостатки и там и там чисто эстетические.
Жонглирование символьными выражениями. В нетривиальных случаях оказывается куда проще.
> Например?
Вы правы, недостатки и там и там чисто эстетические.
«жонглирование символьными выражениями» ещё более нетривиально. Попробуйте описать рекурсивный макрос для какого-нибудь факториала без gensym'ов и прочих хаков. В Racket'е о таких вещах задумываться не нужно — автоматическая гигиена всё сделает сама. Плюс ещё много нужных и приятных вещей: www.cs.indiana.edu/~chaynes/danfest/dyb.pdf
Автоматическая гигиена Racket — точно такой же хак как и gensym.
В одном случае это надо держать в уме, в другом — нет. Плюс к тому, система макросов Racket умеет в точности то же самое, что и CL (в либе даже defmacro есть для любителей), но умеет и многое другое — потому как оперирует не голыми s-expr, а s-expr с дополнительной лексической информацией. Именно поэтому макросистема CL является строгим подмножеством макросистемы Racket.
а почему не используете nohup?
У коллег ровно один аргумент против CL — отсутствие бесплатных хостингов. Пожалуйста, скажите что я просто не умею их искать.
Мы же серьезные, взрослые люди или стремимся произвести такое впечатление :) При развитии проекта в любом случае потребуется хостинг и лучше сразу начинать с хорошего. Можно поспрашивать у друзей, мне например catap предлагал сравнительно дешевый хостинг под Common Lisp. Никто не запрещает кооперироваться. Ну а если хочется попробовать — все можно делать на своей машине.
* (ql:quckload 'swank)
опечатка, пропущена i
опечатка, пропущена i
НЛО прилетело и опубликовало эту надпись здесь
Начиная с hunchentoot 1.2.0 HUNCHENTOOT:ACCEPTOR-REQUEST-DISPATCHER более нету , также нету поля hunchentoot:acceptor-dispatch-request. Вместо них можно использовать
Пожалуйста, исправьте.
(defmethod hunchentoot:acceptor-dispatch-request ((acceptor debuggable-acceptor) request) ...) Пожалуйста, исправьте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настоящий веб-сайт на Common Lisp за 9 шагов