пятница, 12 июня 2009 г.

[comp.prog] Пару слов о метапрограммировании в Ruby

Это кривая отношения Ruby-разработчиков компании ThoughtWorks к метапрограммированию в Ruby. Она взята из рассказа Мартина Фаулера об опыте использования Ruby в проектах ThoughtWorks.

Хорошо видно, как резко происходит переход от непонимания и неумения использовать метапрограммирование к его чрезмерному использованию. А затем, так же резко отношение меняется к нормальному, прагматичному – все хорошо в малых дозах.

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

четверг, 11 июня 2009 г.

[comp.flame] О прогрессе в индустрии разработки ПО...

…или размышления местечкового философа по мотивам RSDN-овских войн.

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

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

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

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

Означает ли это, что в области разработки ПО прогресса вообще нет? Отнюдь. Прогресс есть. Но вот как его оценивать?

Если судить об информационном шуме, который регулярно поднимается вокруг чего-то нового или основательно подзабытого, то может сложиться впечатление, что прогресс существенен. Вот что я могу вспомнить из больших информационных всплесков за последние годы? .Net, Scala, Erlang, Ruby-on-Rails, SOAP и Web-сервисы, RESTful-сервисы, Domain Specific Languages, функциональное программирование и Haskell, multicore-процессоры. Лет пятнадцать назад были какие-то CASE-системы, 4GL, Пролог. Чуть позже – технологии клиент-сервер, потом Java, затем UML, XML, паттерны проектирования и экстремальное программирование.

Ну а если не брать рекламно-информационный шум, то что из всего этого реально сказалось на лично моей продуктивности? А одна очень маленькая и простая идейка из экстремального программирования: автоматизированные unit-тесты. Ну еще за уши можно притянуть более широкое использование константных данных (навеянное функциональным программированием), хотя оно и так в C++ имеет очень давние корни. Итого: за пятнадцать лет профессиональной деятельности программиста (и девятнадцатилетнего увлечения программированием) я столкнулся только с одним(!) реальным проявлением прогресса в области разработки ПО. Все остальное уже было придумано до того, как я вообще написал свою первую программу (ассемблер, языки высокого уровня, грамматики и принципы синтаксического разбора, структурное программирование, метапрограммирование, объектно-ориентированное программирование, функциональное программирование, оптимизированные компиляторы, сборка мусора, виртуальные машины и байт-код, интегрированные среды разработки, системы управления версиями, системы управления базами данных, …)!

Т.е. прогресс в области разработки идет, но идет не очень быстро. Хорошо, что идет. Впрочем, выбора у него все равно нет – хочешь, не хочешь, а идти придется :)

Ну а теперь начинаются, собственно, размышлизмы. Что нужно развивать для того, чтобы производительность программиста повышалась?

Первое направление самое простое. Именно оно и развивается все эти годы. И именно оно обеспечивает прогресс всей отрасли разработки ПО. Это – развитие инструментальных средств разработки. Всего спектра этих средств. Языки программирования (более выразительные и, в тоже время, более однозначные, легко поддающиеся верификации), компиляторы и линкеры, еще более умные IDE (для тех, кому собственных мозгов не хватает), системы тестирования, системы управления версиями и т.д. и т.п. Ни одно из этих средств не способно, на мой взгляд, дать прирост производительности больший 50% на широком спектре задач. Хотя, по совокупности, переход на более продвинутые и удобные инструменты, особенно сильно адаптированные под конкретные задачи, способно повысить “выхлоп” конкретного программиста в разы (но вряд ли на порядок).

А вот второе направление гораздо более важное и сложное. И здесь прогресс нужно выискивать, если не с микроскопом, то уж с увеличительным стеклом точно. Это – совершенствование мыслительных процессов программиста и его мотивации.

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

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

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

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

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

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

Вот как-то так.

Ну и небольшой бонус для тех, кто дочитал до этого места. В RSDN-овском флейме дали ссылку на электронную версию интересной книги Роберта Гласса “Факты и заблуждения профессионального программирования”.

Ну и еще напоследок :) Случайно попал в форум “Компьютерные священные войны” на RSDN. И увидел там совсем свежий, громадных размеров флейм на тему “За что я не люблю С++”. Просто офигел. Годы идут, а ничего не меняется :)) А говорят – прогресс, прогресс… ;)

[life.picture] Earth’s Core?

Здоровская картинка:

Блин, белой завистью завидую людям с такой фантазией!

Взято здесь (там еще много всего).

понедельник, 8 июня 2009 г.

[life] Устроить авиакатастрофу ради страховки?

Никогда не думал, что причиной авиакатастрофы может стать желание получить крупную денежную сумму ради страховки. Тем не менее:

Тем временем, китайская страховая компания PICC Life Insurance Co Ltd готовит выплату в размере $1,4 млн. семье одного из пассажиров разбившегося A330.

Как сообщает издание China Daily, эта компенсация станет крупнейшей в истории страхового бизнеса в КНР. Китайский пассажир в 2008 году приобрел страховку стоимостью 240 тыс. юаней (более $35 тыс.), согласно условиям которой его семье, в случае его смерти, положена сумма в 40 раз превышающая сумму страхового взноса. Издание также сообщает, что для подготовки к рекордной для КНР выплаты создана оперативная группа.

После этой информации пресса стала говорить о том, что катастрофа могла быть спланирована ради получения огромных выплат. Тем более, вспоминают журналисты, такое уже происходило. 21 октября 1999 года второй пилот сознательно разбил Boeing 737-300 авиакомпании Egypt Air, выполняющий рейс Нью-Йорк–Каир. Самолет с 217 пассажирами и членами экипажа на борту упал у побережья штата Массачусетс, в 100 км от острова Нантакет. С борта не поступило ни одного сигнала бедствия, также диспетчерам не пришло не одного автоматического сообщения о неполадках. Приборы показывали, что вся электроника машины работала исправно. Тем не менее, Boeing начал падать с высоты около 10 тыс. метров. За 2,5 км до поверхности океана, выяснили эксперты, лайнер замедлил свое падение, но затем все же рухнул в воду на огромной скорости. Причины катастрофы полностью исправленной машины оставалось загадкой, пока специалистам не удалось вытащить из океана «черные ящики». Расшифровка показала, что самолет потерпел катастрофу по вине второго пилота. Через несколько часов после вылета командир экипажа уступил свое место опытному напарнику – 59-летнему Гамилю эль-Батути. Самописцы записали, как тот 13 раз прочитал традиционную мусульманскую молитву, после чего у лайнера был отключен автопилот и самолет стремительно полетел вниз. Ворвавшийся в кабину командир экипажа попытался спасти машину, но чтобы выровнять высоту у Boeing не хватило мощности турбин. Изучив биографию Батути, следователи выяснили, что его дочь была больна раком кожи, и медики сказали, что для спасения ее жизни необходимо сделать дорогостоящую операцию. Поэтому официальные лица предположили, что Батути намерено погубил самолет, чтобы его семья за счет страховых выплат смогла вылечить дочь. Хотя вскоре следователи выяснили, что пилот имел неплохой заработок и дорогостоящую недвижимость и теоретически мог бы самостоятельно оплатить операцию.

Эксперты также полагают, что в 1997 году командир экипажа погубил рейс SilkAir, который летел из Джакарты в Сингапур. Он исчез с экранов радаров и вскоре после этого упал в реку Муси. Что именно произошло с новой машиной неясно, но наиболее вероятной считается версия о том, что влезший в серьезные долги первый пилот, которому вскоре грозило увольнение, решил свести счеты с жизнью, прихватив с собой 103 пассажиров и членов экипажа.

Афигеть.

[comp;life] Дональд Кнут против патентования ПО

Дональд Кнут направил письмо в Европейскую патентную организацию. В котором изложил свое мнение о том, что программное обеспечение (ПО) не должно быть объектом патентов. Аналогичное письмо он писал в Американское бюро патентов в 1994.

Все таки Дональд Кнут -- очень умный мужик. Жалко, что его в очередной раз не послушают. Впрочем, если история, которую упоминает Кнут, правдива (о том, как пытались законодательно приравнять число Пи к 3, вместо 3.1416…), то границы человеческого маразма настолько широки, что вполне могут вместить и патенты на ПО.