Статьи

Бикультурализм

Перевод интересной статьи Джоэля Спольски Biculturalism

В настоящее время, ОС Windows и Unix конструктивно имеют много общего. Они обе поддерживают схожие модельные представления, начиная от командной строки и заканчивая GUI-интерфейсом для web-сервера; они построены вокруг виртуально общего букета системных ресурсов: от схожих файловых систем до памяти, сокетов, процессов и потоков. Существует небольшой набор сервисов у каждой ОС, которые ограничивают программиста при создании приложений.

Остаются только культурные различия. Да, мы все употребляем пищу, но вон там едят сырую рыбу с рисом, используя деревянные палочки, а тут – бутерброд с колбасой. Культурные различия не приводят к тому, что в американский желудок не может попасть суши, а в японский – БигМак, это так же не означает, что в Америке мало людей, едящих суши или в Японии мало людей, употребляющих гамбургеры, но это приводит к тому, что у американцев, впервые прибывших в Токио, возникает сильное ощущение, что это странное место, черт!, и никакие философские измышления о том, что изнутри мы все одинаковые, мы все любим, работаем, поем и умираем, не изменят того факта, что американец и японец будут неуютно чувствовать себя в ванной друг друга.

Какие же культурные различия у программистов в Unix и Windows? Есть много деталей и тонкостей, но, в основном, все сводится к одной вещи: у Unix-культуры в почете код, написанный для другого программиста, в то время как в Windows-культуре – код, написанный для непрограммиста.

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

Эрик С. Рэймонд (Eric S. Raymond) недавно написал толстую книгу о программировании в Unix: «Искусство Unix-программирования» («The Art of UNIX Programming»), в которой детально рассказывает о культуре программирования. Вы можете купить эту книгу и прочесть ее в твердой копии, или, если политика Рэймонда слишком анти-идиотична для вас, чтобы обсуждать вопрос выплаты ему денег, можете прочесть ее он-лайн бесплатно и будьте спокойны, он не получит ни копейки за свой тяжелый труд.

Давайте рассмотрим маленький пример. В культуре Unix-программирования наибольшим пиететом пользуются программы, вызываемые из командной строки, поведение которых полностью определяется набором аргументов, а вывод подобной программы может быть легко сохранен в виде форматированного, понятного машине текста. Такие программы в почете, поскольку они могут легко быть включены программистами в другие программы или большие программные продукты. Иллюстрацией может послужить ключевая особенность Unix, которую Рэймонд назвал «молчание – золото», суть ее в том, что программа, успешно выполнив задание, не должна ничего не выводить на экран. Не важно, что вы сделали: набрали 300-символьную команду для создания файловой системы, или собрали и проинсталлировали ПО, или послали пилотируемую ракету на Луну. Если все прошло успешно, необходимо просто ничего не выводить на экран. Приглашение командной строки обозначит, что результат положительный.

Это важная особенность Unix-культуры, поскольку вы программируете для других программистов. Как говорит Рэймонд: «Болтливые программы не дружат с другими программами». В Windows, наоборот, вы пишете для тетушки Марго, которая в праве считать, что программа, ничего не выводящая на экран в случае успеха, будет хуже другой программы, ничего не выводящей на экран в случае ошибки или неправильного запроса.

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

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

Представьте, что вы наняли Unix-программиста и Windows-программиста и дали им задание написать приложение для конечного пользователя. Unix-программист создаст командную строку или управляемое текстовыми командами ядро, и, возможно, погодя, построит GUI, для управления ядром. Таким образом, основные операции с приложением будут доступны другим программистам, вызвавшим его из командной строки и получившим ответ в виде простого текста. Windows-программист начнет с GUI и, возможно, погодя, добавит скриптовый язык для автоматизации работы с интерфейсом. Это приемлемо для культуры, в которой 99,999% пользователей не являются программистами ни в каком виде и не пытаются ими стать.

Есть одна показательная группа Windows-программистов, которые в основном пишут для других программистов: сами разработчики Windows из Microsoft. Они делают это создавая, API на С, которые обеспечивают функциональность, а затем создают приложения с GUI-интерфейсом, которые вызывают эти API. Все, что вы можете сделать в пользовательском интерфейсе Windows, может быть сделано программно в любом подходящем языке программирования. Например, Microsoft Internet Explorer представляет собой миниатюрную, объемом 89кб, программку; вокруг нее надстроено более дюжины мощных компонент, которые свободно доступны изощренным Windows-программистам, и которые создавались, чтобы быть гибкими и мощными. К сожалению, поскольку программисты не имеют доступа к исходному коду подобных компонент, они могут использовать только те возможности, которые разрешены и предусмотрены разработчиками из Microsoft, что не всегда срабатывает. Иногда это баги, иногда – ошибки оформления вызова API, но это трудно отследить, не имея исходного кода. Стремление Unix-культуры к открытому исходному коду делает разработку приложений более удобной. Любой разработчик Windows ПО может рассказать о том, как он четыре дня провел в дебаге, т.к., скажем, он считал, что объем памяти, возвращаемый LocalSize, должен быть таким же, как и полученный ранее с помощью LocalAlloc, или другой подобный баг, который мог быть найден за 10 минут, имей он под рукой исходный код этой библиотеки. Рэймонд придумал замечательную историю (перевод этой истории см. ниже) для иллюстрации подобной ситуации, те, кто хоть раз работал с бинарными библиотеками, подтвердят, что эта история – правда.

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

Давайте обратим внимание еще на одно культурное различие. Рэймонд говорит: «Классическая документация Unix написана кратко, но полно… Это изложение подразумевает, что читатель способен сделать очевидные выводы из написанного, но явно не выраженного, он уверен в себе и доверяет своей дедукции. Читайте каждое слово внимательно, поскольку повторять никто не станет». О да, мне кажется, что он учит молодых программистов писать еще более невероятные маны.

С конечными пользователями вы далеко на этом не уедите. Рэймонд назвал это «сверхупрощенное снисхождение» («oversimplifying condescension»), но Windows-культура принимает, что конечные пользователи не любят читать, и если они собрались прочесть вашу документацию, они ограничатся только возможным минимумом, таким образом, вам необходимо объяснять вещи помногу раз… действительно, признаком хорошего файла справки в Windows является то, что любой раздел может быть прочитан и понят без изучения остальных.

Как мы получили такие разные стремления? Вот еще одна причина, делающая книгу Рэймонда хорошей: он подробно рассказывает об истории и эволюции Unix и переносит новых программистов назад в 1969 год сквозь всю ее богатую историю. В то время, когда Unix создавалась и формировалась ее культурная основа, не было конечных пользователей. Компьютеры были дорогими, машинное время было дорогим, и обучение работы с компьютером фактически было обучением программировать. Поэтому нет ничего удивительного в том, что эта культура поощряет развитие вещей, полезных для других программистов. Windows же, наоборот, создавалась с единственной целью: продать столько копий, сколько только можно. Миллионмиллиардов копий. «Компьютер на каждом рабочем месте, в каждом доме» ставшее явной целью команды создателей Windows, определило ее стиль и основные ценности. Легкость использования непрограммистами – единственная возможность поместить ее на каждый стол в каждом доме, и поэтому «практичность прежде всего» (usability uber alles) стало культурной нормой. Программисты как потребители отошли на второй план.

Эта культурная пропасть настолько большая, что Unix даже никогда не пыталась завоевать десктопы пользователей. Тетушка Марго не может использовать Unix, и периодические попытки сделать Unix дружелюбным для пользователя настолько, чтобы тетушка Марго смогла им пользоваться – проваливаются, исключительно потому, что они предпринимались программистами, воспитанными Unix-культурой. Например, Unix придерживается правила разделения образа действия от способа действия (separating policy from mechanism), которое исторически происходит от разработчиков X. Это ведет прямо к пропасти между двумя интерфейсами; никто не согласен со всеми деталями пользовательского интерфейса, но все полагают, что это нормально, а тетушка Марго полагает, что очень даже ненормально использовать разные интерфейсы для работы с буфером в разных программах. Итак, уже 20 лет как разработчики Unix пытаются создать хороший пользовательский интерфейс для своих систем, но, в то же время, CEO крупнейшего поставщика Linux говорит людям, что домашние пользователи должны использовать Windows. Я слышал, экономисты говорят, что Силиконовую Долину невозможно воссоздать, скажем, во Франции, поскольку французская культура настолько жестко отреагирует на фиаско, что предприниматели даже не рискнут начать подобное предприятие. Возможно, это справедливо и для Linux: она никогда не будет ОС для десктопов, т.к. культурное наследие будет препятствовать этому. ОС Х доказала: Apple все же создала Unix для тетушки Марго, но только благодаря тому, что инженеры и управляющие Apple, хорошо знакомы с культурой конечного пользователя (что я бы назвал «Windows-культурой», хотя, исторически, это заслуга Apple). Они отвергли программистско-центристский фундамент Unix-культуры. Они даже переименовали системные директории, – какая ересь! – для использования обычных английских слов «application» и «library» вместо «bin» и «lib».

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

Существует слишком много монокультурных программистов, которые подобно американскому ребенку, никогда не покидавшему городок Сент-Пол в Миннесоте, не чувствуют разницы между своим культурным наследием и общечеловеческими ценностями. Я встречал слишком много Unix-программистов, которые с презрением относятся к программированию в Windows, считая, что Windows – это язычество и вообще, глупо. Рэймонд сам часто попадается в эту ловушку: пренебрежительное отношение к чужой культуре без понимания истоков ее происхождения. Гораздо сложнее отыскать такую нетерпимость в среде Windows-программистов, они, в целом, ориентированы на решение конкретной задачи и не настолько заидеологизированны. И, в конце концов, Windows-программисты признают недочеты своей культуры и смотрят на это прагматично: «Послушайте, если вы хотите продать текстовый редактор большому количеству людей, он должен работать на их компьютерах, и если для этого нам придется использовать Дьявольский Реестр вместо замечательных ~/.rc файлов для сохранения настроек, так оно и будет». Неопровержимый факт, что мир Unix наполнен самосовершенным культурным превосходством, «адвокатурой» и палка-точка сектантами с блудной кармой, в то время как мир Windows более практичен («да все что угодно, мне тут жить надо»), берет свое начало в культуре, чувствующей себя в долгой осаде, не имеющей возможность вырваться из серверной кельи и рынка гуру и попасть на мэйнстримный десктоп. Это «высокомерие слабого» – самый большой изъян «Искусства Unix-программирования», но это, по-настоящему, не промах: в целом, книга полна невероятно интересных взглядов на множество аспектов программирования, что я просто буду пропускать мимо ушей идеологические разглагольствования, т.к. в этой книге есть чему поучиться. Более того, я рекомендую эту книгу разработчикам всех культур и платформ, преследующим любые цели, ведь большинство описанных там идей – универсальны. Когда Рэймонд обращает внимание, что CSV формат хуже формата /etc/passwd, он пытается выделить Unix на фоне Windows, но знаете, что? Он прав. /etc/passwd легче обработать, чем CSV-файл, и, если вы прочтете эту книгу, вы узнаете, почему, и вы станете лучшим программистом.

Эрик С. Рэймонд.

История Дж. Рэндома Нового. (J. Random Newbie).

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

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

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

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

Новый несколько переживал по поводу этой даты завершения проекта. Возможно, у него недоставало опыта, но он читал Дилберта (Dilbert) и слышал пару историй от опытных программистов. Он знал – руководство имеет тенденцию, которую один обозвал эвфемизмом «агрессивный» график. Возможно, он читал «Марш смерти» Эда Йордана (Ed Yourdon's Death March), который в далеком 1996 году заметил, что большинство проектов имеют бюджет времени и средств на 50% меньший, чем требуется, и ситуация только ухудшается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии и дополнения - почтой