RESTAS. Изменения в схеме инициализации модулей

Внёс небольшие изменения в систему инициализации субмодулей, которые решают следующие проблемы:

• Функция инициализации, которая определялась при помощи restas:define-initilization, не вызывалась при непосредственном запуске модуля с помощью restas:start
• Функция инициализации вызывалась непосредственно при определении субмодуля с помощью restas:define-submodule, а не при непосредственном включении его в состав родительского модуля - это могло вызвать проблемы при множественном использовании модуля в качестве субмодуля (немного путанно).

API остался прежним, но изменились некоторые макросы, так что необходимо удалить старые .fasl для систем, использующих RESTAS.

Эти изменения доступны в git-версии. Давно надо было сделать, но как-то руки не доходили ((

Отпуск

Уезжаю в отпуск. Не будет около 20 дней.

Хакеры и худоджники. Любимый фрагмент.

Вероятно все читали замечательное эссе Пола Грэма "Хакеры и художники", но очень хочется привести из него один фрагмент, который мне нравится особенно сильно:

Хакерам теория вычислений нужна не больше, чем художникам - химия красок. Надо знать, как высчитывать время и пространственную сложность, еще - про Тьюрингову полноту. Ну, еще не помешает помнить хотя бы концепцию конечного автомата - на случай, если пишешь синтаксический анализатор или библиотеку регулярных выражений. Вообще-то художникам приходится помнить о химическом составе красок гораздо больше.

Я обнаружил, что лучшие источники идей - не области, в названии которых фигурирует слово "компьютер", но те, что населены творцами. Живопись - источник существенно богаче, нежели теория вычислений.

К примеру, меня в колледже учили: прежде, чем приблизиться к компьютеру, программу следует целиком записать на бумаге. Оказывается, я программировал не так. Мне нравилось программировать перед компьютером, а не над листом бумаги. Хуже того, я не писал терпеливо всю программу, проверяя, нет ли ошибок, я извергал безнадежно кривой код и постепенно приводил его в норму. Отладка, учили меня, - это последний заход, когда вылавливаешь опечатки и упущения. Я же работал так, что программирование походило на бесконечную отладку.

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

Осознание этого факта реально влияет на разработку ПО. Язык программирования прежде всего должен быть гибким. Язык программирования - чтобы думать о программах, а не формулировать программы, которые уже обдуманы. Карандаш, а не ручка. Статический контроль типов - неплохая штука, если б программировали и впрямь так, как учат в колледже. Но ни один известный мне хакер так не работает. Нам требуется язык, что позволит карябать, сажать кляксы и стирать, а не вроде как сидишь с чашкой типов данных и вежливо беседуешь со строгой престарелой тетушкой-компилятором.

Раз уж мы заговорили о статическом контроле, то вот что. Назвавшись творцами, мы избавимся еще от одной проблемы, что терзает науки: от зависти к математике. Любой ученый втайне верит, что математики всех умнее. Кажется, математики в это верят не меньше остальных. А в итоге ученые стараются, чтобы их работа на вид получалась математической до предела. Может, в какой-нибудь физике это и не беда, но чем дальше от естественных наук, тем больше усугубляется проблема.

Ну, разумеется - страница формул впечатляет. (Совет: для особой выразительности вводите греческие переменные.) И потому так соблазнительно заняться проблемами, к которым можно подойти формально, а не над теми, что, скажем так, важны.

Если бы хакеры видели в себе творцов - писателей или художников, - такого соблазна бы не возникало. Писатели и художники математикам не завидуют. Они считают, что занимаются чем-то совершенно не связанным с математикой. Как и хакеры, я полагаю.

RESTAS - обновление документации и версия 0.0.10

Обновил документацию на RESTAS - добавил API Reference. Теперь все упоминания каких-либо функций или макросов превратились ссылки на соответствующее описание в API Reference. А что бы документация не отличалась от текущий возможностей сделал версию 0.0.10.

Ну и пара слов о cl-sphinx, с помощью которой я делаю документацию. Немного допилил её для обеспечения ссылок на определения, теперь можно в одном месте вставить, например, описание функции:

.. defun:: restas:reconnect-all-routes
  :args:

  Реинициализирует диспетчер запросов. и т.п.

а в других ссылаться на это определение с помощью

:fun:`restas:reconnect-all-routes`

Получается очень удобно и просто.

Common Lisp и DSL. Другой взгляд.

swizard опубликовал статью о Common Lisp и DSL, в которой достаточно ясно изложил мнение, что наиболее эффективное использование Common Lisp заключается в разработке DSL. Мало того, он предлагает начинающим начинать именно с этого. Позвольте не согласится.

Кратко - DSL не нужны кроме тех редких случаев, когда они очень хороши и реально упрощают решение задачи. Это не имеет отношения к Common Lisp, либо к какому либо другому языку. Например, Эрик Раймонд писал о DSL как о классической традиции программирования под UNIX и всяческих расхваливал преимущества данного подхода. Однако на практике лишь малая часть Unix-программ используют какие-либо DSL. Это однозначно свидетельствует о том, что разработчики, несмотря на все разрекламированные свойства DSL, стараются избегать их использования (да, я действительно считаю, что "миллионы мух не могут ошибаться", поскольку речь идёт не о мухах, а о, по большей части, талантливых разработчиках).

Если говорить о Common Lisp, то мне совершенно не понятно на чём основано мнение, что "common lisp и заслужил себе славу мета-языка " (с). В реальной практике программирования на Common Lisp использование DSL встречается редко. Связано это с тем, что, на мой взгляд, использование DSL просто противоречит духу Common Lisp, по крайней мере, в его современном виде.

Наиболее сильной и характерной чертой Common Lisp является мощная поддержка интерактивной разработки, что значительно упрощает постоянный рефакторинг кода и проектирование "снизу вверх", которые характерны для современных подходов к разработке. Программирования на основе DSL, однако, требует другого подхода: задача делится на две подзадачи - проектирование DSL и описание решения на этом DSL. Проектирования языка программирования, пусть даже это маленький DSL, это сложная задача, повышающая требования к качеству проектирования системы. В контексте современных задач, когда приложение работает сразу во многих областях, также существенно усложняется выделения предметной области для конкретного DSL. Сложность возникающих проблем дизайна приводит к необходимости проектирования "сверху вниз", что стразу убивает большую часть преимуществ интерактивной разработки. Поскольку для современных задач характерна неточность в требованиях, которые выясняются по мере разработки (обычно, ближе к концу), то проектирование "сверху вниз" связано со слишком большими рисками и сопутствующими накладными расходами.

Использование DSL возможно и целесообразно лишь в некоторых областях, но не для широкого круга задач. ИМХО, мнение о том, что при программировании на Common Lisp следует широко использовать DSL основано на позиции старой "lisp-гвардии", представители которой застряли где-то в начале 80-ых.

Обновление документации на RESTAS

Обновил документацию на RESTAS, дополнив инструкции по установке, а также добавил статья про интеграцию SLIME и RESTAS.

Ebuild на iolib-0.7.0

Наконец появился ebuild на iolib-0.7.0, но он зависит от cffi-9999.ebuild, с чем я, конечно смириться не могу (ибо это исключает возможность использования данного пакета на боевых серверах). Поэтому, в своём оверлее сделал cffi-0.10.5_p20100818.ebuild и установил зависимость iolib от него как

>=dev-lisp/cffi-0.10.5_p20100818

Немного протестил - вроде работает нормально.