Пол Грэм: Глава 2. Хакеры и художники (Habr edition)26.05.2016 14:48

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

За 13 лет глава, одноименная с названием книги, затерялась в сети. Для удобства, хочу опубликовать ее, собранную по кусочкам из различных архивов.

Перевод Анастасии Грызуновой, Яны Щекотовой. Приведение текста в порядок — CaptainCrocus. Помощь в публикации — компания Edison.

Оригинал — Hackers and Painters (May 2003)

Закончив аспирантуру по computer science, я пошел на художественный факультет изучать живопись. Многие удивились, что компьютерщик вдруг заинтересовался живописью. Эти люди, видимо, считали, что хакерство и художество — очень разные занятия: хакерство — холодное, точное и методичное, а художество — яростное выражение некого первобытного порыва.

Оба представления неверны. У хакерства и художества масса общего. Из множества различных типов людей хакеры и художники — едва ли не самые похожие.

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

Мне никогда не нравился термин «computer science». Главным образом потому, что такой науки не бывает. «Computer science» — мешок старьевщика, куда история капризно свалила кучу слабо связанных областей науки — получилась какая-то Югославия. На одном полюсе математики, которые зовут свою работу computer science, чтобы получать гранты DARPA. На экваторе — какое-нибудь компьютерным естествознание: скажем, поведение алгоритмов при передаче данных по сетям. А на другом полюсе — хакеры; они пишут интересное ПО, и компьютеры для них — только среда самовыражения, как бетон для архитектора или краска для художника. Все равно что математиков, физиков и архитекторов согнать на один факультет.

Иногда работу хакеров называют «программной инженерией» (software engineering). Этот термин тоже сбивает с толку. С тем же успехом можно назвать инженером архитектора. Между архитектурой и инженерией граница нечеткая, однако она есть. Проходит она между «что» и «как»: архитектор решает, что делать, инженер вычисляет, каким образом.

«Что» и «как» разделять не следует. Пытаясь решить, что делать и не понимая, как, просто напрашиваешься на неприятности. Но безусловно, хакеры не просто умеют решать, как воплотить спецификацию. В своем апогее хакерство спецификации создает — правда, как выясняется, чтобы создать спецификацию, лучше всего ее воплотить.

Не исключено, что однажды «computer science» развалится на составляющие, подобно Югославии. Может, оно и к лучшему. Особенно если в итоге моя родина — хакерство — станет суверенной.

Наверное, с административной точки зрения удобно упаковать все эти разнообразные занятия в один факультет. Только это очень запутывает. Вот еще одна причина моей нелюбви к термину «computer science». Допустим, те, кто на экваторе, занимаются примерно экспериментальной наукой. Но те, что на полюсах, математики и хакеры, к науке вообще-то отношения не имеют.

Математиков это вроде бы не тревожит. Они с радостью ограничиваются теоремами, как и прочие математики с матфака, и вскоре, я думаю, перестают замечать, что на доме, куда они ходят на работу, снаружи висит вывеска «computer science». Но хакерам от этой вывески — одна головная боль. Если хакеры занимаются наукой, значит, им и действовать надо по-научному. И хакеры из университетов и научно-исследовательских лабораторий считают, что должны писать научные труды, а не делать, что хочется — создавать прекрасные программы.

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

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

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

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

Тесты легко проводить, и нет ничего соблазнительнее теста, который вроде как работает.

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

Лучший критерий — время. Со временем прекрасные вещи расцветают, а уродские — теряются в забвении. Увы, времени может потребоваться больше, чем длится человеческая жизнь. Сэмюэл Джонсон говорил, что для формирования писательской репутации требуется сто лет [1]: пока не умрут влиятельные друзья писателя, а затем и их поклонники.

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

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

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

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

К примеру, меня в колледже учили: прежде, чем приблизиться к компьютеру, программу следует целиком записать на бумаге. Оказывается, я программировал не так. Мне нравилось программировать перед компьютером, а не над листом бумаги. Хуже того, я не писал терпеливо всю программу, проверяя, нет ли ошибок, я извергал безнадежно кривой код и постепенно приводил его в норму. Отладка, учили меня, — это последний заход, когда вылавливаешь опечатки и упущения. Я же работал так, что программирование походило на бесконечную отладку.

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

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

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

Ну, разумеется — страница формул впечатляет. (Совет: для особой выразительности вводите греческие переменные.) И потому так соблазнительно заняться проблемами, к которым можно подойти формально, а не над теми, что, скажем так, важны.

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

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

Я сам обнаружил это совсем недавно. Когда Yahoo купила Viaweb, меня спросили, чем я хочу заниматься. Мне бизнес-аспекты никогда особо не нравились, и я сказал, что хочу заниматься одним хакерством. Попав в Yahoo, я обнаружил, что для них это означает воплощать программные продукты, а не создавать. Программисты для них — это такие технологи, которые переводят видения (ну, назовем их так) менеджеров на язык кода.

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

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

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

Войны разработок на новых рынках следует вести там, где еще никто не возвел укреплений. Там можно выиграть по-крупному, создав смелый продукт и устроив так, чтобы его созданием и воплощением занимались одни и те же люди. Microsoft в начале сама так работала. И Apple. И Hewlett Packard. Я подозреваю, так делали все успешные стартапы.

Итак, один из способов создавать прекрасные программы — открыть собственный стартап. Однако тут имеются две проблемы. Во-первых, в стартапе приходится заниматься кучей всего, помимо написания программ. В Viaweb мне, считай, повезло, что я хакерствовал четверть времени.

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

Другая проблема в том, что ПО, приносящее деньги, и ПО, которое интересно писать, особо не пересекаются. Языки программирования писать интересно, и первый продукт Microsoft, в сущности, им и был, но теперь за языки программирования не платят. Если хочешь денег, надо браться за проблемы, которые бесплатно никто не решит, настолько они чудовищны.

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

Думаю, в сфере программного обеспечения проблема решается концепцией, известной почти любому творцу: дневной работой. Фразу ввели музыканты, которые играют по ночам. А вообще это означает, что одна работа за деньги, другая — по любви.

Дневная работа в начале карьеры имелась почти у всех творцов. Этим знамениты художники и писатели. Если повезет, найдешь работу, связанную с твоим настоящим делом. Музыканты нередко работают в музыкальных магазинах. Хакер, работающий над языком программирования или операционной системой, вполне может найти работу, где все это пригодится. [2]

Разумеется, идея не нова. На этом строится все программирование с открытыми исходниками. Я, собственно, хочу сказать, что, может, open source — верная модель: ее правильность независимо подтверждают и все остальные творцы.

Я бы удивился, если б работодатель с неохотой позволял хакерам работать на проектами с открытыми исходниками. В Viaweb мы с неохотой нанимали тех, кто этого не делал. На собеседованиях нас больше всего интересовало, какое ПО программист пишет в свободное время. Если не любишь работу, по-настоящему хорошо работать не сможешь, а если любишь хакерство, неизбежно станешь работать над собственными проектами. [3]

Хакеры — творцы, а не ученые, следовательно, метафору следует искать не в науках, но среди других творцов. Чему еще учит нас живопись?

Во-первых, на примере живописи мы узнаем — проверяем, во всяком случае, — как учиться хакерству. Рисовать учишься, главным образом рисуя. С хакерством — то же самое. Большинство хакеров постигает ремесло вовсе не изучением курсов программирования в колледже, но созданием собственных программ — начиная лет с тринадцати. В школе вы учитесь хакать, только хакая. [4]

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

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

Тот факт, что хакеры учатся в процессе работы, еще раз демонстрирует, как различны хакерство и наука. Ученые не учатся науке в процессе, они проводят лабораторные исследования и формулируют задачи. Ученые начинают с идеальной работы — в том смысле, что пытаются воспроизвести труд, который кто-то сделал за них. А затем они наконец могут делать нечто оригинальное. Хакеры же с самого начала делают нечто оригинальное; просто оно еще плохое. Поэтому хакеры начинают с оригинального и доводят его до совершенства, а ученые начинают с совершенства и доводят до оригинальности.

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

Писатели тоже так делают. Бенджамин Франклин учился писать, резюмируя основные пункты эссе Эддисона и Стила, а затем пытаясь их воспроизвести. Рэймонд Чандлер то же самое проделывал с детективными рассказами.

И хакеры могут учиться программировать, изучая качественные программы, — не только снаружи, исходники тоже. Один из наименее известных плюсов программирования с открытыми исходниками в том, что оно сильно упростило обучение программированию. Когда я учился, нам приходилось в основном изучать примеры из книг. Единственный тогдашний большой кус кода — Unix, но даже он не был открытым исходником.

Большинство тех, кто его читал, изучали незаконные фотокопии в книге Джона Лайонза, написанной в 1977 году, но разрешенной к публикации лишь в 1996-м.

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

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

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

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

Звучит парадоксом, но великое полотно должно быть лучше, чем должно быть. Создавая портрет Джиневры де Бенчи (Национальная галерея), Леонардо поместил за ее головой можжевеловый куст. В нем он тщательно прописал каждый листик. Многие художники полагали, что это просто фон, обрамление для головы. Кто станет пристально изучать куст?

Не таков Леонардо. Он тщательно работал над каждым фрагментом — все равно, будут его тщательно разглядывать или нет. Он был как Майкл Джордан. Неумолим.

Неумолимость — ключ к победе: невидимые детали все вместе становятся видимы. Проходя мимо портрета Джиневры де Бенчи, люди нередко обращают на него внимание, даже не взглянув на табличку с подписью «Леонардо да Винчи». Все невидимые детали вместе образуют нечто потрясающее, словно тысяча едва слышимых голосов, что поют в унисон.

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

Будь хакер простым исполнителем, превращающим спецификацию в код, он бы работал с начала до конца, будто канаву копал. Но если хакер — творец, следует учитывать вдохновение.

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

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

В хакерстве это буквально значит оставлять баги. Мне нравится отладка: во время отладки хакерство получается прямолинейным, каким его все и считают. Есть конкретная проблема, и нужно ее решить. Программа должна делать X. А она делает Y. Что не так? Ты понимаешь, что в итоге победишь. Расслабляет, как стену красить.

Живопись учит нас не только справляться с собственной работой, но и работать вместе. Многие великие работы прошлого — плод трудов десятков рук, хотя на табличке в музее, быть может, значится лишь одно имя. Леонардо учился в мастерской дель Вероккио и написал ангела в «Крещении Христа». Подобные случаи были правилом, а не исключением. Микеланджело считали особо рьяным, поскольку он настаивал на том, чтобы самому написать все фигуры на потолке Сикстинской капеллы.

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

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

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

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

Господи, как я ошибался. Выяснилось, что умение смотреть чужими глазами — практически ключ к успеху. Сопереживание — совершенно не обязательно самопожертвование. Вовсе нет. Если понимаешь чужую точку зрения, совсем не значит, что станешь действовать в чужих интересах. В некоторых ситуациях — на войне, к примеру, — действуешь ровно наоборот [5].

Большинство творцов творят для людей. А чтобы привлечь аудиторию, требуется понять, что ей нужно. Почти на любом живописном полотне — люди, потому что люди интересуют людей.

Быть может, сопереживание — единственное важнейшее различие между хорошим хакером и великим. Некоторые хакеры очень умны, но с точки зрения сопереживания — просто солипсисты. Таким людям трудно создавать великое ПО [6]: они не видят продукт глазами пользователя.

Чтобы проверить, насколько людям дается сопереживание, понаблюдайте, как они разъясняют технические вопросы собеседнику, ничего не смыслящему в технологиях. У всех есть знакомые, вообще-то умные, но комически не способные решить эту задачу. Если спросить их за ужином, что такое язык программирования, они отвечают примерно так: «Ну, высокоуровневый язык — то, что использует компилятор на входе для генерирования объектного кода». Высокоуровневый язык? Компилятор? Объектный код? Человек, не знающий, что такое язык программирования, этих слов уж точно не знает.

Программное обеспечение отчасти само себя объясняет. Поэтому, чтобы написать хорошее ПО, следует понимать, как мало понимает пользователь. Он обратится к ПО без малейшей подготовки, и лучше пусть ПО не обманет пользовательских ожиданий и сделает, что должно, потому что пользователь инструкций читать не станет. Лучшая известная мне система с этой точки зрения — «макинтош» 1985 года. Он делал то, что обычно ПО не делает: просто работал [7].

Исходники тоже должны себя объяснять. Если бы мне требовалось научить людей единственной фразе о программировании, я бы научил их цитате, приведенной в начале «Structure and Interpretation of Computer Programs» [8]:

Программы пишутся, чтобы люди их читали, и лишь иногда — чтобы машины их выполняли.

Сопереживать надо не только пользователям, но и читателям. Это в ваших интересах — вы сами окажетесь одним из них. Немало хакеров сначала писали программы, а спустя полгода выясняли, что понятия не имеют, как эти программы работают. Несколько моих знакомы после таких случаев поклялись никогда больше не писать на Perl [9].

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

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

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

Да, я признаю, что сейчас хакерство — не так круто, как живопись, однако следует помнить, что и живопись во времена расцвета не казалось такой уж крутой.

С некоторой долей уверенности можно утверждать: сейчас — дни расцвета хакерства. В большинстве других областей великие работы были созданы раньше. Живопись, созданная в период между 1430 и 1500 гг., остается непревзойденной по сей день. Шекспир появился, когда только возник профессиональный театр; Шекспир вознес его на такие вершины, что любой драматург по сей день живет в его тени. Альбрехт Дюрер сделал то же самое с гравюрами, а Джейн Остин — с романистикой.

Это повторяется снова и снова. Новая среда возникает и захватывает людей так, что те за первую пару поколений выжимают из ее возможностей почти все. Судя по всему, хакерство сейчас находится как раз в этой фазе.

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

Примечания

[1] Джонсон написал в предисловии к своему изданию Шекспира:
«Он уже давно пережил свой век, период, который обычно отмерен для оценки художественной ценности книги. Какие бы преимущества перед ним ни открывались от частных упоминаний, местных традиций или временных мнений, все они уже утрачены за много лет до этого; и каждая радостная тема или повод для печали, которые ему предоставил искусственный образ жизни, сейчас лишь затемняют сцены, которые они когда-то освещали. Влияние поддержки и соперничества закончилось; его дружественные и враждебные отношения канули в небытие; его работы не поддерживают ничье аргументированное мнение, и не подпитывают распри с обличительными речами; они не могут ни потворствовать тщеславию, ни потакать озлобленности, а их читают исключительно ради получения удовольствия и, следовательно, превозносят только если удовольствие получено…»

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

[3] Microsoft мешает работникам вносить свой вклад в open source проекты, даже в их свободное время. Но сейчас так много отличных специалистов работает над open source проектами, что основным результатом такой политики может быть то, что им станет сложнее нанимать первоклассных программистов.

[4] То, что вы узнаете о программировании в колледже аналогично тому, что вы узнаете о книгах или одежде: да у вас в школе вкус абсолютно отсутствовал.

[5] Вот пример прикладного сопереживания. Если мы в Viaweb не могли выбрать из двух вариантов, мы спрашивали себя, какой из них больше расстроит конкурентов. Однажды конкурент добавил в свой продукт опцию — в сущности, бесполезную, но то была одна из немногих опций, которые не добавили мы, и в профессиональной прессе о конкуренте много писали. Можно было объяснять, что опция бесполезна, но мы решили, что конкурент больше расстроится, если мы сами ее внедрим. В общем, мы написали свою версию в тот же вечер.

[6] Кроме текстовых редакторов и компиляторов. Для них хакерам сопереживание не требуется, потому что типичные пользователи — сами хакеры.

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

[8] Abelson, Harold, and Gerald Sussman, Structure and Interpretation of Computer Programs, MITPress, 1985.

[9] Упростить чтение программ не означает забить их комментариями. Я бы развил мысль Эбелсона и Сассмена: языки программирования должны создаваться для выражения алгоритмов и лишь изредка — чтобы сообщать компьютерам, как их выполнять. Хороший язык программирования объясняет ПО лучше английского. Комментарии нужны лишь в том случае, если в программе какой-то ляп, про который нужно читателю сообщить, — как на дороге, где стрелки висят лишь на резких поворотах.

© Habrahabr.ru