Hackers and Painters

Май 2003

(Это эссе основано на гостевой лекции в Harvard, в которую вошёл более ранний доклад в Northeastern.)

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

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

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

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

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

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

Возможно, однажды «computer science», как Югославия, распадётся на составные части. И это могло бы быть к лучшему. Особенно если бы это означало независимость для моей родной земли — хакерства.

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

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

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

К сожалению, красивые вещи не всегда становятся лучшим предметом для статей. Во-первых, исследование должно быть оригинальным — а как знает всякий, кто писал кандидатскую диссертацию, верный способ убедиться, что осваиваешь нетронутую территорию, — застолбить участок, который никому не нужен. Во-вторых, исследование должно быть основательным — а неуклюжие системы дают более содержательные статьи, потому что можно написать о препятствиях, которые приходится преодолевать, чтобы хоть что-то заработало. Ничто не порождает столь сочных проблем, как старт с неверных предпосылок. Бо́льшая часть AI — пример этого правила: если предположить, что знание можно представить в виде списка выражений логики предикатов, аргументы которых обозначают абстрактные понятия, то у вас будет масса статей о том, как заставить это работать. Как любил говорить Ricky Ricardo: «Lucy, you got a lot of explaining to do».

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

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

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

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

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

Есть вещи похуже, чем непонимание твоей работы окружающими. Бо́льшая опасность в том, что ты сам неправильно поймёшь свою работу. За идеями ты отправляешься в смежные области. И если ты оказался на кафедре computer science, возникает естественный соблазн поверить, например, что хакерство — это прикладная версия того, чего теоретическая computer science является теорией. Все годы в аспирантуре меня не покидало неуютное ощущение где-то в глубине сознания, что мне следовало бы лучше знать теорию и что с моей стороны было большим упущением забыть всё это в течение трёх недель после выпускного экзамена.

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

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

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

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

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

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

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

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

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

Сам я обнаружил это совсем недавно. Когда Yahoo купила Viaweb, меня спросили, чем я хочу заниматься. Бизнес-сторона мне никогда особо не нравилась, и я сказал, что просто хочу хакать. Придя в Yahoo, я обнаружил, что для них хакерство означало реализацию софта, а не его проектирование. Программистов считали техниками, переводящими в код видения (если это подходящее слово) продакт-менеджеров.

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

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

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

Место, где надо вести design-войны, — это новые рынки, где ещё никто не успел возвести укреплений. Именно там можно крупно выиграть, взяв смелый подход к дизайну и поручив одним и тем же людям и проектировать, и реализовывать продукт. Сама Microsoft так и поступила на старте. Так же поступила Apple. И Hewlett-Packard. Подозреваю, что так поступал почти каждый успешный стартап.

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

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

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

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

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

Когда я говорю, что ответ для хакеров — иметь подработку, а над красивым софтом работать на стороне, я не выдаю это за новую идею. Именно в этом и состоит весь смысл open-source-хакерства. Я лишь говорю, что open-source — вероятно, правильная модель, потому что её независимо подтвердили все остальные создатели.

Мне кажется удивительным, что какой-нибудь работодатель может неохотно отпускать хакеров работать над open-source-проектами. В Viaweb мы бы неохотно брали на работу того, кто этого не делает. Когда мы собеседовали программистов, главное, что нас интересовало, — какой софт они пишут в свободное время. Нельзя сделать что-то по-настоящему хорошо, если ты этого не любишь, а если ты любишь хакать, ты неизбежно будешь работать над собственными проектами. [2]

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

Одно, чему мы можем научиться — или хотя бы что подтвердить — на примере живописи, это то, как учиться хакать. Живописи учатся в основном через саму живопись. То же и с хакерством. Большинство хакеров учатся хакать не на курсах программирования в колледже. Они учатся хакать, написав собственные программы в тринадцать лет. Даже на занятиях в колледже хакерству учишься в основном через само хакерство. [3]

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

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

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

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

Писатели делают то же самое. Benjamin Franklin учился писать, кратко излагая мысли из эссе Addison и Steele, а затем пытаясь их воспроизвести. Raymond Chandler проделывал то же самое с детективными рассказами.

Хакеры, аналогично, могут учиться программировать, разглядывая хорошие программы — не только то, что они делают, но и их исходный код. Одно из менее разрекламированных преимуществ движения open-source в том, что оно облегчило обучение программированию. Когда я учился программировать, нам приходилось полагаться в основном на примеры из книг. Единственным крупным куском доступного тогда кода был Unix, но даже он не был open source. Большинство тех, кто читал исходники, читали их в нелегальных ксерокопиях книги John Lions, которую, хоть и написанную в 1977 году, не разрешали публиковать до 1996-го.

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

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

(Структура крупных компаний затрудняет для них такой подход, так что вот ещё одно место, где у стартапов есть преимущество.)

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

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

Звучит как парадокс, но великая картина должна быть лучше, чем ей необходимо быть. Например, когда Leonardo писал портрет Ginevra de Benci в National Gallery, он поместил за её головой куст можжевельника. На нём он тщательно прописал каждый отдельный листок. Многие художники могли бы подумать: это всего лишь нечто для фона, чтобы обрамить её голову. Никто не станет вглядываться в это так пристально.

Но не Leonardo. То, насколько усердно он работал над частью картины, совершенно не зависело от того, насколько пристально, по его ожиданиям, кто-либо станет в неё вглядываться. Он был как Michael Jordan. Неумолим.

Неумолимость побеждает, потому что в совокупности невидимые детали становятся видимыми. Когда люди проходят мимо портрета Ginevra de Benci, их внимание часто оказывается мгновенно прикованным к нему — ещё до того, как они взглянут на табличку и заметят, что там написано Leonardo da Vinci. Все эти невидимые детали соединяются, порождая нечто просто ошеломляющее, — словно тысяча едва слышных голосов, поющих в унисон.

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

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

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

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

В хакерстве это может буквально означать накапливать баги. Я люблю отладку: это единственный момент, когда хакерство оказывается таким же прямолинейным, каким его представляют люди. У тебя полностью ограниченная задача, и всё, что нужно сделать, — её решить. Программа должна делать x. Вместо этого она делает y. Где она ошибается? Ты знаешь, что в конце концов победишь. Это так же расслабляет, как красить стену.

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

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

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

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

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

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

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

Эмпатия — пожалуй, единственное самое важное различие между хорошим хакером и великим. Некоторые хакеры весьма умны, но в том, что касается эмпатии, практически солипсисты. Таким людям трудно проектировать великий софт [5], потому что они не способны видеть вещи с точки зрения пользователя.

Один из способов определить, насколько у человека хорошо с эмпатией, — понаблюдать, как он объясняет технический вопрос тому, у кого нет технического образования. Мы все, наверное, знаем людей, которые, будучи в остальном умными, в этом просто комично плохи. Если их на званом ужине спросят, что такое язык программирования, они скажут что-то вроде: «А, язык высокого уровня — это то, что компилятор использует на входе для генерации объектного кода». Язык высокого уровня? Компилятор? Объектный код? Тот, кто не знает, что такое язык программирования, явно не знает и что такое всё это.

Часть того, что должен делать софт, — это объяснять себя. Поэтому, чтобы писать хороший софт, надо понимать, как мало понимают пользователи. Они подойдут к софту безо всякой подготовки, и ему лучше бы делать то, что они угадают, потому что руководство они читать не станут. Лучшей системой в этом отношении из тех, что я когда-либо видел, был оригинальный Macintosh 1985 года. Он делал то, что софт почти никогда не делает: он просто работал. [6]

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

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

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

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

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

К сожалению, на этот вопрос трудно ответить. В престиже всегда есть большое запаздывание во времени. Это как свет далёкой звезды. Живопись престижна сейчас благодаря великим работам, сделанным людьми пятьсот лет назад. В своё время никто не считал эти картины такими важными, какими их считаем мы сегодня. Людям той эпохи показалось бы очень странным, что Federico da Montefeltro, герцог Урбинский, однажды будет известен прежде всего как тот тип со странным носом на картине Piero della Francesca.

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

Что мы можем утверждать с некоторой уверенностью — так это то, что сейчас золотые дни хакерства. В большинстве областей великое создаётся на ранних этапах. Картины, написанные между 1430 и 1500 годами, до сих пор не превзойдены. Shakespeare появился как раз тогда, когда рождался профессиональный театр,

и развил эту форму так далеко, что всякому драматургу с тех пор приходилось жить в его тени. Albrecht Durer сделал то же самое с гравюрой, а Jane Austen — с романом.

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

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

Примечания

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

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

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

[4] Вот пример прикладной эмпатии. В Viaweb, если мы не могли выбрать между двумя вариантами, мы спрашивали: что́ наши конкуренты возненавидели бы больше всего? Однажды конкурент добавил в свой софт функцию, по сути бесполезную, но поскольку это была одна из немногих, что были у них и не было у нас, они вовсю раструбили о ней в отраслевой прессе. Мы могли бы попытаться объяснить, что функция бесполезна, но решили, что конкурента сильнее разозлит, если мы просто реализуем её сами, и в тот же день к вечеру наспех сколотили собственную версию.

[5] За исключением текстовых редакторов и компиляторов. Хакерам не нужна эмпатия, чтобы их проектировать, потому что они сами и есть типичные пользователи.

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

[7] Способ сделать программы лёгкими для чтения — не напихивать их комментариями. Я бы продвинул цитату Abelson и Sussman на шаг дальше. Языки программирования должны проектироваться для того, чтобы выражать алгоритмы, и лишь попутно — чтобы сообщать компьютерам, как их исполнять. Хороший язык программирования должен подходить для объяснения софта лучше, чем английский. Комментарии должны требоваться только там, где есть какой-то костыль (kludge), о котором нужно предупредить читателей, — точно так же, как на дороге стрелки ставят лишь на участках с неожиданно крутыми поворотами.

Благодарности Trevor Blackwell, Robert Morris, Dan Giffin и Lisa Randall за чтение черновиков этого текста, а также Henry Leitner и Larry Finkelstein за приглашение выступить.