QuckLisp: how to use my own local changes?

One of the first beginner’s questions regarding using QuickLisp is – how to build some Common Lisp project and to see the effect of the local changes if this project is already in the QL-repository? The problem is – each time, when you try to build such project, QL will try to download sources from its repository and that means that local changes will be ignored. First you will maybe try to change the build configuration asd-file, right? This is the wrong way.
In QuickLisp blog I found one post about The Quicklisp local-projects mechanism. One of the goals of this mechanism is to override libraries Quicklisp does provide. Namely, the solution is just a PATH of such projects, i.e. you just should to clone your git-repo into ~/quicklisp/local-projects directory. That location tells QuickLisp to use local source tree and doesn’t use some remote QL-repositories during the build process. You don’t need to change some asd-file or something like that. Good luck and don’t forget to have a lot of fun with Common Lisp 😉

Let over Lambda

Ведется работа по переводу книги Let over Lambda…
Я начал писать этот пост почти год назад. Я хотел привлеч внимание русскоязычных ЛИСПеров к процессу перевода. Возможно кто-то нашел бы время и оказал бы помощь. Не опубликовал я этот пост тогда потому, что даже для перевода книги нужно разрешение автора. Иначе это нарушение авторских прав. Сейчас уже перевод закончен, а переводчик (Ametov Imil, ник Charlz_Klug) получил разрешение от автора на публикацию своего труда (автор постепенно, глава за главой, открывал материал). Я вернулся к этому посту и решил закончить начатое. Хоть замысел теперь не столько в поисках волонтеров-переводчиков, сколько в информации о наличии перевода как такового, который уже закончен и ждет читателей 🙂

Итак, исходники перевода книги можно скачать тут. Для сборки книги openSUSE-пользователям понадобится доустановить пару пакетов:

> sudo zypper in texlive-upquote
> sudo zypper in texlive-collection-langcyrillic
> sudo zypper in texlive-cyrillic

Большое тебе спасибо, Имиль, за перевод. Книга классная. Уверен, многие весело проведут время, эксперементируя с макросами Common Lisp, которым посвящена книга 😉

Paradigms of Artificial Intelligence Programming

Наконец-то получил заказанную накануне книгу Paradigms of Artificial Intelligence Programming Питера Норвига. До того как купить её, я получил в рунете немало негативных отзывов о ней. Связанны они были главным образом с тем фактом, что книга эта очень старая, т.е. матерал безнадежно устарел, а методики программирования, описанные в ней, уже давно не используются. Должен сразу сказать, что подобные заявления по поводу Lisp, лично у меня всегда вызывали только улыбку 🙂

This book can lead to a deep appreciation of the unique strengths of Lisp and help the reader understand why Lisp is still in active use nearly 40 years after it was first developed

Серьезно. Я не поленился написать этот пост, поделиться с вами, потому что в действительности это и сегодня очень ценный труд по программированию искуственного интеллекта. Книга всего на 3 года старше “ANSI Common Lisp” Пола Грэма, перевод которой так тепло был принят в сети всего 2 года назад.

Материал в PAIP подробнее описывает не только сам Common Lisp, но и переплетается с идеями и методами, используемыми в программировании ИИ, что делает чтение ещё интереснее. Книга является богатым источником интересный идей и примеров. На протяжении почти 1000 страниц, автор (кстати, знакомый нам также своей статей “Научитесь программировать за десять лет”) приводит 10000 строчек исходного кода (доступного в интернете). В сети также можно найти немало обсуждений приведенного в книге кода.

Книга использовалась на протяжении многих лет как учебник в лучщих computer science универстетах США. Каждая из её 25 глав включает в себя около 10 упражнений разной сложности. Более подробное описание книги можно найти тут.

Цена за книгу на амазоне варьируется, но в общем она меньше, чем цена за ее доставку 😉

(format t “more than 80 characters per line”)

Столкнулся сегодня с интересной особенностью функции format в Common Lisp. По умолчанию она выводит только по 80 символов на строку, а остальную часть переносит на следующую. Причина такого поведения, как вы уже догадались, историческая, и заключается в том, что раньше большинство UNIX терминалов использовало только 80-символьные строки на экране (наследие перфокарт IBM?).

До этого мне никогда не нужны были строки длинее, но сегодня я решил переписать один из своих скриптов, а именно: в качестве вывода использовать CSV– вместо XLS-файла. Так как скрипт просто генерировал таблицу, то я не стал для этого подключать целую библиотеку для работы с CSV, а решил самому написать функцию для создания файлов этого формата.

CSV означает Comma-Separated Values, т.е. это простейший формат таблиц, где существует только два правила: каждая новая строка в нашем файле будет новой строкой в таблице; для сток должен указывается так называемый разделитель (по умолчанию это запятая), который будет делить строку на ячейки (или столбцы). Другими словами, если в нашем выводе встречается символ новой строки, CVS перенесет весь остальной вывод на новую строку и продолжит заполнять ячейки уже на ней.

Common Lisp: more Libraries, more Frameworks, more fixes…

Пожалуй позволю себе еще один пост о Lisp, а именно – о его использовании “в продакшин”. Буквально на этой неделе на хабре снова был очередной пост-перевод на эту тему, к тому же я сейчас практически все свободное время на работе посвещаю переписыванию некоторых скриптов с Python на Common Lisp, что является причиной интереса коллег к этой теме.

Но мой пост все же будет отличаться от большинства других. Дело в том, что я считаю неправильным саму постановку вопроса. Когда я читаю комментарии обоих сторон, я замечаю, что говорят они о разных вещах. Сам Lisp, как таковой, т.е. ядро этого языка, на много мощнее Python (давайте будем сравнивать его с Python, раз уж последний уже вытесняет Perl, а Ruby пока составляет ему конкуренцию только в Web). Обратите внимание на книги по Python (или другим языкам программирования), они как правило начинаются с описания типов данных. Я помню как не знал с какой стороны подойти к Lisp, когда так привык к python’новским dictonary. Этот тип данных является ядром самого Python. Но даже начального знакомства с Lisp (это было уже на первой неделе работы с Lisp) мне хватило, чтобы реализовать свой тип данных, который позволял мне делать тоже самое в Lisp, что и dictonary в Python (в процессе написания я нашел в сети информацию о Lisp-хеш-таблицах, но все же решил довести дело до конца). Я до сих пор под впечатлением, что в моем арсенале теперь есть язык, который позволяет создавать абстрации, ограниченные по возможностям лишь моей фантазией и представлением о том, что и как “можно”.

Но правы и те, кто забрасывают риторические, как им кажется, вопросы о столь низкой популярности Lisp. Правы они в том, что он действительно совсем не популярен. Но вовсе не потому, что сам язык в чем-то уступает. Дело тут в библиотеках, а точнее – в поддержке этих библиотек сообществом. На домашней странице проекта Quicklisp гордо значится число поддерживаемых библиотек:

Quicklisp is a library manager for Common Lisp. It works with your existing Common Lisp implementation to download, install, and load any of over 1,200 libraries with a few simple commands.

Да, более 1200 библиотек поддерживается этим library manager’ом, но это значит лишь, что я могу без проблем найти их, установить и использовать в моем Lisp-проекте. Это совсем не значит, что все эти библиотеки хорошо документированны, и существуют примеры в сети как ими пользоваться. Вовсе нет. Есть сообщество пользователей, да. Кто-то из них наверняка использует, к примеру, SMTP или SQL, поэтому вы, я думаю, без проблем найдете в сети пару примеров, а может быть даже блог-посты, а может быть даже страницу, посвященную этой библиотеке, с подробным описанием функций. Но есть в их числе и те, которые написал какой-нибудь прыщавый студент-очкарик несколько лет назад, и теперь, возможно, после того как нашел работу или завел семью, не занимается поддержкой своей библиотеки. Я не буду приводить пример. Библиотекой пользоваться очень не просто, т.к. она устарела, нет документации, нет примеров… а альтернативы, т.е. другой библиотеки для тех же целей, в Quicklisp нет. Если вы использовали GNU/Linux или BSD-системы в 90х или даже начале 2000х, то вы можете себе предствить о чем идет речь.
В Python такой проблемы нет, ну или почти нет. Этот язык окружил себя сегодня просто огромным сообществом, которое само-собой является поддержкой этого языка. То там то здесь появляются все новые и новые библиотеки, framework’и. Наконец, у Python есть Pyton Foundation.
Да, полка книг о Python есть и у меня, так что на ближайшие 5-10 лет по поводу трудоустройства, я думаю, мне можно не переживать. Кстати, если вы интересовались поиском работы в Европе, то наверняка слышали про stepstone.de. Посмотрите сколько мест она вам выдаст по запросу “Java” или “.NET”, а теперь скажите: вы находите стиль Java столь элегантным, выразительным, а сам язык мощным или просто продуманным? 🙂 Ее популярность обусловлена совсем другими причинами. Java, как и .NET, это два единственных в мире Enterprise языка программирования. А это, к сожалению, не имеет совсем никакого отношения ни к удобству использования, ни к продуманным типам данных, ни к простоте и стилю языка, а также не самым лучшим образом отражается на ее лицензии 😉

Я хожу по тонкому льду, позволяя себе такую роскошь как специализацию только на Free Software технологиях и системах, а так же программирование на тех языках, которые действительно приятно использовать, а не тех, которые так популярны по той или иной причине (хотя причина, как мы знаем, как правило всегда одна и та же).

Как Java и .NET обходят по популярности (на рынке труда) Python, так же и Python обходит Common Lisp. Но все же что-то приводит Java-программитов к Python, Perl или Ruby, а те, кто знаком с последними, рано или поздно хотя бы поверхностно знакомятся с Lisp. Ко второй группе отношусь и я, и я должен сказать, что код на Python лучше (в функциональном стиле?) пишет тот, кто знаком с Python и Lisp, чем тот¸ кто пишет только на Python. Возможно не все поймут последнее предложение, а Python-only программисты c ним, т.е. со мной, не согласятся 😉

Да, наша команда использует Common Lisp “в продакшин”, и я рад, что есть те, кто поддерживают необходимые для нас библиотеки. Я благодарен им. Программирование на Common Lisp интересней. Возможности обработки данных намного мощнее. Если получится доработать/починить некоторые библиотеки, которые нам нужны, я не против переписать весь python код на Common Lisp. Если это действительно получится, я обещаю выложить фиксы в отрытый доступ и посвятить пару блог-постов примерам и просто описанию этих библиотек.

Common Lisp, MySQL and openSUSE

С недавних пор позволил себе наглость писать на Common Lisp’е (CL) на работе. Добрался до скриптов, которые до меня были написанны на perl’e, а точнее – понадобилось кое-что в них добавить, и я решил, что переписать их на CL будет и быстрее и полезнее для меня. Скажу сразу, что нет ничего, что можно сделать на CL, но нельзя, к примеру, на perl или python. Другим будет лишь подход к решению, несмотря на то, что, к примеру, на python тоже можно очень не плохо писать в функциональном стиле. Именно из-за этого подхода программисты CL находят его использование столь интересным, гибким и выразительным.
В этом посте я постараюсь показать, что в использование CL нет ничего сверхестественного. Дополнительные библиотеки, скачиваемые из интернета, стандартная библиотека языка… постораемся сделать что-то практическое.

OpenBSD – stumpWM

Лёгким движением руки брюки превращаются… Брюки превращаются… Превращаются брюки… В элегантные шорты. Простите, маленькая техническая неувязка.

Да, для установки stumpWM в OpenBSD действительно достаточно лёгкого движения руки: пару команд и эту ОС будет намного интересней использовать в качестве десктопа. Надеюсь, у нас маленьких технических неувязок не получится 😉

Используется дефолтная конфигурация OpenBSD. Нет ни wget, ни curl. Lisp-интерпретарора тоже нет.

# pkg_add wget
# pkg_add sbcl

> wget http://beta.quicklisp.org/quicklisp.lisp

> sbcl --load quicklisp.lisp --eval "(quicklisp-quickstart:install)" \
--eval "(ql:add-to-init-file)"
> sbcl --eval "(ql:quickload \"stumpwm\")"

> cat ~/.xsession
exec /usr/local/bin/sbcl --eval "(ql:quickload \"stumpwm\")" --eval "(stumpwm:stumpwm)"

> cat ~/XTerm
XTerm*foreground: darkgreen
XTerm*cursorColor: darkgreen
XTerm*background: black
XTerm*scrollBar: True
XTerm*saveLines: 1000
XTerm*font: 9x15

Естественно XTerm вы можете настроить как захотите. Этот файл можно вообще не создавать. Файла ~/.xsession в свежей системе нет. Создайте его и добавтье exec-строку. Я использую xdm для запуска X Window.

openSUSE :: stumpWM

When you think about GNU/Linux, you probably think about servers or data storage systems. It could be also development machines or maybe desktops (but probably not). For me GNU/Linux was always place for different experiments and also platform on which I can implement my ideas (which often break system). So, today I would like to tell a bit about the Stump Window Manager.

Let’s start by saying that stumpWM is a tiling, keyboard driven X11 Window Manager written entirely in Common Lisp, and Common Lisp is a one of dialects of the Lisp – a family of a multi-paradigm programming languages (supports a combination of procedural, functional, and object-oriented programming paradigms). There are many reasons to use stumpWM. For example, you would like to have benefits of tiling window managers (its tiling windows to use the whole screen and focus on a user experience which is highly keyboard driven operation), or maybe you just want to learn Common Lisp (as we all know, reading the source code of a big professional project is a good idea when you learn a new programming language).

“ANSI Common Lisp” Paul Graham

Наверняка многие Lisp’еры вначале изучения этого языка читали статью Побеждая посредственность, в которой Пол Грэм рассказывает о причинах успеха компании Viaweb, основанной им с Робертом Моррисом. Статья безусловно захватывающая. Пол, словно шутя, объясняет, как без особых проблем они обходили конкурентов, подогревая тем самым интерес читателя к Common Lisp.
После прочтения этой статьи задаешься вопросом о книге, по которой можно было бы познакомиться с этим удивительным языком, который Пол сравнивает с секретным оружием. Многим хочется разобраться во вкусностях языка как можно быстрее, поэтому очень популярной книгой среди новичков является Practical Common Lisp. С этой книги начинал и я. В ней делается акцент именно на практическое применение языка. Проблема в том, что, как правило, к ФП приходят уже после изучения нескольких императивных языков, а это два совершенно разных подхода к дизайну программ. Пока вы не научились думать функционально, пользы от использования функциональных языков будет немного. Именно поэтому, параллельно с обучением языку, так важно показывать примеры, написанные в функциональном стиле, а также рассказывать и сравнивать их с примерами, написанными на императивных языках.
Пол подарил нам не только статью, о которой я упомянул в начале, он также является автором книги “ANSI Common Lisp”. В отличие от Practical Common Lisp, в ней очень хорошо сбалансированн материал и по функциональному подходу, и по знакомству с синтаксисом Common Lisp, т.е. очень хороший вариант для начинающих. Стоит также отметить краткость, простоту и доступность материала, что очень важно, когда речь идет именно о введении в язык.

Я так увлекся рассказом о ФП, что совсем упустил основную идею. В ноябре прошлого года издательство “Символ-Плюс” представило перевод этой книги. 17 лет книга ждала перевода на русский язык. Конечно кто-то скажет, что переводы не нужны, а читать все и вся нужно на языке оригинала. Не буду спорить. Скажу лишь, что я рад, что документации о Lisp и функциональном программировании на русском языке становится все больше 🙂

openSUSE :: Common Lisp Packaging Guide

About week ago Andreas Jaeger started discussion about packaging guidelines change process.
The packaging guidelines regulate all the nitty gritty details of packaging for the openSUSE distribution. There are general rules, rules about legal aspects of a package, about specific package features and about specific package types.

Until now we haven’t official rules for Common Lisp packages. For this reason I created a new page about it: Lisp Packaging Guidelines. You can find there rules and a bit information about Common Lisp packaging related stuff. It is still not official! I would like to invite all of openSUSE packagers and Lisp developers to join discussion about this and find the most interesting, correct, handy and optimal rules for openSUSE distribution (please discuss before change something in wiki).

Russian edition: Common Lisp the Language, 2nd Edition (Guy Steele)

Решил помочь с переводом книги Common Lisp the Language (by Guy Steele). Книга распространяется бесплатно и доступна для чтения в online.

Проект перевода был начат Михаилом Филоненко – Lisp хакером из Минска, который оформил в LaTeX исходники 23 глав книги на русском, и выложил их на github.com (фактически он один перевел почти всю книгу; работа над переводом сейчас – это просто вычитка: поиск опечаток/ошибок/неточностей).

Зачем перевод? Перевод это скучно. Я не раз слышал этот контраргумент. Я занимаюсь переводом многих интересующих меня проектов по нескольким причинам:

• Практика работы с той или иной технологией. В данном случае это git и LaTeX.
• Культура. Free and Open Source cообщество. Альтруизм 🙂
• Перевод как способ заставить себя вчитываться по-настоящему внимательно. Читая ту или иную научную документацию, не раз замечал, что, после прочтения нескольких страниц, я не могу пересказать то, о чем только что прочитал. Все вроди бы понятно, но, читая не сосредоточившись, смысл ускользает. Остается уверенность, что материал пройден и понят. Уверенность эта ошибочная 🙂
  Переводя текст вы вдумываетесь в каждую мысль автора. Пытаетесь сформулировать эту же мысль на другом (как правило – родном) языке, т.е. не повторяете слова при пересказе, а ищите синонимы из другого языка. Переводя абзац за абзадцем, страницу за страницей, выстраивается целая смыславая цепочка из мыслей. Вы пересказываете и записываете каждую мысль, что является залогом понимания и запоминания материала.
• Я люблю проекты, которыми занимаюсь. Lisp, openSUSE, OpenBSD… мне просто нравится быть частью этого. Занимаясь этим я постоянно узнаю что-то новое.

Ну и напоследок немного практики на всякий случай для тех, кто ещё захочет помочь. Скачиваем исходники книги:

> git clone --depth 1 https://github.com/filonenko-mikhail/cltl2-doc

Переходим в каталог с исходниками и собираем книгу в PDF:

> cd cltl2-doc
> ./rumakepdf.sh

Русский текст в тех же файлах, что и английский. Ориентрироваться какая глава в каком файле: смотрим в online версии название файла. Например, первая глава – Вступление – это файл intro.html, значит её исходники лежат в файле intro.tex. Вторая глава – Типы данных – файл dtypes.tex, и т.д.
Если вы все же решите что-то перевести, свяжитесь заранее со мной или Михаилом.

(fun (open-build-service (+ openSUSE stumpWM)))

Common Lisp – один из диалектов мультипарадигменного языка программирования Lisp. Поддерживает комбинацию процедурного, функционального и объектно-ориентированного программирования. Я начал изучать Lisp именно из-за его истинно функциальной природы. Реализация решений тех или иных задачь при использовании функционального подхода (декларативного программирования) сильно отличается от столь привычного императивного. Его использование очень расширяет горизонты программиста.

Одной из интересных особенностей Lisp-программ является возможность их изменения “на лету”. Это значит, что мне не надо их перекомпилировать или перезапускать интерпретатор. Я просто подключаюсь к запущенному процессу и меняю его поведение, внося изменения в его код. Это делает хакинг на много проще и интересней.

К сожаленью в openSUSE-репозиториях практически нет Lisp-программ. Есть Emacs, но он написан на Emacs Lisp, а это другой диалект с другими правилами. Есть Lisp-интерпретаторы, но вносить изменения в код интерпретатора и следить за изменениями в его поведении все же не столь интересно. Свои первые программы aka “hello world” изменять тоже скучно; хочется работать с большим проектом, чтение кода которого научит тебя новым трюкам этого языка и просто покажет как надо на нем программировать.

Мой выбор остановился на проекте stumpWM. Его не было в репах, так что собирать его предстояло из исходников. Собрать С/C++ или даже Python-проекты с Qt/GTK+ библиотеками не составляет особого труда для большинства из нас, но в мире Lisp все это работает несколько иначе…

COMMON LISP: USERS OF OTHER LANGUAGES ;-)

(Re-posted from here: http://kvardek-du.kerno.org/2010/01/how-common-lisp-programmer-views-users.html)

Another System Definition Facility

ASDF is Another System Definition Facility: a tool for specifying how systems of Common Lisp software are comprised of components (sub-systems and files), and how to operate on these components in the right order so that they can be compiled, loaded, tested, etc…

It seems that until now we didn’t have ASDF in Open Build Service (true Lisp-hackers got it from git only?). Anyway I built a very simple RPM-package. Nothing special: just git-version that include some documentation and ASDF sources of course. Maybe I will build also a deb packages for Debian/Ubuntu.

[1]> (load "/usr/share/common-lisp/source/asdf/asdf.lisp")
;; Loading file /usr/share/common-lisp/source/asdf/asdf.lisp ...
;; Loaded file /usr/share/common-lisp/source/asdf/asdf.lisp
T
[2]> (asdf:asdf-version)
"2.20"

Programming Paradigms (Stanford)

Lecture by Professor Jerry Cain for Programming Paradigms (CS107) in the Stanford University Computer Science department.

Programming Paradigms (CS107) introduces several programming languages, including C, Assembly, C++, Concurrent Programming, Scheme (Lisp), and Python. The class aims to teach students how to write code for each of these individual languages and to understand the programming paradigms behind these languages.

Thanks a lot for sharing 😉