пятница, 27 августа 2010 г.

Отпуск

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

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

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

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

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

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

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

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

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

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

понедельник, 23 августа 2010 г.

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`
Получается очень удобно и просто.

пятница, 20 августа 2010 г.

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-ых.

четверг, 19 августа 2010 г.

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

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

среда, 18 августа 2010 г.

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
Немного протестил - вроде работает нормально.

вторник, 17 августа 2010 г.

Выравнивание в closure-template-html-mode

Благодаря помощи cvb удалось реализовать мою мечту - прикрутить выравнивание кода в closure-template-html-mode.el (из состава cl-closure-template). Осталось ещё несколько тонких моментов, которые не учитываются реализованным механизмом, но такие ситуации встречаются довольно редко. Теперь править код шаблонов стало намного, намного приятней. Ну и заодно немного разобрался как это всё реализуется в Emacs.

четверг, 12 августа 2010 г.

Chrome: Edit with Emacs

Давно хотел заполучить для Chromium (Chrome) аналог It's All Text! и вот, наконец, с подсказки dmitry_vk нашёл Edit with Emacs. Данный пост написан с помощью этого расширения. Жизнь, однако, налаживается...

среда, 11 августа 2010 г.

Запретить drag-and-drop изображений в Firefox

В Firefox есть очень противная вещь - если нажать на мышкой на изображение, то инициируется совершенно бессмысленный drag-and-drop. Мне это просто не нравится, но тут ещё и мешает моему приложению, ибо у меня своя реализация drag-and-drop и она должна срабатывать на div, который в том числе содерижт img, но если пользователь щёлкает на img, то начинается совершенно левый перенос картинки. В webkit есть css-свойство -webkit-user-drag, которое можно выставить в none, но для Firefox его аналога нет. Немного потыкал гугл, но нужного мне рецепта не нашёл. Пришлось найти самому, впрочем, он тривиален:
$(document).bind("dragstart", function (evt) { evt.preventDefault(); } );
Всё, никакого левого drag-and-drop.

вторник, 10 августа 2010 г.

CL vs Haskell, динамика vs статика и прочий бред

Тут кажется наметилась новая волна срача на обозначенные темы. При этом, типично спор сводится к выяснению программист с каким инструментом будет более эффективен. Типа что можно сделать за 8 часов на Haskell, а что на CL. Даже если не принимать во внимание тот факт, что для самых типовых задач обычно больше можно сделать на Java, ибо просто библиотек больше, то всё равно это бессмыслица. Пять дней в неделю по восемь часов (или типо того) мы якобы пишем код. Если бы мы действительно тратили это время на написание кода, тогда имело бы наверное смысл проводить подобные сравнения. Я не знаю как все, но я не могу. Если я трачу 4 часа в день на код, то это обычно удачный день. Многие дни у меня уходят просто в пустую. Я просто не могу собраться и сосредоточиться на работе. Поскольку при этом я обычно всегда делал намного больше окружающих, то имею основания полагать, что описанная ситуация является весьма типичной. Да, ещё иногда случаются приступы вдохновения, когда я работаю по 14-16 часов с полной концентрацией, чувствую себя счастливым и суммарный эффект от таких редких периодов намного превышает эффект от всех остальных дней.

Если говорить о повышении производительности, то технические аспекты языка: есть автоматическая сборка мусора или нет, есть вывод типов или нет, функциональный или императивный и т.п. вообще не имеют особого значения. Ибо основой способ повышения производительности заключается в увеличении времени, которое я реально трачу на решение задачи: в уменьшении количества "пустых" дней, в увеличении числа эффективных часов в сутки, в повышении частоты "приступов вдохновения". Для этого наверное есть разные приёмы. Например, Хемингуэй (видимо, в писательской деятельности есть те же самые проблемы) писал, что нельзя выписываться полностью, всегда нужно останавливаться когда ещё есть что сказать, тогда на следующий день можно эффективно включиться работу.

Peter Seibel пишет в PCL, что
Выгоды от использования Lisp заключены в переживаниях и впечатлениях от его использования
И это ключевой аспект, о котором часто забывают. Лично для меня Common Lisp это язык, который лучше других способствует поддержанию интереса к разработке и позволяет более эффективно справляться с периодами бездействия. Для кого-то, видимо, подобным языком является Haskell (хотя мне и трудно это представить) и он выбирает его. А другие способны не засыпать, когда пишут на Java.

пятница, 6 августа 2010 г.

iolib-0.7.0 издевается, да и не только она

На днях вышел новый, и давно ожидаемый, релиз библиотеки IOLib - 0.7.0. Поскольку Stelian Ionescu, разработчик этой библиотеки, так же является основным разработчиком и gentoo-lisp-overlay, то я ожидал, что сразу же появится и соответствующий ebuild. Однако, его пока нет. И раздумывая над этим фактом я вдруг сообразил, что IOLib-0.7.0 зависит от нестабильных git-версий alexandria и CFFI. Вот на этом факте я совершенно запутался и перестал понимать: что может означать релиз библиотеки, которая зависит от функционала, который ещё не был выпущен в виде какого-либо релиза? При чём, ситуация с alexandria вообще является клинической, ибо проект существует уже не один год, а ни одного релиза до сих пор не было! Ситуация с CFFI тоже интересна, ибо Stelian является один из её разработчиков и мог бы повлиять на выход нового релиза, да бы совместить с релизом IOLib, но нет, этого не происходит. Блин, давно же известно, что делать релизы надо чаще и раньше (ну если вы не в команде Debian), но нет, среди CL-разработчиком этому правилу следуют, кажется, только разработчики SBCL.

Вообще, в принципе, мне нравится что делает Stelian Ionescu, по мысли, по заложенным идеям очень хорошо. Но... степень хаоса в связанных с ним проектов, по моим представлениям (и наблюдениям), просто зашкаливает. Что вызывает серьёзное беспокойство и опасения насчёт целесообразности использования.

вторник, 3 августа 2010 г.

Статья об использовании RESTAS для создания pastebin-приложения

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

Статья: http://restas.lisper.ru/tutorial/pastebin.html