суббота, 17 декабря 2011 г.

[prog] Где прозвучала фраза avoid success at any cost?

Прочитав вот этот комментарий, в частности следующие предложения:

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

попытался вспомнить, где именно я видел высказывание “avoid success at any cost” по отношению к Хаскелю.

Если не ошибаюсь, вот в этой презентации Саймона Пейтона Джонеса – Wearing the hair shirt. A retrospective on Haskell.

[life] Хорошая иллюстрация способностей настоящего руководителя

Неожиданно для себя нашел ее в книжице Петра Подгородецкого “Машина” с евреями. Книжица, кстати, редкая мура, я даже дочитать ее не смог. Но вот две нижеследующие цитаты впечатлили. Обе относятся к рассказу о способностях Иосифа Давыдовича Кобзона.

Первая про организованность:

Иосиф Давыдович — фантастический организатор. У него феноменальная память, которой он умело и профессионально пользуется. Надо видеть, как утром он, еще лежа в постели, вызывает своего директора и дает ему задания на день, примерно с полчаса. Директор стоит с блокнотом и ручкой, а Кобзон диктует: «Итак, сегодня третье ноября. Необходимо от моего имени послать букет цветов (красные розы) такой-то такой-то в день сороковин ее супруга. Поздравить телефонным звонком (пусть меня соединят) такого-то с днем рождения. Забрать два концертных костюма из химчистки. Перенести массаж с 16 на 16.30. Позвонить от моего имени на „Мосфильм" и извиниться за то, что не приму участия в вечере в Доме кино. Соединить меня с Юрием Михайловичем Лужковым — я подтвержу свое участие в мероприятии, которое он организует. Послать такой-то два билета на концерт в „России" с моей визиткой и букетом цветов. Заказать обед в ресторане „Метрополь" на три лица». И далее в том же духе. Без пауз и перерывов, разве что сока глотнет, и все.

Лично я придерживаюсь мнения, что одно из главных требований к руководителю – это умение справляться с потоком разнообразных и разнокалиберных дел. Вспомогательные средства вроде ежедневников, TODO-списков, будильников и напоминалок – это всего лишь вспомогательные средства. Если ты сам не в состоянии запомнить, что тебе нужно сделать, то поможет разве что тотальное внесение всех предстоящих дел в электронный ежедневник, да еще с напоминалками на каждое дело в режиме snooze ;)

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

И еще одна цитата о способности переключать контексты:

У великого мастера мозги работали одновременно как бы в двух режимах. Помню, как во время очередной поездки в Афганистан мы работали в армейском госпитале, где лечились самые тяжелые раненые. Представляете, сидят, лежат молодые пацаны, кто без рук, кто без ног, кто вообще как обрубок. У кого-то глаз нет… В общем, без слез смотреть в зал нельзя. Мы играем, а сами ревем. А Кобзон поет какую-то песню про маму, про Родину. У него течет огромная слезища. И тут, во время проигрыша, он совершенно спокойно оборачивается к кому-то из музыкантов и спрашивает: «А какой сейчас курс чека в Москве?» То есть с одной стороны — артистизм, неподдельные эмоции, а с другой — прагматичность, холодный расчет, так необходимый в бизнесе. Я не знаю, хорошо это или плохо, кто-то назовет это профессиональным цинизмом, какой бывает у опытных врачей. Но главное — чтобы этот цинизм никогда не перевешивал. Вот этому равновесию у Кобзона надо учиться. У него все всегда было под контролем, и зрители в зале никогда не чувствовали, что у певца в голове работает мощный компьютер, который может решать совершенно иные проблемы.

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

[life.nature.photo] Паук в камуфляже

Название паука Caerostris sexcuspidata.

Снимок найден здесь.

пятница, 16 декабря 2011 г.

[prog] Ввязался в спор о краткости имен идентификаторов

Вот в этот: Наименования переменных.

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

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

const size_t expected_bytes = calculate_expected_message_size();
const size_t bytes_read = load_data_from_stream( expected_bytes );
if( bytes_read != expected_bytes )
   ...;
binary_buffer_ptr_t whole_message = extract_raw_message();
binary_buffer_ptr_t message_payload =
   check_and_remove_protocol_headers( whole_message );

писать так:

const size_t e = calculate_expected_message_size();
const size_t r = load_data_from_stream( e );
if( r != e )
   ...;
binary_buffer_ptr_t m = extract_raw_message();
binary_buffer_ptr_t p = check_and_remove_protocol_headers( m );

Чего лично я не приемлю и за что “бью по рукам”. Ничего не поделать, учился у хороших учителей, давно, когда в образовании использовался Паскаль и книжки Вирта. А место, даже на дискетах, под исходные тексты экономить уже было не принято. Кстати, мониторы тогда были еще алфавитно-цифровые, с разрешением 80x25 знаков, так что текста на экране было намного меньше, чем сейчас. И IDE с автодополнением, подсказками и нафигацией по коду не было. Зато хороший стиль кода очень ценился.

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

Допустим, нам нужно сформировать SQL-ный select, где количество столбцов определяется внешними параметрами. Как это может выглядеть в императивном стиле с переменными? Как-то вот так:

std::string select_statement = "select id";
if( need_creation_time )
   select_statement += ", ctime";
if( need_modificaton_time )
   select_statement += ", mtime";
...
select_statement += " from my_table where ...";

Переменная одна, название ей дано длинное. А вот если мы напишем что-то подобное в функциональном стиле с иммутабельными сущностями, то получится что-то вроде:

s1 = "select id";
s2 = if( need_creation_time ) s1 + ", ctime" else s1;
s3 = if( need_modificaton_time ) s2 + ", mtime" else s2;
...
select_statement = sN + " from my_table where ...";

Т.е. если давать сущностям s1…sN какие-то вменяемые названия (вроде statement_with_opt_ctime, statement_with_opt_mtime и т.д.), то элементарно задолбешься выдумывать промежуточные названия. Да и смысла большого они нести не будут. Хотя, по моему мнению, обилие сущностей вида s1, s2 и т.д., не есть хорошо. Страшно далеко ФП от народа железа ;)

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

PS. Почему я так резко прореагировал на эту тему? Потому, что на днях случайно была найдена серьезная ошибка. В одной из версий программы один разработчик заменил код:

stream << range.m_left
   << range.m_right
   << range.m_client
   << range.m_priority;

на код:

// Если диапазон оказался слишком большим, то нужно его сузить
// принудительно передвинув правую границу.
id_t right = range.m_right;
if( range.m_right > range.m_left + package_size )
   right = range.m_left + package_size;
stream << range.m_left
   << right
   << range.m_client
   << range.m_priority;

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

// Если диапазон оказался слишком большим, то нужно его сузить
// принудительно передвинув правую границу.
id_t right = range.m_right;
if( range.m_right > range.m_left + package_size )
   right = range.m_left + package_size;
stream << range.m_left
   << range.m_right
   << range.m_client
   << range.m_priority;

Понятное дело, что ошибка обнаружилась далеко не сразу и случайно. А уж если бы вместо range, right, m_left, m_right использовались бы имена вида R, L, R1, R2 и т.д., то я бы только функциональщикам и пожелал бы сопровождать такой код.

PPS. Еще ссылки:
- заметка в блоге lionet на какое-то исследование понятности написанного в разном стиле кода;
- очень интересная реакция на это исследование в блоге sleepy_drago;
- скептическая точка зрения Бертранда Мейера на околопрограммистские исследования (на английском).

вторник, 13 декабря 2011 г.

[life.sport.darts] Дартс и алкоголь (читая воспоминания Эрика Бристоу)

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

Потому-то их так трудно обыграть ;) Поскольку в разумных количествах алкоголь в дартсе является допингом. Меньше волнуешься, меньше думаешь, бросаешь на инстинктах, поэтому-то и попадаешь туда, куда нужно. Я и сам в изрядном подпитии (правда уже после официального турнира) на Дартс-Весне 2011 в коммерческом парном турнире умудрился сделать два 180 в матче до двух побед – результат, который мне пока не удалось превзойти :)

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

В этой связи интересно было узнать, что традиция пьянства в дартсе имеет давние корни. Очень красочно это описывает в своих воспоминаниях Эрик Бристоу – пятикратный чемпион мира, легенда дартса, под именем которого прошла целая эпоха в 1980-х годах. Всем интересующимся рекомендую пятую главу его автобиографии, опубликованную недавно на dartslife.ru. Занимательное чтиво.