Прочитав вот этот комментарий, в частности следующие предложения:
Если хаскель начнут изучать из-за профита или из-за желания стать каким-то там маргиналом, то пиши пропало. Вместо нормальных программистов будут работники за еду.
попытался вспомнить, где именно я видел высказывание “avoid success at any cost” по отношению к Хаскелю.
Если не ошибаюсь, вот в этой презентации Саймона Пейтона Джонеса – Wearing the hair shirt. A retrospective on Haskell.
Неожиданно для себя нашел ее в книжице Петра Подгородецкого “Машина” с евреями. Книжица, кстати, редкая мура, я даже дочитать ее не смог. Но вот две нижеследующие цитаты впечатлили. Обе относятся к рассказу о способностях Иосифа Давыдовича Кобзона.
Первая про организованность:
Иосиф Давыдович — фантастический организатор. У него феноменальная память, которой он умело и профессионально пользуется. Надо видеть, как утром он, еще лежа в постели, вызывает своего директора и дает ему задания на день, примерно с полчаса. Директор стоит с блокнотом и ручкой, а Кобзон диктует: «Итак, сегодня третье ноября. Необходимо от моего имени послать букет цветов (красные розы) такой-то такой-то в день сороковин ее супруга. Поздравить телефонным звонком (пусть меня соединят) такого-то с днем рождения. Забрать два концертных костюма из химчистки. Перенести массаж с 16 на 16.30. Позвонить от моего имени на „Мосфильм" и извиниться за то, что не приму участия в вечере в Доме кино. Соединить меня с Юрием Михайловичем Лужковым — я подтвержу свое участие в мероприятии, которое он организует. Послать такой-то два билета на концерт в „России" с моей визиткой и букетом цветов. Заказать обед в ресторане „Метрополь" на три лица». И далее в том же духе. Без пауз и перерывов, разве что сока глотнет, и все.
Лично я придерживаюсь мнения, что одно из главных требований к руководителю – это умение справляться с потоком разнообразных и разнокалиберных дел. Вспомогательные средства вроде ежедневников, TODO-списков, будильников и напоминалок – это всего лишь вспомогательные средства. Если ты сам не в состоянии запомнить, что тебе нужно сделать, то поможет разве что тотальное внесение всех предстоящих дел в электронный ежедневник, да еще с напоминалками на каждое дело в режиме snooze ;)
Тут, кстати, уместно вспомнить случай, который произошел со мной совсем недавно. Сидел у коллеги в кабинете и перед уходом сказал: “Хорошо, сейчас вернусь к себе и отошлю всем письмо.” Но пока шел к себе напрочь об этом забыл. Вспомнил случайно где-то через час, в течении которого с головой был погружен в какую-то техническую проблему, о которой задумался еще в коридоре, пока шел от коллеги в свою комнату.
И еще одна цитата о способности переключать контексты:
У великого мастера мозги работали одновременно как бы в двух режимах. Помню, как во время очередной поездки в Афганистан мы работали в армейском госпитале, где лечились самые тяжелые раненые. Представляете, сидят, лежат молодые пацаны, кто без рук, кто без ног, кто вообще как обрубок. У кого-то глаз нет… В общем, без слез смотреть в зал нельзя. Мы играем, а сами ревем. А Кобзон поет какую-то песню про маму, про Родину. У него течет огромная слезища. И тут, во время проигрыша, он совершенно спокойно оборачивается к кому-то из музыкантов и спрашивает: «А какой сейчас курс чека в Москве?» То есть с одной стороны — артистизм, неподдельные эмоции, а с другой — прагматичность, холодный расчет, так необходимый в бизнесе. Я не знаю, хорошо это или плохо, кто-то назовет это профессиональным цинизмом, какой бывает у опытных врачей. Но главное — чтобы этот цинизм никогда не перевешивал. Вот этому равновесию у Кобзона надо учиться. У него все всегда было под контролем, и зрители в зале никогда не чувствовали, что у певца в голове работает мощный компьютер, который может решать совершенно иные проблемы.
Тему переключения я когда-то уже затрагивал. И недавно вновь убедился в том, насколько она важна: пришел на совещание оторвавшись от процесса отладки, слушал что-то в пол уха, а когда дело перешло к вопросам, которые можно было бы задать начальству, то тупо ничего не вспомнил. Потому, что в голове крутились только детали отладочной печати из последнего тестового прогона программы.
Вот в этот: Наименования переменных.
Впечатления, как это обычно бывает после общения с евангелистами-функциональщиками, неважные. Как будто общаешься с подвыпившими людьми – думая о чем-то своем они высказывают суждения, которые, по их мнению, должны быть очевидны всем и каждому. Что совсем не так и для того, чтобы понять контекст высказывания нужно приложить немало усилий.
Когда я слышу разговоры о том, что идентификаторы (имена констант или переменных) должны быть короткими, я инстинктивно считаю, что люди предлагают вместо:
| 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;
- скептическая точка зрения Бертранда Мейера на околопрограммистские исследования (на английском).
Когда я первый раз год назад приехал на соревнования по дартс в Минск, то ближе к вечеру с удивлением обнаружил, что от многих игроков начинает изрядно попахивать. Потом обнаружилось, что потребление алкоголя до, во время и, особенно, после турниров – это в порядке вещей. Некоторые игроки прямо с утра начинают разминаться пивком и продолжают делать это в течении всего дня.
Потому-то их так трудно обыграть ;) Поскольку в разумных количествах алкоголь в дартсе является допингом. Меньше волнуешься, меньше думаешь, бросаешь на инстинктах, поэтому-то и попадаешь туда, куда нужно. Я и сам в изрядном подпитии (правда уже после официального турнира) на Дартс-Весне 2011 в коммерческом парном турнире умудрился сделать два 180 в матче до двух побед – результат, который мне пока не удалось превзойти :)
Тем не менее лично я, как и еще (к счастью) многие спортсмены, в официальных соревнованиях играю трезвым. Так честнее, интереснее. И, главное, участвую я в турнирах для того, чтобы проверить собственный уровень. А с допингом это уже не проверка, а обман самого себя. Поэтому-то я не очень хорошо отношусь к пьянству во время соревнований. Особенно, когда это приобретает такие масштабы, как на Belarus Open 2011.
В этой связи интересно было узнать, что традиция пьянства в дартсе имеет давние корни. Очень красочно это описывает в своих воспоминаниях Эрик Бристоу – пятикратный чемпион мира, легенда дартса, под именем которого прошла целая эпоха в 1980-х годах. Всем интересующимся рекомендую пятую главу его автобиографии, опубликованную недавно на dartslife.ru. Занимательное чтиво.
