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

image

Зараз Пол Грем вчить уряду та університети як створювати стартап-хаби, а от раніше… він провів чудову аналогію між висококваліфікованими програмістами і художниками.

За 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». В аспірантурі мене постійно мучила смутна думка, що слід більше уваги приділяти теорії, і вельми безтурботно з мого боку забувати її цілком через три тижні після випускних іспитів.

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

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

Приміром, мене в коледжі вчили: перш, ніж наблизитися до комп'ютера, програму слід цілком записати на папері. Виявляється, я програмував не так. Мені подобалося програмувати перед комп'ютером, а не над аркушем паперу. Гірше того, я не писав терпляче всю програму, перевіряючи, чи немає помилок, я erupted безнадійно кривий код і поступово приводив його в норму. Налагодження, вчили мене, — це останній захід, коли вылавливаешь помилки та упущення. Я ж працював так, що програмування схоже на нескінченну налагодження.

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

Усвідомлення цього факту реально впливає на розробку ПЗ. Мова програмування насамперед повинен бути гнучким. Мова програмування — щоб думати про програми, а не формулювати програми, які вже обдумані. Олівець, а не ручка. Статичний контроль типів — непогана штука, якщо б програмували і справді так, як вчать в коледжі. Але жоден відомий мені хакер так не працює. Нам потрібно мова, що дозволить карябать, садити плями і прати, а не ніби сидиш з чашкою типів даних і ввічливо розмовляєш зі строгою старою тітонькою-компілятором.

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

Ну, зрозуміло — сторінка формул вражає. (Порада: для особливої виразності вводите грецькі змінні.) І тому так спокусливо зайнятися проблемами, до яких можна підійти формально, а не над тими, що, скажімо так, важливі.

Якби хакери бачили в собі творців — письменників чи художників, — такого спокуси би не виникало. Письменники і художники математикам не заздрять. Вони вважають, що займаються чимось абсолютно не пов'язаних з математикою. Як і хакери, я вважаю.

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

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

Схоже, у великих компаніях тільки так і відбувається. Корпорації так роблять, щоб у підсумку знизити середній рівень відхилень. Лише деякі хакери вміють по-справжньому створювати, і обчислити їх нелегко. Тому компанії не вручають майбутнє програмного продукту геніального одинака, а влаштовують так, щоб продукт створювала група, а хакери його лише втілювали.

Якщо хочете заробити грошей, весь час пам'ятайте про це, — ось одна з причин успіху стартапів. Великі компанії знижують середні відхилення підсумкового продукту, бо не хочуть катастроф. Але вирівнюючи коливання, втрачаєш не лише нижні екстремуми — верхні теж. Великим корпораціям від цього ні холодно, ні жарко, бо вони перемагають не за рахунок геніальних продуктів. Вони перемагають, бо не так кошмарны, як інші великі корпорації.

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

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

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

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

Інша проблема в тому, що ЗА, що приносить гроші, і, що цікаво писати, особливо не перетинаються. Мови програмування писати цікаво, і перший продукт Microsoft, по суті, ним і був, але тепер за мови програмування не платять. Якщо хочеш грошей, треба братися за проблеми, які безкоштовно ніхто не вирішить, настільки вони жахливі.

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

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

Денна робота на початку кар'єри була майже у всіх творців. Цим знамениті художники і письменники. Якщо пощастить, знайдеш роботу, пов'язану з твоїм справжнім ділом. Музиканти нерідко працюють в музичних магазинах. Хакер, який працює над мовою програмування або операційною системою, цілком може знайти роботу, де все це стане в нагоді. [2]

Зрозуміло, ідея не нова. На цьому будується всі програмування з відкритими вихідними кодами. Я, власне, хочу сказати, що, може, open source — вірна модель: її правильність незалежно підтверджують і всі інші творці.

Я б здивувався, якщо б роботодавець з небажанням дозволяв хакерам працювати на проектами з відкритими вихідними кодами. У Viaweb ми з небажанням наймали тих, хто цього не робив. На співбесідах нас найбільше цікавило, яке ЗА програміст пише у вільний час. Якщо не любиш роботу, по-справжньому добре працювати не зможеш, а якщо любиш хакерство, неминуче станеш працювати над власними проектами. [3]

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

По-перше, на прикладі живопису ми дізнаємося — перевіряємо, у всякому разі, — як вчитися хакерства. Малювати навчаєшся, головним чином малюючи. З хакерством — те ж саме. Більшість хакерів осягає ремесло зовсім не вивченням курсів програмування в коледжі, але створенням власних програм — починаючи років з тринадцяти. В школі ви вчитеся хакать, тільки хакая. [4]

Художник залишає полотна, за якими можна простежити, як він навчався. Якщо розглянути роботи художника в хронологічному порядку, стане видно, що кожна наступна картина містить досвід попередніх. Як правило, в ранніх роботах виявляється зародок пізніших творчих успіхів.

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

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

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

Письменники теж так роблять. Бенджамін Франклін вчився писати, резюмуючи основні пункти есе Еддісона і Стіла, а потім намагаючись їх відтворити. Реймонд Чандлер те ж саме робив з детективними оповіданнями.

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

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

І ось ще чому вчить нас живопис: картини створюються шляхом покрокового вдосконалення. Зазвичай картина починається з ескізу. Поступово додаються деталі. Але не просто додаються. Іноді початковий план виявляється помилковим. На безлічі картин, якщо розглянути їх під рентгеном, виявляються зміну руки і ноги або перекроєна риси обличчя.

Цього ми могли б у живопису повчитися. По-моєму, хакерам слід діяти саме так. Нерозумно розраховувати, що специфікації програми виявляться ідеальними. Вже краще визнати це відразу і писати програми так, щоб змінювати специфікації на льоту.
(Структура великих корпорацій цього не дозволяє, так що і тут у стартапів перевагу.)

Тепер начебто всім відомо про небезпеку передчасної оптимізації. Я думаю, є підстави турбуватися з-за передчасної розробки — з-за того, що занадто рано буде вирішено, що саме програма має робити.

Уникнути цієї небезпеки допоможуть правильні інструменти. Хороший мова програмування, як олійні фарби, без проблем дозволяє з легкістю передумати. Динамічний контроль типів — великий плюс: не потрібно одразу підписуватися на конкретне уявлення даних. Але ключ до гнучкості в тому, щоб зробити мову дуже абстрактним. Короткі програми переписувати легше.

Звучить парадоксом, але велике полотно повинно бути краще, ніж повинно бути… Створюючи портрет Джиневры де Бенчи (Національна галерея), Леонардо помістив за її головою ялівцевий кущ. У ньому він ретельно прописав кожен листочок. Багато художники вважали, що це просто фон, обрамлення для голови. Хто стане пильно вивчати кущ?

Ginevra de Benciimage
Leonardo's Ginevra de' Benci, 1474.

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

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

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

Будь хакер простим виконавцем, перетворює специфікацію код, він би працював з початку до кінця, ніби копав канаву. Але якщо хакер — творець, слід враховувати натхнення.

За звинуваченням у хакерстві, як і в живописі, робота відбувається циклами. Іноді новий проект захоплює так, що готовий працювати по шістнадцять годин на добу. А іноді нічого особливо не чіпляє.

Щоб якісно працювати, не слід забувати про ці цикли: вони залежать від того, як їх сприймаєш. Коли їдеш у гору на машині з ручною коробкою передач, деколи треба пригальмовувати, щоб не стихнути. Відступ рятує задуми, та вони не глухнуть. І в живописі, і звинуваченням у хакерстві одні завдання жахливо честолюбні, а інші — втішно звичайні. Розумно притримувати прості завдання до моментів, коли без них просто заглохнешь.

За звинуваченням у хакерстві це буквально означає залишати баги. Мені подобається налагодження: під час налагодження хакерство виходить прямолінійним, яким його всі і вважають. Є конкретна проблема, і її потрібно вирішити. Програма повинна робити X. А вона робить Y. Що не так? Ти розумієш, що в підсумку переможеш. Розслабляє, як стіну фарбувати.

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

Baptism of Christimage

Наскільки мені відомо, художники, разом працюючи над полотном, ніколи не писали одні й ті ж фрагменти. Зазвичай майстер писав основні фігури, а помічники — інші і фон. Але ні один не писав поверх чужої роботи.

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

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

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

Господи, як я помилявся. З'ясувалося, що вміння дивитися чужими очима — практично ключ до успіху. Співпереживання — зовсім не обов'язково самопожертву. Зовсім ні. Якщо розумієш чужу точку зору, зовсім не означає, що будеш діяти в чужих інтересах. У деяких ситуаціях — на війні, приміром, — дієш рівно навпаки [5].

Більшість творців творять для людей. А щоб залучити аудиторію, потрібно зрозуміти, що їй потрібно. Майже на будь-якому мальовничому полотні — люди, тому що люди цікавлять людей.

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

Щоб перевірити, наскільки людям дається співпереживання, поспостерігайте, як вони роз'яснюють технічні питання співрозмовнику, нічого не смыслящему в технологіях. У всіх є знайомі, взагалі-то розумні, але комічно не здатні вирішити цю задачу. Якщо запитати їх за вечерею, що таке мова програмування, вони відповідають приблизно так: «Ну, високорівнева мова, що використовує компілятор на вході для генерації об'єктного коду». Високорівнева мова? Компілятор? Об'єктний код? Людина, що не знає, що таке мова програмування, цих слів вже точно не знає.

Програмне забезпечення почасти сама себе пояснює. Тому, щоб написати гарний, слід розуміти, як мало розуміє користувач. Він звернеться до ЗА без найменшої підготовки, і краще хай не обдурить користувальницьких очікувань і зробить, що повинно, тому що користувач інструкцій читати не стане. Краща відома мені система з цієї точки зору — «макінтош» 1985 року. Він робив те, що зазвичай не робить: просто працював [7].

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

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

Співпереживати треба не тільки користувачам, але і читачам. Це у ваших інтересах — ви самі станете одним з них. Чимало хакерів спочатку писали програми, а через півроку з'ясовували, що поняття не мають, як ці програми працюють. Кілька моїх знайомі після таких випадків поклялися більше ніколи не писати на Perl [9].

Недолік вміння співпереживати зв'язується з інтелектом — до такої міри, що в певних колах він навіть модний в деякому роді. Не думаю, що вони якось корелюють. У математиці та природничих науках можна обійтися і без співпереживання; в таких областях люди зазвичай розумні, тому два цих якості утворили зв'язку. Але є купа нездар, яким співпереживання теж не дається. Ви послухайте людей, які телефонують із запитаннями на ток-шоу. Вони задають ці питання настільки криво, що ведучому нерідко доводиться переробляти за них.

Отже, механізм хакерства — той же, що у живопису і літератури, — але так воно круто? Зрештою, життя всього одна. Може, краще присвятити її чогось великого?

На жаль, простої відповіді немає. Слава завжди сильно запізнюється. Як світло далекої зірки. Живопис користується визнанням великих полотен, створених п'ятсот років тому. Тоді цим полотнам надавали набагато менше значення, ніж сьогодні. В ті часи людям здалося б вкрай дивним, що коли-небудь Федеріко да Монтефельтро, герцога Урбіно, буде відомий в основному як хлопець з дивним носом на картині П'єро делла Франческо.

Federico da Montefeltroimage
Piero della Francesca's Federico da Montefeltro, 1465-66

Так, я визнаю, що зараз хакерство — не так круто, як живопис, проте слід пам'ятати, що і живопис часів розквіту не здавалося таким вже крутий.

З деякою часткою впевненості можна стверджувати: зараз — дні розквіту хакерства. В більшості інших областей великі роботи були створені раніше. Живопис, створена в період між 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] Спростити читання програм не означає забити їх коментарями. Я б розвинув думку Эбелсона і Сассмена: мови програмування мають створюватися для вираження алгоритмів і лише зрідка — щоб повідомляти комп'ютерів, як їх виконувати. Хороший мова програмування пояснює краще англійської. Коментарі потрібні лише в тому випадку, якщо в програмі якийсь ляп, про який потрібно повідомити читачеві, — як на дорозі, де стрілки висять лише на різких поворотах.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.