Lisp, the Universe and Everything

Реальная норма часов работы программиста в день

2011-12-21T09:47:00.004+02:00

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

И вот, на днях на хакерньюз я наткнулся на отличную статью профессиональной писательницы о повышении эффективности ее труда в 5 раз (с 2 до 10 тысяч слов в день). Фактически, ей удалось это сделать за счет выработки метода систематического вхождения в поток. А как все мы творческие работники знаем, поток — это залог эффективной работы*. Но, что в этой статье для меня было действительно важным — это то, что человек, добившийся такой эффективности, констатировал факт: собственно непрерывной работы у нее в среднем 4 часа в день — в самых удачных случаях до 7 — плюс 2 часа с утра, которые расходуются на подготовительную работу. А если вырабатывать больше, то эффективность начинает падать. Не говоря о том, что можно перегореть.

Это наблюдение совпадает и с моим опытом: у меня такое же количество (4-6) часов эффективного писания кода в день. В этом нет ничего удивительного, поскольку труд программиста ничем не выделяется из ряда других творческих профессий: писателя, дизайнера или же композитора. Что же тогда делать с 8-ми часовым рабочим днем? На самом деле, ничего плохого в том, что только 50-75% рабочего времени тратится собственно на работу нет: остальное время тоже не пропадает зря, посколько тратится на комуникацию (без которой любая компания и проект обречены), а также какие-то нерабочие активности, которые формируют ту самую мифическую "корпоративную культуру". И даже если этих активностей нет (фриланс) — это не значит, что: а). программист может это время потратить на работу над кодом б). программисту они не нужны (нужны, возможно, только в другой форме: социализация нужна всем).

Т.е. выходит 2 числа, характеризующие нормального программиста: максимум 6 часов (а в среднем: 4 часа) программирования в день и коэфициент 1.5 соотношения часов программирования к часам работы. И эти числа нужно принять как исходные данные, на основании которых менеджеры могут стоить какие-то предположения, оценки и методики.

Кроме того, такой взгляд разрешает для меня диллему эстимейтов: должен и может ли, вообще, их делать программист?

Функция time профилировщиков программ выдает обычно 2 числа: total time и real/cpu time. Первое значение — это фактическое время, которое прошло от старта программы до завершения. На него могут влиять такие факторы, как кеширование, ожидание ввода-вывода и т.п. А сpu time — это время, которое программа действительно выполнялась на процессоре. По-хорошему, именно это, второе время, может научиться оценивать программист: т.е. время, которое ему понадобиться для написания и отладки кода, когда он будет находится в "разогретом" режиме работы. А вот общее время — которое, на самом деле, интересует бизнес — может научиться оценивать только менеджер, беря во внимание оценки программистов (и их историческое качество), а также 100500 других факторов, которые могут повлиять на режим его работы: кеширование, своевременное заполнение пайплайнов, переключене контекста и т.д.

* Те, кто не знает, может очень быстро узнать из уст человека, который сформулировал эту концепцию (или из его классической книги Flow):

Clojure & Complexity

2011-11-30T20:18:00.009+02:00

I gave a rather messy lightning talk at the recent ECLM on this topic (see below). I think, the messiness can be attributed mostly to my undesire to criticize anything, built with good intentions, including Clojure. Yet in software development there's clearly a need for thorough evaluation of different approaches, languages and technologies, because, we must admit, lots and lots of decisions on such things as architecture or language/platform choice are made on purely subjective and even emotional bases (see "hype"). So below is a more detailed account of the (excessive) complexities, I've encountered working with Clojure in a real-world environment: a half-year project to develop a part of a rather big Java-based server-side system. Also I should note, that I was following Clojure almost since its initial public release, have participated in the early flames on c.l.l. and even edited a Clojure introduction article in the Russian functional programming journal fprog.ru. But this was only the first chance to make a reality check...

But, first of all, I'd like to refer you to the talk of Rich Hickey at the Strange Loop conference "Simple made Easy", the principles of which really resonate with me. Yet it's so often the case, that it's hard to follow your abstract principles, when you're faced with reality (also guilty of that). And another point is that it's not really beneficial to push the principles to the extreme, because there's always the other side, and engineering is the art of making trade-offs: if you don't find room for them, the other side will bite you. So the points below basically boil down to these 2 things: examples of "complecting", and "things should be made as simple, as possible, but not simpler" (attributed to Einstein).

Interactive development

Lisp is considered a so called platform-language in a sense that it implies the existence of certain facilities and runtime environment constraints, that form a distinct and whole environment. Unlike some other languages, usually called scripting, which rely on a pre-existing environment, like the OS (e.g. Posix), web server, web browser etc. Other platform languages are, for example, Java, C# or Erlang, while scripting languages are JavaScript, Perl or PHP. Clojure is a language on a pre-existing platform, which is JVM, and so doesn't define its own platform. This is the source of, probably, the biggest complecting in the language, as it tries to be a stand-alone dynamic, functional language, explicitly discouraging imperative object-oriented style. But the JVM-platform is oriented at static imperative object-oriented ones.

From the Lisp dynamic point-of-view a lot of JVM's facilities are inferior:

mostly static runtime image and object system with only partial opportunities for redefining things on-the-fly instead of a fully dynamic one
static namespaces (tied to a file system) instead of dynamic packages
static exception system instead of a dynamic (restartable) condition system
limited and flawed number representation system instead of a full numeric tower
more limited calling convention (only positional parameters and absense of multiple return values)
more limited naming scheme
XML-based build facilities instead of eDSL-based ones - althouh, here Clojure can provide its own option, but the currently existing one - Leiningen is a weird beast of its own (for example, you can get CLASSPATH out of it, but can't put it in except through project.clj, which has a lot of limitations)
absense of tail call optimization

Surely, there are also some current advantages of the Java platform:

availability of a concurrent GC (although it's not the default one)
good JIT-optimizing compiler
and what's most important, larger amount of available tools and libraries

Yet, if we return to the top of the list of shortfalls, we can see, why interactive development in Clojure is much less productive, then in Lisp. What adds to it is, that Clojure uses a one-pass compiler (not very modern).

Going into more details on this will be a whole separate post, so I'll just sum up, that interactive development in Clojure is hampered both by the JVM sticking in different places (especially, if you work on projects, combining Clojure and Java code) and Clojure's own misfeatures.

Syntax

From its early days Clojure was positioned as a "modern" Lisp. And what this "modernity" actually implied is:

more accessible syntax and broader support for vectors and maps as opposed to Common Lisp, in which only lists, allegedly, were first-class citizens
built-in concurrency primitives
being Lisp-1 instead of Lisp-2, which makes heavy functional style programming more concise
cleaning up some minor "annoyances": 4 equality operators, interning reader, etc.

Starting from the bottom, the minor issues make it not easy to start, but they are actually conceptually simple and useful, once you get accustomed. Lisp-1 vs Lisp-2 is a matter of taste: for example, I prefer #', because it's an annotation, while others perceive it as noise. And there's no objective advantage of one over another: yes, Lisp-1 makes something like (<map> </key>) instead of (gethash <map> <key>) possible, yet it makes macros more complicated. And concurrency I'll discuss separately.

What's left is broader support for vectors and maps, including destructuring. I agree, that declarative syntax for common datastructures is a crucial for productive use of any language up to the point of defining the same literal syntax ({}) for hash-tables in CL. Thankfully, that is supported by the language, so this syntax is as first-class in CL, as in Clojure, and, as in many aspects, nothing prevents "modernizing" Lisp in this aspect without creating a whole separate language... This doesn't hold for Clojure, as it doesn't have facilities to control the reader in the same way CL does: actually, in this regard Clojure is very different from Lisp — it hardly provides facilities for controlling any aspect of the language — and this control is a critical part of Lisp's DNA.

And pushing syntax to the extreme has it's shortcomings in Clojure as well. Rich argues, that defining both lists and vectors with parens (in Lisp list is '() and vector is #()) is complecting. But, I'd say, that a much harder case of complecting is this:

)))))))])))))])]) — the joy of debugging ASTs

And it's not even about Clojure: although here it's even worse, because for some reason, that escapes me, let (and defn, and many others) uses vectors for argument lists. Aren't they called lists for a reason? So this once again actualizes the problem of counting closing parens, effectively solved for Lisp long ago with emacs.

At the same time "modern" Clojure poorly supports such things as keyword arguments in functions or multiple return values and many other not so "modern", but very effective facilities, that I personally would expect to see in a modern language...

There's only one true way: functional

In my talk I referred to one of the ugliest pieces of code, I've ever written, which was a very complicated Clojrue loop, i.e. a loop/recur thing (and I've honestly tried to factor it out).

Basically there are two opposite approaches to iteration: imperative looping and functional recurring. Many languages have a strong bias towards one or another, like Python discouraging recursion and Clojure discouraging imperative loops by imposing immutability. But the thing is, that there are problems, for which one of the approaches yields by far more concise and understandable code. If you want to traverse a tree, recursion is a way to go. While if you are accumulating several sequences at once, which may reference results, obtained at the previous computations and also at each iteration there's not one, but several outcomes, recursions often becomes too messy. Yet in Clojure there's not even good support for recursion (which has an advantage of factoring different pieces of code into functions), but a special construct loop/recur, which shares the downsides of both approaches and does hardly provide any of the benefits. That's a pity, as iteration is the basic programming construct and no code file can do without it. And here we see a case of detrimental over-simplification.

And there are also lazy sequences, which complect sequences and streams. In theory, those are the same things, but, as the saying goes, in theory, theory and practice are the same, but in practice... Surely this makes writing a compiler easier at the cost of complicating reasoning about sequences in day-to-day programming.

EDIT: as was correctly pointed by the commentators, you can have sort of mutable local variables with transients, and that allows to express some of the imperative loops in a more concise manner.

Concurrency

In the early days of Clojure in one of the discussions on c.l.l. S.Madhu (if I remember correctly) called Clojure's concurrency primitives "snake oil". I thought, that there may be some personal issues in such attitude, but having tried it for myself and learned about all the alternatives in the concurrency space, I don't think it was too far from reality. First of all, Clojure addresses only shared-state concurrency on a single computer, while most hard concurrency problems appear in the context of distributed systems and are currently solved with approaches, like the Actor model or MapReduce. And on the single machine I've seen very few problems, that can't be solved with a combination of thread pools (with thread-local storage), Lisp-style special variables and databases. In fact Clojure provides its own (often limited) variants of all the above mentioned approaches and nothing more:
- agents instead of actors
- vars (analogue of CL's special variables)
- STM for databases
- map/reduce, pmap

To be able to provide them Clojure imposes some restrictions, most notably the one of immutability. Also in their implementation it doesn't follow the Lisp principle of giving control to the programmer: you can't swap one STM variant/strategy for the other. Heck, you can't even control the number of threads, that pmap uses!

Among all this approaches, STM is the most notable one (as others are just a copy of the established technologies). And it has a tough competition from databases and other transactional datastores. The advantages are no impedance mismatch and, possibly, better efficiency. Yet the database is language-agnostic, which is often useful, it's more accessible and understandable. And, what's most important: there's durability and there's a choice, that you can utilize, depending on your needs. The best use case for STM I've found so far was to hold statistical counters, accessed simultaneously from many threads, yet this problem is easily solvable with Redis, for example. And the same applies to other uses I can think of, So, the paradox of Clojure is that, although it was ushered with the idea of solving concurrency problems, it still has a lot to prove in this space: and not with toy examples of ant colonies, but real-world applications, made possible with its approach (like RabbitMQ or Ejabberd showcasing Erlang's aptitude for building massively parallel systems).

Final thoughts

I've written a long article, but there are many more details left out (just adding code snippets, will make it twice as big). There's also a lot of good things about Clojure, which I didn't mention: its seamless integration with Java, for example, which makes it a good scripting language for Java applications. Macros, basic datastructures, vars, they all work great. Ring was also an enlightenment.

Yet, overall the language doesn't leave up to its promise of being a modern Lisp: actually, it's not a Lisp at all. Well, how do you define Lisp? S-expressions, macros, closures etc? Surely, all (at least most of) those features may be present, although Dylan was a Lisp without s-expressions, for example. But, in my opinion as a Lisp programmer, what makes a true Lisp is dynamicity, simplicity and putting control in developer's hands (flexibility and extensibility). The mentioned features are mostly a derivative of this principles, and also they all should have a backend for extension: reader, compiler, condition system, object system, special variables etc, they all do in Lisp. And Clojure gives up on all these principles if not altogether, than substantially: many of the features are there and the new ones arrived, but the backend is missing.

Common Lisp is well optimized for the common use-cases in the design space of dynamic flexible languages. And it's probably very close to local maximum in it. At least it's good enough. Clojure is more of a hybrid, and hybrids are built by complecting: in Clojure's case complecting Lisp and Java, Lisp and Haskell. The result is interesting, but, in my opinion, it's not optimal. Surely it has its use-cases.

Still, Clojure sees decent adoption (which is good, because it proves, that parens aren't a problem after all :) I think it's a combination of several things. The language still has a lot of good stuff from Lisp (as well as some good things from Haskell, although they don't match very well), and those who start using it are mostly Java and Ruby programmers, for whom it breaks the psychological barriers to using Lisp (we all know the FUD). The other thing is lack of a decent native (not like Jython or JRuby) dynamic language on the JVM. And finally, there's marketing, i.e. Clojure concurrency primitives. And the challenge for Clojure community is to produce a "killer" application, that will utilize them, or the hype will wane, and pretty soon...

Videos from ECLM 2011

2011-11-27T19:39:00.002+02:00

Today I've finally finished uploading all the videos to the ECLM channel on blip.tv/eclm. There are a lot of very interesting talks and the topics range from Lisp-based companies' experiences to exciting Lisp projects (like quicklisp or zen X server) to community issues (like the announcement of the Stichting Common Lisp Foundation or good Lisp style). Of 7 lengthy talks, announced at the event's website, only 5 are available now:

Luke Gorrie's account of his exciting startup Teclo Networks will be published somewhat later not to compromise the business (and it's a great talk, so don't miss it :),
and Paul Miller's showcase of LinkExplorer, a Windows LispWorks CAPI-based GUI application was not recorded by the request of his company.

In total, there are 12 videos, including the lightning talks (and the lucky 13th will join later). My personal favourite is Jack Harper's story of building Secure Outcomes, with a lot of invaluable engineering insights.

The sound quality is not stellar, because, unfortunetely, there was a laying of the ground 50Hz signal on the mic's signal at the site. But judging from my experiences in organizing TEDxKyiv, sound is the usual point of failure at conferences, and it's pretty hard to get it right. Yet, I hope, that next meeting will have a more professional recording set up (maybe through CLF), because, in my opinion, these videos are extremely valuable to the community. I really miss some talks from ECLM 2009, like Kuroda Hisao's, Dave McClure's or Dan Weinreib's, and most of all, the Piano.aero one...

For me the overall meeting experience was really fantastic, and the talks actually form only a minor half of that. Immersing myself into the Lisp community and participating in so many profound conversations with brilliant Lisp programmers was the really exciting part. The good overview of the conference experience is given by Luís Oliveira. So I'm really looking forward for the ECLM 2012. Maybe, organize it in a different European city this time?..

Book review: Algorithms of the Intelligent Web

2011-04-05T14:45:00.003+03:00

TL;DR The book should have been named "Building Machine Learning Apps in Java for Dummies". Worth reading if such name excites you.

This book aims to become a comprehensive guide in commonly used Machine Learning technics. And generally it succeeds in that with one reservation: it more resembles a sophomore synopsis, than a professor's lecture.

I should say, that I couldn't manage to finish the book, and had read only Chapters 1,2 and 5. But the structure of each chapter is roughly the same: a brief high-level description of the common approaches in the described sphere. Then a list of Java libraries, available for the task. Selection of one of them and a description of how solid, robust and mature it is. Then several pages of Java code, showing how to prepare input parameters and actually make use of the libraries. Finally a note, that there are some limitations or pecularities, but discussing them in more detail is out of the scope of the book. Thus, the amount of new material for anyone at least slightly familiar with the subject and programming in general is minimal (I would say, that for me it was around 10%.) No insights, nothing novel, that can't be found on the first page of Google results on the topic, no account of personal experience or "war stories". Such book doesn't require 20 years of industrial experience under the hood to write — this could be done by any working programmer. The recipe seems simple: for each topic take the first two pages of Wikipedia entry on it, list the available libraries for solving the problem, add a couple of examples from their manual, bingo!

There's also another problem: the code is in Java. This is good for the authors, as it increases the book size and makes it seem much more solid, than in reality. But all the unnecessary cruft like half-line type declarations and bookkeeping code for loops (which amounts to more than half of the code, I'd say) makes it really hard to follow along. You need to really focus to be able to translate the code in mind to some high-level conceptual form before grasping it. (Although, there's a shortcut: just assume, that all the code is mostly irrelevant and skip). It's like the authors used the trick of all students: hide your poor understanding of the subject behind all the recondite words you've heard. So the advice for any algorithmical book: if you want to make the code easy to follow write it in Python or Lisp. At least it would make really apparent, if there's not a lot of essence to it... ;)

So the book is worth reading only if you're new to the field, don't want to spend time learning the subject, but need to get some working program fast (and don't object using Java for that).

various Lisp stuff

2011-01-08T09:30:00.006+02:00

In the spirit of xach's "policy" for half-baked projects I've also published some of my experiments:

If somebody finds that useful, let me know.

Роль CTO в технологической компании

2010-10-17T15:16:00.002+03:00

Есть известная максима, давно проповедуемая Полом Гремом и взятая на вооружение большей частью американского стартап-сообщества, о том, что технологические стартапы должны иметь минимум двух основателей. Можно много дискутировать на тему, с чем это связанно: например, есть версия, что "если предприниматель не способен убедить в своей идее хотя бы еще одного человека, то он тем более не сможет убедить в этом рынок". Я же пришел к выводу, что всё упирается в ответ на вопрос, что можно аутсорсить, а что нет? Как известно, нельзя этого делать с ключевыми функциями компании. И первой ключевой функцией является формирование ее идентичности на рынке. Этим занимается человек, называемый американцами CEO, хотя более правильно было бы назвать его просто лидером проекта. По своей базе он может быть как инженером, так и маркетологом, финансистом или продажником. Это не столь важно, поскольку его главная роль, которая заключается в том, чтобы вести компанию в правильном направлении и рассказывать об этом рынку через маркетинг, биздев, продажи, PR и т.д. и т.п., не требует особой специализации. Очевидно, что при этом он должен стоять у истоков идеи, которая реализуется, и сам крепко верить в нее, иначе он не сможет убедить в ней других. И эта роль настолько обширна, что она должна быть единственной сферой ответственности такого человека. Да, он может быть крутым программистом и вносить свой вклад, а, воможно, и наибольшее ноу-хау в технологии своей компании, но он не может быть ответственным за эту сферу в целом. Потому что, если отвечать за два дела одновременно, то ни одно из них не выйдет сделать хорошо. И это показывает опыт, в том числе и мой собственный.

Вот здесь и выходит на арену CTO, роль которого в компании заключается в технологическом лидерстве. Часто считается, что СТО должен написать основную часть кода, если это касается софтверного стартапа. Это не обязательно. Код могут написать хоть 10 фрилансеров или 100 миллионов обезьян, поскольку это довольно стандартная работа, и если правильно поставить задачу, с ней прекрасно справится наемный сотрудник. Но вот, что сложно — так это поставить задачу и сформулировать рамки, в которых должен развиваться проект, а потом следить за тем, чтобы они соблюдались. В технологическом бизнесе, как ни крути, а основные риски все-таки технологические. И все остальные участники процесса (наемные сотрудники, клиенты и т.д.) будут их только увеличивать. Единственный, кто может и должен с ними бороться — это СТО.

СТО — это роль того, кто принимает окончательное решение, выбрать технологию Х, за которую выступает разработчик, или Y, которая сейчас на волне хайпа. Это тот, кто не спит ночами из-за того, что не настроен бекап базы данных. Это тот, кто вводит практику ревью кода и добивается ее реального воплощения. Тот, кто отвечает программистам на вопросы: "зачем?", "почему?" и "когда?" Тот, кто отбирает подходящих инженеров. И принимает еще 100500 разных решений, а потом добивается их исполнения. В общем, это тот, кто создает технологическую культуру компании и не дает появляться технологическуму долгу, который в будущем (и, скорее, близком, чем отдаленном) потянет компанию ко дну или же не даст ей развиваться необходимыми темпами.

Так что правило про двух основателей я переформулировал бы так.

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

ASDF как язык описания систем

2010-08-13T17:57:00.009+03:00

Это третья статья в серии про ASDF. Первая часть — об ASDF 2, вторая — об архитектуре ASDF.

Как было замечено ранее, ASDF выполняет 2 связанные, но все же довольно разные по требованиям со стороны пользователей функции: описание систем и управление их сборкой. В этой статье я постараюсь перечислить распространенные (и не очень) шаблоны его применения для этих задач, собранные мной из более 70 open-source Lisp библиотек, с которыми приходилось работать. Я думаю, что систематизация этих знаний сослужит хорошую службу Lisp-сообществу и будет полезна как начинающим, так и экспертам, которые смогут усовешенствовать свои техники.

Изначально в этой статье я планировал разобрать все основные шаблоны использования ASDF, но материала оказалось слишком много, поэтому более сложным темам его применения как build-инструмента будет посвящена следующая серия.

Прямые ссылки на полезные вещи:

новый проект c помощью ASDF за 2 минуты
пакет для defsystem-формы
правильные символы в именах систем и пакетов
имена и пути компонент
платформо-зависимые описания систем

Начало работы с ASDF

ASDF нельзя назвать инструментом, который можно освоить за 5 минут. Я сам, например, очень долго вникал в идеологию и особенности его работы, и делал это в основном методом проб и ошибок (мануал мне плохо помогал :). Однако, сейчас мне кажется, что эти трудности связанны не с особенностями ASDF (какими-то неудачными архитектурными решениями и т.п.) или Lisp'а, а, в первую очередь, с отсутствием должной документации и best-practices. Именно этот пробел я и хочу заполнить. Да, всё, что будет показано ниже, почерпнуто из широкодоступного кода Lisp-библиотек, однако часто нужны скорее tutorial'ы, которые позволят быстро начать работу и сразу получить ожидаемый результат. Поэтому начнем именно с такого самого простого примера.

Итак, чтобы создать новый проект с помощью ASDF — нужно создать директорию проекта (пусть будет testprj), в которой поместить имеющиеся lisp-исходники (пусть это будет файл app.lisp) и создать в этой директории файл testprj.asd, в который поместить следующую форму:

(asdf:defsystem #:testprj
  :components ((:file "app")))

Для загрузки нового проекта в Lisp-среду нужно, чтобы наш testprj.asd файл был в известных ASDF местах. На данный момент поддерживается 2 способа задания таких мест: аналог PATH (*central-registry*) и source-registry (использующий конфигурационные файлы). Самый распространенный подход (в POSIX-окружении) — это создать ссылку на asd-файл в какой-то специальной директории (например, ~/.lisp), которая добавлена в *central-registry*.

В общем полная настройка такого варианта выглядит так:

$ ln -s <path-to-testprj.asd> ~/.lisp/testprj.asd

;; обычно это делается в rc-файле lisp'а (например, .sbclrc)
CL-USER> (push "~/.lisp/" asdf:*central-registry*)

;; далее можно выполнять (для ASDF 2):
CL-USER> (asdf:load-system :testprj)
;; или для любой версии ASDF:
CL-USER> (asdf:oos 'asdf:load-op :testprj)
;; или в большинстве окружений (например, SBCL), даже:
CL-USER> (require :testprj)

Вот и всё.

Другие формы в ASD-файле

На самом деле, ASD-файл — это обычный lisp-исходник, просто с другим расширением, что помогает найти его ASDF'у, поэтому в нем могут находится и другие lisp-формы. Впрочем, прежде, чем помещать туда произвольные формы, стоит очень хорошо подумать. Во всяком случае, ASD-файл следует сохранить полностью декларативным, поскольку большинство инcтрументов, созданных вокруг ASDF, должны иметь возможность просто читать этот файл, не исполняя.

Пакет для `defsystem`

Единственный класс форм, размещение которых в ASD-файле необходимо (помимо defsystem и некоторых других ASDF-специфичных форм, о которых будет сказано далее) — это формы работы с пакетом.

Сейчас в Lisp-сообществе есть 2 конкурирующих взгляда на то, как это делать:

простой — определять системы в пакете ASDF (in-package :asdf)
скурпулезный — определять отдельный пакет только для ASDF-описания системы:;; Пример из описания системы ARCHIVE: (defpackage :archive-system (:use :cl :asdf)) (in-package :archive-system)

Лично я являюсь сторонником первого подхода, поскольку он не добавляет избыточной сложности. Его единственный недостаток — в возможном конфликте символов, однако он решается использованием особых символов (#:testprj или :testprj). Единственным случаем, когда вариант отдельного пакета может оказаться препочтительнее — это какие-то очень сложные описания систем с зависимостями от дополнительных пакетов. Впрочем, это верный признак того, что вы делаете что-то не так и, просто, не пользуетесь всеми возможностями ASDF.

Использование символов

Имена ASDF-систем в форме defsystem, как и CL пакетов в defpackage, можно задавать несколькими способами:

символом: (defsystem testprj ...)
кивордом: (defsystem :testprj ...)
неинтернированным символом: (defsystem #:testprj ...)
строкой: (defsystem "TESTPRJ" ...)

Мне не сразу стал понятен принцип выбора, но он прост: нужно использовать неинтернированные символы (а все остальные встречающиеся варианты связанны с тем, что авторы просто не знали или не понимали этот вариант :).

Вариант строки, в принципе, эквивалентен, но не эстетичен, киворда — приводит к "засорению" пакета keywords,— а просто символа — подвержен риску конфликта имен (его точно не стоит использовать, если описывать систему внутри ASDF-пакета).

Задание зависимостей

Я бы сказал, что ключевой функцией ASDF является разрешени зависимостей между исходными файлами в рамках одной системы и между разными системами. Все зависимости в ASDF задаются ключевым словом :depends-on в описании соответствующего компонента (файла, модуля, системы и т.д.)

Зависимости от других систем

Разумеется, любая серьезная система существует не в вакууме, а использует множество других библиотек. Несмотря на миф об их отсутствии в lisp-экосистеме :), большие проекты, над которыми мне приходилось работать, как правило, использовали порядка 20-30 сторонних библиотек (включая рекурсивные зависимости).

Предположим, что наш проект использует библиотеку утилит RUTILS. В таком случае нам нужно немного расширить его описание:

(asdf:defsystem #:testprj
  :depends-on (#:rutils)
  :components ((:file "app")))

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

Зависимости между файлами

Если в проекте больше одного lisp-файла, то стандартной практикой является добавления файла packages.lisp, в котором описываются 1 или несколько пакетов, которые будут использоваться (создавать любой неигрушечный проект в рамках cl-user пакета строго не рекомендуется :).

Предположим, что помимо app.lisp, мы также используем файл support.lisp. В таком случае наше описание приобритет следующую форму:

(asdf:defsystem #:testprj
  :depends-on (#:rutils)
  :components ((:file "packages")
               (:file "support")
               (:file "app")))

Однако мы не задалт порядок загрузки отдельных файлов, что может привести к неожиданным результатам (скажем, Lisp будет ругаться на форму (in-package #:testprj) в файле support.lisp, поскольку файл packages.lisp еще не загружен. Поэтому эту форму нужно доработать:

(asdf:defsystem #:testprj
  :depends-on (#:rutils)
  :components ((:file "packages")
               (:file "support" :depends-on "packages")
               (:file "app" :depends-on "support")))

Тут мы не пишем, что app зависит от packages, поскольку зависимости транзитивны.

Такой последовательный (serial) вариант зависимостей характерен для доброй половины проектов, поэтому для него есть специальная декларация для defsystem: :serial t. С ней наше описание снова упростится:

(asdf:defsystem #:testprj
  :depends-on (#:rutils)
  :serial t
  :components ((:file "packages")
               (:file "support")
               (:file "app")))

В основе ASDF лежит расширяемая объектная модель компонентов и операций над ними. Некоторые разработчики используют в описании систем прямое имя класса :cl-source-file, а не :file. А вот класса file в ASDF как раз нет: конкретный класс определяется из слота default-component-class модуля (система — потомок модуля) и по умолчанию, конечно, является как раз lisp-исходником.

Помимо этого описан ряд других вариантов, компонент, а также всегда можно описать свой собственный (об этом — в следующей статье).

Например, интересной практикой является подобная декларация компонента:

:components ((:static-file "cl-oauth.asd")
             ...

(static-file — это любой статичный файл, который не обрабатывается компилятором, например файл лицензии или, как в данном случае, собственно файл описания системы — ведь он обрабатывается только ASDF. Зачем его добавлять? Например, если мы расчитываем, что будем реализовывать какую-нибудь операцию, типа publish-op, для создания дистрибутива из исходных файлов).

Модули

Модули ASDF — это логические компоненты системы, которые объединяют несколько других компонент. Использование модулей позволяет решить 2 задачи:

аггрегированно управлять зависимостями

Скажем, у нас есть 2 части системы: бэкенд и фронтенд, которые зависят от общего файла утилит. И при изменении каждой из них мы не хотим перекомпилировать другую. В таком случае логично будет описать каждую часть в виде отдельного модуля

распределить исходники по разным директориям (в какой-то степени это аналог модулей в Python, но без управления видимостью — об этом в следующей статье)

(defsystem :arnesi
  ...
  :components
  ((:module :src
            :components ((:file "accumulation"
                                :depends-on ("packages" "one-liners"))
                         (:file "asdf" :depends-on ("packages" "io"))
                         (:file "csv" :depends-on ("packages" "string"))
                         (:file "compat" :depends-on ("packages"))
                         (:module :call-cc
                                  :components ((:file "interpreter")
                                               (:file "handlers")
                                               (:file "apply")
                                               (:file "generic-functions")
                                               (:file "common-lisp-cc"))
                                  :serial t
                                  :depends-on ("packages" "walk"
                                               "flow-control" "lambda-list"
                                               "list" "string"
                                               "defclass-struct"))))
   ...))

А можно ли разложить файлы по разным директориям не привязываясь к модели зависимостей, которая накладывается модулями? Да. У любого компонента есть слот :pathname, который позволяет явно задать путь к нему. Однако его использование имеет свои особенности — об этом дальше.

Имена компонент и путь к ним

У любого ASDF-компонента есть обязательный аттрибут имя, который используется при его поиске и разрешении зависимотстей. Однако этот аттрибут *не задается* декларацией :name в описании компонента.

(defsystem :ch-image
   :name "ch-image"
   ...)

В этом коде :name "ch-image" несет чисто эстетический смысл (не верите? :)

Имя задается первым символом в декларации компонента: в данном случае ch-image, или же в случае модуля выше — :src, или же "accumulation" для файла там же. Все внутренние функции ASDF умеют работать как с символьным, так и со строковым представлением имен, описанных выше.

Кроме того, у каждого компонента есть аттрибут pathname, который определяет его положение в файловой системе. Однако, в отличие от имени, его как раз можно задать соответствующей декларацией. Например, этот пример задает относительный собственно ASD-файла путь к модулю io.multiplex библиотеки IOLIB: :pathname (merge-pathnames #p"io.multiplex/" *load-truename*).

Если же путь не задавать явно, то он вычисляется из имени, расширения (которое определяется типом компонента) и положения в иерархии модулей. Таким образом для примера задания модуля в arnesi (выше) для компонента :file "interpreter" будет вычислен такой путь: src/call-cc/interpreter.lisp.

Ну и ответ на вопрос, как разбросать файлы по директориям, не используя модули: задать для всех файлов явный :pathname.

Мета-информация

Defsystem-форма позволяет задать большое количество полезных метаданных для системы. Очень важно указать как минимум следующие:

:version, например :version "0.0.1" (подробнее о версиях — в отдельной статье)
:author или :maintainer (с указанием e-mail'а, чтобы к вам впоследствии смогли обратиться и предложить миллионы за доработку и поддержку вашей прекрасной библиотеки :)
:licence — чтобы люди знали, как они могут пользоваться вашими поделками

Платформо-зависимое описание систем

CL предоставляет исключительно удобный механизм условной компиляции и выполнения кода (#+/#-). И как раз в описаниях систем он, разумеется, находит широкое применение:

предотвращение загрузки системы в целом — тут интересны примеры из двух альтернативных библиотек для FFI:

#+(or allegro lispworks cmu openmcl digitool cormanlisp sbcl scl)
(defsystem uffi ...)

;; CFFI: этот вариант, безусловно, правильнее, чем просто тихо ничего не сделать
#-(or openmcl sbcl cmu scl clisp lispworks ecl allegro cormanlisp)
(error "Sorry, this Lisp is not yet supported.  Patches welcome!")

вынесение функций, зависящих от конкретной lisp-среды в отдельные файлы — пример из все того же CFFI:

:components (#+openmcl    (:file "cffi-openmcl")
             #+sbcl       (:file "cffi-sbcl")
             #+cmu        (:file "cffi-cmucl")
             #+scl        (:file "cffi-scl")
             #+clisp      (:file "cffi-clisp")
             #+lispworks  (:file "cffi-lispworks")
             #+ecl        (:file "cffi-ecl")
             #+allegro    (:file "cffi-allegro")
             #+cormanlisp (:file "cffi-corman")

закладка нескольких вариантов построения библиотеки, в зависимсоти от каких-то условий. Тут проще всего привести примеры:

;; использовать ли acl-regexp2-engine?
(defsystem :cl-ppcre
  :version "2.0.3"
  :serial t
  :components ((:file "packages")
               (:file "specials")
               (:file "util")
               (:file "errors")
               (:file "charset")
               (:file "charmap")
               (:file "chartest")
               #-:use-acl-regexp2-engine
               (:file "lexer")
               #-:use-acl-regexp2-engine
               (:file "parser")
               #-:use-acl-regexp2-engine
               (:file "regex-class")
               #-:use-acl-regexp2-engine
               (:file "regex-class-util")
               #-:use-acl-regexp2-engine
               (:file "convert")
               #-:use-acl-regexp2-engine
               (:file "optimize")
               #-:use-acl-regexp2-engine
               (:file "closures")
               #-:use-acl-regexp2-engine
               (:file "repetition-closures")
               #-:use-acl-regexp2-engine
               (:file "scanner")
               (:file "api")))

;; какие бэкенды генерации графических файлов доступны?
(defsystem :ch-image
   ...
   (:module
    :io
    :components
    (#+ch-image-has-tiff-ffi
     (:cl-source-file "tiffimage")
     #+ch-image-has-cl-jpeg
     (:cl-source-file "jpegimage")
     #+(and ch-image-has-zpng)
     (:cl-source-file "pngimage")
     (:cl-source-file "imageio"
                      :depends-on (#+ch-image-has-tiff-ffi
                                   "tiffimage"
                                   #+ch-image-has-cl-jpeg
                                   "jpegimage")))
    :depends-on (:src))

;; :name не имеет значения
CL-USER> (defsystem :ch-image
           :name "ch-image1")
#<SYSTEM "ch-image" {AA7A911}>
CL-USER> (describe *)
#<SYSTEM "ch-image" {AA7A911}>
  [standard-object]

Slots with :INSTANCE allocation:
  NAME                     = "ch-image"
  VERSION                  = #<unbound slot>
  IN-ORDER-TO              = NIL
  DO-FIRST                 = ((COMPILE-OP (LOAD-OP)))
  INLINE-METHODS           = NIL
  PARENT                   = NIL
  RELATIVE-PATHNAME        = #P"/home/vs/lib/lisp/ch-image_0.4.1/"
  OPERATION-TIMES          = #<HASH-TABLE :TEST EQL :COUNT 0 {AA7AB61}>
  PROPERTIES               = NIL
  COMPONENTS               = NIL
  IF-COMPONENT-DEP-FAILS   = :FAIL
  DEFAULT-COMPONENT-CLASS  = NIL
  DESCRIPTION              = #<unbound slot>
  LONG-DESCRIPTION         = #<unbound slot>
  AUTHOR                   = #<unbound slot>
  MAINTAINER               = #<unbound slot>
  LICENCE                  = #<unbound slot>

Новости Redis и cl-redis

2010-07-09T12:18:00.005+03:00

Наконец, дошли руки обновить наш клиент для Redis и доработать его для поддержки новых режимов, которые добавились в последних версиях БД. Заодно и проверить утверждения из статьи о том, что клиент тривиально расширяемый и легко адаптируется к изменениям.

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

Короче говоря, у Redis появилась поддержка хеш-таблиц, но обнаружился баг у всех команд, которые передают ключи (в терминах Redis — "поля") в таблице (самый простой пример: HGET table field). Почему этого не заметили разработчики? Видимо, потому, что родной клиент использует для общения с сервером не описанный протокол с разными вариантами передачи команд: inline, bulk и т.п.,— а простой унифицированный способ в форме multi-bulk, т.е. вместо строки "HGET table field", которую посылал наш клиент, вот что:

"*3
$4
HGET
$5
table
$5
field"

Соответственно, наверно, и не заметили особенность при обработке полей в случае передачи команды в inline-форме.

Справедливости ради, нужно сказать, что если порыться в документации, то можно найти замечание, что

"A good client library may implement unknown commands using this command format in order to support new commands out of the box without modifications."

(т.е. самый продуктивный путь был — снова перечитать спецификацию протокола :) Теперь вот, задумался, может стоит перевести все команды на эту multi-bulk форму. И API упростится, будет не:

(def-cmd HGET (key field)
"Retrieve the value of the specified hash FIELD."
:generic :bulk)

(def-cmd HGET (key field) :bulk
"Retrieve the value of the specified hash FIELD.")

С другой стороны, немного уменьшиться производительность.

Вообще, Redis все в большем количестве мест использует multi-bulk форму (поскольку она наиболее общая). Поддержка PubSub сделана также на ней, хотя и с небольшим отклонением.

PubSub — это сейчас такой горячий пирожок, который все хотят съесть. Как это реализовано здесь? Есть команды SUBSCRIBE и PSUBSCRIBE, позволяющие подписаться на каналы соответственно по имени и по шаблону (типа "news.*"). И есть PUBLISH, которая посылает сообщения. Сообщения доставляются условно мгновенно и приходят в рамках тех активных соединений, в которых произведена подписка. Таким образом, типичный подход к применению этого, насколько я понимаю — это когда у нас есть отдельная нить-слушатель, которая обрабатывает приходящие сообщения и иницирует какую-то реакцию в программе. Где-то так:

(with-connection ()
(red-subscribe "chan")
(loop
   (let ((msg (expect :multi)))
     (bt:make-thread (lambda ()
                       (process (elt msg 2))))
     ;; или же, например
     (bt:with-lock-held (*lock*)
       (push (elt msg 2) *internal-queue*)))))

Сообщения имеют вид '("message" <канал> <сообщение>) для простой подписки и '(<шаблон> <канал> <сообщение>) для PSUBSCRIBE. Вот, собственно, и всё.

Как видно из примера, получение сообщений из канала блокирующее и выполняется просто за счет вызова функции expect, которая во всех обычных командах присутствует в паре tell-expect. Так что, возвращаясь к моим утверждениям про легкую расширяемость и адаптацию — они подтвердились (и один из примеров — вот он).

Redis действительно быстро развивается и много чего меняется, добавляются радикально новые варианты использования: в данном случае транзакции и PubSub. Но для поддержки всего этого в клиенте хватает точечных изменений на уровне реализации протокола, никакого рефакторинга. В этот раз нужно было добавить еще несколько вариантов ожидания ответа: :queued (для транзакций), при котором считывается сразу несколько разнородных ответов подряд; :float; а также :pubsub,— поменять несколько определений команд, потому что поменялась сама их спецификация. Ну и добавилась обработка особого случая транзакций, когда любая команда возвращает "QUEUED" вместо своего стандартного ответа.

PS. Да, и еще про транзакции: теперь, как видите, Redis и их поддерживает. Что меня заинтересовало — это обсуждение гарантий целостности (на этой же странице внизу), которые, на первый взгляд, недостаточны: нет условия успешного завершения всех команд в рамках транзакции, чтобы транзакция была признана успешной. Т.е. ROLLBACK не предусмотрен. Но вот, что пишет на этот счет Сальваторе Санфилиппо:

I think you are missing the point about MULTI/EXEC, that is, a Redis command only fails on syntax error or type mismatch. That is, in code without errors the transaction will either be executed as whole or nothing. Still it is true that if there are programming errors like using a list command against a set, or a syntax error, only the sane commands will be performed and the others instead will fail, but it's very hard for this to happen in production.

Так что транзакции в Redis кислотные по-своему, и нужно хорошо уяснить для себя их семантику, прежде чем браться применять. (И опять, возвращаясь к тому, с чего я начинал: встает проблема адекватности документации. А идеальная документация — исполняемая... ;)

Внутреннее устройство ASDF

2010-07-09T07:58:00.006+03:00

Это вторая статья в серии про ASDF. Первая рассказывала про нововведения в ASDF 2.

Итак, рассказ о внутренностях ASDF начнем с того, что меня самого испугала бы задача создать с нуля подобную систему. В данном случае в идеале нужно единомоментно получить программу, обладающую одновременно такими довольно противоречивыми характеристиками:

хорошо покрывающую основные варианты использования (в случае ASDF — это и средство описания систем (для их последующего распространения), и менеджер сборки)
простую и удобную для непосвященных в детали пользователей
хорошо расширяемую для того, чтобы позволить развивать сопутствующую инфраструктуру (например, такие средства как ASDF-INSTALL)
ну и, разумеется, сразу корректно работающую

ASDF была впервые написана Деном Барлоу в 2001 году. Как я понимаю, подспорьем при ее создании был фундаментальный труд Кента Питмана, обобщающий опыт в этой сфере, "Описание больших систем" (1984 года), а также опыт эксплуатации ее предшественника MK:DEFSYSTEM. Т.е., по сути, ASDF была "второй системой", но в данном случае, к счастью, удалось избежать реализации соответствующего синдрома.

Что же представляет из себя эта сама по себе довольно большая система изнутри? Хребтом ASDF является иерархия классов component → module → system, которые содержат информацию об именах, местоположении и зависимостях систем и их компонент, метаинформацию, а также служебную информацию самой ASDF.

Кроме того описаны классы операций, которые могут выполняться над системами, как то: compile-op, load-op, test-op и т.д. Почему операции являются объектами, а не просто ключами, что напрашивается на первый взгляд? Во-первых, это позволяет наследовать от них и при этом точечно менять поведение связанных обобщенных функций. Но даже более важно то, что объект операции имеет определенные свойства: операцию-родитель, является ли операция форсированной (хотя это свойство на данный момент не работает корректно), таблицы отработанных и еще не отработанных узлов и т.д. Это имеет и свой недостаток, поскольку кажется несколько избыточным для обычного пользователя. В версии ASDF 2 для его устранения введены функции-обертки load-system, compile-system и test-system.

На уровне пользовательского API на основе всех этих классов функционирует макро defsystem, а также обобщенная функция operate.

Defsystem — это хороший инструмент описания систем, знакомый и понятный, я думаю, каждому. Он ведет свою историю еще от Lisp Machine Lisp DEFSYSTEM, хотя с тех пор и существенно эволюционировал в сторону упрощения интерфейса.

Параметры defsystem-формы не передаются, как можно было бы предположить, напрямую в (make-instance 'system ...), а сперва обрабатываются функцией parse-component-form. При этом часть параметров передается как есть, а часть транслируется или используется в качестве мета-параметров. Остановлюсь на двух из них:

defsystem можно применять не только для стандартных систем, но и их потомков за счет параметра :class
параметр :depends-on (и :weakly-depends-on¹), на самом деле, не присутствует в качестве слота в классе component. Его содержимое транслируется в содержимое слота in-order-to, которое описывает зависимости более гранулярно отдельно для каждой операции. Кстати, этот слот можно задать напрямую в defsystem-описании, чем иногда пользуются при необходимости указания нестандартных сценариев поведения. Впрочем, среди установленных у меня порядка 70 библиотек я нашел только несколько примеров такого использования, самый интересный из которых — в описании системы weblocks-prevalance (в остальных случаях это применяется для указания зависимостей систем-тестовых наборов). В данном случае устанавливается зависимость от дополнительно определенной операции prepare-prevalance-op:

(defsystem weblocks-prevalence
   :name "weblocks-prevalence"
   ;; кстати, нет смысла задавать параметр `name' для системы,
   ;; поскольку имя берется из символа, передаваемого в defsystem
   :description "A weblocks backend for cl-prevalence."
   :depends-on (:metatilities :cl-ppcre :cl-prevalence :bordeaux-threads)
   :components ((:file "prevalence"))
   :in-order-to ((compile-op (prepare-prevalence-op :weblocks-prevalence))
                 (load-op (prepare-prevalence-op :weblocks-prevalence))))

А сама операция prepare-prevalence-op характеризуется всего одним дополнительным методом, отвечающим за подгрузку дополнительной системы, находящейся по внутреннему пути, не известному в *central-registry*:


(defmethod perform ((op prepare-prevalence-op)
                    (c (eql (find-system :weblocks-prevalence))))
  (unless (find-package :weblocks-memory)
  ;; load weblocks if necessary
  (unless (find-package :weblocks)
    (asdf:oos 'asdf:load-op :weblocks))
  ;; load weblocks-memory.asd
  (load (merge-pathnames
         (make-pathname :directory '(:relative "src" "store" "memory")
                        :name "weblocks-memory" :type "asd")
         (funcall (symbol-function
                   (find-symbol (symbol-name '#:asdf-system-directory)
                                (find-package :weblocks)))
                  :weblocks)))
  ;; load weblocks-memory
  (asdf:oos 'asdf:load-op :weblocks-memory)))

Впрочем, это можно было бы сделать и иначе :)

Проблемой использования defsystem, которой я коснусь в следующей статье на тему шаблонов применения ASDF, является то, что есть соблазн отступить о чисто декларативного описания системы и добавить в него некоторые исполняемые элементы, например, чтение и подстановку версии системы из отдельного файла. Как по мне, было бы разумно обрабатывать эту форму в рамках (let ((*read-evel* nil) ...), чтобы исключить такие варианты. Причина тут в том, что ASDF-описание может обрабатыватся более, чем 1 раз при поиске систем и разрешении зависимостей, и работа с ним в таком случае выполняется в режиме просто чтения. Возможно, это ограничение будет со временем установлено: во всяком случае это уже обсуждалось в рассылке.

Теперь рассмотрим функцию operate, которая является точкой входа в область собственно ядра ASDF, которое отвечает за поиск и выполнение операций над зависимыми компонентами. Она опирается на обобщенные функции traverse, роль которой — в построении плана выполнения той или иной операции, и perform, которая собственно выполняет конечные действия, будь то компиляция, загрузка файлов и т.д, а также на функцию find-system. Кроме того, интересным дополнением (неким альтер-его) perform является explain, которая только указывает, какое действие должно быть выполнено. Хорошая иллюстрация возможностей применения explain дана в статье Питмана:

(DOLIST (STEP (SYSDEF:GENERATE-PLAN system :UPDATE))
  (SYSDEF:EXPLAIN-ACTION system STEP)
  (UNLESS (NOT (Y-OR-N-P "OK? "))
     (SYSDEF:EXECUTE-ACTION system STEP)))

Этот код на Lisp Machine Lisp позволяет пошагово выполнять обновление системы при условии согласия пользователя на каждом шаге.

Операция traverse реализует алгоритм поиска и разрешения зависимостей ASDF. Сам по себе он не стоит отдельного рассмотрения, но что интересно, это то, что алгоритм может обрабатывать 3 типа зависимостей:

привычную простую форму (:depends-on (:cl-ppcre ...))
версионированную форму (:depends-on ((:version :cl-ppcre "1.2.3") ...))
зависимость от фичи (:depends-on ((:feature :x86) ...))

Ко второй форме мы еще вернемся в теме о поддержке версионности. А на счет третьей, то к ней относится интересный комментарий в коде ASDF: "Congratulations, you're the first ever user of FEATURE dependencies! Please contact the asdf-devel mailing-list." :)

Точкой входа в механизм поиска Лисп-систем в операционной системе является функция find-system, которая смоделированна на основе стандартной функции find-class. (Артефактом такого подобия является параметр errorp, необходимость в котором как здесь, так и в find-class и find-method, в которых также реализован этот подход, как по мне, по меньшей мере сомнительна). Find-system одновременно проверяет наличие системы среди уже загруженных (таблица таких систем со врменем последнего обновления находится в *defined-systems*), а также ищет на диске с помощью функции system-definition-pathname, которая в свою очередь раскручивает механиз поиска систем функциями, заданными в списке *system-definition-search-functions*. На данный момент в этом списке 2 основных функции: "классический" поиск в директориях, заданных в *central-registry*, и новый поиск в source-registry. Очень важной особенностью find-system, про которую не нужно забывать, это ее побочный эффект — загрузка ASD-файла системы в память и регистрация его в *defined-systems*.

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

В общем-то, это и всё ядро ASDF. Остальное — это ряд утилит для работы с операционной системой, среди которых несколько очень полезных функций, заслуживающих более широкой известности в Лисп-мире (например, run-shell-command, load-pathname, parse-windows-shortcut и другие), а также добавленные в ASDF 2 механизмы определения местонахождения FASL-файлов (в чем-то аналог ASDF-BINARY-LOCATIONS, для которого добавлен и compatibily mode) и работы с центральным реестром.

Разобравшись во внутренностях ASDF я пришел к довольно неожижанному для себя выводу: в ее основе лежит хорошо продуманный объектно-ориентированный дизайн, дающий воможность для ее эффективного применения не только непосредственно, но и как основы для других инструментов. Более того, используя ее как кейс, можно даже учить людей настоящему практическому объектно-ориентированному проектированию². В то же время, этот дизайн, конечно, не идеален.

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

И еще можно сказать, что ASDF намного ближе по своей философии к (качественным) продуктам "классических" системных языков, таких как С++ или Java, чем к распространенному в последнее время в Лиспе bottom-up стилю. В то же время, за счет использования полезных возможностей Лиспа: мультиметодов, функций высших порядков и т.п.,— он намного менее церемониален и многословен, так сказать, без перегрузки шаблонами проектирования.

В следующей статье — о некоторых шаблонах использования ASDF.

¹ разница в том, что изменение "слабых" зависимостей не вызывает перекомпиляцию зависящих от них компонент
² ... а не такому далекому на поверку от реальности, который можно увидеть, например, в знаменитой книге Гради Буча

И в придачу, непонятная визуализация того, как происходит поиск системы:)

Уникальные технологии Common Lisp

2010-07-05T08:43:00.005+03:00

Написано для: developers.org.ua
Время написания: октябрь 2008

Базовые подсистемы языка

В языке Common Lisp есть как минимум 3 инфраструктурных технологии, во многом формирующие подходы к его применению, которые в других языках либо отсутствуют вовсе, либо реализованы в очень ограниченном варианте. Для компенсации их отсутствия пользователи других языков часто вынуждены использовать Шаблоны проектирования, а порой и вообще не имеют возможности применять некоторые более эффективные подходы к решению типичных задач.

Что это за технологии и какие возможности дает их использование?

Макросистема

Это основная отличительная особенность Common Lisp, выделяющая его среди других языков. Ее реализация возможна благодаря использованию для записи Lisp-програм s-нотации (представления программы непосредственно в виде ее абстрактного синтаксического дерева). Позволяет программировать компилятор языка.

Позволяет полностью соблюдать один из основополагающих принципов хорошего стиля программирования DRY (не-повторяй-себя).

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

Примеры применения:

Определение управляющих конструкций языка, которые могут использоваться на равне со стандартными (на самом деле практически все стандартные управляющие конструкции также являются макросами. Основу языка — “аксиомы”, которые невозможно определить через другие конструкции — составляют специальные операторы). В качестве примера можно привести анафорические управляющие конструкции (см. библиотеку Anaphora), которые, используя принцип “convention over configuration”, скрывают реализацию некоторых типичных шаблонов.
Самый простой пример — макро AIF (или IF-IT), которое тестирует первый аргумент на истинность и одновременно привязывает его значение к переменной IT, которую, соответственно, можно использовать в THEN-clause:
```
(defmacro aif (var then &optional else)
`(let ((it ,var))
  (if it ,then ,else)))
```
Учитывая то, что в CL ложность представляется константой NIL, которая также соответствует пустому списку, такая конструкция, например, часто применяется в коде, где сначала какие-то данные аккумулируются в список, а потом, если список не пуст, над ними производятся какие-то действия. Другой вариант, это проверить, заданно ли какое-то значение и потом использовать его:
```
(defun determine-fit-xture-type (table-str)
"Determine a type of Fit fixture, specified with TABLE-STR"
(handler-case
    (aif (find (string-trim *spacers* (strip-tags (get-tag "td" (get-tag "tr" table-str 0) 1)))
               *fit-xture-rules* :test #'string-equal :key #'car)
         (cdr it)
         'row-fit-xture)
  (tag-not-found () 'column-fit-xture)))
```
* В этой функции проверяется, есть ли во второй ячейке первой строки HTML таблицы какие-то данные и в соответствии с этим определяется тип привязки для Fit-теста. Переменной it присвоены найденные данные.
Создание DSL‘ей для любой предметной области, которые могут иметь в распоряжении все возможности компилятора Common Lisp. Ярким примером такого DSL’я может служить библиотека Parenscript, которая реализует кодогенерацию JavaScript из Common Lisp. Используя ее, можно писать макросы для Javascript!
```
(js:defpsmacro set-attr (id attr val)
`(.attr ($ (+ "#" ,id)) ,attr ,val))
```
* Простейший макрос-обертка для задания аттрибутов объекта, полученного с помощью селектора jQuery
В форме локальных макросов (MACROLET) для модуляризации и разделения потоков вычислений внутри сложных функций, а также для соблюдения принципа DRY при написании лишь слегка отличающегося кода в различных местах одной функции.

Наконец, создание инфраструктурных систем языка. Например, с помощью макросов можно реализовать продления (библиотека CL-CONT), ленивые вычисления (библиотека SERIES) и т.д.

…ну и для многих других целей.

Больше по теме: Paul Graham, On Lisp

Мета-объектный протокол и CLOS

Основа объектной системы языка. Позволяет манипулировать представлением классов.

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

Уникальной является технология комбинации методов, позволяющая использовать стандартные способы комбинации: перед, после, вокруг,— а также определенные пользователем.

Примерами использования мета-объектного протокола также являются инфраструктурные системы языка, реализованные в виде библиотек:

object-persisance: Elephant, AllegroCache
работа с БД: CLSQL
интерфейс пользователя: Cells

Библиотека CLSQL создана для унификации работы с различными SQL базами данных. Кстати, на ее примере можно увидеть проявление мультипарадигменности Common Lisp: у библиотеки есть как объектно-ориентированный интерфейс (ORM), реализованный на основе CLOS, так и функциональный (на основе функций и макросов чтения).

С помощью мета-объектного протокола стандартный класс языка расширяется специальным параметром — ссылкой на таблицу БД, к которой он привязан, а описания его полей (в терминологии Lisp: слотов) — дополнительными опциональными параметрами, такими как: ограничение уникальности, ключа, функция-преобразователь при записи и извлечении значения из БД и т.д.

Больше по теме: Gregor Kiczales et al. The Art of Metaobject Protocol

Система обработки ошибок / сигнальный протокол

Система обработки ошибок есть в любом современном языке, однако в CL она все еще остается в определенном смысле уникальной (разве что в C# сейчас вводится нечто подобное). Преимущество этой системы заключается опять же в ее большей абстрактности: хотя основная ее задача — обработка ошибок, точнее исключительных ситуаций,— она построена на более общей концепции передачи управления потоком выполнения программы по стеку. …Как и системы в других языках. Но в других языках есть единственный предопределенный вариант передачи управления: после возникновения исключительной ситуации стек отматывается вплоть до уровня, где находится ее обработчик (или до верхнего уровня). В CL же стек не отматывается сразу, а сперва ищется соответствующий обработчик (причем это может делаться как в динамическом, так и в лексическом окружении), а затем обработчик выполняется на том уровне, где это определенно программистом. Таким образом, исключительные ситуации не несут безусловно катастрофических последствий для текущего состояния выполнения программы, т.е. с их помощью можно реализовать различные виды нелокальной передачи управления (а это приводит к сопроцедурам и т.п.) Хорошие примеры использования сигнального протокола приведены в книге Practical Common Lisp (см. ниже).

Больше по теме:

Вспомогательные технологии

Кроме того в CL есть ряд технологий менее значительных, которые нельзя назвать в полной мере уникальными, но которые существенно упрощают его применение и делают программы более ясными, а также дают дополнительные возможности для расширения языка:

Протокол множественных возвращаемых значений

Дает возможность возвращать из функции несколько значений и по желанию принимать все их (и привязывать к каким-то переменным) или только часть. По-умолчанию для кода, не использующего эту функциональность, передается только 1-е значение.

Казалось бы, это простая возможность, однако, на поверку, она требует обширной поддержки на языковом уровне (учитывая необходимость поддержки возврата из блоков и т.п.).

Протокол обобщенных переменных

Это аналог свойств в некоторых ОО-языках. Концептуально, оперирует понятием места (place) — по сути дела ячейки памяти, однако не физической (без манипуляции указателями) — это может быть просто объект или же элемент какой-то структуры (будь-то опять же объект, список, массив и т.д.) Таким образом, имеются намного большие возможности, чем при использовании обычных свойств, поскольку для любой функции, которая читает значения какого-либо места, можно указать функцию которая его значение задает.

Больше по теме: Paul Graham, On Lisp, Ch.12 “Generalized Variables”

Макросы чтения

Это инструмент модификации синтаксиса языка за пределы s-выражений, который дает программисту возможность, используя компилятор Lisp, создать свой собственный синтаксис. Его работа основана на фундаментальном принципе Lisp-систем: разделении времени чтения, времени компиляции и времени выполнения — REPL (Read-Eval-Print Loop). Обычные макросы вычисляются (раскрываются, expand) во время компиляции, и полученный код компилируется вместе с написанным вручную. А вот макросы чтения выполняются еще на этапе обработки программы парсером при обнаружении специальных символов (dispatch characters). Механизм макросов чтения является возможностью получить прямой доступ к Reader’у и влиять на то, как он формирует абстрактное синтаксическое дерево из “сырого” программного кода. Таким образом, можно на поверхности Lisp использовать любой синтаксис, вплоть до, например, C-подобного. Впрочем, Lisp-программисты предпочитают все-таки префиксный унифицированный синтаксис со скобками, а Reader-макросы используют для специфических задач.

Пример такого использования — буквальный синтаксис для чтения hash-таблиц, который почему-то отсутствует в спецификации языка. Это, кстати, еще один пример того, каким образом CL дает возможность изменить себя и использовать новые базовые синтаксические конструкции наравне с определенными в стандарте. Основывается на буквальном синтаксисе для ассоциативных списков (ALIST):

;; a reader syntax for hash tables like alists: #h([:test (test 'eql)] (key . val)*)
(set-dispatch-macro-character #\# #\h
   (lambda (stream subchar arg)
     (declare (ignore subchar)
              (ignore arg))
     (let* ((sexp (read stream t nil t))
            (test (when (eql (car sexp) :test) (cadr sexp)))
            (kv-pairs (if test (cddr sexp) sexp))
            (table (gensym)))
       `(let ((,table (make-hash-table :test (or ,test 'eql))))
          (mapcar #'(lambda (cons)
                      (setf (gethash (car cons) ,table)
                            (cdr cons)))
                  ',kv-pairs)
          ,table)))))

Больше по теме: Doug Hoyte, Let Over Lambda, Ch.4 “Read Macros”

Послесловие

В заключение хотелось бы коснуться понятия высокоуровневого языка программирования. Оно, конечно, является философским, поэтому выскажу свое мнение на этот счет: по-настоящему высокоуровневый язык должен давать программисту возможность выражать свои мысли, концепции и модели в программном коде напрямую, а не через другие концепции, если только те не являются более общими. Это значит, например, что высокоуровневый язык должен позволять напрямую оперировать такой сущностью, как функция, а не требовать для этого задействовать другие сущности такого же уровня абстракции, скажем, классы. Подход к созданию высокоуровневого языка можно увидеть на примере Common Lisp, в котором для каждой задачи выбирается подходящая концепция, будь то объект, сигнал или место. А что дает нам использование по-настоящему высокоуровневых языков? Большую расширяемость, краткость и адаптируемость программы к изменениям, и, в конце концов, настоящую свободу при программировании!

Интересная задачка: вытесняющий мультипроцессинг в userland

2010-07-05T08:26:00.003+03:00

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

Интересно было бы увидеть, как это реализовывается в разных языках? (Я так понимаю, что в Smalltalk это должно быть тривиально за счет наличия объекта контекста. А где еще?)

ASDF 2

2010-06-30T12:56:00.003+03:00

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

ASDF является фактически единственным на данный момент сборщиком Common Lisp програм. Более того он играет свою роль в различных менеджерах дистрибутивов, хотя и не является самим по себе полноценным решением. И, я бы сказал, что со своей ролью инструмента сборки он справляется довольно неплохо, а вот в сфере описания дистрибутивов есть проблемы, которые пока что не решены на практике. Это заставляет многих людей, в том числе и меня, вообще не пользоваться подобными инструментами и произвоить установку дистрибутивов вручную (благо в Common Lisp среде, в том числе и благоаря ASDF это очень просто¹), а других (в том числе и меня) задумыватся о создании собственного средства: примеры тому — Mudballs, Lispy, CL-Librarian, LibCL...

В недавней статье в журнале ПФП я написал, что

развитие средства управления пакетами должно идти именно с учетом децентрализованной структуры Лисп-среды, а не вопреки ей.

К такому же заключению мы пришли и в процессе обсуждения темы на форуме lisper.ru, которое также заставило меня немного заглянуть под капот ASDF, чтобы узнать, насколько реально и легко создать на его основе пакетный менеджер. Этот "быстрый взгляд" в итоге вылился в растянутое на целый месяц неспешное ковыряние кода и его доработку для полноценной поддержки версионирования. Свое решение я направил в список рассылки asdf-devel, однако оно вряд ли будет интегрированно. В любом случае, этой теме я собираюсь посвятить отдельную запись в этой серии.

А начнем мы с того, что нового нам несет ASDF 2, релиз которого состоялся 31 мая, и который уже скоро войдет в вашу любимую Лисп реализацию.

Целая новая версия системы претерпела существенный рефакторинг и доработку силами Фарэ и Роберта Голдмана. С точки зрения пользователей она включает в себя следующие улучшения (разумеется, накопленные и отлаженные за посление ряд релизов):

версионность самой библиотеки, возможность обновления ASDF

добавление более простого пользовательского интерфейса

добавление нового способа конфигурации

сохранение FASL-файлов отдельно (в других директориях) от исходного кода

улучшение работы c путями и соответствующее расширение классов component и system

исправление некоторых багов

Вот lightning talk Роберта на встрече TwinCity лисперов, посвященный ASDF 2. Нужно заметить, что ценность этого релиза не только практическая, но и символическая, знаменующая переход проекта на новую стадию разработки: более структурированную и прогнозируемую.

Итак, кратко о новых фичах.

1. Возможность обновления ASDF.
Сейчас любой пользователь может воспользоваться самой новой версией ASDF, просто загрузив ее через (asdf:oos 'asdf:load-op 'asdf) (но не через require!) Подробнее об этом в мануале, который, также улучшается.

2. Более простой пользовательский интерфейс — это функции load-system, compile-system и test-system. Вроде бы как, тривиальное изменение, но избавляющее новичков от необхоимости думать, почему это операции load-op и т.п. являются объектами, а не функциями, и других схожих волнений. Это важно в борьбе с кажущейся сложностью ASDF. При этом методы на test-op, как и раньше — и это понятно — нужно описывать разработчикам систем.

3. Системный реестр (source-registry) — новый способ конфигурации :)
Именно таким является новый, и по замыслу авторов основной способ задания места расположения исходников систем у пользователя. В то же время старый вариант через *central-registry* остается полностью функциональным и поддерживаемым. Более того, он был дополнен проверкой на самую неприятную и, наверно, частую ошибку при использовании ASDF — отсутствие слеша в конце пути к директориям — теперь этой неразберихи больше не будет.

Что же такое системный реестр? Это набор конфигурационных файлов в предопределенной структуре директорий для каждого пользователя, смоделированных по принципу *.conf.d директорий в Unix. А также собственно DSL для конфигурации. Простой пример того, как это работает из мануала:

В директории ~/.config/common-lisp/ находится файл source-registry.conf со следующей конфигурацией:
(:source-registry
 (:tree "/home/fare/cl/")
 :inherit-configuration)
В данном случае поиск установленных систем производится рекурсивно в поддиректориях в /home/fare/cl/.

Однако это объяснение и пример далеко не исчерпывающи, поэтому лучше читать соответствующий раздел руководства и проверить все собственноручно.

Честно говоря, как по мне, то новый подход для индивидуального разработчика менее удобен, чем использование *central-registry*. Однако он лучше подойдет для средств автоматического конфигурирования (и, я думаю, что как раз опыт в рамках ITA, где используется много Lisp серверов приложений, послужил отправной точкой для разработки этого способа), а также для использования в пакетных менеджерах. И хорошо, что теперь есть альтернативы для каждого из случаев.

4. Cохранение FASL-файлов теперь происходит в компилятор-специфичных директориях, по умолчанию спрятанных в домашней диретории пользователя. Благодаря этому устраняются проблемы как конфликта прав в случае использования одних и тех же исходников библиотек разными пользователями, так и stale FASLs, которые возникают при апгрейде реализации (в частности для SBCL).

5. В общем, исправлены основные недочеты, которые присутствовали в ASDF при работе с путями в разных операционках, а в классы компонент и система добавлены слоты, указывающие абсолютное положение их в файловой системе. Также исправлены и некоторые другие баги, о чем можно почитать в Changelog'е.

Какие проблемы остались? Из существенных для меня — две: нечеткая семантика форсированных операций (параметр :force t), а также недостатки работы с версиями (этой теме будет посвящена отдельная запись, поэтому не буду касаться ее здесь).

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

В следующей записи — немного о внутренностях ASDF...

¹ Мой алгоритм установки Lisp библиотеки:
- Загрузить tar.gz файл
- Развернуть в ~/lib/lisp/
- Создать символическую ссылку на ASD-файл в ~/.lisp/
- (И вариация для случая работы с разными версиями одного пакета): ссылка на ASD-файл основной версии в ~/.lisp/, а при необходимости использования альтернативной версии, скажем hunchentoot-0.15.7 вместо hunchentoot-1.1.0 (push "~/lib/lisp/hunchentoot-0.15.7/" asdf:*central-registry*) (аналог PATH).

Что такое стартап?

2010-06-29T23:15:00.004+03:00

Или точнее, что отличает настоящий стартап от других видов бизнеса? Еще один вопрос, не имеющий никакого практического значения, но всегда являющийся интересной темой для поговорить :)

После 2-х лет, в течение которых я более-менее имею отношение к этой сфере, сегодня пришла простая формулировка, что же я под ним понимаю.

В общем, стартап — это начинание, в котором сочетаются и сбаллансированны 3 составляющих: исследовательская, инженерная и бизнес. Исследовательская отвечает за сферу инноваций, инженерная — за их "доставку" до конечного потребителя, а бизнес — за извлечение из этого денег, позволяющих продолжать работу, развиваться и достигать личных целей основателям. При этом тут, на самом деле, не важна сфера: инженерия сейчас нужна не только в Интернете :), но и в биохимии, и во флористике. (Вот, кстати, хорошая цитата про то, почему же отдельно исследование, а отдельно инженерия, случайно встреченная мною в статье в Википедии: "The theory, while correct in as far as it goes, is not sufficient to allow one to do engineering").

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

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

Mathematicians vs computer scientists

2010-06-16T15:59:00.001+03:00

There is a considerable difference between a mathematician’s view of the world
and a computer-scientist’s. To a mathematician all structures are static: they have
always been and will always be; the only time dependence is that we just haven’t
discovered them all yet. The computer scientist is concerned with (and fascinated by)
the continuous creation, combination, separation and destruction of structures: time is
of the essence. In the hands of a mathematician, the Peano axioms create the integers
without reference to time, but if a computer scientist uses them to implement integer
addition, he finds they describe a very slow process, which is why he will be looking
for a more efficient approach. In this respect the computer scientist has more in com-
mon with the physicist and the chemist; like these, he cannot do without a solid basis in
several branches of applied mathematics, but, like these, he is willing (and often virtu-
ally obliged) to take on faith certain theorems handed to him by the mathematician.
Without the rigor of mathematics all science would collapse, but not all inhabitants of a
building need to know all the spars and girders that keep it upright. Factoring off cer-
tain detailed knowledge to specialists reduces the intellectual complexity of a task,
which is one of the things computer science is about.
--"Parsing Technics"

Парадигмы программирования, followup

2010-05-31T21:22:00.003+03:00

Полтора года назад написал про парадигмы программирования. Сейчас подумал, что нужно называть вещи своими именами, а не так, как принято. :)

Например, функциональный язык — это такой, где вы будете задачи решать через функции. Т.е., когда вы беретесь за новую задачу, то напишите какой-нибудь defun или function. Следующим ключевым свойством функциональных языков является вот что: все есть выражение (expression), т.е. возвращает значение, а не утверждение (statement). Всё. На этом функциональность, строго говоря заканчивается. Но есть еще очень много других видов языков. Вот Haskell, например, язык, вообще говоря, не такой уже функциональный язык. Потому что решать вы все будете через типы и напишите сначала Data :: Type. А функции — лтшь один из частных случаев этих типов (один из типов, попросту говоря), но ведь гораздо интереснее такие типы, как монады или функторы. В общем, язык, на самом деле, алгебраический, т.е. для математиков (по складу ума). Вообще, все языки более-менее для кого-то там по складу ума.

Далее, вот, Common Lisp — наполовину функциональный, наполовину декларативный (потому что в половине случаев я начну не с defun, а с defmacro). А еще на треть объектно-ориентированный, потому что для defclass тоже часто найдется место (но без фанатизма). А Scheme — действительно чисто функциональный, так кроме функций больше ничего нет. Дальше посмотрим на Erlang — это сперва язык для конкурентного программирования. Всё закручено вокруг процессов и обмена сообщениями между ними. Это только на поверхности там пролог и функции, это всего лишь синтаксис. Т.е. нельзя отрицать функциональную ориентированность Erlang'а, но язык таки process-oriented/message-passing. А что же этот знаменитый функциональный язык JavaScript? Нет, нет и нет: "всё — выражение" не выполняется, и хотя функции — обычный синтаксис для записи кода, но ядро языка — это события и коллбеки, event-driven, как говорят американцы.

Возьмем теперь Ruby. Тут всё на классах и лямбдах, т.е. анонимных функциях. А обычные функции превращены в сообщения. Да еще и всё — выражение. Вот такая анархия или мультипарадигменность. И ко всему прочему полный контроль у программиста. Получается объектно-procедурно-немного декларативно-ориентированный. Еще есть Python. Тут все немного (или намного) регулярней. Есть классы и функции, но не всё выражение, анонимных функций, считай нет. В общем, glorified C (как хорошо показывет пример Cython), но, главное, что динамический и разумно простой. Современный объектно-ориентированный процедурный язык, в общем.

C Java, например, всё понятно. Тут чистый классовый подход. Класс на inner классе сидит и анонимным классом погоняет. Говорят, это называется объектно-ориентированный подход, хотя это, вообще-то, про Smalltalk или даже про Python. А тут у нас класс-ориентированный, чистой воды. На закуску остается C++, которому можно всё, особенно в версиях Boost и 0x. Только вот, забывают заметить, что это 3 отдельных языка: С, ++, а также еще Tempaltes. И это не говоря про препроцессор. Тут тоже, как бы, всё class-based, но всё — не объект, а указатель. Короче говоря, такой машинно-ориентированный язык с системами типов и классов, в придачу к возможности застрелить себя в ступню, как говорят опять же американцы...

Про brainfuck и все остальное более-менее без изменений.

Лисп — философия разработки

2010-05-26T15:43:00.002+03:00

Написано для: Практика функционального программирования №5
Соавтор: Александр Манзюк

Чтобы не делать перепечатку, помещаю тут только аннотацию. Основной текст — по ссылке выше.

В статье исследуются подходы к разработке, практикуемые в Лисп-среде, на примерах решения различных прикладных задач на языке Common Lisp. Вы узнаете о том, что макросы — это не только синтаксический сахар, но и прекрасный инструмент инкапсуляции, что кроме глобальных и локальных переменных бывают еще специальные, что полиморфные интерфейсы можно создавать без привязки к классам, а также о том, что определять стратегии передачи управления можно не только с помощью монад. Рассмотрены и решения прикладных задач: клиент для хранилища данных Redis, прокси между двумя бизнес-приложениями, внутренний API веб-сервиса, библиотека парсерных комбинаторов.

Простая модель налоговой реформы для малого И крупного бизнеса

2010-05-18T15:35:00.016+03:00

Я не буду касаться здесь каких-то сложных с экономической точки зрения идей и тем, таких как: нужно или не нужно НДС и т.п. Взамен же попробую обратиться к столь общим вопросам, как: простота, эффективность, сбаллансированность и справедливость,— которых "немного" не хватает в текущей системе. Отсюда, как по мне, и растут ноги у всех проблем.

Итак, первое, единый налог и проблемы, связанные с его использованием для "оптимизации" налогообложения.

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

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

В чем проблема для других форм. Простой пример: есть человек, который выполняет какую-то профессиональную деятельность, например, моет окна. Он может делать это в рамках компании и получать зарплату 4000 грн в месяц, при этом налоговое бремя, которое ложиться на такую компанию — еще 2400 грн, а сам человек на руки получает 3400 грн (а 15% платит налога на доход). Если он моет 20 окон в месяц, то за каждое окно компания должна брать с заказчика 320 грн (+ НДС :), чтобы хотя бы выйти в 0 (будем считать, что больше расходов нет). Теперь представим, что тот же человек моет окна как частный предприниматель: теперь, чтобы получить свои 3400 грн, ему нужно выручить всего то 3600, т.е. при цене 320 грн за окно, помыть около 11 с хвостиком окон. А если он помоет 20, то заработает 7800, что ровно в 2 раза больше. Спрашивается, как компания сможет конкурировать с таким фрилансером? Отсюда и зарплаты в конвертах, и "оптимизация" через СПД. Т.е. виновато не только высокое налоговое бремя (хотя это виновник №1), но и несбаллансированная налоговая система (хотя это все-таки только №2).

Второй момент: допустим человек моет окна самостоятельно, но не регистрируется как СПД, а платит обычный налог на доход (15%). Хотя такая ситуация немного противоречит закону, однако, по сути, это те условия, в которых находятся все наемные работники, если вообще не принимать в рассмотрение компании. Т.е. наемные работники тоже проигрывают СПДшникам на эти 15%.

Теперь рассмотрим вопрос пенсий. СПД-шник платит в пенсионный фонд 84 грн. В то же время любой наемный работник платит 33,2% своей зарплаты, что составляет минимум 300 грн. В результате оба будут получать одинаковую социальную пенсию. Но даже, если человек будет иметь сногсшибательную зарплату и платить огромные отчисления в ПФ, никто не гарантирует, что через 30 лет он будет получать какую-то громадную пенсию, как и сейчас не получают большой пенсии советские герои труда, проработавшие по 50 лет на каких-то вредных производствах и т.д. Потому что государство у нас такое, ответсвенное. Зато из этих отчислений будет платиться огромная пенсия сегодня депутатам, секретным агентам и академикам. Это, ясное дело, абсолютно не справедливо и неэффективно. Как эффективнее — ниже.

Итак, существование СПД-формы — это громадная несправедливость по отношению к: 1. компаниям, 2. простым работникам 3. будущим пенсионерам.
С другой стороны, проблема не столько в ней, сколько в гигантском налоговом бремени на компании, точнее собственников (почти 60% начисления на зарплату наемных рабочих + 25% налог на дивиденды, который, фактически, является двойным налогообложением). Это бремя приводит к тому, что блокируется рост зарплат и происходит тенезация экономики. А в пенсионном фонде все равно дырка, которая покрывается из бюджета.

Предложения по решению проблемы исходят из простейших идей:
1. СПД — это самозанятый профессионал, который делает работу самостоятельно.
2. Пенсии должны быть справедливыми (во всех отношениях :)

Соответственно:

1. СПД форма должна существовать и еще более упроститься.
- Во-первых, в области видов деятельности. Зачем искусственно ограничивать людей: есть специалисты широкого профиля, почему не дать им заниматься теми разными занятиями, которые им по душе? Т.е. КВЕД можно оставить только для статистики, но ни в коем случае не делать его ограничением, как сейчас.
- Во-вторых, уплата налога должна быть не такой частой (хотя бы раз в квартал), особенно в связи с п.2
- В-третьих, нужно убрать верхнее ограничение на размер выручки (если специалист мирового класса зарабатывает миллионы, он что, перестает быть предпринимателем?), но в то же время СПД не должен использовать наемный труд. Вообще. Если нужны помощники, пускай тоже оформляются как СПД и работают по подрядному принципу. Если у вас есть сотрудники, то это уже компания. Просто, у нас создание компании является нереально сложным делом.

2. Ставка налога на СПД должна быть приравнена к налогу на доход физлиц. Это, во-первых, справедливо по отношению к наемным работникам, во-вторых, выгодно для государства. Ну и, в-третьих, не вызовет принципиальных возражений у любого предпринимателя, который понимает, что налоги платить надо, но они должны быть подъемными. В то же время это будет справедливо к тем, кто по каким-то причинам не работает на данный момент как предприниматель: нет прибыли — нет налога. Вообще, предприниматель, который временно (от 1 квартала) сидит без работы, также должен иметь право стать на биржу труда, как и обычный уволенный сотрудник и какое-то время получать социальное пособие. О соцопсобии — ниже.

3. Сферу соцфондов можно радикально упростить и, при этом, сохранить существующие пенсии (потерять которые так боятся чиновники). Все трубят о втором уровне пенсионной системы, но никто не пытается доходчиво объяснить, что это такое. На самом деле все должно выглядеть очень просто: должна быть единая, не зависящая от зарплаты, социальная пенсия, которая выплачивается всем нетрудоспособным людям из ПФ, а также социальная помощь по безработице от государственной страховой компании. Обе эти величины должны равняться прожиточному минимуму. Помощь от несчастных случаев тоже должна быть стандартизована и зависить только от категории (тяжести) травмы, а не от зарплаты. Таким образом, имея статистику по количеству работающих, пенсионеров, безработных и несчастных случаев, можно рассчитать необходимую величину единого социального взноса с каждого работающего (не зависимо от того, сотрудника компании, или СПД, или даже рантье) на бюджетный год для выхода на нужные цифры компенсаций для неработающих. (Т.е. для СПД помимо налога на доход добавляется единый социальный взнос, меняющийся из года в год. Такой взнос нужно будет платить раз в месяц или же наперед).

А как быть с пенсией, которая выше социальной и т.п.? Для этого и существует второй уровень пенсионной системы, как и второй уровень страховой системы. Он состоит из добровольных отчислений работающих сверх обязательного социального взноса. Естественно, такие добровольные отчисления могут делаться как в государственный ПФ и СК, так и в негосударственные по выбору страхователя. И они должны быть персонализированны. Впрочем, такие отчисления могут делать за сотрудников и компании (опять же добровольно), и иметь в связи с этим какие-то налоговые льготы и т.п. (это уже вопрос экономических моделей). Также, например, государство может делать такие отчисления для всего госаппарата, чтобы сохранять существующую сейчас систему высоких пенсий чиновникам — это будет его конкурентным преимуществом на рынке труда :)

А как покрывать дефицит ПФ для выплаты текущих обязательств государства сверх социальной пенсии (средства на которую, напомню, собираются через единый социальный взнос): пенсий, которые уже начисленны пенсионерам, которые, разумеется, не могут делать никаких отчислений? На самом деле, также как и сейчас — из госбюджета и это будут очень большие деньги :) Но хорошая новость в том, что с введением такой пенсионной системы обязательства бюджета будут с каждым годом уменьшаться, как и список тех пенсионеров, которые будут получать пенсию старого образца. Остается вопрос, как быть с теми, кому 54, 58, 50? Для них (как и для всех остальных работающих) можно ввести прогрессивную шкалу пенсии, которую уже должно государство: разделить количество роработанных лет на полный стаж до пенсии и получить процент от той пенсии, на которую человек мог рассчитывать по старой системе. Т.е. для человека, которому остался работать год, а он проработал 24, это будет 96%, а для того, кто проработал 2, а еще впереди 32 это будет 4%. Это обязательство государства, как и перед текущими пенсионерами. Остальную сумму можно будет набирать за счет добровольных взносов.

Таким образом, на мой взгляд, пенсионная система станет не только справедливой, но и подъемной для бизнеса (точнее, бизнес вообще будет устранен от субсидирования ПФ), и, в то же время, можно будет сохранить статус кво для современных пенсионеров. А то, что все это будет субсидироваться из бюджета — так, во-первых, оно и сейчас так происходит, а, во-вторых, это, на мой взгляд, оправданная общесоциальная жертва за радикальное улучшение социально-экономической ситуации в стране. И все остальные налоговые проблемы — это, просто, детский лепет по сравнению с этой....

4. Наконец, последнее: нужно радикально упростить создание и, что немаловажно, ликвидацию компаний (ООО). Во-первых, администрирование этих процессов: тут можно очень долго говорить. Во-вторых, снизить ограничение по нижнему размеру уставного фонда (неподъемное для многих бизнесов вначале деятельности). Можно говорить, что есть всякие командитные общества, но это же не полноценная бизнес-форма...

GUI в Common Lisp — еще один миф

2010-03-28T09:45:00.000+03:00

Написано для: habrahabr.ru

Бытует расхожее мнение, что в Common Lisp нет или же плохая поддержка графики. Это еще один миф из серии, что Lisp — это язык только для подсчета факториалов. На самом деле, как и в большинстве других прикладных сфер общего назначения (например, веб, форматы передачи данных, взаимодействие с БД и т.д.) в Lisp-среде есть полный спектр библиотек и тулкитов для всех основных платформ с разными уровнями абстракции.

Linux/Unix

Базовой библиотекой для графики из Common Lisp под Unix является CLX. Это аналог xlib, т.е. низкоуровневый клиент, напрямую общающийся по X-протоколу.

Кроме того, есть обертки для основных графических фреймворков разной степени зрелости: LTK, CL-GTK2, CommonQt, CL-CAIRO2. Лично мне доводилось иметь дело с LTK, и работа с ним тривиальна. Хороший пример приложения, его использующего — простой и удобный Lisp-редактор/REPL ABLE.

Windows

Кроме возможности использовать кросс-платформенные фреймворки из прошлого раздела, есть еще LispWorks CAPI, о котором только положительные отзывы. Единственная особенность заключается в том, что, как и большинство профессиональных сред разработки на любых языках под Windows, LispWorks стоит довольно дорого (ок. 1200 $), а CAPI доступна только в профессиональной версии. (Впрочем, попробовать его можно и в trial версии).

Также есть CL-OPENGL, которая, разумеется, кросс-платформенная.

MacOS X

Дополнительно к Unix-библиотекам для MacOS X есть хорошие Cocoa-биндинги в Clozure CL.

Специфические Lisp-решения

Библиотека McCLIM реализует Lisp Interface Manager спецификацию, определяющую весьма развитый протокол по оперированию с графическими примитивами. Хотя спецификация является платформо-независимой, сама библиотека на данный момент основанна на CLX с вытекающими отсюда последствиями пригодности только для Unix-среды. Если это не есть ограничением, то именно она нужна вам, если вы собираетесь писать что-то, сильно завязанное на графику: игру, графический или CAD-редактор, или же новый ~~Emacs~~Climacs.

Оригинальным подходом к GUI, зародившимся в Lisp-среде является проект Cells, который переносит spreadsheet-парадигму взаимозависимых "ячеек" на графический интерфейс. У него несколько Lisp-реализаций c тем или иным бэкендом: CELLS-GTK, CELLTK, CELLO,— а также есть и порты на другие языки.

Выводы

В общем, варианты есть на любой вкус и запросы. С чего начать? Для простого GUI я бы выбрал LTK или CL-GTK2. Оба они кросс-платформенные. Первый по причине максимальной простоты, даже примитивности. Соответственно, и подходит он для примитивных приложений. Второй — потому что это хорошая обертка для современной объектно-ориентированной графической библиотеки, активно развивающаяся, да еще и с русским автором :)

PS. Еще несколько более специфических графических библиотек, конечно, можно найти на Cliki.

Пару мыслей об SCTest

2010-03-27T12:31:00.002+02:00

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

В этот раз панель была очень показательна, поскольку на ней присутствовали представители 3-х основных категорий участников test'а:
- состоявшийся, как правило, без сторонней помощи (венчурных инвесторов), а благодаря личным качествам и работе, предприниматель. Как раз пример того, у кого есть чему поучиться;
- tru стартапер, т.е. человек, хорошо изучивший стартап-"технологии", как правильно надувать пузырики, что нужно говорить инвесторам и т.п. (Эти качества, по моему мнению, на самом деле независимы от настоящих бизнес-качеств, которые присущи первой категории людей, так что "настоящий стартапер" может как ими обладать, так и не обладать);
- startup kiddie (по аналогии со script kiddie), т.е. молодой человек, увлеченный хайпом стартап-движения, и порой считающий, что сможет в этой игре переиграть "старших товарищей" (упреждиск: если относить меня к какой-то из этих категорий, то разве что к этой).

Интересна реакция на выступление представителя M$ — как раз синдром startup-kiddies, которые всё знают и всё могут. Я не говорю о том, что у большинства из пристуствующих на компьютере стоит ворованная копия той самой Windows (упреждиск: пишу это на Linux). Дело в другом: выступал отличный профессионал, с местами интересным докладом, содержащим много полезной информации (конечно, не без корпоративщины и прямой рекламы, а также самолюбования: оказывается, Vista была провалом, потому что Intel с чипсетами подкачал :) А реакция была не поискать интересное, а поерничать, когда же он будет кричать "Developers, developers...", и поприкалываться, что человек не умеет пользоваться PowerPoint'ом (что в данном случае было банальной глупостью). Элементарной культуры и самоуважения не хватает...

What's on Coders' Minds?

2010-03-15T09:29:00.005+02:00

Recently I've finished reading Coders at Work by Peter Siebel — another excelent book, that has given me a lot of food for though concerning programming. This weekend I've decided to perform a little analytics on it to see common patterns. I've collected statistics on the questions of programming language use, interrelations between them and topics, that might be relevant for the sequeals (there are so many other great programmers out there in the wild :)

1. Programming language preferences

First comes C, that was mentioned by all the coders. Only Peter Norvig didn't speak about it in some detail. It seems, that everyone had at least medium experience programming in it (except maybe for Norvig and Fran Allen), which proves, that the language truly is the Lingua Franca of programming community.

Next in terms of mentions comes C++, Java and Lisp, that were mentioned by more than 12 people.

C++ netted mostly negative or at least neutral reviews. Moreover, it seems, that only a couple of people had any big real-world coding experience in it: others (like Jamie Zawinski) tried to avoid using it at all cost.

On the contrary at least 4 of the people had a substantial hands-on involvement in Lisp programming, but mostly in the past decades. Others mentioned it more as an important alternative or a design influence.

The same amount of coders were really experienced in the Java world. Others just mentioned it as either the recent derivative of the Algol-family, or as a typical example of object-oriented approach, or for its automatic memory-management capability.

Next comes a pack of languages, that are mostly in wide use today, some gradually falling from grace and some getting more traction. These include: Fortran, Assembler, Python, JavaScript, BASIC, Perl and Pascal. All were mentioned by 6 to 10 people. Among them Assembler, BASIC and Pascal are obviously mostly out of use, but were the three most mentioned first languages in someone's carrers. And Fortran has it's distinct role as the default scientific language (and as the first high-level language).

The next group of languages were mentioned rarely, but they were supported by strong advocates. These are Haskell, Smalltalk, and to a lesser extent Scheme and the ML family. Also the same amount of mentions went to the now defunct previously important ones: Tcl, APL, PL/I, BCPL, and COBOL.

Interestingly enough some of the most wide-spread languages of today: PHP, C#, and Ruby,— were mentioned only once or twice and only in passing. The same concerns 3 other more or less important contemporary languages: Objective-C, Scala and Erlang,— that got only a single mention. The reasons for that seem to be different, but one of them can be, that bright representatives of those languages' communities (except for Erlang's creator Armstrong) were not interviewed.

Finally, a host of other languages, not in use today, got mentioned at least twice. They are: Ada, Algol, Eiffel, E, Prolog, Self, Simula, SNOBOL and Teco.

2. Social graph

4 of the coders had some Berkley background, 3 — MIT and 2 — CMU. Among the most important organizations were Google (4 coders work there and 4 other mentioned its practices), Microsoft (1 employee and 7 other having some problem with them), IBM (1 employee, mostly everyone's first computer :), Xerox PARC and Netscape/Mozilla.

Also worth mentioning is that 13 of 15 interviewed programmers were from the USA, 2 from Europe.

3. Recommended books

* SICP (5 mentions)
* The Art of Computer programming (obviously) (5 mentions)
* Design Patterns (3), although all spoke of it as at least controversial
* The psychological books: "The Mythical Man-Month" and "Psychology of Computer Programming", each brought up both by Steele and Bloch (2 mentions)

And once were recommended these books:
* Beautiful Code: Leading Programmers Explain How They Think, Andy Oram, Greg Wilson (eds.) (O’Reilly, 2007)
* Code Complete, Steve McConnell (Microsoft Press, 1993)
* Compiling with Continuations, Andrew W. Appel (Cambridge University Press, 1992)
* The Design and Analysis of Computer Algorithms, Alfred V. Aho, John E. Hopcroft, and Jeffrey D. Ullman (Addison-Wesley, 1974)
* The Elements of Programming Style, Brian Kernighan and P.J. Plauger (Computing McGraw-Hill, 1978)
* Elements of Style, William Strunk and E.B. White (Longman, 1999)
* Hacker’s Delight, Hank Warren (Addison-Wesley, 2002)
* Higher-Order Perl, Mark Jason Dominus (Morgan Kaufmann, 2005)
* Java Concurrency in Practice, Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea (Addison-Wesley, 2006)
* Java Puzzlers: Traps, Pitfalls, and Corner Cases, Joshua Bloch and Neil Gafter (Addison-Wesley, 2005)
* Programming Pearls, Jon Bentley (ACM Press, 1999)
* Purely Functional Data Structures, Chris Okasaki (Cambridge University Press, 2008)
* Zen and the Art of Motorcycle Maintenance: An Inquiry into Values, Robert Pirsig (Bantam, 1984)

The only unexpected omission seem to be "Goedel, Escher, Bach: an Eternal Golden Braid", which is the favorite programming book of many.

4. Other things

The tools in use include Emacs (most mentioned) and GDB. Others were: Java IDEs (Eclipse, NetBeans and IntelliJ), profilers, and correctness checkers, like JSLint, Valgrind and QuickCheck.

There were also a few topics, brought up by many of the coders, apart from the ones, explicitly triggered by the interview questions. Those are API and GUI design (often in connection with the ugliness of WinAPI), transactional memory (and other ways of tackling the massively multicore world), and means of inter-process communication and data-interchange. This may be a suggestion for questions of the future interviews.

Some of the coders came to programming through games or programmed some. 2 times were mentioned Pac-Man and the Game of Life. Also variants of tic-tac-toe, tetris, and Adventure were named. Still game programming is one of the most important parts of the programming industry and no prominent person from it was present (although John Carmack was planned).

5. Conclusions (who to interview next?)

The next candidates can be derived from the mentions' graph, but this can lead to confinement inside of the subset of all programming communities due to the cluster nature of "schools" of influence. So it's also worth considering the missing languages and georgaphical diversity.

So, among the important pears of our coders were:
* Richard Stallman, founder of the FSF and GNU (3 mentions)
* Guido van Rossum, creator of Python (3)
* Bjarne Stroustrup, creator of C++ (3)
* Danny Bobrow, a prominent lisper (3)
* Larry Wall, creator of Perl (2)
* Adele Goldberg, who was at the root of object-oriented movement (2)
* Bill Gosper, another prominent lisper (2)

Also were mentioned the famous computer scientists: Edsger Dijkstra, Tony Hoare and Noahm Chomsky.

It can be seen, that the mentioned persons were mostly programming language designers. But this book showed, that it is equally important to present the opinion of language users, because in many areas it can diverge. In search of such people we can direct ourselves to the "missing languages" side. And the first one of those is actually C++ for its wide spread is not reflected by the interviewed, who were important representatives of that school of thought. Apart from language's creator Stroustrup, 2 people come to mind: John Carmack of idSoftware fame and Raymond Chen from Microsoft. The Ruby camp has another interesting feature: it's main proponents are very loudly heard in the programming world. David Hanson, Dave Thomas, Reginald Braithwhite, Tim Bray and Chris Wanstrath (Github) all have influential blogs. The other one famous Ruby programmer, whom it could be really interesting to interview, is Why the Poignant Stiff. It would also be interesting to hear the voice of those "unknown" heroes of the PHP and C# world, because it can resonate with lots and lots of programmers in the world. From other (well represented in the previous book) communities the prominent figures are Ian Bicking (Python), Edi Weitz (Lisp), Ward Cunningham (Java) and Luke Gorrie (Erlang, Smalltalk, Lisp).

This book also featured a number of interviews with computer scientists: Knuth and Allen, as well as Norvig, Steele and Peyton Jones (although those three are more on the practical side). Among their pears in the CS world, obviously, the most mentioned were Abelson and Sussman. Next come Danny Bobrow, Aho and Ulman (among the living).

Talking about geographical diversity, Edi Weitz and Luke Gorrie represent Europe. Other interesting European coders are the creators of PHP Rasmus Lerdorf, Prolog Alain Colmerauer and OCaml Xavier Leroy. And in every programming community there can easily be named prominent European hackers (like Ola Bini from JRuby team). It is also worth "visiting" Japan, the former USSR (that had it's own tradition in CS and software), and, possibly, India and China. From Russia such people as: Eugene Roshal (creator of the Rar compression format), Stepan Pachikov (founder of Evernote), and Viktor Shchepin (author of ejabberd Erlang-based jabber server),— can be named.

Finally, the last diversity question, that was raised by Peter Siebel himself, is women participation. The first woman candidate, that can be derived from the analysis, is Adele Goldberg. One other woman, that comes to mind, is Allison Randal, working on the Parrot virtual machine and Perl 6 programming language.

(Actually most of the mentioned names were in the list of possibil candidates for the first book).

О страшных монадах

2009-11-07T23:41:00.005+02:00

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

Как верно было подмечено, монады — это очень просто. А еще монады — везде. Почему же тогда у многих с ними проблемы?

1. Терминология
Где-то написано, что использование нетипичной для предметной области терминологии — это аттрибут троллинга (к сожалению, не удалось найти ссылку). Можно возразить: "да ведь монады — это же математический термин". Да, но математика и инженерия (в частности, программирование) — разные дисциплины. Математики не строят мосты, да. А термин монада не относится к предметной области программирования. В ней есть такое понятие как "вычисление" (computation). (Пусть меня осудят, но) фактически, монада в Haskell — это стратегия вычисления.

Почему же тогда говорят "поместить/извлечь значение в/из монаду/ы"? Говорят так для простоты. На самом деле, можно лишь запустить определенное вычисление с определенным входным значением (отсюда и идиома run...). Слишком похоже на "запустить процедуру", не так ли?

Так что с термином "монада" либо создатели Haskell были недостаточно дальновидны, либо, просто, хотели эпатировать программистский мир.

2. Подход к изучению
К сожалению, большинство объяснений монад так или иначе отталкиваются от того, что монада — это всего навсего тип и 2 простые функции. Но проблема в том, что от того, что вы поймете, как работают функции return и bind, вам не станет сразу ясно, зачем они нужны вместе. Отталкиваться в понимании того, что такое ~~монады~~ стратегии вычисления, нужно от того, зачем они нужны? Сейчас я сделал именно так, и все легко стало на свои места.

Какие бывают стратегии вычисления? Я сейчас не буду называть самую важную из них, а напишу о ней в следующей записи — пока предлагаю прийти к ответу самостоятельно. Могут быть: вычисление, которое завершается неудачно, если неудачно завершается хотя бы одно из внутренних подвычислений — это знаменитая монада Maybe, которую мы сейчас рассмотрим. Может быть вычисление, которое использует какое-то доступное для всех подвычислений "хранилище" данных — State. Есть вычисление, которое связанно с обменом данными с внешней средой — IO и т.д.

Бытует мнение, что Haskell — ленивый язык (более того, это официальная позиция). На самом деле, все немного сложнее или проще, зависит от того, как посмотреть. Во-первых, всем понятно, что абсолютно (или, как говорится, чисто) ленивого языка быть не может, поскольку в таком случае мы никогда не получим какого-то результата работы программы. Каким образом Haskell'исты выходят из этого затруднения? Принято говорить, что, в целом, язык ленивый, а вся неленивость/энергичность (eagerness) находится (так и хочется сказать, заточЕна) внутри монад. Но дело в том, что любая Haskell-программа находится внутри монады IO. В итоге оказывается, что ленивыми в Haskell являются только чистые функции, а все вычисления (в понимании программистском), которых, на самом деле, большая часть — все равно остаются энергичными. В то же время любая чистая Haskell-функция, учитывая pattern matching и немутируемые переменные, по большому счету представляют из себя одну case-конструкцию и вызов других функций. Красиво? Часто, да. Однобоко? Тоже. ОК, но самое интересное дальше.

И в других языках примерно то же самое! По сути, разница только в том, что:
(а) не проведена четкая граница между ленивыми вычислениями и энергичными. Впрочем, каждый может для себя ее проводить сам: например, можно думать о ленивых вычислениях как об аттрибутах "математических" функций (и таким образом их и программировать), а об энергичных — как о процедурах. В любом языке может быть реализована ленивая стратегия вычислений, однако не везде это сделать одинаково легко...
(б) программист самостоятельно может строить процесс вычисления адекватный конкретной задаче. По сути, построение вычислительных процессов и есть одно из главных составляющих собственно того, что мы понимаем под программированием

Можно выдвинуть предположение, что все разные виды вычислений можно свести к ~~нескольким десяткам~~ определенному количеству монад. И, изучив их, можно будет составлять вычисления, как кубики в конструкторе. (И это предположение действительно выдвигается). В таком случае монады и вправду становились бы решающим методом абстракции в программировании. Впрочем, оказывается, что даже сведя вычисления к монадам, составлять их также легко, как кубики, не удается, и приходится прибегнуть к помощи еще одних монад — монадных преобразователей (monad transformers). В итоге, монада на монаде сидит и монадой погоняет... :) (Можно было догадаться исходя из принципа вычислительной эквивалентности. Вообще говоря, приняв во внимание этот принцип, можно понять, что максима "there is no silver bullet" таки справедлива всегда).
И еще одно: вывод про сведение всех вычислений к определенному набору не нов. Он лежит в основе структурного программирования, где доказано, что все вычисления можно свести к комбинации последовательного выполнения, условного выражения и цикла.

Вот тут то разница между Haskell'ем и другими языками становится наиболее существенной: другие языки имеют синтаксическую поддержку определенного узкого набора монад, и дают возможность создавать другие монады ad hoc с использованием того или иного механизма. Haskell, по сути, делает то же самое, только создание новых монад регуляризирует и вгоняет в определенные рамки. Итак Haskell — это язык, в котором дисциплина на первом месте.

В общем, концепция монад очень полезна, чтобы понять, что могут быть совершенно любые стратегии вычислений и не стоит считать, что возможны только те, которые определенный язык считает родными (вот, в С не было стратегии вычисления Exception, а в С++ появилась :)

Возвращаясь к Maybe. Его все понимают, так ведь? Это нужно для того, чтобы если где-то в последовательности вычислений у нас получился элемент Null (Nothing), это значение в итоге вернулось в качестве результата, и при этом другие части вычисления не имели проблем с обработкой такого значения.

Этот шаблон хорошо знаком всем, кому доводилось встречаться с логическими операторами с коротким замыканием. Идеально он работает в Common Lisp, где значение nil также является логической ложью (это, кстати, считается многими одним из кардинальных преимуществ Common Lisp над Scheme, в котором эти 2 значения разделены). Ниже приводится пример реализации Maybe на CL, аналогичный примеру из пособия по монадам:


(defmacro maybecall (val &rest funs)
  "Consequently apply a sequence of FUNctionS to the
return value of the previous computation, starting with VAL"
  `(and-it ,val
           ,@(mapcar (lambda (fun)
                       `(funcall ,fun it))
                     funs)))

;; где:
(defmacro and-it (&rest args)
  "Like AND, but IT is bound to the value of the previous computation"
  (cond ((null args) t)
        ((null (tail args)) (first args))
        (t `(let ((it ,(first args)))
              (when it
                (and-it ,@(tail args)))))))

;; работает?

(defun mother (x)
  (gethash x *mothers*))

(defun father (x)
  (gethash x *fathers*))

(setf (gethash :b *fathers*) :e
      (gethash :a *fathers*) :d
      (gethash :b *mothers*) :c
      (gethash :a *mothers*) :b)

(maybecall :a #'mother #'father) => :e
(maybecall :a #'mother #'father #'father #'brother) => nil
;; и даже на brother не ругается, потому что до него дело не доходит

Впрочем, я понял, что обычный AND (или AND-IT) в CL — это и есть полноценная реализация Maybe стратегии. Притом простая и понятная, нет?

3. Нужны ли монады за пределами Haskell'я?
То, что в других языках представляет из себя единую ткань вычислений, в рамках Haskell разделено на 2 класса: чистые (обычные функции) и "грязные" (монады). Это приводит к разделению (дублированию) синтаксиса и усложнению программного кода (полная противоположность дуалистического подхода). В то же время, это делает рассуждения о программах более структурированными и помогает (однако не гарантирует!) соблюдению принципа ссылочной целостности. В теории концепция монад полезна для понимания того, что такое вычисления. На практике же введение дополнительных правил приводит к тому, что появляется определенный предел выразительности языка и близости его к предметной области. Именно так, несмотря на заявления программистов на Haskell об обратном: концепция монады, монадного трансформера и т.д. неимоверно далеки от любой предметной области, которая встречается при программировании, а абстрагировать их средствами Haskell не удастся. Более того, само понятие вычисления, которое в других языках остается имплицитным, в Haskell'е достается на поверхность. Именно с этим, по-моему, связанны частые претензии к преувеличенной сложности Haskell программ.

---

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

Еще по теме:
* All About Monads
* Why monads have not taken the Common Lisp world by storm

О Haskell

2009-11-02T21:25:00.008+02:00

Обновление: обсуждение на habrahabr.ru Изучай Haskell ради... Haskell'а

Я долго (несколько лет) не решался составить окончательное мнение о Haskell'e: слишком противоречивы были мысли. И вот, наконец, благодаря этой записи о разборе программки определения двудольности графа я могу это сделать :)

Я понял, что Haskell-программисты — в основном, нужно сказать, хобби-программисты — это те, кто программирует не решение задачи, алгоритм, систему, а Haskell! [1] Посмотрите, какой простой алгоритм описан в заметке, а сколько вокруг него нагромождено языковых конструкций, объяснений и дискуссий. Чтоб доказать, что он очень простой, привожу пример кода на Lisp'е, который решает ту же задачу без никаких монадных трансформеров и т.п. (не обращайте внимание на большой docstring):

(defun test-bipartite (graph)
"Test for bipartiteness a GRAPH, that is given as a list of pairs
vertix - list of immediately connected vertices, like:

'((0 . (1))     (1 . (0 2 8))
(2 . (1 3))   (3 . (2 6))
(4 . (5 7))   (5 . (4))
(6 . (3))     (7 . (4 8))
(8 . (1 7)))
-- bipartite one

'((0 . (1 2))   (1 . (0 2 8))
(2 . (1 3))   (3 . (2 6))
(4 . (5 7))   (5 . (4))
(6 . (3))     (7 . (4 8))
(8 . (1 7)))
-- not bipartite one

'((0 . (1 2))   (1 . (0 2 8))
(2 . (1 3))   (3 . (2 6))
(4 . (5 7))   (5 . (4))
(6 . (3))     (7 . (4 8))
(8 . (1 7))   (9 . ()))
-- not connected one"

(let ((map (make-hash-table))
     (visited '()))

 (labels ((con1 (v)
            "vertices immediately connected to V"
            (tail (assoc v graph)))

          (paint (v level)
            "paint the graph from vertix V, return all
           visited so far (in subsequent calls of PAINT) vertices"
            (pushnew v visited)
            (setf (gethash v map) level)
            (mapc (lambda (v) (paint v (1+ level)))
                  (remove-if (lambda (v) (member v visited))
                             (con1 v)))
            visited))

   ;; first we paint and check, that all vertices are visited
   (unless (set-exclusive-or (paint 1 0)
                             (mapcar #'first graph))
     (every (lambda (entry)
              (every (lambda (v)
                       (oddp (+ (gethash (first entry) map)
                                (gethash v map))))
                     (tail entry)))
            graph)))))

Мне хорошо знакомо это умонастроение — когда в погоне за максимальным использованием мощи языка забываешь о самой задаче,— поскольку в Lisp-мире оно тоже часто встречается: есть языки, которые способны действительно увлечь. И выражение "это взорвало мне мозг" часто звучат и по поводу Lisp'а, и по поводу Haskell'а. Но это же — фигня! Конечно, не может не радовать узнать что-то новое, но не нужно же радоваться этому, как ребенок новой игрушке. Хороший язык программирования должен быть максимально понятен и прост, должен давать человеку свободу самовыражения. Честно говоря, именно этому я обрадовался, когда открыл для себя Lisp: что нашел то, что искал. А не тому, что увидел какую-то конструкцию или изворот, который не доводилось встречать раньше.

Так что же, вывод: всем программировать на Lisp? Я, конечно, за, но вывод тут другой: Haskell — очень интересный язык, у которого есть как плюсы, так и минусы. Плюсы: это интересная семантика и сильная теоретическая база, хорошая скорость выполнения современных компиляторов. Минусы: ужасно нерегулярный синтаксис [2], искусственная ограниченность, которая приводит к необходимости задействовать сложные подоходы там, где отлично справятся и простые. И им просто обязательно стоит заниматься, если вас интересует тема языков программирования как таковых, их развития и исследований. Из Haskell берут многое другие более практичные языки: яркий пример тому Clojure. Но он не для написания больших систем и даже не для исследования алгоритмов в общем случае. У языков программирования кроме синтаксиса и семантики есть еще третий аспект, пожалуй даже важнейший, о котором часто забывают — прагматика. То, как язык используется, для чего он предназначается, чем живет сообщество его разработчиков и пользователей. Прагматика Haskell'а заключается в том, что он существует прежде всго для исследования... Haskell'а.

[1] Есть, конечно, исключительные, прекраснейшие Haskell-программисты, написавшие на нем много полезного кода для реального мира, но это, как говорится в нелюбимом мной афоризме, только подтверждает правило.

[2] Для современного языка нерегулярный синтаксис — это неуважение к своим пользователям. Ведь никто в современном мультиязыковом мире не программирует на одном языке, поэтому нельзя требовать от человека держать в голове идиосинкразии каждого. И этих общеупотребимых языков будет все больше и больше, а количество legacy кода уменьшаться не будет. Я сейчас имею дело с Lisp, Python, Php, C, JavaScript, Shell, Java. И это ведь не самый яркий пример.

Очередная встреча по Lisp

2009-08-03T14:40:00.002+03:00

Первая встреча по Lisp'у, я считаю, удалась.
Попробуем еще раз: http://www.developers.org.ua/calendar/event/f2hv5cnvjg2uj3qqtk43r2fv7s/.
Тема: кодогенерация.

О микроплатежах

2009-06-12T14:22:00.001+03:00

Написано для: Лига.Блоги

В своем предыдущем комментарии я затронул тему того, что до сих пор ни в Украине, ни в мире не появился удобный и получивший широкое распространение сервис микроплатежей. Вообще, под микроплатежами можно понимать разные вещи. Я имею в виду платежи, которые незначительны настолько, что человеку проще перелатить даже до 10-20% от их суммы, зато произвести их быстро и без лишних забот. Понятно, что для каждого это разные суммы, но в среднем это платежи, комиссия по которым не превышает пары десятков гривен (для нашей страны в данное время). В общем, современная экономика говорит, что главная проблема — это транзакционные издержки и их нужно стараться минимизировать. Эти издержки складываются из финансовых, временных, а также усилий и рисков. Микроплатежи находятся в той части спектра экономической активности, где увеличение финансовых издержек наименее нежелательное из перечисленных пунктов.

Еще раз, зачем нужны микроплатежи?

* Для оплаты товара в Интернет-магазинах. Иногда да, хотя в данном случае, поскольку имеет место акт передачи товара из рук в руки, можно применять оплату наличными (как, собственно, у нас в основном и делаеют). К сожалению, как в анекдоте, что заказывать товары при коммунизме можно будет по телефону, а получать по телевизору — у нас пока не получается. Микроплатежи отлично могли бы применяться при доставке товаров по почте, но таких товаров у нас, традиционно, не много.
* Для переводов небольших сумм между людьми. Однозначно, это намного проще, чем банковские или мгновенные переводы. И они в этой сфере уже применяются, но пока по-серому.
* Для оплаты различных услуг: коммунальных, виртуальных и некоторых реальных. Это основное применение для микроплатежей. На самом деле, как раз отсутствие такой полноценной возможности тормозит развитие очень большого числа мелких услуг (в первую очередь виртуальных).

На мой взгляд, единственный путь появления полноценных микроплатежей — через операторов мобильной связи. По сути дела, сейчас они предоставляют такую возможность, но только в ограниченной форме: пополнение счета другого человка (*125*...) И этой возможностью некоторые уже сейчас пользуются даже для организации оплаты мелих услуг. Это типичные мироплатежи, в которых комиссия составляет до 25% (и не смотря на такой высокий процент, люди пользуеются этой услугой).
В чем ограниченность? Главное, нельзя использовать переведенные деньги для оплаты чего-то иного, кроме услуг самого оператора и его афиллированных компаний, нельзя, что называется, "вывести деньги из системы". Второй, менее значительный недостаток: сейчас суммы платежей должны быть кратны 10 (а ведь нет никаких проблем снизить кратность до 1).

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

Так почему же этого не делается? Загвоздки:

* Юридические. При этом оператор становится банком? Не совсем. Всего лишь расчетной системой. Скорее всего подобная деятельность требует лицензирования и согласования. Однако операторам и так приходится заниматься подобными вещами постоянно. Использование системы для ухода от налогов? Во-первых, не больше, чем при расчете наличными :) Во-вторых, есть пути мимимизации этого: например, обязательная регистрация для мерчантов (тех, кто хочет использовать систему для получения оплаты за товары или услуги). А так ведь, всё прозрачно — наоборот удобно для налоговой.
* Издержки при вводе денег в систему: условно говоря, человек покупает карточку предоплаты на 30 гривен, выпуск и распространение которой стоит 1 грн. Эта гривна — это 3%, которые не сможет компенсировать комиссия за вывод денег из системы (которая тут должна быть не больше тех же 2-3%). Но ее можно компенсировать введя комиссию на каждый платеж: ту же гривну или даже 50 копеек.
* Мошенничество. Для микроплатежей этот вопрос стоит на последнем месте. Ведь никого не смущают возможности мошенничества при пополнении чужого мобильного счета: такая функция намного полезнее, так ведь?
* Организационные. Безусловно, построение подобной системы — это серьезный проект. Однако, он менее серьезен, чем построение самой сети оператора, с чем они успешно справляется.

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

А в перспективе подобная система может стать вообще глобальной и составить конкуренцию таким фирмам как Visa и MasterCard.

k-nucleotide benchmark

2009-06-02T00:51:00.002+03:00

Read the discussion on k-nucleotide benchmark in debian shootout (http://groups.google.com/group/comp.lang.lisp/msg/d50c86053c9000b7) and decided to play with it a little: to use as hash-table keys numbers in base 4 instead of gene strings. That gave a speed gain of around 30%: http://shootout.alioth.debian.org/u32q/benchmark.php?test=knucleotide&lang=sbcl&id=3.
But still 12 times slower, than the C++ variant. Perhaps native strings (instead of full unicode) would have given 2-2.5 times additional speedup. But what else can be improved?

k-nucleotide бенчмарка

2009-06-02T00:40:00.006+03:00

Почитал дискуссию о k-nucleotide бенчмарке в debian shootout'е (в c.l.l.) и решил немного с ней поиграться: вместо строк генов в качестве ключей хеш-таблицы использовать соответствующие числа в базе 4. В результате удалось улучшить время выполнения примерно на 30%: http://shootout.alioth.debian.org/u32q/benchmark.php?test=knucleotide&lang=sbcl&id=3.
Но все равно медленнее С++ аналога в 12 раз. Допустим, если отнять unicode-строки, то получится ускорение еще в 2-2,5 раза. А что еще можно улучшить?

Идеи по поводу tedxkyiv

2009-05-27T14:04:00.001+03:00

@tagline
У оригинального TED обычно есть какие-то большие темы (по 3-4 на конференцию), например: "зеленое будущее", "переосмысление бедности", "сознание" и т.д. Наверно, было бы неплохо, чтобы и у TEDx тоже была какая-то объединяющая тема. И посколько в последнее время Украина как-то не дает таланты, являющиеся глобальными лидерами мысли (у нас сейчас хорошо получаются только футболисты и боксеры), то и тему можно выбрать только локальую, украинскую. Мне сразу приходит на ум "Как нам модернизировать Украину?"

@speakers
Ну и, в соотвествии с темой должны подбираться докладчики. Я так понимаю, что формула TED: известная личность + видение. В этом плане у нас тоже не густо: во всяком случае трудно выделить среди известных политиков, бизнесменов, ученых или гиков тех, у кого действительно есть видение, которое бы было шире их личных интересов и касалось хотя бы всей Украины, не говоря уже о мире в целом.

Единственный хороший пример, который мне приходит на ум -- это Татьяна Монтян. Она известный человек с вполне конкретными достижениями (была адвокатом в нескольких резонансных делах, создала блог "Инфопорн", признанный лучшим коллективным блогом Украины на BlogCampCEE'08), и у нее есть видение: от коррупции нас спасет введение всеобщих открытых реестров недвижимого имущества и переход к титульной системе учета прав на него.

Другие известные люди, теоретически могущие иметь видение, которые приходят на ум:
* Вячеслав Брюховецкий, бывший ректор Киево-могилянской академии
* Михаил Згуровский, ректор КПИ
* Михайло Свистович (создатель сайта maidan.org.ua и один из инициаторов Гражданской кампании "Пора") и его жена Мирослава, бывшая мером Ирпеня
* из бизнесменов можно упомянуть разве что Романа Хмиля, директора компании "GlobalLogic"

Наверное, есть смысл устроить брейншторм на тему докладчиков, потому что кандидатур (во всяком случае, на первый взгляд) совсем не много.

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

Встреча по Lisp'у

2009-05-25T17:45:00.001+03:00

Устраиваю в эту пятницу встречу пользователей Lisp в Киеве.
Подробности: http://www.developers.org.ua/calendar/event/531khsfol4dujub66mkc4cet74/

Мыслекарты для планирования трат

2009-05-25T12:42:00.002+03:00

Написано для: habrahabr.ru

Инструмент Mind Map довольно нов: настолько, что у него нет даже устоявшегося русского названия. Обычно его называют интеллект-картами, картами памяти, сознания или мозга, и даже ментальными картами. Как по мне, довольно громоздкие и не удобные имена, в которых, что самое главное, не четко передается суть понятия (мне в них слышатся какие-то анатомические оттенки: вот тут левое полушарие, тут правое, а тут мозжечок… :) А ведь это, если максимально упростить, картинки, изображащие понятия и логические связи между ними. Можно было бы сказать карты понятий, но тоже звучит громоздко, а вот карты мыслей — проще. Ну и, следуя по традиции словообразования в русском языке: мыслекарты![1]

Мыслекарты помогают лучше осознать какие-то сложные и/или состоящие из многих компонентов системы за счет подключения визуального канала восприятия и, соответственно, образного мышления. Говорят, что в среднем человек может удерживать в оперативной памяти лишь 7 отдельных объектов. Но это в том случае, если эти объекты слабо связаны в сознании друг с другом. А вот, если добавить ассоциации, то потенциальные возможности работы с ними в уме и запоминания неимоверно расширяются. В книге "Основы практики на пианино" утверждается, что именно на этом построены методы людей, практикующих фотографическую память...

Но я отвлекся. При чем мыслекарты к личным финансам? Не считая, конечно, того, что оба эти явления как-то касаются темы личного развития :), связь нам подсказал один из пользователей нашего сервиса по учету финансов[2]. А что если применить эти карты к планированию трат на ближайшее будущее? Например, можно задумать траты, которые могут потенциально выйти за рамки семейного бюджета, но чтобы это понять, нужно посидеть с карандашом и блокнотом и прикинуть свои будущие расходы и доходы, добавить ингридиенты сбережений и незапланированных трат, и щепотку везения, а на выходе получить прогноз, удастся ли осуществить запланированное. В общем-то, в этом может неплохо помочь учетная система: ведь в ней есть уже почти вся нужная информация. Другой вопрос, что ее нужно показать так, чтобы человек не утонул в этом океане цифр. Вот тут на помощь и приходит наглядность и простота мыслекарт. Но, как говорится, «лучше один раз увидеть, чем сто раз услышать», поэтому попробую показать, что имеется в виду.

Вот так выглядел оригинальный набросок, присланный мне:

А вот такой вышла наша первая реализация:

Попробую кратко описать ее работу. Сейчас можно планировать во временных горизонтах месяца, квартала и года. Для пользователя за предыдущий период, заканчивающийся сегодняшним днем, подсчитываются его траты и доходы. Эти суммы и есть прогноз на период планирования. На основании этого прогноза, а также баланса на текущий момент считается прогноз баланса в конце срока, а разница между планируемым доходом и тратами — это накопленный/потраченный остаток конкретно за период. Поскольку наши карты служат прежде всего для планирования трат[3], то траты разбиваются по нескольким самым большим категорям. Человек может прикинуть, по каким из них что-то изменится (например, можно сэкономить) и внести эти изменения прямо на карту. Какие-то категории можно вообще убрать. (Кроме того, можно перейти по ссылке и посмотреть на все траты по каждой категории). Естественно, все изменения мгновенно отражаются на суммах расхода, остатка и баланса. Также можно поменять и ожидаемый доход. Человек может добавить на карту свои планы и сразу увидеть, насколько остатка денег за период хватит, чтобы покрыть каждый из них в отдельности, а также их общую сумму. Наконец, определившись с какими-то из планов, их можно «добавить в корзину» (подтвердить). И только тогда они внесут свою лепту в сумму расходов за период. Собственно, это пока и все.

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

Что касается технической стороны, то это тема для статьи в другом блоге. Замечу лишь, что карта полностью реализована на языке Javascript, подручным материалом выступала незаменимая библиотека jQuery (беру свои слова назад: это не костыль :). Конечно, большим недостатком использования исключительно DOM является отсутствие возможности изображать произвольные объекты: наверно, еще пару лет придется пользоваться различными хаками, пока не станет повсеместно распространенным тег CANVAS. В данном случае, например, вместо рисования линий показываются масштабируемые готовые картинки. Это позволяет добиться сравнительно небольшой нагрузки на браузер, однако иногда приводит к мини подвисаниям (в момент переключения между картинками).

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

[0] Сообщество LiveJournal по теме мыслекарт
[1] А еще, выражаясь научным языком, наверно, их можно отнести к семантическим сетям
[2] Приятно, что в этом отношении сбывается то, о чем я написал в анонсе fin-ack.com: многие интересные идеи приходят от пользователей
[3] Впрочем, ничто не мешает использовать их для планирования доходов или еще чего-то

42

2009-04-11T17:42:00.004+03:00

Кстати, об основополагающем вопросе... Это число, наверно, следующее по количеству упоминаний после фразы "Hello world" и foo-bar-baz в различных тюториалах по программированию. Когда-то я перевел отрывок из книги, в котором рассказывается о его истории, на русский. Вот от.
В целом, Дугласа Адамса, наверно, стоит почитать каждому -- в нем столько злободневного и в то же время вечного...

correcting Transfer-encoding:chunked problem in nginx

2009-04-05T21:20:00.004+03:00

While Igor Sysoev is thinking on how to properly (i.e. robustly and efficiently) implement handling of Content-encoding:chunked with unset Content-Length in nginx, I needed to hack a quick workaround (for those, who need it "here and now"). I decided to post it here for those who may need it:


--- old/ngx_http_request.c 2009-04-05 20:41:18.000000000 +0300
+++ new/ngx_http_request.c 2009-04-05 20:38:33.000000000 +0300
@@ -1403,16 +1403,6 @@
         return NGX_ERROR;
     }
 
-    if (r->headers_in.transfer_encoding
-        && ngx_strcasestrn(r->headers_in.transfer_encoding->value.data,
-                           "chunked", 7 - 1))
-    {
-        ngx_log_error(NGX_LOG_INFO, r->connection->log, 0,
-                      "client sent \"Transfer-Encoding: chunked\" header");
-        ngx_http_finalize_request(r, NGX_HTTP_LENGTH_REQUIRED);
-        return NGX_ERROR;
-    }
-
     if (r->headers_in.connection_type == NGX_HTTP_CONNECTION_KEEP_ALIVE) {
         if (r->headers_in.keep_alive) {
             r->headers_in.keep_alive_n =


--- old/ngx_http_request_body.c 2009-04-05 20:41:39.000000000 +0300
+++ new/ngx_http_request_body.c 2009-04-05 20:34:45.000000000 +0300
@@ -54,11 +54,6 @@
 
     r->request_body = rb;
 
-    if (r->headers_in.content_length_n < 0) {
-        post_handler(r);
-        return NGX_OK;
-    }
-
     clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
 
     if (r->headers_in.content_length_n == 0) {
@@ -180,7 +175,8 @@
 
     } else {
         b = NULL;
-        rb->rest = r->headers_in.content_length_n;
+        rb->rest = r->headers_in.content_length_n >= 0 ? r->headers_in.content_length_n
+                                                       : NGX_MAX_SIZE_T_VALUE;
         next = &rb->bufs;
     }

In the mean time I've sorted out for myself the server's internals. What can I say? First of all the event-driven architecture is complicated. Especially, when there's no high-level description, who is calling what. And especially under virtually complete absence of comments in the code.

And about C and Lisp (based on examining the source of the two HTTP-servers: nginx and Hunchentoot). Lisp is clay, shape whatever you want with all the connected advantages and shortcomings. C... There's a children's construction set from metal bars and corners. It's fun to play with them. And, generally, everything is quite clear, it's possible to assemble good, solid constructions. But making a vase with rounded corners — it's for the geeks...

исправляем проблему с Transfer-encoding:chunked в nginx

2009-04-05T20:53:00.005+03:00

Пока Игорь Сысоев думает над тем, как правильно (т.е. надежно и быстродейственно) реализовать обработку Content-encoding:chunked при не заданной Content-Length в nginx, мне пришлось сделать workaround (для тех, кому это нужно "здесь и сейчас"). Решил его выложить, может, кому-то кроме меня это тоже будет нужно:


--- old/ngx_http_request.c 2009-04-05 20:41:18.000000000 +0300
+++ new/ngx_http_request.c 2009-04-05 20:38:33.000000000 +0300
@@ -1403,16 +1403,6 @@
         return NGX_ERROR;
     }
 
-    if (r->headers_in.transfer_encoding
-        && ngx_strcasestrn(r->headers_in.transfer_encoding->value.data,
-                           "chunked", 7 - 1))
-    {
-        ngx_log_error(NGX_LOG_INFO, r->connection->log, 0,
-                      "client sent \"Transfer-Encoding: chunked\" header");
-        ngx_http_finalize_request(r, NGX_HTTP_LENGTH_REQUIRED);
-        return NGX_ERROR;
-    }
-
     if (r->headers_in.connection_type == NGX_HTTP_CONNECTION_KEEP_ALIVE) {
         if (r->headers_in.keep_alive) {
             r->headers_in.keep_alive_n =


--- old/ngx_http_request_body.c 2009-04-05 20:41:39.000000000 +0300
+++ new/ngx_http_request_body.c 2009-04-05 20:34:45.000000000 +0300
@@ -54,11 +54,6 @@
 
     r->request_body = rb;
 
-    if (r->headers_in.content_length_n < 0) {
-        post_handler(r);
-        return NGX_OK;
-    }
-
     clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);
 
     if (r->headers_in.content_length_n == 0) {
@@ -180,7 +175,8 @@
 
     } else {
         b = NULL;
-        rb->rest = r->headers_in.content_length_n;
+        rb->rest = r->headers_in.content_length_n >= 0 ? r->headers_in.content_length_n
+                                                       : NGX_MAX_SIZE_T_VALUE;
         next = &rb->bufs;
     }

Мимоходом, разобрался немного во внутренностях этого сервера. Что можно сказать? Во-первых, event-driven архитектура — это сложно. Особенно, когда нет общего описания, кто кого вызывает. И особенно при почти полном отсутствии комментариев в коде.

Ну и про С и Lisp (по итогам копания в коде двух HTTP-серверов: nginx и Hunchentoot). Lisp — это глина, лепи себе, что заблагорассудится, со всеми вытекающими плюсами и минусами. C... Есть такие конструторы из металлических планок и уголков. Интересно с ними играться. И, в общем-то, довольно понятно все, можно собрать хорошие, надежные конструкции. Но вот сделать из этого какую-нибудь вазу с закругленными углами — это для фанатов...

CL-WHO macros

2009-03-23T15:32:00.006+02:00

CL-WHO is a library, that performs HTML generation from s-expressions (which I'll call pseudo-html forms). As for now it has one major shortcoming due to the way the input is processed by the WITH-HTML-OUTPUT macro: it doesn't support using macros, that expand to pseudo-html forms. (And the reason for it is that the input is first subjected to rule-based transformations to allow intermixing pseudo-html and lisp forms).

Let's look at the simple example...

First we just process plain pseudo-html:

CL-USER> (with-html-output-to-string (s)
           (:p "a"))
"<p>a</p>"

Then we mix it with Lisp code with the help of using a special symbol HTM to hint WITH-HTML-OUTPUT, where to switch:

CL-USER> (with-html-output-to-string (s)
           (:ul (dolist (a '(1 2 3))
                  (htm (:li (str a))))))
"<ul><li>1</li><li>2</li><li>3</li></ul>"

Now we try to define a macro:

CL-USER> (defmacro test (a)
           `(htm (:li (str ,a))))
TEST
CL-USER> (with-html-output-to-string (s)
           (:ul (dolist (a '(1 2 3))
                  (test a))))

But the following code will cause UNDEFINED-FUNCTION error ("The function :LI is undefined.") Why? Because the translation of pseudo-html s-expressions would be already finished by the time of macroexpansion of TEST, so it will be expanded not inside (:ul (dolist (a '(1 2 3)) ...), but inside calls to WRITE-STRING.

It's definitely unlispy (not to be able to use macros anywhere you want :), so from the beginning of using CL-WHO I tried to find a work-around. (And I guess, many did the same). At least in the mailing list I turned out to be not the only one, who proposed something...

Below 3 solutions, that I've tried (in chronological order) are described. Each implements a distinct approach to combining pseudo-html forms with macros.

Delimited macroexpansion: introduce an additional special symbol (in the lines of already present HTM, STR, ESC and FMT) -- EMB, which will instruct CL-WHO to MACROEXPAND-1 the enclosed form during input transformation.

This is the example (based on the example from CL-WHO manual):

(defmacro embed-td (j)
  `(:td :bgcolor (if (oddp ,j) "pink" "green")
        (fmt "~@R" (1+ ,j))))

(with-html-output-to-string (*http-stream*)
 (:table :border 0 :cellpadding 4
         (loop for i below 25 by 5
               do (htm
                   (:tr :align "right"
                        (loop for j from i below (+ i 5)
                              do (htm (emb (embed-td j)))))))))

I implemented it by tweaking the WITH-HTML-OUTPUT underlying input transforming function TREE-TO-TEMPLATE:

(defun tree-to-template (tree)
  "Transforms an HTML tree into an intermediate format - mainly a
flattened list of strings. Utility function used by TREE-TO-COMMANDS-AUX."
  (loop for element in tree
        nconc (cond ((or (keywordp element)
                         (and (listp element)
                              (keywordp (first element)))
                         (and (listp element)
                              (listp (first element))
                              (keywordp (first (first element)))))
                      ;; normal tag
                      (process-tag element #'tree-to-template))
                     ((listp element)
                      ;; most likely a normal Lisp form (check if we
                      ;; have nested HTM subtrees) or an EMB form
                      (list
                       (if (eql (car element) 'emb)
                           (replace-htm (list 'htm (macroexpand-1 (cadr element)))
                                        #'tree-to-template)
                           (replace-htm element #'tree-to-template))))
                     (t
                      (if *indent*
                        (list +newline+ (n-spaces *indent*) element)

This is a simple and undertested solution, so it, probably, may fail in some corner cases. At least I couldn't make it reliably work, when I tried to combine it with PARENSCRIPT code (see http://common-lisp.net/pipermail/cl-who-devel/2008-July/000351.html). So it's just a direction (yet a quite possible one). But I decided to leave it aside to try the second approach...

Preliminary macroexpansion: don't modify CL-WHO, but build on top of it a macro infrastructure to expand the macros, before the whole form is passed to WITH-HTML-OUTPUT.

After thinking about a problem for some time I came to a conclusion, that it would be better to treat CL-WHO as just a good processor for static pseudo-html data, and on top of it build macros, which will allow eventually to add macroexpansion ability. For that let's consider such model: if we want to use macros, we define an "endpoint", at which they should be expanded (the function, that generates HTML after all). I called this endpoint WHO-PAGE. It will function as DEFMACRO, taking a backquote template, in which we can explicitly control evaluation of forms.
```
(defmacro def-who-page (name (&optional stream) pseudo-html-form)
 "Creates a function to generate an HTML page with the use of
WITH-HTML-OUTPUT macro, in which pseudo-html forms, constructed with
DEF-WHO-MACRO, can be embedded. If STREAM is nil/not supplied
WITH-HTML-OUTPUT-TO-STRING to a throwaway string will be used,
otherwise -- WITH-HTML-OUTPUT"
 `(macrolet ((who-tmp ()
               `(,@',(if stream
                         `(with-html-output (,stream nil :prologue t))
                         `(with-html-output-to-string
                            (,(gensym) nil :prologue t)))
                     ,,pseudo-html-form)))
    (defun ,name ()
      (who-tmp))))
```
The definition of this HTML-generation functions uses macrolet to expand the macros before passing the body to CL-WHO. And the special macros, that will be used inside the template, could be defined like this:
```
(defmacro def-who-macro (name (&rest args) pseudo-html-form)
  "A macro for use with CL-WHO's WITH-HTML-OUTPUT."
    `(defmacro ,name (,@args)
     `'(htm ,,pseudo-html-form)))
```
But that's not all. Sometimes we will need to evaluate the arguments, passed to who-macro (to be able to accept pseudo-html forms as arguments), so a complimentary utility can be added (it's named by the PARENSCRIPT naming convention):
```
(defmacro def-who-macro* (name (&rest args) pseudo-html-form)
  "Who-macro, which evaluates its arguments (like an ordinary function,
which it is in fact.
   Useful for defining syntactic constructs"
  `(defun ,name (,@args)
     ,pseudo-html-form))
```
The example usage can be this:
```
(def-who-macro title (for &optional (show-howto? t))
  "A title with a possibility to show howto-link by the side"
  `(:div :class "title"
         (:h2 :class "inline"
              "→ " ,(ie for)) " "
         (when ,show-howto?
           (how-to-use ,for)) (:br)))

(def-who-macro* user-page (title &key head-form onload body-form)
  `(:html
    (:head (:title ,(ie title))
    (:link :rel "stylesheet" :type "text/css"
                  :href "/css/user.css")
    (:script :src "/js/user.js" :type "text/javascript"
                    "")
    ,head-form)
    (:body :onload ,onload
    ,(header-box)
    (:table ,@(wide-class)
     ,body-form)
    ,(footer-box))))
```
I could successfully use this approach and have added some additional features to it (docstings and once-only evaluation, for example). Actually, I've built a whole dynamic web-site on it, and then faced a problem. As the code of the system grew quite complex with several layers of who-macros, SBCL started to lack resources to compile it. More specifically, upon re-compilation of the system it sometimes fell into heap dump. We tried to investigate the problem, but couldn't dig deep enough to find it's cause (or just lacked enough knowledge to properly debug it).

But the possibility of this solution indeed shows the nature of Lisp: virtually everything can be changed and all the boilerplate for that can be made transparent to the end-user. Alas it also shows, that this flexibility comes at a cost: it's pretty hard to build a robust and simple system, that will handle all the possible corner cases.

Transparent macroexpansion (idea and basic implementation by Victor Kryukov): the last approach (which I use now) was proposed in CL-WHO mailing list. It's in some sense the most obvious one: modify CL-WHO rules to accommodate macroexpansion.

Here's the implementation of this idea, that I use, which is tightly based on the one, proposed by Victor:

(defparameter *who-macros* (make-array 0 :adjustable t :fill-pointer t)
  "Vector of macros, that MACROEXPAND-TREE should expand.")

(defun macroexpand-tree (tree)
  "Recursively expand all macro from *WHO-MACROS* list in TREE."
  (apply-to-tree
   (lambda (subtree)
     (macroexpand-tree (macroexpand-1 subtree)))
   (lambda (subtree)
     (and (consp subtree)
   (find (first subtree) *who-macros*)))
   tree))

(defmacro def-internal-macro (name attrs &body body)
  "Define internal macro, that will be added to *WHO-MACROS*
and macroexpanded during W-H-O processing.
Other macros can be defined with DEF-INTERNAL-MACRO, but a better way
would be to add additional wrapper, that will handle such issues, as
multiple evaluation of macro arguments (frequently encountered) etc."
  `(eval-when (:compile-toplevel :load-toplevel :execute)
     (prog1 (defmacro ,name ,attrs
              ,@body)
       (unless (find ',name *who-macros*)
         ;; the earlier the macro is defined, the faster it will be found
         ;; (optimized for frequently used macros, like the inernal ones,
         ;; defined first)
         (vector-push-extend ',name *who-macros*)))))

;; basic who-macros

(def-internal-macro htm (&rest rest)
  "Defines macroexpasion for HTM special form."
  (tree-to-commands rest '*who-stream*))

(def-internal-macro str (form &rest rest)
  "Defines macroexpansion for STR special form."  
  (declare (ignore rest))
  (let ((result (gensym)))
    `(let ((,result ,form))
       (when ,result (princ ,result *who-stream*)))))

(def-internal-macro esc (form &rest rest)
  "Defines macroexpansion for ESC special form."
  (declare (ignore rest))
  (let ((result (gensym)))
    `(let ((,result ,form))
       (when ,form (write-string (escape-string ,result)
                                 *who-stream*)))))
(def-internal-macro fmt (form &rest rest)
  "Defines macroexpansion for FMT special form."
  `(format *who-stream* ,form ,@rest))

An interesting side-effect here is, that now HTM (et al.) becomes not just a symbol, but a normal macro, so this will work out of the box:

CL-USER> (with-html-output-to-string (s)
           (:ul (dolist (a '(1 2 3))
                  (test a))))

And a user-level DEF-WHO-MACRO, that incorporates ONCE-ONLY (which is regularly needed for this domain) and docstring support can be defined like this:

(defmacro def-who-macro (name attrs &body body)
  "Define a macro, that will be expanded by W-H-O.
/(Its name is added to *WHO-MACROS*).
Body is expected to consist of an optional doctring and declaration,
followed by a single backquoted WHO template.
All regular, optional and keyword arguments are wrapped in ONCE-ONLY
and can't contain pseudo-html forms."
  `(eval-when (:compile-toplevel :load-toplevel :execute)
     (unless (find ',name *who-macros*)
       (vector-push-extend ',name *who-macros*))
     (defmacro ,name ,attrs
       ,@(when (cdr body) ; docstring
           (butlast body))
       ,(let ((attrs (if-it (or (position '&rest attrs) (position '&body attrs))
                            (subseq attrs 0 it)
                            attrs)))
             (if attrs
                 `(once-only ,(mapcar #`(car (as 'list _))
                                      (remove-if #`(char= #\& (elt (format nil "~a"
                                                                           (car (mklist _)))
                                                                   0))
                                                 attrs))
                    `(htm ,,(last1 body)))
                 (last1 body))))))

I hope the above explanations and examples can be grasped easily. And moreover, that they will be useful for those, who are searching for the solution to the same problem. Still, if questions arise, be free to ask them.
If someone uses a different approach, I'm very interested to hear about it.

PS. Btw, Edi Weitz mentioned in the mailing list, that he is preparing a new version of the library. As he'd said, that addition of macroexpansion was on his TODO list, it will be interesting to see, what the new CL-WHO will hold...

О самоподписных сертификатах

2009-03-10T14:17:00.001+02:00

Написано для: habrahabr.ru

В связи с моим участием в проекте fin-ack.com постоянно сталкиваюсь с подобными замечаниями:

я не доверяю вашому самоподписному сертификату, почему вы не купите «нормальный» сертификат?

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

Но сперва отвечу на вопрос, почему у нас нет "нормального" сертификата? (На самом деле, с недавнего времени есть :) Самая главная причина в том, что в нашем списке приоритетов этот пункт стоял на N-ном месте, и только сейчас все N-1 предыдущих пунктов были выполнены. Когда работаешь над новым проектом, всегда приходится от чего-то отказываться, потому что ресурсы, прежде всего временные, ограничены...

А почему же он стоял аж на N-ном месте?
Во-первых, зачем вообще нужен сертификат SSL? Для того, чтобы зашифровать HTTP-соединение между браузером и сайтом, по которому будет передаваться пароль и какие-то другие конфиденциальные данные. Что изменится, если сертификат не подписан доверенным центром сертификации? Ничего! Соединение все равно будет зашифрованно точно также. Единственная возможная проблема: атака человек-посредине, которая в Интернете обычно является phishing'ом или pharming'ом.

При фишинге пользователя перенаправляют на сайт с похожим URL. При этом в браузере обязательно появится предупреждение про сертификат (такое же предупреждение появляется и при первом заходе на реальный сайт с самоподписным сертификатом).

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

Отличие фарминга в том, что в данном случае пользователь попадет как-бы на тот сайт, на который хотел (судя по URL). Впрочем, ему также как и при фишинге будет показано сообщение о недоверенном сертификате.

Но многие вкладывают в сертификат SSL больший смысл:

...Если же сертификат выдан каким-нибудь Verisign-ом (для примера), то это некая "гарантия" что за этим сайтом стоит настоящая организация/частное лицо и уж как минимум "есть с кого спросить в случае чего". Т.е. вообще это как гарантия "серьезности" намерений владельцев сайта.

Мы прекрасно понимаем, что такое мнение имеет право на жизнь. Но ведь все не так просто. Ничто не мешает купить сертификат у Verisign или другого вендора на липовую контору или подставные личные данные. Они не могут проверить наличие у клиента юридических оснований выдавать себя за условные ООО "Рога и копыта" из г.Пермь, Россйская Федерация. Единственное, что проверяется при выпуске сертификата — это то, принадлежит ли вам домен, для которого вы его запрашиваете.
Так что, как по мне, покупка сертфиката у Verisign'а — это всего-навсего демонстрация того, что компания готова выбросить 500$ и несколько человеко-часов, а то и больше на утрясение всех организационных вопросов, вместо того, чтобы потратить это время и деньги на разработку новых возможностей или же реальное улучшение безопасности системы. Вообще, Verisign — это для банков. Есть другие вендоры, с которыми проще и дешевле (пример — ниже).

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

Не достаточно продуманная система доступа к конфиденциальным данным, которая имеет дыры

Проблемы в работе ПО, которое используется системой (ОС, веб-сервер, реализация протоколов шифрования), позволяющие осуществить взлом

Атаки типа человек-посредине, социальная инженерия

Фишинг/фарминг (человек-посредине), по моему мнению, один из наименее важных рисков, поскольку его намного труднее осуществить, его быстро перекроют и, поэтому, такая атака имеет смысл только для систем с очень большим количеством пользователей, из которых можно быстро выудить очень ценные данные (классический пример: интернет-банкинг). По сравнению с этим намного проще запустить сканер уязвимостей и обнаружить, что в системе используется старая версия OpenSSH или на Windows не установлена какая-то заплатка (к нам каждый день стучатся тысячи таких тестировщиков :). Или обнаружить какую-то XSS или SQL-injection уязвимость. Это не говоря о более сложных проблемах создания безопасных Интернет-систем, таких как, например, корректное использование сессий (и куки) для аутентификации. Именно этому нужно уделять внимание в первую очередь!

Еще один аспект безопасности, связанный с сертификатами. Будь он самоподписным или выданным Verisign'ом, все равно с ним ассоциирован секретный ключ, который нужно где-то хранить. Более того, он постоянно используется веб-сервером при открытии HTTPS-соединений, т.е. его нельзя применить один раз при включнии питания, сохранить на флешку и спрятать в сейф. Что будет, если кто-то завладеет ключом? (программист, который имел доступ к серверу, взломщик или еще кто-то). В идеале, этот ключ зашифрован, но при желании и наличии ресурсов его можно расшифровать (и сейчас это дешевле, чем организовать фишинг-атаку). А ведь мы не учли, что некоторые веб-сервера или реверс-прокси вообще не умеют работать с зашифрованными ключами. А еще ведь пароль может быть захардкожен где-то в тексте программы или скрипта, который ее запускает... Так что то, что на каком-то сайте красуется бирочка, что его SSL сертификат подписан Verisign, не дает никакой гарантии, что в один прекрасный день не появится фарминг-аналог, использующий тот же сертификат с украденным секретным ключом.

Тут я даже не вспоминаю о таких аспектах, связанных с системой PKI, как особенности ее поддержки на разных специфических платформах, таких как j2me...

Резюме: есть вещи, которые, в целом, правильные, но не всегда стоят затраченных усилий. Концентрация стартапов должна быть на другом, а мелочи, подобные "правильным" сертификатам должны идти вторым эшелоном. Сначала, как говорят американцы, нужно "get the product right". Всему свое время.

P.S. Собственно говоря, я понимаю, что чем пытатся изменить общественное мнение, проще под него подстроится, поэтому у нас уже есть "правильный" сертификат (время подошло). Кстати говоря, который стоит в 10 раз дешевле, чем большинство (спасибо GoDaddy!). Цель данной статьи в первую очередь в том, чтобы еще раз коснуться неисчерпаемой темы информационной безопасности в Интернете и постараться правильно расставить акценты в одном из ее аспектов.

Курс "Системное программирование и операционные системы"

2009-02-26T11:41:00.006+02:00

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

Попробовал обратиться через форум devua: http://www.developers.org.ua/forum/topic/384. Пока безрезультатно. Может, я не туда обращаюсь или у нас так просто не принято?

Sending SMTP mail with UTF-8 characters from Common Lisp

2009-02-17T22:48:00.003+02:00

Today I explored the topic of sending a base64-encoded SMTP message and it turned out to be rather tricky. I discovered, that for this task (if you don't rely on Franz's infrastructure) effectively 4 libraries should be used. And as they are very scarcely documented, I decided to write this short description.

CL-SMTP

Initially I knew very little about SMTP protocol (except for HELO and EHLO). So I started with the plain CL-SMTP functionality of SEND-EMAIL [1]. The function is not documented and has no own errors, it just re-signals the errors of the underlying USOCKET library. That's why it required some effort on my part to understand, why the following code produces USOCKET:UKNOWN-ERROR [2]:

(cl-smtp:send-email "localhost" "noreply@our.domain.net" "test@gmail.com"
                    "subject"
                    "тест")
Explanation: Sending mail through the SMTP server on localhost from noreply@test.com to test@gmail.com with the body "тест".

It turned out, that the SMTP server just didn't accept the non-ascii characters in the body, because the default encoding is 7bit.
In the process I discovered the useful debugging feature of CL-SMTP: (setf cl-smtp::*debug* t) [3]. It will print the SMTP interaction log.

CL-MIME

So I asked Google and found this article by Hans Hübner, where he explains his enhancements of CL-SMTP (currently integrated in the codebase) and describes how to send attachments with it. But to properly apply his examples to my case I first had to learn a couple of things about MIME. In the example Hans uses multipart/mixed Content-type for sending a message with attachments. But it is not necessary for the simple task of sending a text message in UTF-8 charset. For that you can use text/plain Content-type and UTF-8 charset. But for non-ascii symbols to be accepted by the mail server they should be encoded (usually) in base64 (Content-encoding header). All this activities are handled with CL-MIME library. The library is quite self-explanatory so the lack of documentation doesn't hurt, except for a couple of moments.
First of all, properly formatted MIME text data is produced with the function PRINT-MIME [4], which takes the CLOS MIME object with the appropriately set fields. The problem is, that the generated data contains both MIME headers and the part, which should go into the message body. So the function's output can't be used as an argument to SEND-EMAIL, because the headers will go to the data section, and the mail-client won't consider them (which will result in decoded body). For this case (and other cases, when you need more control of the process of SMTP interaction) Hans has created a high-level macro WITH-SMTP-MAIL [5]. There's a little catch in it as well: unlike SEND-EMAIL it accepts the list of recipients (while the former — a sole recipient string).

CL-BASE64 & ARNESI

The second thing, which caused me most trouble, actually, was the tricky and once again undocumented handling of :CONTENT initarg of the MIME objects [6]. When you provide :ENCODING initarg, such as, primarily, :BASE64, the content part of the data, emitted with PRINT-MIME, will be subjected to the appropriate encoding (performed by CL-BASE64). The interesting thing is, that it will produce wrong output for UTF-8 strings. The proper argument format is an octet array. And you need a function to reduce the string to this format.

ARNESI is a useful library. It provides a lot of small utilities from different spheres. So I was glad to find out, that the needed function STRING-TO-OCTETS [7] is provided by it, because the lib was already utilized in my project.

It's worth mentioning, that if non-ascii characters are used inside MIME body, they can be sent as is. But, AFAIU, it's not so robust as in base64 encoded form.

Result

So the final code turned out to be like this:

(defun send-email (text &rest reciepients)
  "Generic send SMTP mail with some TEXT to RECIEPIENTS"
  (cl-smtp:with-smtp-mail (out "localhost" "noreply@fin-ack.com" reciepients)
    (cl-mime:print-mime out
                        (make-instance 'cl-mime:text-mime
                                       :encoding :base64 :charset "UTF-8"
                                       :content (arnesi:string-to-octets text :utf-8))
                        t t)))

Lessons learned

To send plain text ascii email use CL-SMTP:SEND-EMAIL

If USOCKET:UKNOWN-ERROR is signaled, most probably, the arguments are not properly formatted

For debugging (setf cl-smtp::*debug* t)

To efficiently use MIME utilize CL-SMTP:WITH-SMTP-EMAIL in conjunction with CL-MIME:PRINT-MIME

You need to supply an octet vector, not a string to CL-MIME:TEXT-MIME's :CONTENT initarg.

To break a UTF-8 string into octets use ARNESI:STRING-TO-OCTETS

Nokia Locate Sensor

2009-02-01T11:54:00.002+02:00

From idea:

Received: by 10.141.28.2 with HTTP; Mon, 22 Oct 2007 05:25:31 -0700 (PDT)
Message-ID: <89dc7c5b0710220525p4e33dd50i6cb85d85cc1b0903@mail.gmail.com>
Date: Mon, 22 Oct 2007 15:25:31 +0300
From: Vsevolod
To: info@janchipchase.com
Subject: idea to help not forget phones
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_8479_1626797.1193055931431"
Delivered-To: vseloved@gmail.com

------=_Part_8479_1626797.1193055931431
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello Jan,

My name is Vsevolod Dyomkin. I wanted to share a design idea related to
mobile phones with you, as an only person I can presently reach, who can
possibly facilitate its implementation.

Today I have seen your presentation at TED.com concerning the uses of mobile
phones. What interested me in it is the mention of places, which serve as
gravity centers for important carried items. In my opinion, the existence of
such places, in spite of the natural need for them, brings about one big
potential inconvenience…

Take my example, I work inside a big building and at my workplace the level
of mobile signal is very poor, so I'm forced to leave my phone in the other
part of the room where the connectivity is better. This sometimes leads to
unpleasant situations when I forget the phone, leaving the room and
building. Other example can be, when a person comes to a party and leaves
her phone in some place not to be distracted by it. Afterwards he'll pretty
probably forget about it. This may not only be the case with phones, but
also with other carried items as well.

To prevent such situations I've come up with the following idea: to have a
small device which informs you (like beeps), when you part, for example, 10
meters from the item. It will consist of two parts — a number of RFID tags
(in a form-factor of small round colored stickers), which can be sticked to
a mobile phone, a key, an id card etc. and a receiver/speaker, which can be
a charm on a keyring or a bangle, which beeps. The receiver can optionally
show the color of a sticker, which caused an alarm.

To me this is an example of delegation of mundane/error-prone tasks to
technology :-) — in this case the delegation of the necessity to flap one's
pockets...

If you find it interesting, fell free to contact me
Best regards
Vsevolod

...to implementation

How lexical scope is important

2009-02-01T00:49:00.005+02:00

"Fexprs more flexible, powerful, easier to learn? (Newlisp vs CL)" @ c.l.l.
Rainer Joswig (with some participation from Kaz Kylheku and Pascal Bourguignon) on a practical example explain, what problems of dynamic scope (still used in the suggested "improved" newLisp, which turns out to be old, actually :) are solved by lexical scope.
Bonus: how to create lisp-style special global variables in C++ (and a discussion of what can be improved in CL in this regard)

Технология надежной и удобной аутентификация для web

2008-12-25T10:44:00.001+02:00

Написано для: habrahabr.ru
Время написания: январь 2008

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

В чем именно неэффективность каждого из существующих способов?

Простой пароль: удобно, но есть несколько угроз, и самая главная даже не столько несанкционированное ознакомление с ним, сколько то, что примерно одна и та же комбинация логин/пароль может быть использована для множества разнообразных сервисов, часть из которых может быть недостаточно защищена.
Одноразовые пароли: безопасно и относительно удобно (но, все-таки, добавляется лишнее устройство), но довольно дорого.
Сертификаты цифровой подписи: безопасно, но очень неудобно (проблемы с кросс-платформенной поддержкой токенов), а также дорого.
Использование второго канала связи для подтверждения (обычно, мобильного телефона): относительно безопасно, относительно удобно, относительно масштабируемо (пока...).
OpenID: безопасно, но на данный момент труднодоступно из-за того, что у 99% людей нет доверенного веб-сервера.

Однако, сейчас уже можно замахнуться на глобальную систему аутентификации, если использовать сочетание ставших уже реальностью 3 феноменов:

IPv6;
OpenID;
стабильное интернет подключение с мобильного телефона/коммуникатора.

Вот она:
Каждый мобильный телефон, находясь в сети провайдера, будет постоянно подключен к интернету и иметь статический IPv6 адрес, а также DNS вида <номер телефона>.<домен оператора>. В каждом телефоне будет встроен сервис OpenID.
Таким образом, человеку нужно будет лишь каждое утро логиниться на свой телефон для того, чтобы иметь возможность автоматически аутентифицироваться на любом сайте. В такой системе, разумеется, появляется уязвимое место — сам телефон, в случае завладения которым, злоумышленники могут выдать себя за его владельца. Но тут, даже на первый взгляд, видится достаточно много способов защиты:

(не говоря о блокировке телефона по звонку оператору);
для каких-то чувствительных тракзакций (например, платежей) можно сделать дополнительную авторизацию в виде, например, пароля (вот уже и двухфакторная аутентификация);
можно добавить биометрическую аутентификацию или использование дополнительного токена, например, RFID-брелка, который человек может носить на связке ключей, шее или запястье, и который должен находится не дальше, например, 2 м от телефона, чтобы работал OpenID сервис.
Думаю, есть и другие разумные способы...

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

Surprise with Lambdas

2008-12-23T10:01:00.003+02:00

Tobias Rittweiler posted an explanation about the difference between (lambda and #'(lambda. The article is really useful, because I remember several times seeing the question in discussions unanswered.
Well, after reading LoL I sticked to using (lambda variant and I consider it to be the right thing: the less tokens, the less questions and confusion.

All I can add is, that Common Lisp continues to surprise me with how well thought it's design is. So, throw away the reader macros — it works by itself :)

Мой текущий проект: fin-ack.com

2008-12-19T10:07:00.002+02:00

Написано для: habrahabr.ru
Время написания: декабрь 2008

1. Кому нужен учет личных финансов?

Многие люди считают, что они не ведут личной бухгалтерии, поскольку у них нет на это времени или им этот аспект жизни не интересен. Для кого-то это действительно так (но только в течение некоторого времени). Но, если задуматься, практически все городские жители вынуждены в той или иной форме вести учет своих финансов. Вопрос только в том, насколько он организован и какие средства для этого используются.

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

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

Разумеется, многие осознали для себя необходимость вести организованный учет (а кого-то это заставляют делать те или иные жизненные обстоятельства) и уже используют какие-то средства. Я, например, начинал с обычных текстовых файлов. Большинство, конечно, предпочтут Excel из-за встроенных в него финансовых функций. Кто-то идет дальше и использует для этого специализированные программы: GNU Cash, MS Money, Quicken или еще одну из сотни аналогов. Многие из этих программ написаны для PDA и дают огромное преимущество того, что находятся всегда под рукой, однако теряют в функциональности...

Этот подход, безусловно, самый простой. Самый ли удобный? Все зависит от ситуации.

Если человек постоянно перемещается или, во всяком случае, работает на нескольких компьютерах, у него возникает проблема синхронизации данных между рабочими местами.

Другой, пожалуй даже большей головной болью является забота о резервном копировании.

Безопасность, на первый взгляд, кажется в лучшем состоянии по сравнению с хранением своих данных у 3-х лиц, однако, PDA можно потерять или в него могут приспокойно заглянуть коллеги по работе или знакомые (пока вы куда-то отлучились), а в файлы на стационарном компьютере тоже может залезть кто-то. Самое неприятное тут то, что это может сделать кто-то из тех, кто вас знает, а, по сути, только такие люди могут быть заинтересованы в том, чтобы узнать о ваших финансах.

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

Я думаю, понятно, что мы предлагаем подход к учету финансов в облаке, на веб. Он лишен описанных выше недостатков, однако, безусловно, имеет определенные особенности. Разумеется, идея не оригинальна, в том числе и в сфере личных финансов. Когда я заинтересовался этим вопросом года 2 назад, уже начали появляться подобные системы. На западе их уже, наверное, около десятка. Зачем нужна еще одна?

2. Наш подход и принципы, на которых построен сервис

Повторюсь, у каждого, наверно, есть примеры того, как веб-средства хранения личной информации выводят работу с ней на новый уровень. Забавно видеть, когда коллеги из разных компаний, которые пользуются корпоративной почтой, теряют время и бизнес-возможности из-за того, что оказываясь вне офиса (в коммандировке или на больничном) не могут получить доступ к ней. В итоге, все равно, приходится использовать G- или Y-mail. А сколько денег приходится тратить компаниям для обеспечения доступа к корпоративной почте через веб?.. Для меня такой killer app в свое время стал del.icio.us, который вернул мне возможность полноценно и легко пользоваться букмарками. Кстати, именно del.icio.us (в его предыдущей инкарнации) был вдохновением в дизайне пользовательского интерфейса для fin-ack.

В сфере управления небольшими объемами данных веб-сервис — это, как говорят, американцы win-win. И разработка с поддержкой проще и дешевле, и использование. Веб-сервис выигрывает за счет эффекта масштаба. Если каждому из тысячи пользователей нужно потратить на организацию бэкапа своих данных 10 минут, то даже если проработка сложной и надежной схемы резервного копирования займет у разработчиков день, эти 8 часов все равно не сравнить с 160 часами, потраченными каждым пользователем в отдельности. Также и на поддержку.

Чем же уникально наше решение? Конечно, я изучал то, что уже есть, а также (по возможности) мнения людей. Говорят, главная проблема с учетом финансов в том, что людям лень постоянно вводить свои траты и доходы. На этом предположении даже основана система 4konverta. В Америке эту проблему решают по своему: поскольку у них 90% рассчетов происходит по карточкам (т.е. в безналичной форме), они берут информацию о тратах прямо у банков, и каждая из систем пытается конкурировать в том, кто лучше автоматически обработает эту информацию, категоризирует ее и т.д. (По-моему, это выброс усилий на ветер). Да и удивляешься доверчивости американцев, спокойно отдающим аутентификационные данные от своего счета третьей стороне. Скольку уже было скандалов с кражей личных данных у любых компаний, начиная с AOL?! Другим недостатком такого подхода является то, что их системы заточены под автоматический учет трат, поэтому у них зачастую даже нет возможности вносить их вручную (например, насколько я помню, так устроена система Mint).

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

Во-первых, нужно самому придумать удобный для себя workflow. Например, мне совершенно не интересно, что в моем чеке из супермаркета 20 наименований продуктов. Я запишу их просто как "еда" и поставлю общую сумму. В среднем за день мне нужно ввести в систему 3-5 записей, а занимает это 3-5 минут. За это время я могу посмотреть на свои балансы, подумать о планах, сделать еще какой-то анализ.

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

Не нужно запоминать свои траты — их нужно вводить сразу. Для этого мы разработали специальный мобильный клиент. У которого к тому же есть некоторые другие функции, актуальные для устройства в вашем кармане.

Следующий важнейший вопрос — это безопасность. Очень многие не хотят хранить свои финансовые данные у третьих сторон. В этом есть как рациональное, так и эмоциональное зерно. Как по мне, личная переписка ценнее финансовых данных (если, конечно, вы не занимаетесь противозаконными операциями), а она уже давно перекочевала на веб. У нас опять же несколько ответов на этот вопрос:

Мы сохраняем полную анонимность пользователей. При регистрации не требуется вводить никаких личных данных (даже электронной почты). Единственный способ идентифицировать пользователя, который остается — IP-адрес — мы обязуемся не хранить в соответствии с Пользовательским соглашением. (Естественно, если использовать прокси, то и такая возможность идентификации отпадает). Единственное, мы собираемся использовать информацию о местоположении с точностью до города, однако это никак не нарушает анонимность.

Передача данных защищена SSL. Данные хранятся на нашем сервере, а не у третьих сторон.

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

Что немаловажно, конфиденциальность пользовательских данных, защищает бизнес-модель нашей компании. В Интернете очень много бесплатных сервисов, но в сфере обработки личной информации бесплатность часто является плохим признаком. Почему? Понятно, что сервис создается не из альтруистических побуждений, а так или иначе для заработка денег. Как? Кто-то может надеятся на авось: "вот наберем миллион пользователей и к нам будет стоять очередь покупателей". Это значит, что велика вероятность того, что сервис долго не проживет, и придется искать другой. Кто-то рассчитывает на рекламную модель, но в этой сфере она не будет работать (слишком мало времени пользователю интересно проводить на таких сайтах, не говоря уже об использовании мобильных клиентов, которые вообще сводят это время практически на нет). Точнее, она может заработать тогда, когда разработчики будут готовы делиться данными своих пользователей с третьими сторонами. Короче говоря, бесплатный сыр — только в мышеловке, и кому, как не людям, которые учитывают свои финансы, не понимать, что за все нужно платить — вопрос только в том, стоит ли оно того?

Мы выбрали хорошо зарекомендовавшую себя в этой сфере (например, проектами 37signals) модель частично платной системы. Это значит, что те функции, которые являются действительно отличительными, будут иметь небольшую абонплату. В то же время базовой учетной системой всегда можно будет пользоваться бесплатно. Более того, счета будут выставляться по истечении 3-х месяцев постфактум, т.е. будет возможность полноценно попробовать систему в течение этого срока, а затем решить, использовать ли ее дальше и в какой форме: платной или бесплатной. При этом мы никому не будем передавать или продавать данные пользователей!

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

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

инструменты для решения своих задач;

рассказать, как ими можно пользоваться;

показать примеры разных подходов к их применению.

Fin-ack.com не является Web2.0 приложением, но он к этому движется. По моему мнению, в большинстве случаев создания веб-сервисов именно так и нужно поступать: сначала должна быть добротная базовая система, которая не хуже оффлайн аналогов. А по мере привлечения пользователей она должна развиваться вместе с ними и создавать возможности, просто недоступные для своих оффлайн конкурентов. Это и есть реализация одного из принципов Web2.0 по Тиму О'Рейлли: системы, которая становится тем лучше, чем больше людей ее используют. У нас есть идеи, как можно использовать аггрегированную информацию множества пользователей в их интересах, но об этом не стоит говорить до их появления. Я уверен, что многие идеи прийдут от пользователей.

В то же время мы движемся и дальше — к Web3.0 :) Если так можно назвать тенденцию, которую тот же Тим О'Рейлли называет "transcend the web", а другие — тем, что большинство людей в будущем будут работать с веб-приложениями посредством своего мобильного телефона. А в мобильный нельзя "запихнуть" веб-сайт. Приложения для него должны разрабатываться с учетом ограничений этого устройства, а также тех контекстных возможномтей которые оно дает.

Рассказывать о конкретных особенностях нашей системы не буду, статья и так уже достаточно большая. Надеюсь, fin-ack.com сам способен рассказать о себе.

PS.

Почему в теме Lisp? Ну, потому что вся серверная часть написана на Lisp... :)

Парадигмы программирования

2008-12-15T18:37:00.005+02:00

Со всем спектром придуманных на сегодня парадигм программирования можно ознакомиться в Википедии. В этой статье я хотел остановиться на тех из них, которые имеют значительное влияние на современные языки и программные среды, и о которых, соответственно, обязательно иметь представление любому разработчику. Обязательно потому, что за каждой из парадигм стоит огромная работа по поиску путей решения типичных проблем, возникающих при программировании "интуитивным"[1] путем, и не учитывать этот опыт — значит наступать на те же грабли в который раз и заново придумывать велосипед. Разумеется, многое из написанного в статье общеизвестно, но несмотря на это дискуссии на эти (базовые) темы возникают вновь и вновь. Эта статья — попытка упорядочить для себя общую картину, а также установить точку отсчета, к которой можно было бы привязываться впоследствии.

Основные парадигмы

Структурное программирование
Эта парадигма представляет в основном теоретическое значение (хотя и является неотъемлемой частью практически всех современных языков). По сути, это был первый сдвиг парадигмы в программировании, когда после появления первых абстрактных и высокоуровневых по сравнению с ассемблером языков, пришло осознание, что разрабатывать на них также нужно на более высоком уровне абстракции, чем на ассемблере: в терминах условных выражений и циклов, а не передачи управления между метками. И, что не удивительно, был достигнут консенсус, неоднократно с тех пор подтвержденный практикой, что при использовании более абстрактных конструкций программирование становится более доступным, а программы — расширяемыми, поддерживаемыми,— и, в целом, можно решать намного более сложные задачи.
Эта парадигма основывается на работах Дейкстры, Хоара, Вирта и других, которые доказали, что любое вычисление можно выразить через 3 базовые операции:
- последовательное выполнение;
- условный переход;
- цикл с условием.
Девиз структурного программирования — "GOTO является вредным".

Объектно-ориентированное программирование
Это самая распространенная на сегодняшний день парадигма, которая является развитием идей структурного программирования. Она подается как реализация "естественного" взгляда на окружающий мир, в котором всё является объектом. Она, как известно, покоится на 3-х китах:
- инкапсуляция;
- наследование;
- полиморфизм.
Однако, учитывая распространение, которое она приобрела, а также, наверное, тот факт, что понятие "естественного" и строго математического определения немного отличаются, каждый ОО-язык понимает эти 3 концепции по-своему (во всяком случае, последние две), и каждое такое понимание имеет право на жизнь и применение.
Наследование включает, условно говоря, наследование "свойств" и "функциональности".
Для свойств оно может быть основано на классе (от абстрактного к конкретному) — см. C++, Java,— или же на прототипе (от конкретного к абстрактному) — JavaScript.
Наследование же функциональности и полиморфизм — это 2 стороны одной медали. В Lisp подходе, основанном на родовых функциях эти 2 концепции унифицируются в рамках одной абстракции. Наследование функциональности может пониматься по-разному: как наследование реализации или как наследование интерфейса (см. http://weblog.raganwald.com/2008/04/is-strictly-equivalent-to.html). С другой стороны спектра находится обобщение подхода родовых функций — мультиметоды Clojure — диспетчиризация не только по типу аргументов, а и по любому предикату от аргументов.

Самой распространненой, однако не единственной рализацией ОО-модели является придуманная в SmallTalk и перенятая в той или иной степени C++, Java, Python и другими основными современнымя языками модель передачи сообщений (диспетчиризация метода по типу первого аргумента, который является объектом, принимающим сообщение). Этот подход я бы еще назвал субъектно-ориентированным программированием, потому что в нем неявно считается, что каждый объект совершает действия, т.е. становится субъектом. В зависимости от динамичности языка в нем может поддерживаться утиная типизация (Duck typing), согласно которой для вызова метода для объекта этот объект должен иметь метод с такой сигнатурой, при этом его тип может не проверяться (динамическая передача сообщений).

Функциональное программирование
Эта парадигма имеет свои корни в Лямбда-исчислении Черча и ее первой реализации — оригинальному Lisp'у — больше лет, чем первому структурному языку Algol-60.
Сейчас функциональная парадигма (в форме декларативного программирования) противопоставляется императивному подходу. Ее основа — это функция в математическом понимании (преобразование входных данных), а не функция как процедура, меняющая состяние мира.
Концепциями функциональной парадигмы являются:
- программирование без побочных эффектов (ссылочная прозрачность)
- применение функций высших порядков (итерации с помощью map и рекурсии, карринг, композиция...)
Основным направлением в ФП сейчас направлением являются т.н. "чисто" функциональные языки, которые реализуют такие концепции, как:
- ленивые вычисления
- строгая типизация и вывод типов
- сопоставление с образцом (pattern matching)
Это Haskell, ML (Ocaml, SML), Scala и Qi.
Однако, и динамические (не поддерживающие строгую типизацию) функциональные языки (как правило, имеющие Lisp-основу) также существуют и активно развиваются: Scheme, Erlang, Clojure.

Мета-программирование
Основными идеями этой парадигмы являются возможности расширения базового языка превоклассными (такими, которые смогут использоваться наравне со встроенными) конструкциями, а также всегда программирование на уровне адекватном логике решаемой задачи и прдеметной области. Мета-программирование поддерживается методологией проектирования и разработки снизу-вверх, при которой сложная система разбивается на уровни, каждый из которых соответствует определенным независимым горизонтельным задачам: от уровня утилит-расширений языка вплоть до уровня доменно-специфического языка для моделирования той или иной прикладной области,— и реализуется постепенно уровень за уровнем. При этом на каждом уровне сложность задачи не увеличивается, поскольку примитивами на нем являются абстракции, выработанные на более низких уровнях.
Таким образом мета-рограммирование порождает концепцию DSL — доменно специфических языков, создаваемых для той или иной предметной области (языко-ориентированное программирование), одновременно и использующими возможности хост-языка (все его базовые подсистемы, такие как: сбор мусора, математические библиотеки и т.д.), и являющимися адаптированными в синтаксисе и семантике к той сфере, для которой они реализованы.
К мета-программным возможностям можно отнести те или иные особенности многих языков. Например, в C это перпроцессор, в C++ — в каком-то смысле, перегрузка операторов, а также применение шаблонов для абстракции на уровне системы типов. В Python — это механизм декораторов, позволяющий динамически дополнять реализацию методов. Попытки добавить определенные макросистемы делаются во многих языках. Это, например, MetaLua, а также модули andand, rewrite, rubymacros и др. в Ruby и т.д. Безусловно, базовым языком для парадигмы мета-программирования является Lisp, в котором и зародились (и продолжают зарождатся) ее концепции.

Скриптинговые языки
Можно сказать, что это недопарадигма, поскольку она не основывается на какие-то фундаментальные исследования или принципы. Основная идея тут — максимальное удобство и простота ad-hoc реализации опеределенного класса решений на определенной архитектуре (иными словами, практичность). Это обуславливает такие характеристики языка, как:
- динамичность
- интерпретируемость
- привязка к хост-системе
В рамках этой парадигмы получили свое рождение такие языки, как: Perl (и PHP), Python, Ruby, Tcl, Lua, Basic, JavaScipt, Shell-языки (Bash, PowerShell, ActionScript, AppleScript, ...), некоторые из которых впоследствии переросли ее и перешли, как правило, в категорию объектно-ориентированных языков.

Программирование, ориентированное на параллелизм
Это самая новая парадигма и, пожалуй, еще не до конца сформировавшаяся, поскольку пока что нет косенсуса на счет того, какая из предложенных концепций станет общепризнанной (если это вообще произойдет). А это и развитие архитектуры, подобной MapReduce Google, и асинхронная передача сообщений между процессами (полностью без общего состояния) Erlang'а, и использование программной транзакционной памяти — обобщения концепции транзакции в базах данных на любое вычисление (Haskell, Clojure). Основой для выделение этого подхода в отдельную парадигму стало понимание того, что использование блоков для синхронизации параллельных вычислений не является масштабируемым и поддерживаемым решением при реализации многопоточности (в том числе см. http://jcp.org/en/jsr/detail?id=166). Можно провести параллели между этой парадигмой и процедурной: проблема с использованием блоков аналогична проблеме goto. Пока что ясно одно: эта парадигма станет развитием функционального подхода с его краеугольными камнями немутируемых структур данных и ссылочной целостности.

Дуализм типизации

Несмотря на распространенное мнение поддержка языком программирования того или иного вида типизации является ортогональным к парадигме, которую этот язык реализует. Более того, вопрос типизации можно рассматривать в 2-х аспектах:

Слабая vs сильная. Это различие скорее количественное, чем качественное. "Абсолютно" сильная типизация (как это реализовано в Haskell'е) не позволяет никакого приведения типов (во время исполнения). Более слабые системы типизации дают такую возможность до определенной степени. Например, многие источники называют С слабо-типизированным языком, поскольку он позволяет выполнять неявное приведение типов, а также явное приведение указателей (что не дает возможность проверить тип на этапе компиляции).
Статическая (проверка типов во время компиляции) vs динамическая (проверка на этапе исполнения). Суть динамической типизации можно изложить во фразе из Common Lisp: "у переменных нет типов, типы есть только у значений". Это не значит, что типы не проверяются (как это происходит в нетипизированных языках, тких как Assembler и Forth, но они проверяются при выполнении операций над конкретными значениями во время исполнения программы. Поэтому в динамическом с сильной типизацией Lisp'е не может возникнуть ошибки сегментации памяти при попытке использовать значение не того типа, которая часто встречается в статическом со слабой типизацией С. По мнению идеологов статической типизации, благодаря ее использованию можно исправить большой класс ошибок в программе, связанных с использованием несоответствующих типов, с помощью явного указания типов и их проверки компилятором. А также увеличить быстродействие программы благодаря отсутствию необходимости проверки типов во время исполнения. В то же время написание таких программ является более длительным и сложным процессом (языки со строгой статической типизацией еще называют bondage & discipline languages), и что самое неприятное, их становится очень трудно менять впоследствии. Поэтому, наверное, ни тот ни другой подход не являются предпочтительными в общем случае и могут быть оба использованы в зависимости от конкретной задачи и преференций разработчиков. В идеале, должны появиться языки, которые будут позволять задействовать обе системы параллельно или на выбор. Например, в Common Lisp есть возможность объявлять типы для выражений и переменных для того, чтобы отключить их проверку во время исполнения — это решает проблему скорости для динамического языка, однако не адресует вопрос статической проверки типов при компиляции.

Ссылки на другие интересные парадигмы

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

Программирование на основе стека
Языки на основе стека — это очень простые языки, примитивные операции которых построенны вокруг манипуляции этой структурой данных. Такой подход, в основном, избавляет от необходимости использования переменных для ссылок на значения (point-free programming). Кроме того, синтаксис таких языков становится весьма унифицированным (как правило, используется постфиксная нотация), что дает возможность задействовать мета-программирование.
Языками на основе стека являются PostScript и Forth. Кроме того, большинство виртуальных машин современных языков, такие как JVM, .Net CLR, Perl Parrot и т.д. также являются языками основанными на стеке.
Логическое программирование
Это реализация в языке модели формальной логики. При этом результаты работы программы часто являются побочными эффектами логического вывода. Интерес таких языков в том, что они предлагают совершенно иную модель вычислений, чем фон Неймановская архитектура или Лямбда-исчесление Черча, соответственно некоторые задачи, например, связанные с праллельными вычислениями или имеющие четкую математическую модель, можно решать с применением совсем других подходов. В рамках этой парадигмы получили развитие такие концепции, как бэктрекинг и сравнение с образцом (pattern matching).
Программирование в массивах
Это направление было введено в APL и продолжает развиваться в его последователях J/K/Q, также его реализации присутствуют в MatLab'е и Mathematica. Базовая идея заключается в том, чтобы обобщить скалярные операции на векторные типы данных. Кроме того в этих языках, как правило поддерживается point-free programming. Их удобно использовать для выполнения сложных математических вычислений и они представляют скорее исследовательский интерес. Интересным примером промышленной системы с использованием таких языков является БД kdb+.

P.S

В заключение хотелось бы упомянуть еще одну парадигму или, скорее, анти-парадигму: эзотерические языки (эзоязыки). Эту концепцию также называют Turing tarpit (бочка дегтя Тюринга), потому что эзоязыки показывают, что можно легко создать Тюринг-полный язык, на котором будет совершенно невозможно программировать. По-моему, это хороший урок для тех, кто утверждает, что язык программирования не имеет значения. Да, на любом Тюринг-полном языке можно реализовать любой алгоритм и любую программу, но поробуйте сделать это на brainfuck'е, использующем только 8 допустимых символов и 8 операций, на котором "Hello world" выглядит так:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

, или на Whitespace, для которого весь набор значащих символов составляют пробел, табуляция и новая строка.

[1] Как верно замечено в книге "Основы практики на пианино" в сложных областях деятельности существует настолько много методов решения задач, что даже не смотря на неплохие способности человеческого мозга навскидку выделять более эффектиные из них (которые мы называем "интуитивными"), даже среди этого подмножества есть группа методов, которые являются на порядки эффективнее других, но для того, чтобы их найти, простой интуиции не достаточно.

1 namespace to rule them all

2008-12-14T23:42:00.003+02:00

This thing scares and confuses me: filter even [1..10]
Is even a function or a var?
Personally I'd prefer: filter #'even [1..10]

Common Lisp's n-namespace property is one of the most underestimated features of this most underestimated language. In CL you virtually always know, what you are dealing with, a variable or a function. "Phew!" you say, "in C++ as well". Not so fast. If you try to use callbacks you don't. And when we enter the realm of the functional paradigm, where functions fly all around like daggers in the infamous house, it's really good to know for sure.

Let's restate the rules:
1. Prefix notation: in first position of a form should always be a name of a function/macro/special operator (unless it's an inner form of a macro, which introduces its own structure). So:
* (+ 1 2), not (1 + 2)
* (print 1) -- just like print(1)
* (with-open-file (in "test.txt") ...) -- a structural macro

2. If you want to pass a function somewhere #' is your best friend. Thus you can (fun)call it, apply it, map/filter with it etc.

3. Finally we need to add one more ingredient to the recipe -- the ability to use (lambda ...) forms in function position. We can do it with such a reader macro:

(set-dispatch-macro-character #\# #\f
     (lambda (stream subchar arg)
       (declare (ignore subchar)
  (ignore arg))
       (let ((sexp (read stream t nil t)))
         (let ((fname (gensym)))
           (setf (symbol-function fname) (eval `(lambda ,@sexp)))
           fname))))

which allows us to write this code:

CL-USER> (#f((a b) (+ a b)) 1 2)
3

Парадокс Монти Холла

2008-10-26T20:15:00.003+02:00

Пример того, как программистский подход к решению проблемы может сделать даже парадокс тривиально понятным.

(defun monty-hall (n)
  "Возвращает отношение доли успешных и неуспешных розыгрышей
игры Монти Холла при выборе стратегии всегда менять изначально
выбранную дверь"
  (let ((succ 0.0)
        (fail 0.0))
    (dotimes (i n)
      (let ((choice (random 3)) 
            (prize (random 3)))
        (if (= choice prize)
            (incf fail) ; мы выбрали правильную дверь, но придется поменять
            (incf succ)))) ; мы выбрали неправильную дверь, значит, после смены -- правильную
    (/ succ fail)))

И статистика:
CL-USER> (monty-hall 100)
1.5641025
CL-USER> (monty-hall 1000)
1.6455027
CL-USER> (monty-hall 10000)
1.9958059
CL-USER> (monty-hall 100000)
2.0147724
CL-USER> (monty-hall 1000000)
1.9966408
CL-USER> (monty-hall 10000000)
1.9986455

Monty Hall Paradox

2008-10-26T20:06:00.006+02:00

The example of how tackling a problem in a "hacker's hat" can make a paradox trivial to understand.

(defun monty-hall (n)
  "Returns a ratio of success rate to failure rate, if we follow
the strategy of always switching the initially selected door in
the Monty Hall Problem"
  (let ((succ 0.0)
        (fail 0.0))
    (dotimes (i n)
      (let ((choice (random 3)) 
            (prize (random 3)))
        (if (= choice prize)
            (incf fail) ; we've chosen the right door, but will need to switch
            (incf succ)))) ; we've chosen the wrong door and after switching -- the right
    (/ succ fail)))

And the statistics:
CL-USER> (monty-hall 100)
1.5641025
CL-USER> (monty-hall 1000)
1.6455027
CL-USER> (monty-hall 10000)
1.9958059
CL-USER> (monty-hall 100000)
2.0147724
CL-USER> (monty-hall 1000000)
1.9966408
CL-USER> (monty-hall 10000000)
1.9986455

"Clojure for Lisp Programmers" Talk Summary

2008-10-23T09:02:00.005+03:00

In his talk Rich Hickey made an overview of the major features of Clojure and the design rationale behind them. Except for being Lisp-1, as far as I understand, Clojure is mostly based in and inspired by Common Lisp. Moreover, it tries to push some of the CL technologies to even purer abstraction and generality.

I've tried to categorize the discussed features in their relation to Common Lisp:

Taken from CL and stretched/modified
- destructuring
- nil behavior in conditionals
- defmacro
- multimethods with dispatch by an arbitrary function of arguments
  Obviously is more general, than the CL variant, although Rich failed to mention, that CL's generic functions have also dispatch by EQL, which is enough for, I think, 95% of the situations.
- first-class immutable & persistent data-types: list, vector, hash-map and set
- seq(uence) protocol
  I consider the last 2 a very important idea and a good candidate for implementation as a CL library.
Intentionally different from CL
- Side-effect free reader & separate symbol resolution for macros
  This is also a well thought-out choice, which gives a lot of food for thought.
- Lisp-1. Symbols and vars separated (in Lisp-2 vars are symbol-value or symbol-function)
  In my opinion, not the best option. But it's, obviously, the simpler one to implement
- egal equality
Additional technologies
- STM (MVCC), agents & refs, commute
  A full-fledged innovative concurrent infrastructure.
- Call-ability of data-structures as vars
  A controversial choice, which may lead to a lot of confusion.
- Metadata
  In some sense, a substitute for lack of multiple-values. Besides, a partial introduction of support for the prototype pattern (although lacking inheritance).
Different from CL because of the need for JVM integration (CL solution being superior)
- no multiple-values
- namespaces instead of packages
- boolean true/false
Arbitrary choices inferior to CL solutions (because too much work needed to implement & some infrastructure already available)
- exception handling
- debugging & profiling tools
- boxed integers instead of numeric tower

Re: An Acceptable Lisp

2008-08-25T22:01:00.005+03:00

Recently I've been thinking about programming languages in general and how they relate to Common Lisp, spurred by such questions (and discussions) as Why Ruby is an acceptable Lisp?, Does Common Lisp need a better type system?, What do you LISPers think of Haskell?, Paul Graham's Arc is released today... what is the long term impact? etc.

As far as I understand, what people mean, when they talk about acceptable Lisp, is not Lisp per se, but a universal high-level programming language. It's just, that Lisp has made a bold claim to be such one. Is it? More on that later.

...So, first I've analyzed the languages, which are wide-spread now, whether they can deliver universality, so to say.

Kent Pitman has very accurately noted (Q16: Scheme in CS), that most people program in assembly languages, be they concrete, like C/C++, or abstract, like Java. And that is understandable, because these languages allow a straightforward solution, and for the majority is content with that. And that's one of the most important arguments, why purely functional programming languages can't become universally-accepted.

What about high-level languages? First of all, what kind of an animal is that? My idea is, that it should be a language, in which you can declare what to do and not how, think of any problem in terms of its domain vocabulary and not in terms of moving bits and bytes around. But that's, obviously, an oversimplification. One of the most important qualities of a high-level language is, that it provides efficient means of abstraction (and the function is the most important — that's why languages without first-class functions don't count as high-level). The high-level language should not only provide means to solve a real-world problem, but as well to solve a problem of solving such problems. Well, although I can't express concisely and clearly, what's that, I'm sure, that there exists a common understanding, or rather feeling, of that concept among the people, who raise such questions.

So, what languages do we consider high-level?

Python is an attempt at a high-level language. But it's stuck in the middle of a road from imperative to high-level. The goal of the language's design was not to achieve universality, but to create a robust dynamically-typed object-oriented language for scripting, and it's reached, but there's no more ambitious aims ahead...

Ruby is definitely not an "acceptable Lisp" — it's a clean Perl (with a "mixin" of Smalltalk). The aim of a language is power, but in a somewhat myopic (Perl) view, i.e.: the ability to hack (which in the context is the opposite of build complex systems) neatly and fast. That's why everything, which was considered in the historical context of the language's creation as a powerful feature to have, was incorporated into it. From classes to keyword parameters to regular-expressions to anonymous functions. Surely a lot of the achievements of language design from Lisp ans Smalltalk and other languages are in Ruby, but it's not "turtles all the way down" -- not uniform enough to be able to efficiently develop new high-level concepts on top of it, which will fit (so you're mostly left with what's already in the language. (Btw, Mr. Braitwaite tries to prove the opposite).

C# (it seems, they are incorporating first-class functions in C#3) is an interesting example of a language, which is based on C++ and Java and gradually moves to high-levelness. But still it lacks underlying vision of universality, it's very similar to Python in a way, that the imperative paradigm with it's class-oriented extension if considered the most important and basic one, thus limiting the others to being second-level citizens.

Erlang is just a DSL for concurrency programming. It's functional, but not at all intended to be universal.

Haskell is definitely different from the previously discussed languages, because it really is built on the basis of an abstract ideology and not as a pile of features. It's 2 fundamentals are pure functionality and type-inference, and as a manifestation of this ideas it achieves prominent results. But this ideas do not lead to a language, capable of adapting to every problem and producing the most natural solution.

Forth, J et al.. Why they can't be universal? I think it's a debate between an ordinary to ourselves (alphabetic) language and an hieroglyphic one. They are definitely a way of their own, and a very interesting one, but not a way to unification, I think.

Scheme is a high-level language, built from a set of Lisp "axioms", whose biggest flaw is prohibition of real macros. Paul Graham's Arc is an attempt to bring macros to Scheme, but, i think, it's early to say, whether it will succeed as a separate language or a successor to Scheme.

Common Lisp
Is Common Lisp an acceptable Lisp, i.e. is it a universal high-level programming language? I don't think, that it is, and that has been proven by history, so to say (it's not even near to being universally accepted). But it, surely, is the most advanced language in this direction and it possesses some of the high-level features, that are not present in other languages (and these features are actually the features of "ideal" Lisp, from which Common Lisp derives its name). Briefly about them:
* Parens are not a drawback. On the contrary, they are a powerful basis for abstraction, because they help to denote a form — the universal building block of it. Form is both data and code. Then there are S-expressions which are supported by parens, but have the other underlying concept — prefix notation, which unifies operations (mostly coded in infix notation in other languages) and function application (either prefix or suffix, but never infix).
* As Paul Graham has pointed, the best way to design a language is to start from the most general set of axioms. And Lisp (Common Lisp included) follows this principle, moreover its set of axioms is probably the most general one.
* Macros are built on top of Lisp's general-purpose s-expressions being code and data. I think it's obvious, why they are obligatory to a high-level programming language -- because syntactic abstraction is one of the most common ones.
* No "religious" adherence to any specific programming paradigm, but taking the best principles from every one (at least at the time of language's design).
* A concise standard. It's funny, when other language programmers "complain" about the CL standard being bloated, incomplete and outdated. Maybe, the only language, which can claim to have at least a somewhat accurate, complete and up to date one is Java (or rather could), while others either don't have any (Ruby, Python etc.) or have a lot of revisions, vendor-specific parts and incompatibilities between them (JavaScript, C++ and so on). And the fact, that the functional programming languages, which usually have clear formal specifications, are constantly in the process of revising them, as for me, seems to prove, that they just didn't reach maturity yet.

But, still, there are some features, or rather underlying principles, that Common Lisp lacks.
* What static typing folks want?
I "belong" to the dynamic typing camp, but I think, I understand, what the other camp needs. The Lisp idea, that variables don't have types and only values have, should be acceptable to them. But they want a compiler subsystem, which checks one of the dimension of the program's correctness (the dimension, that really allows verification), based on the programmer's declaration. And that surely can be considered an important high-level feature. Moreover, it seems to be a reachable goal.
What CL has is optional type declaration and runtime check. Qi implements static type-checking and type-inference, and besides other functional-paradigm features. But it abandons prefix-notation and multi-paradigm approach as a whole. Thus it's a very advanced functional language with roots in Lisp, but not Lisp. Neither it is universal.
What can be done inside Lisp to add static type-checking to dynamic one? I think there's a possibility at least to implement partial "lexical" type-checking for lexical variables. But how to do that properly is a different question. Anyway, I'm sure, that although a "universal language's" type system can have a deep mathematical foundation, it should allow not only logical formalisms for defining types, but as well plainer and simpler variants.

* What Schemers wanted, and why they chose Scheme?
As far as I understand, people who choose Scheme over CL do that not because it nil and false, nor for the lack of macros. And not because it's Lisp-1, but to be more precise, because it supports evaluation of the car of a list, while CL only allows function (and macros, and special-forms) names in it. I don't see, why there can't be a compromise between the 2 approaches: leave multiple namespaces, which is, as practice shows, very beneficial, and at the same time treat the function cell (car of a list) differently: if it's a name, it should be from the function namespace, while if it's a list -- it's a form, which should be evaluated and produce either a function object or a function name.

* Some idiosyncrasies, mostly inherited, should be removed (not all functions are generic; errors do not subclass standard-object etc.). The MOP should be in the standard. And the tradition of incorporating the best from every paradigm should be continued: at least the concurrency-oriented paradigm is relevant.

* Community process.
If the ideal Lisp is ever to appear it should have a standard and a process of modifying it without loosing backward compatibility.
I understand, what kind of a difficult and bureaucratic process was the effort for the Common Lisp standard, and that it's not going to be repeated. Well, it's not necessary. The times have changed, and now excellent implementations of a language are produced by the community, which is globally distributed. There's no central power and a big client (like DARPA), which demands official standard. The standard should and could be produced by the community as a result of a consensus. Why Python, Perl or Arc will never become universal? Because their development is mostly determined by the tastes and preferences of their "benevolent dictators", and their views, whatever enlightened and advanced be them, are subjective and can't be accepted universally. Today there's virtually no other power in the Lisp world, except its users. Nor big organizations, like Microsoft, Google or DARPA, neither dominant implementation producers. So I think, that if the members of the CL community with the biggest impact on it, like the participants of the original standardization process, who are still active in the Common Lisp world: Kent Pitman and Daniel Weinreib,-- as well as the new generation of prominent lispers: Pascal Constanza, Edi Weitz, Paul Graham,-- and others were able to self-organize and setup a community process for the creation of the new Lisp standard, it could yield a desired result.

Maybe it's time to start advancing from Common Lisp to Universal Lisp?..

Shell — секретное оружие Unix :)

2008-08-23T15:00:00.004+03:00

Написано для: habrahabr.ru
Время написания: февраль 2008

Как я написал в одном комментарии:

если не хотите знать про коммандную строку, то в линуксе вам делать нечего. Будет вам та же винда, только вместо одних проблем получите другие...
--comment605950

С другой стороны, как раз в shell заключается одно из кардинальных отличий Unix-систем, то, что делает эти системы открытыми...

В чем же основные особенности Unix shell, которых нет в Windows?

Весь процесс конфигурации и администрирования Unix построен на работе с текстовыми файлами. Shell — это полноценный язык программирования, заточенный для манипуляции строками и работы с тектсовыми файлами. К тому же, именно как расширение возможностей shell по обработке строк и возник Великий язык PERL!.
Благодаря п.1 shell — это отличный инструмент для постепенного изучения самой операционной системы.
Наличие shell способствует реализации важного принципа создания любых программ:
Если это простая программа, которая предназначена для выполнения ограниченного числа операций, ее нужно реализовывать как набор команд, родных для платформы, на которой она работает (как правило, платформой является ОС). Если же имеем дело со сложной интерактивной программой с потенциально неограниченным набором операций — ее нужно реализовывать как язык опять же на родном для платформы носителе (сейчас наиболее родным и удобным носителем при взаимодействии с компьютерами все же является текст, а не звук, графика или что-либо еще).
Примерами 1-го и 2-го подхода могу служить tcpdump, реализованный полностью в текстовом режиме, над котором не представляет труда надстроить интерфейс (по сути, Ethereal — и есть подобный интерфейс), и emacs — самый расширяемый текстовый редактор.
В этом проявляется основное отличие философии Unix и Windows: в Win интерфейс програм по умолчанию делается на графическом языке, из-за чего программы практически невозможно сопрягать или строить на их основе новые. Потому что для этого нет поддержки на уровне ОС. И для того, чтобы сделать программы расширяемыми, все равно приходится использовать текст (пример — тот же VBA в Word и Excel).
Автодополнение команд и, что самое главное, путей. Трудно даже представить, сколько времени и сил экономит эта небольшая возможность!
Полный набор утилит для всех возможных задач администрирования.

Стоит также перечислить утилиты shell, которые обязательно нужно использовать в повседневной работе с системой:

man — это справка по ОС, которая включает не только описание работы всех команд, но также и что должно быть в большинстве из конфигурационных файлов, а также много другой полезной информации;
less — просмотр текстовых файлов;
grep (программистов, не знающих о grep, не берут на работу в Amazon.com :);
locate — быстрый поиск файлов.

а еще можно вспомнить группы утилит, использование которых намного удобнее и эффективнее их графических аналогов:

настройки сети (позаимствованные Windows);
управления пакетами;
управления пользователями;
монтирования томов...

Можно только повториться, что для тех, кто не хочет работать в shell, Linux или другая Unix-based ОС — во многом такая же неудобная и непонятная система, как и Windows. Но стоит все-таки попробовать разобраться с shell — хотя бы для того, чтобы посмотреть, как правильно администрируются информационные системы.

О пользе унификации и вреде предубеждений

2008-07-25T15:46:00.001+03:00

Написано для: developers.org.ua (изменен код макро gcase)
Время написания: июль 2007

In fact, let’s not even worry about Java. Let’s not complain about Microsoft. Let’s not worry about them because we know how to program computers, too, and in fact we know how to do it in a meta-way. We can set up an alternative point of view, and we’re not the only ones who do this, as you’re well aware.[1]
–Alan Kay
There is a huge difference working with a language where you have to wait a year to get a new loop statement from the language designer and compiler implementer - or - where you do it yourself in twenty minutes.[2]
–Rainer Joswig

1. Принципы хорошего стиля программирования

На Западе широко известна следующая концепция из классического учебника MIT по программированию “Структура и интерпретация компьютерных программ”:

Сперва мы хотим утвердить идею, что компьютерный язык — это не просто способ добиться от компьютера выполнения операций, но, скорее, что это новое средство для формального выражения идей о методологии. Таким образом, программы должны быть написаны для людей, чтобы они их читали, и только между прочим для машин, чтобы они их исполняли.[3]

Есть и другой подход: программа — как набор кубиков лего, которые нужно любой ценой состыковать вместе, а где совсем не сходиться — допилить напильником.

Хороший стиль программирования должен обладать такими качествами как элегантность и максимально возможная простота понимания результатов. Это, в конце концов, есть мера трудозатрат на написание программы, ее отладку и поддержку, а также удовлетворения программиста от процесса труда.

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

К сожалению, современные мейнстрим языки жертвуют целью сделать возможным хороший стиль из коньюнктурных соображений реализации. В результате нам приходится использовать корявые языки, что приводит к полной неэффективности на более высоких уровнях абстракции. Мало того, что программист для того, чтобы получить возможность создания серьезных программ, вынужден вкладывать большое количество времени в изучение эзотерических технологий, которые через пару лет устареют (они устаревают как раз из-за своей ограниченности и привязки к конкретным промежуточным архитектурам), таких как: фабрики классов COM или же MFC на пару с Win32 API, AJAX и пр. Применение этих технологий серьезно затрудняет развитие достигнутых результатов другими людьми, которые не имеют времени, желания или возможности изучить их, не говоря уже о внутренних ограничениях самих технологий.

Также и хорошая парадигма, как и любая другая идеология, дает большой выигрыш на начальном этапе, но становится тормозом развития впоследствии, и языки программирования созданные для реализации концепций одной парадигмы становятся ее заложниками. Человек лучше всего думает на естественном языке, и хороший язык программирования должен давать ему возможность наиболее естественно (т.е. близко к их оригинальной форме) выразить свои мысли о структурах данных и алгоритмах, которые составляют по Вирту все, из чего состоят программы, накладывая при этом как можно меньше ограничений. В языке программирования должны быть равные возможности реализации любой прадигмы, любой концепции, способной зародиться в голове программиста, наиболее простым и элегантным путем. Такой подход лежит в основе Lisp’а, “программируемого языка програмиирования”.

2. Ограниченность языков с жестким синтаксисом

Если говорить по существу, то первая проблема большинства языков — жесткий и часто весьма запутанный и не унифицированный синтаксис, который, если немного перефразировать слоган Perl’а, делает некоторые вещи (которые по мнению создателя языка должны быть простыми) простыми, а остальные — как прийдется. А приходится так, что, большинство концепций, которые не были приняты во внимание при создании языка, требуют огромных трудозатрат для реализацию теми, кто в них нуждается. В качестве примера можно привести такую вездесущую потребность, как передача функций в качестве параметров другим функциям (так называемым, higher-order functions), которую не возможно элегантно реализовать в императивных языках (С или Java). Можно обратиться к функциональным языкам, но и здесь мы видим, что в основу языка заложено множество семантически-нагруженных конструкций, об универсальности которых говорить не приходится.

Важнейшей характеристикой любого языка программирования являются предоставляемые им средства абстракции. В идеале должна быть возможность абстрагировать типичные шаблоны и конструкции программного кода таким образом, чтобы не только в каждой программе использовать термины, хорошо соответствующие предметной области (абстракции процедур, функций и классов, доступные в большинстве языках), но также чтобы снять необходимость рутинного повторения более общих конструкций “среднего уровня”, которые нельзя отнести ни к самому языку, ни к конкретной предметной области. Только так можно обеспечить соблюдение принципа хорошего стиля — писать все только один раз.

Показательным в этом отношении является шаблон with-..., который используется в Lisp’е в таких задачах, как работа с файлами и потоками, интерфейсами и протоколами обмена информацией. Примером может быть запись данных в файл. Это требует выполнения таких операций, как объявления переменной потока вывода, открытие физического файла на запись, при этом проверки на предмет того, возможно ли это, и выполнения соответсвующих операций в случае ошибок. Также не нужно забывать о необходимости закрыть файл после окончания манипуляций с данными. Все эти операции просты и рутинны, а необходимость их повторного написания много раз приводит к бесполезной трате времени, а также к тому, что файл в конце концов забывают закрыть… В Lisp эта констукция реализуется с помощью макро with-open-file в теле которого выполняются манипуляции с данными. Почему такой подход не применяется в других языках — об этом ниже.

3. Синтаксис Lisp’а

Почему-то распространено мнение, что у Lisp’а сложный синтаксис, впрочем обычно подразумевается другое — зачем все эти скобки??! А вот Lisp-программисты считают, что у Lisp’а вообще нет синтаксиса.

На самом деле, как верно подмечено в комментарии Тима Бредшоу у Lisp’а синтаксис минимальных обязательств. Можно сказать, что он выполняет только лишь функцию необходимой регуляризации английского языка для того, чтобы исключить неоднозначность.

Программы Lisp’а — это текст: есть атомы — символьные идентификаторы — это слова, есть список — атомы, разделенные пробелами и взятые в скобки — это предложение. Lisp Reader4 (можно легко представить себя на его месте) читает этот текст и интерпретирует его в качестве так называемых s-выражений, т.е. подходит к нему с таким набором предпосылок:

в любом s-выражении первым идет имя операции, а остальные элементы могут быть s-выражениями либо атомами

любой атом является либо именем либо означает сам себя

таким образом, s-выражение имеет следующий вид: (имя элемент элемент ...), где элемент — список либо атом.

Так зачем все-таки все эти скобки??! Риску начать издалека. Когда люди впервые занялись символьной математикой, они начали с использования простых операций — = + - * > < — которые имели 2 аргумента, т.е. выражения записывались в виде c = а + b. Им сразу же пришлось столкнуться с проблемой порядка операций (что будет, если записать d = a + b * c, и появились скобки, которые вернули в математику однозначность :). Чуть позднее появилась концепция функции, т.е. обощенной операции, которая имеет аргументы и значения. Поскольку многие функции также могут иметь несколько аргументов и даже несколько значений, их пришлось записывать, например, так: f(x, y, z) := (x, y) + (y, z). Здесь уже теряется единообразие: для базовых операций используется инфиксная нотация (т.е. операция записывается между своими аргументами), а для самой функции — по сути дела префиксная (или польская нотация). Что если попытаться свести все к единой нотации: := f x y z + (x y (y z. Не все понятно и однозначно. Убрать неоднозначность можно, добавив скобок: (define f (x y z) (+ (x y) (y z))). Выглядит не совсем привычно, но и изначальная конструкция тоже не была первым, что мы изучили в школе на математике.

4. Метапрограммирование

Что дает нам префиксная запись операций по сравнению, например, с С-подобным синтаксисом? Думаю, кому-то интересно будет узнать, что во внутренних структурах компилятора программа С выглядит так же. Я, конечно, не имею в виду, что там у них тоже скобки :). Но после прохождения сложного синтаксического разбора С-программа преобразуется компилятором в абстрактное синтаксическое дерево (AST). Код Lisp’а — это и есть AST, подавляющая часть которого скомпрессирована в виде MACRO’в (или, как находчиво придумал Conrad Barski — SPEL’ов), записанный прямо у нас перед глазами. И, поскольку мы избавлены от необходимости трансляции кода программы из ее обычного синтаксиса в AST и обратно, открывается возможность для широкого использования MACRO’в: если мы видим повторяющиеся части в дереве, их легко абстрагировать.

На это можно посмотреть и с другой стороны:

Lisp — это исполняемый XML с более дружественным синтаксисом.[4]

Ведь XML-файл — это тоже по сути дерево данных и метаданных. Только, чтобы избежать круглых скобок, создатели SGML/HTML/XML придумали использовать угловые и записывать название каждого тэга дважды! HTML элементарно преобразуется в подмножество Lisp’a, как показывают многочисленные реализации Lisp’овых библиотек для HTML-генерации (например, CL-WHO или ParenScript, который также реализует JavaScript и CSS). Интересно то, что в Lisp’е HTML-генерация намного естественней заточенного специально под задачу создания динамических веб-страниц PHP, в котором все в конце концов сводится к банальному вызову функции echo.

За счет использования MACRO’в, Lisp позволяет выражать свои мысли в наиболее лаконичной и адекватной форме, а каждый программист имеет способы самостоятельно сформировать набор примитивных конструкций языка, с которыми он будет работать в рамках конкретной проблемы, программы или платформы. Вы можете сказать, как и в большинстве других языков if ... then ... else ..., но также вы можете сказать when … then …, unless ... then ...; кроме того, вы можете сказать condition 1 -> expression 1; ... condition n -> expression n, case ... variant 1: expression1 ... variant n: expression n. И это далеко не полный список, на самом деле, вы можете легко реализовать любую логическую конструкцию и по возможностям использования в программах она ни чем не будет отличаться от обычного if-then-else.

Конкретный пример: в стандарте Lisp есть 3 вида case конструкций, которые имеют такую обобщенную форму:


    case-конструкция тестовый элемент
    (значение1 форма1)
    ...
    (значениеN формаN)
    [(otherwise формаN+1)]

Они отличаются тем, что обычная case-конструкция имеет default clause, а 2 другие: ecase и ccase, — выдают ошибки в случае ненахождения значения тестового элемента в списке возможных. Ограничением этих конструкций является использование для сравнения функции eql (опять же одной из множетсва операций, которые используются для проверки на равенство). Эта функция не работает для строк, поэтому я решил написать собственный вариант case, который бы давал возможность использовать любую функцию сравнения. Например, эта может быть функция, которая проверяет нахождение числа в рамках заданного интервала. Хочу обратить внимание на то, что конструкция gcase объявлена мной совершенно таким же образом, как и оригинальные case-конструкции — а возможность узнать их реализацию, не залезая глубоко в код или описание стандартных библиотек (доступа к которым может и не быть), как это делается в других языках, можно, как правило, просто запустив macroexpand.

(defmacro gcase ((keyform &key (test #'eql)) &body clauses)
  "GENERALIZED-CASE -- the difference from simple CASE is that it can
use any given TEST-function. TYPE-ERRORs signaled by TEST-functions are ignored"
  (unless (listp clauses) (error "~a -- bad clause in CASE" clauses))
  (let ((t-clause? nil))
    (when (eql (caar (last clauses)) 'otherwise)
      (setf t-clause? t))
    `(let ((it ,keyform))
      (cond
 ,@(mapcar #'(lambda (clause)
        (if (and t-clause? (eql (car clause) 'otherwise))
     `(t ,@(cdr clause))
     (w/uniqs (c)
       `((handler-case (funcall ,test it ,(car clause))
    (type-error (,c) (warn "The value ~a is not of type ~a"
                           (type-error-datum ,c)
                           (type-error-expected-type ,c))))
         ,@(cdr clause)))))
    clauses))))) [5]

То же самое касается любых других абстракций. Людям, привыкшим работать в жестко ограниченных языках, не понятно, зачем иметь столько конструкций для циклов: do, dotimes, dolist, loop, …,— к которым могут быть дописаны еще какие-нибудь dotree, domap и т.п. (Хотя многие, наверно, вспомнят, что были рады увидеть, наконец, в C# конструкцию foreach, которой так не хватало в С++). В действии все тот же принцип хорошего стиля — писать все только один раз: во-первых, не нужно копи-пейстить одни и те же шаблоны снова и снова, во-вторых, сразу понятно, какого типа цикл перед нами (а не так, как в С: for (;;)), в-третьих, легко можно уточнить и расширить эти конструкции с помощью инструментов такого же типа (все эти операции циклов — тоже MACRO)...

Почему макро-систем нет в других языках? На самом деле они были и есть: Dylan — это Lisp с С-синтаксисом, metalua и пр. Очевидно, что для поддержки макров язык должен иметь возможность задействовать позднее связывание, но главная проблема остается в другом: разнородности и запутанности синтаксиса — в трудности учета самим программистом всех возможных побочных эффектов “скрытия” каких-то частей кода. Не то, чтобы такая система была не возможна — она, просто, не так практична, потому что появляется необходимость дополнительной трансляции кода между разными представлениями в воображении. А для полноценного использования макров, как показывает даже простой пример вверху, часто не удается ограничиться только одним уровнем вложения макрокода.

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

5. Обещание Lisp’а

Большинство книг и введений в Lisp обещает, что изучив его, программист станет другим, лучшим. Вряд ли это так, потому что никого нельзя изменить при отсутствии собственного желания измениться (и всегда можно будет найти объяснение отсутствию желания, будь то “наличие/отсутствие скобок, переменных, объектов, …”, отсутствие библиотек, необходимость кормить семью…). На самом деле, главное обещание Lisp’а в другом — в том, что человек сможет выражать свои мысли при программировании свободно, в любой принятой им парадигме или вне парадигм без необходимости руководствоваться искуственными ограничениями. Идея, которая стоит за Lisp’ом сегодня — ясность. Но, как и за все остальное, за нее приходится чем-то расплачиваться. И, как по мне, пусть это что-то будет парой лишних скобок... :-)

Сноски:
[1] На самом деле, давайте не будем беспокоиться о Javе. Давайте не жаловаться на Microsoft. Давайте не беспокоиться о них, потому что мы тоже знаем, как программировать компьютеры, и, на самом деле, мы знаем, как делать это мета путем. Мы можем установить альтернативную точку зрения и мы не единственные, кто делает так, как вы хорошо знаете
[2] Есть большая разница между работой с языком, в котором вы должны ждать год, чтобы получить новое выражение для цикла от дизайнера языка и реализатора компилятора — или, когда вы можете сделать это сами за 20 минут
[3] First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
[4] http://www.defmacro.org/ramblings/lisp.html
[5] В этой реализации, конечно, есть не только скобки, но и специфические функции, а также несколько синтаксических элементов (называемых синтаксическим сахаром): ' ` , #' ,@. На самом деле, это практически исчерпывающий список всех подобных элементов в Common Lisp, более того все они имеют свои аналоги в форме (имя ...), т.е., в конце концов, можно ограничиться только скобками и именами.

Дилема зеків на київських дорогах

2008-07-25T15:07:00.005+03:00

Написано для: Украинская правда (не опубликовано)
Время написания: январь 2008

Є такий важливий результат теорії ігор — дилема в'язнів.

Коротко, двоє підозрюваних, А і Б, арештовані. У поліції немає достатніх доказів для звинувачення, і ізолювавши їх один від одного, вони пропонують їм одну і ту ж операцію: якщо один свідчить проти іншого, а той зберігає мовчання, то перший звільняється, а другий одержує 10 років в'язниці. Якщо обидва мовчать, у поліції мало доказів, і вони засуджуються до 6 місяців. Якщо обидва свідчать проти один одного, вони одержують по 2 роки. Кожен ув'язнений вибирає, мовчати або свідчити проти іншого. Проте жоден з них не знає точно, що зробить інший. Що відбудеться?

Математично доведено: якщо кожний зі злодіїв буде діяти виключно у своїх (егоїстичних) інтересах, тобто, виражаючись формальною мовою, раціонально, обидва будуть говорити і тому отримають по 2 роки. Чому? Це легко пояснити. Візьмемо одного зі злодіїв. Якщо другий буде говорити, то і йому вигідно те ж саме, бо він отримає тільки 2 роки, а не 10. Якщо ж другий буде мовчати, то і тут вигідно співпрацювати з поліцією, бо замість півроку у в'язниці наш злодій одразу виходить на свободу.

Як бачимо, діючи скоординовано, ці двоє отримали б менший строк, ніж діючи кожний виключно у своїх інтересах. Це пов'язано з тим. що, виражаючись математичною мовою, ця гра — не з нульовою сумою.

Цікаво... А тепер порівняйте це з ситуацією на київських вулицях, особливо під час пробки. Деякі люди, бачачи пробку, думають: "зараз я швиденько прорвуся по порожній зустрічній смузі", "виїду на червоне світло, бо ці бовдури з перпендикулярної вулиці затримались на перехресті більше належного" і так далі. А виходить, що це тіьки погіршує становище. Мабуть, тому, що на кожного хитрого знайдеться ще хитріший, а на кожного зухвалого — ще зухваліший.

Так що, певне — напрошується питання — у більшості киян зеківське світосприйняття? :)

Добре, окрім жартів, чи є вихід з такої ситуації? Ну, як мінімум є 2 виходи: простий і складний. Складний полягає в тому, щоб всім домовитись між собою про певні "правила гри", усні чи письмові, або навіть прийняти закони і створити систему забезпечення їх дотримання.

Є ще простий вихід, який, мабуть, здасться безглуздим хитрому лису, про якого пише Ніко Ланге у своїй статті "Україна не є правовою державою". Справа в тому, що для людей з релігійною (або навіть просто моральною) свідомістю дилеми в'язнів взагалі не існує, бо кожна релігія вчить поводитись по відношенню до оточуючих так, як ви хочете, щоб поводились по відношенню до вас. Це значить, наприклад, пропустити іншого попереду, бо ти хочеш, щоб і тебе пропустили , коли ти поспішаєш; не лізти поперед іншими, бо і тобі не подобається, коли перед тобою влізають... Виявляється, навіть математика говорить, що це, може, й не такий поганий варіант.

Мысли по поводу ICFPС '08

2008-07-16T07:03:00.001+03:00

1. Забавные факты о нашей команде

Изначально наша команда состояла из 4-х человек:
- двоих из Питера: того, кто нас собрал -- Якова Зайцева (lj:iakovz), -- выбравшего Erlang, и его друга с C++
- питонщика из Омска
- меня с Common Lisp
(Более распределенной и полиглотной, наверно, трудно представить. Впрочем, мы считали, что наш основной язык -- Lisp).

В этом составе мы провели тренировку...

Когда началось соревнование, нас было (потенциально) 6: к нам присоединился друг нашего Омского товарища и Эндрю Бейн -- программист на Lisp'е, который искал Lisp'овую команду в списке рассылке.

...А когда мы отправляли, наша готовая программа состояла из 2=х модулей: низкоуровневого на Erlang'е, отвечавшего за маневрирование, написанного Яковом, и моего высокоуровневого для выбора направления. Кроме того, в СКВ была куча C++ кода (не интегрированного с нашим), написанного парнем из Омска, который присоединился последним, в день соревнования. Я не отправлял ее, поскольку мы не знали, что там к чему...

2. Коммуникация

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

Но, что касается нашей пары, с ней тоже произошла забавная история с коммуникацией: в последний вечер мы отлаживали часть Якова во в некотором роде "распределенной" манере: он делал исправление, заводил его в SVN, я забирал его, отправлял через scp на машину с LiveCD, запускал, отлавливал в консоли ошибки, сохранял в текстовый файл, scp назад на свой ноутбук и отправлял Якову по Skype. Она продолжалась, мне кажется, часа 3 и, что интересно, в конце я смог отправить почти работающую программу. :) Это произогло из-за того, что у Якова на работе были какие-то неполадки с интернетом, поэтому он не мог загрузить liveCD, а я оказался настолько тупым, что не подумал запускать клиента по сети...

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

3. Минимальный набор инструментария

который бы понадобился вам в этом году для участия в составе гео-распределенной команды:
* groupchat
* SCM в сети -- GoogleCode доя нас сработал отлично
* отдельный комп для запуска liveCD

4. Задание

Задание этого года -- это как раз такое задание, которое я бы давал студентам в качестве курсовой работы по дисциплине, которая рассматривает основы программирования и алгоритмы. С одной стороны, оно учит большинству умений, необходимых чтобы начать работу в профессиональной группе программистов, а с другой, оно достаточно сложное, чтобы действительно научить чему-то об алгоритмах. Мы также пробовали задание 2004 года -- Муравьев -- оно тоже похоже в этом смысле, но все же больше подходит для курса по компиляторам. В целом, если бы я был преподователем программирования, я бы однозначно использовал материалы всех ICFP соревнований для подобных задач.

5. Чего мне не хватало

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

Вывод:

Это было отличное времяпровождение, которое я бы посоветовал попробовать хотя бы раз в жизни каждому, кто любит программировать.
...И в идеале, конечно, нужно участвовать в составе хорошо подгтовленной команды :)

P.S. Наш сабмишн.

ICFPC '08 Thoughts

2008-07-15T18:31:00.011+03:00

1. Funny things about our team

Our team consisted initially of 4 people:
- 2 guys in St.Petersburg: the guy, who've brought us together -- Yakov Zaytsev (lj:iakovz) -- choosing Erlang, and his friend with C++
- a pythonista in Omsk (Siberia, Russia)
- me with Common Lisp
(As distributed and polyglot, as you can get. Though, we consider Lisp to be our main language).

We had a training session with this roster...

When the contest began, there were (potentially) 6 of us: we were joined a friend of our Omsk teammate and Andrew Baine -- a Common Lisp hacker, who asked in the mailing list to join a Common Lisp team.

...And when we submitted, our final program consisted of 2 modules: a low-level Erlang one for maneuvering by Yakov and my high-level part for direction setting. Besides in the SCM there was a heap of C++ code (not integrated with ours), written by the Omsk guy, who appeared last. (I hadn't submit it for we didn't know, what was it all about)...

2. Communication

As for me, our main problem was communication (and, to some extend, leadership -- there was no outstanding authority among us to resolve all the disagreements): we couldn't agree on the division of tasks, so everyone virtually did, what he wanted, except for us with Yakov. Andrew tried to participate, but didn't succeed because of poor communication and big time difference, I think. We were Russian-speaking and prepared together and, moreover, he joined, when we've being already far in the discussion late at night. So, we didn't have enough time, to get him involved in the beginning, and on the next day it was even harder to start for him.

But with our pair it was also a funny story with communication: on the final evening we debugged Yakov's part in a somewhat "distributed" manner: he made a correction to his module, committed it to SVN, I checked it out, scp'ed to the machine with LiveCD, ran, caught errors popping in the console, wrote them to text file, scp'ed back to my notebook and sent to Yakov over Skype. This debugging session lasted for some 3 hours I think, and actually, I was able to submit some half-working code in the end. :) Such situation was caused by Yakov being at work with poor Internet connection, so he couldn't get hold of liveCD, and me being stupid enough not to think of running the client over the net...

But, from the technical viewpoint, Skype, actually, is as close to perfect as you can get for communication in such distributed groups.

3. Minimum set of tools

you would have needed for participating this year with a geo-distributed team:
* groupchat
* SCM on the net -- GoogleCode worked perfectly for us
* a separate PC to run liveCD

4. Task

This year's task is just a kind of a task to give students for their term paper in the course, that teaches basic programming and algorithms. From one perspective, it would teach you most of the things you need to know to start working in a professional group of programmers, and from the other it's sufficiently advanced to really learn something about algorithms. We've also tried the 2004's task -- Ants -- it's also similar in this sense, but is more suited for the Compiler course. Generally speaking, if I was a programming professor, I would have definitely used the materials from all the ICFP contests as such kinds of tasks.

5. What I lacked

I think, for me the best case would have been to have a team of 4-5 people, situated in at most 2 places (and big time difference between them would've been really helpful), and programming in at most 2 different langs, so that everyone had a supporting person to work on the code together. And, it would've been great if everyone knew both languages.

Conclusion:

It was really a great experience, which I'd recommend to try at least once to anyone, who is fond of programming.
...And it's best, when you are in a well-prepared team :)

P.S. Our submission.