Радикальный подход к разработке приложений

[@arvitaly]

Я обожаю LIsp, но для всех известных мне реализаций просто ужасно обстоят дела с библиотеками. Конечно, я могу дописывать свои на всех уровнях абстракции и это действительно очень круто, но с другой стороны это огромная куча времени — ведь библиотеки и их организация оттачиваются годами.

И еще один момент — создание DSL для каждого проекта безумно интересно, но работая над несколькими сразу — опять таки хочется увидеть примерно одинаковые подходы и определения. Шаблоны, контроллеры и т.д. Да, это действительно может не иметь смысла для конкретного проекта, но на практике универсальность и паттерны нужны для взаимопонимания.

Внимание, вопросы автору статьи:
1. Достаточно ли для Pico Lisp стандартных библиотек (адаптеры к БД, к http-серверам, регулярки, сокеты, потоки (нити), web-клиенты и т.д.)?
2. Насколько все это портировано на различные ОС?
3. Существуют ли web-framework'и с очерченными определениями и стандартными подходами?
4. Есть ли стабильные крупные проекты на Pico Lisp?

[@mmans]

1. Автор проекта — противник разрастания PicoLisp всяческими библиотеками по принципу (чтобы было). На этот счет как-то была дискуссия в списке рассылки. Чем это компенсируется:

a) Встроенная объектная БД очень гибкая и удобная, практически не ограничена по размерам, довольно удобный язык запросов (встроенная реализация Пролога — Pylog), плюс возможность организации распределенной БД, репликация.

б) Простой FFI (foreign function interface), при необходимости несложно вызвать функции из DLL

в) Надобность в пункте б небольшая, т.к. еще проще вызвать другую программу и распарсить вывод благодаря функциональному подходу в работе с файлами.

Потоки принципиально не используются, зато параллельные вычисления с помощью процессов широко применяются. А благодаря компактности VM и интерпретатора оверхед очень небольшой.
Веб-клиент есть. Кстати, на Rosetta Code много примеров решения задач на PicoLisp.

2. Основное требование — POSIX. На Linux, FreeBSD работает. Нативной версии под Win пока нет, никто не взялся. Есть версия интерпретатора на Java (Ersatz PicoLisp, но в ней скорее всего нет поддержки БД). Появилась 64-битная версия (в отличие от 32-битной версии переписана на ассемблере, который генерируется лиспом под различные архитектуры)

3. Да, по сути PicoLisp это и есть (самодостаточный) веб-фреймворк со встроенной БД. В поставке есть «эталонный» пример ERP-приложения в 700 строк (в папке app/) и документация к этому примеру. По словам автора, все его приложения очень похожи на этот пример, просто намного больше классов, форм и т.п. Для конечного пользователя вид может быть совершенно разным, например soccer-analytics.com, но внутри та же самая структура.

4. Опять же со слов автора, самый старый (и еще действующий) проект начат в мае 2001 г, и он же скорее всего самый большой.

[@mmans]

кстати вот свежий пример, скриптинг на PicoLisp плюс web-клиент. Скрипт парсит перевод слова с сайта dict.leo.org. Насколько я знаю, автор PL для скриптов предпочитает использовать его вместо bash

[@diseaz]

Pico Lisp — штука интересная, а вот статья, честно говоря, не блещет. Какой-то очередной манифест за интерпретируемость против компилируемости.

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

ради интереса я установил CLisp и сравнил его с Pico Lisp

С каких это пор CLisp стал считаться компилируемым? То, что он компилирует в байт-код не отменяет интерпретации этого байт-кода. Сравнивайте хотя бы с SBCL тогда уж.

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

Ну да, поэтому мы не будем брать этот пример, на котором компиляция хорошо себя проявляет, а возьмем пример, где основное время уходит на управление памятью, а интерпретация/выполнение кода ~1% от всего времени.

может быть написано прямо на C, если это критично по времени (в этом случае выполнение заняло бы всего 0.2 с)

Лучшие компиляторы Lisp вполне приближаются по скорости полученного кода к C, особенно на вычислительных задачах. И говорить, что 30–60-кратное замедление не критично, нельзя.

Миф 2: Лиспу Необходимо Множество Типов Данных

Ну, если не обращать внимания на 60-кратное замедление, то можно и без всяких типов обойтись — компилятор сам разберется.

С другой стороны, Pico Lisp поддерживает только три встроенных типа данных

И можно сказать, что программа, частично написанная на C из-за недостатка скорости, написана на Lisp, а компиляторы, которые позволяют всю программу написать на Lisp, всего лишь дав компилятору подсказки в виде типов данных, не нужны.

[@arvitaly]

Большое спасибо, понятно, есть вопросы/комментарии:

а) Опять таки интересуют бенчмарки, т.е. понятно что для небольших проектов можно и в одном файле в списках базу сделать ((:a 1 :b «aaa» :c 0)… :-) Но меня интересуют именно высокие нагрузки и большие БД. Есть ли сравнительные тесты где-то?
б) Ну это как раз то о чем я говорю, конечно WinAPI и Posix это очень круто, но это низкий уровень и не хочется для каждого проекта делать одно и то же. С другой стороны написание собственных библиотек без поддержки со стороны платформы означает очень высокий порог входа следующих программистов проекта.
в) Эмм, нет не проще. Запуск процесса это огромная бессмысленная трата ресурсов. CGI никем не используется именно по этой причине, а если на каждый запрос еще и множественные процессы создавать…

2. Жаль, люблю работать под Windows. Вообще проблема lisp-ов :-)
3. Вот это интересно, думаю все же посмотрю. Опять таки повторюсь сразу и для 4 пункта, что 1 большой проект да, оправданно и удобно реализовывать на DSL, для нескольких важна узнаваемость.

[@mmans]

вот что нашел по бенчмаркам: NeedForSpeed (свежее), database contest
Суть: еще в 2006-ом PicoLisp занял в 2ое место в конкурсе по СУБД немецкого журнала c't

Pico Lisp made the second place in the DB-Contest of c't magzine (c't
13/06, pp. 190)!… And got an extra medal for the «most original and
surprising program»

По http-серверам: был период, когда выяснилось, что PL быстрее, чем TPD2.

По поводу запуска процесса не соглашусь. Насколько знаю, PicoLisp использует fork запуска дочернего процесса, а у fork-а как раз небольшие расходы, поправьте если ошибаюсь.

Насчет больших БД: автор упоминал как-то об одном проекте с БД около 500Гб, так что с размерами тоже все довольно неплохо. Вообще одним из принципов числится «Unlimited» — размеры структур искусственно не ограничены.

[@andy128k]

Динамическое связывание, списки, интерпретатор, отсутствие типов… Да это же LISP 1.5 из 1960-го!
Сравнение с CLisp вообще умилило. Pico Lisp всего лишь в два раза медленнее самой медленной реализации Common Lisp.

[@anjensan]

Интересно, знаком ли автор с Clojure? Не совсем Lisp, с другой стороны нету проблем ни со скоростью, ни с библиотеками. Ну и конечно ФП — это круто.

[@mmans]

Нет, говорит, только читал немного Clojure-кода на rostettacode.org. Да и смысл ему разбираться в Clojure, если у него есть свой инструмент, который вполне устраивает практически для всех задач, вплоть до замены bash-скриптов?

[@qrasik]

Ну вот, осталось самое главное.
1. Как это правильно собрать под Win/Lin
2. и красивые примеры использования в роли DB и HTTP сервера

[@mmans]

Под Win — можно либо в Cygwin (неск. лет назад пробовал — у Cygwin толком не работали файловые блокировки, а без них multi-user БД в принципе не юзабелен). Но лучше я бы советовал глянуть в сторону coLinux или andLinux.
На Linux:
1) Качаем и распаковываем куда-нибудь в ~/picoLisp/ свежую тестовую версию
2) Ставим gcc и с++
3) Если нужен 32-битный интерпретатор, то (cd src && make picolisp) (для обучения и использования в интранет этого достаточно).
Если нужно собрать 64-битный интерпретатор, то тут чуть посложнее — нужно или сначала собрать 32-битную версию, или иметь установленный Java-рантайм в системе, или (последний вариант), скачать software-lab.de/x86-64.linux.tgz и распаковать в src64/. Это объясняется тем, что 64-битный PicoLisp написан на «псевдоассемблере», из которого генерируется ассемблерный код под конкретную архитектуру процессора (на сегодняшний день поддерживаются x86-64, ppc64 и 64-битный эмулятор для x86). А для генерации как раз нужен работающий интерпретатор.
Если коротко, то в первый раз 64-битную систему пробуем собрать так:

$ (cd src; make)
$ (cd src64; make x86-64.linux)

Насчет красивых примеров — даже не знаю. Задачку надо какую-нибудь практическую. В планах еще PicoLisp tutorial перевести, но пока особого интереса к теме не наблюдаю

[@qrasik]

> у Cygwin толком не работали файловые блокировки, а без них multi-user БД в принципе не юзабелен
Для пробы и/или разработки вполне терпимо. Правда у меня собралось несколько странно. Видимо был невнимателен.

> Задачку надо какую-нибудь практическую.
web-магазин по продаже подержанных депутатов :-)

> но пока особого интереса к теме не наблюдаю
Как правильно подмечено в анекдоте:
… Сынок, так ты не немой? А почему же ты молчал?
А меня раньше все устраивало!…

Разработка ERP систем, да еще и на LISPе, согласитесь, не для всех. А у серьезных людей не всегда есть время на комментирования всего подряд. Работа, дети, общение с друзьями в off-line… Но в закладки вас это добавить совсем не помешало.

[@mmans]

Для пробы и/или разработки вполне терпимо. Правда у меня собралось несколько странно. Видимо был невнимателен.

Оно вполне могло сломаться за эти годы: под Cygwin специально никто не тестирует. Будет время — тоже гляну.

web-магазин по продаже подержанных депутатов :-)

Ого, у вас уже депутатов продают. Шутку оценил :)