О самородкиных, самоделкиных и сломанных крыльях

Вместо вступления…

Когда я вижу сломанные крылья -
Нет жалости во мне, и неспроста:
Я не люблю насилье и бессилье,
Вот только жаль распятого Христа.

В.Высоцкий

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

Запуск программы не фейерверк – его красоту непосвященному не увидеть…

Когда-то я уже говорил, что работа программиста такова, что оценить ее результаты твои близкие далеко не всегда могут. Хорошо с фейерверком – бабахался с ним две недели, потом позвал всю семью, сказал: “А сейчас…” И все увидели, над чем же ты бабахался две недели.

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

Блин. Сейчас, спустя сутки после запуска до меня доходит, что же мы все-таки сделали. И что значат для нас эти сутки устойчивой работы. Это просто трындец. В хорошем смысле слова :)

Объяснить это жене просто нереально. Это же не фейерверк, красота которого видна всем. Блин.

Самородкины, самоучкины, самоделкины…

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

Вот что меня подвигло на написание этого текста: выступление Susan Boyle на Britain's Got Talent. Не само феерическое выступление, а эффект, который оно произвело…

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

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

Если человек наделен от природы какими-то способностями (в данном случае слухом и голосом) то эти способности должны быть развиты и реализованы вовремя. Чтобы начинать карьеру певца в 17-ть лет, а не в 47. Чтобы иметь временной запас на несколько взлетов и падений до тех пор, пока не исчезнет желание этим заниматься. Ну и пока здоровье позволяет.

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

Странный феномен

В интернете наблюдал несколько раз интересный феномен: если какая-то признанная личность скажет какую-нибудь муть, то обязательно найдется большое количество почитателей этой личности, которые будут сказанную муть защищать. В последнее время наблюдал это в блогах Дмитрия Пучкова (aka Гоблин) и Леонида Каганова. А на днях увидел очередное проявление в RSDN. Там появился опус Криса Касперски о жизни и работе в Южной Корее. На мой взгляд – рядовая запись для заштатного блога (вроде моего). Да еще в стиле и с подробностями, которым не место в публичных форумах (да еще и посвященных программированию).

Но, самое интересное, что данное сообщение набрало удивительно большое количество баллов. А на попытки поинтересоваться “А какого, собственно, x.. здесь появилась эта х....я?” тут же появились защитники с лозунгами “Да все пучком!”. Феномен продемонстрировал свое очередное проявление.

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

Хочу оставаться многостаночником. Пока хочу.

На том же RSDN Василий Старостин опубликовал свое резюме для критической оценки участниками RSDN (заодно я узнал, на какую сумму в Москве мог бы претендовать я сам :), поскольку опыт местами весьма схожий). В одной из рецензий Василию порекомендовали определиться, что для него важнее: позиционировать себя как разработчика, архитектора ПО или менеджера проектов. Наверное, с точки зрения современных больших контор по разработке ПО это правильно, вряд ли в больших шарагах нужны “и швец, и жнец, и на дуде игрец”…

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

Кстати, о языке Curl

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

В первый раз я услышал о языке Curl в 2001-м году. В белорусской компьютерной газетке “Компьютерные вести” промелькнула очень коротенькая заметочка:

Создатель Всемирной Паутины Тим Бернерс-Ли предложил использовать разработанный Дэвидом Кранцем язык Curl (выглядящий как смесь C, Tcl и Lisp) в качестве замены комбинации HTML, Java и JavaScript.

(чуть позже в этой же газете тема нашла свое продолжение – сейчас забавно читать тот прогноз)

Мне захотелось узнать, что же это за Curl такой. Как раз тогда я оказался в EPAm-е и, поэтому, не было проблем с поиском Curl-а в Интернете (нужно отметить, что в начале 2001-го более-менее нормальный доступ в Интернет в Гомеле имели далеко не все организации). Так я нашел небольшой отчетик об экспериментальном языке Curl, который был разработан в MIT. Что-то типа вот этого: Curl: A Gentle Slope Language for the Web. А уже потом – сайт curl.com, с которого загрузил и среду исполнения, и средства разработки Curl.

Не то, чтобы меня впечатлил сам язык. Хотя сама идея о том, чтобы сделать и использовать специально предназначенный язык для Web-приложений вместо жуткой смеси из Java, HTML и JavaScript (с чем я тогда столкнулся в EPAm-е) казалась мне очень здравой. Помнится, я сильно недоумевал, почему же эта идея не выстрелила (это теперь-то я знаю, что совершенство технологии к ее широкой востребованности имеет очень и очень посредственное отношение).

Удивили меня в языке несколько вещей. Во-первых, это был, наверное, первый язык, в котором я увидел встроенные типы данных для различных метрических величин. Например, можно было записать один метр как 1m. И это значение нельзя было присвоить переменной типа Time. Такие вещи были зашиты в язык:

{let a:Angle = 2deg} || 2 degrees
{let c:Distance = 1m} || 1 meter
{let d:Mass = 6g} || 6 grams
{let f:Time = 5s} || 5 seconds

А в документации по Curl была подколка в адрес разработчиков программного обеспечения марсианских спутников – мол, если бы они использовали Curl, одним кратером на Марсе было бы меньше:

Because Curl language quantities include the unit of measurement as part of the value, it is easy for you to work with values that have different units of measurement. For example, you can easily compare quantities such as four centimeters (4cm) and two inches (2in). The translation between measurements systems is transparent. Had a certain government agency used the Curl language, there would probably be one less crater on Mars...

Еще меня впечатлило, что язык разметки и язык программирования были очень хорошо выражены в едином синтаксисе. Более того, оба эти языка были настолько хорошо увязаны друг с другом, и сама концепция Curl была настолько ориентированной на это дело, что разработчик получал возможность определять собственные теги разметки, которые были обычными конструкциями языка. Например, если нужно было объявлять параграф, в котором текст был бы написан красным цветом, можно было либо использовать стандартный тег {paragraph} и параметр color:

{paragraph
  color="red",
  This is a text }

или же определить свой собственный тег {red-font-paragraph} (который бы использовал {paragraph} и color внутри себя):

{define-text-format red-font-paragraph as paragraph with
  color="red"}
{red-font-paragraph This is a text }

Все это было насколько просто и элегантно по сравнению с JSP/JavaScript (с которыми тогда бодались мои коллеги), что это впечатляло. Хотя ничего нового в этом не было – в Lisp-е и TeX-е такие приемы уже давно были повседневностью.

Еще очень меня поразила такая возможность Curl-а, как передача фрагмента кода как параметра в функцию. Помнится, там был какой-то специальный синтаксис для такого рода аргументов. И на этом деле в документации к Curl-у был построен прикольный фокус. Сама документация в среде разработки Curl-а (если не ошибаюсь, называлась она Surge Lab) была выполнена в виде обычных Curl-документов. И местами в этих документах встречались небольшие окошки. Внутри окошек располагался фрагмент программы-примера и кнопочка “Исполнить”. Нажимаешь на кнопочку – пример выполняется и ты видишь его результат:

А когда заглядываешь в исходник документации – видишь там вызов какого-то тега, скажем, {example}, с тем самым кодом примера внутри. Все было просто – в тег {example} код передавался как параметр.

В 2001-м году Curl был во младенческом возрасте. Тогда как раз только образовалась компания Curl Corp. (президентом которой, если мне не изменяет мой склероз, был тот самый Тим Бернерс-Ли). И было понятно, что в ближайшее время Curl не станет заметным игроком. Но я надеялся, что заложенная в него замечательная идея быстро обеспечит ему успех. Однако, все оказалось не так просто. Curl Corp. был продан и в конце-концов им завладели японцы. Которые, надо полагать, хорошо поняли, что на просторах Интернета Curl-у ловить нечего, зато есть неплохие шансы в Интранет-проектах. Судя по тому, что сейчас пишут на сайте Curl-а, разработка внутрикорпоративных информационных систем является основной нишей Curl-а. И, похоже, Curl там постепенно получает признание. Что лично меня радует, т.к. неприятно видеть, как хорошие технические идеи погибают под давлением различных исторических и политических факторов.

В истории с Curl-ом есть и вторая линия романа. В процессе знакомства с языком я больше всего впечатлился тому простому факту, что на самом языке можно было очень удобно и просто описывать данные для программы. Например, тогда мне приходилось делать на XML описания Web-приложения. Т.е. приложение на Java, а конфигурация для его развертывания пишется на XML. Читабельность которого гораздо ниже плинтуса. Вообще, маразм по запихиванию XML везде и всюду заслуживает отдельного разговора… Но вернемся к Curl-у. На нем тоже самое описание выглядело, как мне казалось, на пару порядков проще и компактнее, чем на XML. О чем я и написал (в приступе восторга от собственного открытия) профессору Стиву Уорду (Steve Ward), курировавшему эксперимент с Curl-ом в MIT. И он даже мне ответил: мол да, описание на Curl выглядит симпатичнее XML.

Вот тогда я и попал на крючок Curl-овского синтаксиса. Настолько, что сделал свою маленькую библиотечку для работы с конфигурационными файлами в синтаксисе Curl-а (под названием Cls – Curl Like Syntax). Ее первую версию я написал на C++ в 2001-м. С тех пор практически во всех моих C++ных программах конфиги оформляются в Curl-синтаксисе. Да и не только в C++ных, т.к. я портировал ее и под Ruby – ClsRuby.

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

{send-msg
 {agent aag_3::smpp_smsc::bserver.trx::a_channel }
 {msg msg_imit_deliver }
 {field m_count {uint-stream 1 } }
 {field m_sequence_number {uint-stream 12 } }
 {field m_data
  {byte-stream 0x06 0x00 0x04 0x80 0x81 0x82 0x83 0x03 0x04 0x05 } }
 {field m_source_addr {string-stream "7926XXXXXXX" } }
 {field m_dest_addr {string-stream "YYYYYY" } }
 {field m_esm_class {uint-stream 0x40 } }
}

send
exit

Что интересно. Как программисты, так и не программисты, осваивают Cls-формат очень быстро и без проблем. Либо же я просто не замечаю их жалоб ;)

В общем, для меня Curl стал отличным языком для конфигурационных файлов. Гораздо более удобным и практичным, чем XML, YAML или JSON. Вот какая вот история.

PS. Да, я уже знаю про десятое правило Гринспуна об половинчатой и глючной реализации Lisp-а в любой нетривиальной C/C++ программе. Я думаю, что ко мне и Cls оно не имеет отношения. Хотя, говорят, оно распространяется даже на тех, кто в него не верит :)

Интересное интервью с разработчиком языка Falcon

В рамках серии The A-Z of Programming Languages появилось интересное интервью с Джанкарло Николаи, разработчиком скриптового языка Falcon.

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

Но, пожалуй, больше всего мне понравилось очень здравое и взвешенное описание причин, по которым Николаи решил использовать в реализации Falcon-а C++, а не C:

I like OOP and I like the power of C. When I decided to go C++ for Falcon, I was positive that I would have used C for the low level stuff and C++ classes to shape higher concepts. All the applications I had to script were C++, or could integrate with C++. Also, I was told by a friend of mine working in the gaming industry that Virtual Calls was actually more efficient than switches, and we have lot of them in a scripting language. I tested the thing out for myself, and it turned out that modern processors are performing really well in presence of Virtual Calls, so many of the common problems were usually resolved with complex ifs, and switches could be resolved with Virtual Calls instead.

At the beginning I used also STL, which is usually much more performing than any dynamic typing based library (STL maps are at least 10 per cent faster than Python string dictionaries), but that carried on a relevant problem of interoperability with other programs. Falcon was also meant to be a scripting engine, and applications often have different ideas on which version of the STL they would like to use. Moving STL across DLLs is quite hellish and it's a deathblow to the binary compatibility of C++ modules (already less stable than C module binary compatibility by nature). Also, STL caused the code to grow quite a lot, and a lot more than I wanted; so, I temporarily switched back to dynamic typed structures, which are slower, to be sure to clear the interface across modules from external dependencies.

Recently, having found that new compilers are extremely efficient on the fast path of exception raising (actually faster than a single IF on an error condition), I have introduced exceptions where I had cascades of controls for error being generated deep inside the vm.

In short, Falcon uses C++ where it can bring advantages in term of speed and code readability and maintainability, while still being C-oriented on several low-level aspects.

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

Ну и сам язык, Falcon, после прочтения интервью заинтриговал. Создан с прицелом на высокую скорость исполнения и легкую интеграцию в host-приложение (в том числе, как я понял, удобное отображение внутренних структур host-приложения на объекты Falcon-а). Года полтора назад мне пришлось заниматься добавлением возможности скриптования в свой большой C++ный проект. Тогда после анализа возможности интеграции Ruby (очень медленный), Python (специфический синтаксис) и Lua (очень быстрый) я выбирал между Lua и собственной реализацией языка. Выбрал, в итоге, собственную реализацию, поскольку благодаря Curl-подобному синтаксису там было просто реализовывать предметно-ориентированные языковые конструкции. Хотя, конечно, читабельность if-ов и switch-ей пострадала. Если, со временем, придется сменить собственный велосипед на более традиционный скриптовый язык, то обязательно рассмотрю Falcon.