Програмування як вища форма творчості, Різне, Security & Hack, статті

Річі О’Бауер


ПЕРЕДМОВА

У наш час - епоху інформаційного буму - число програміста-
тов стрімко і неухильно зростає. Якийсь час тому мені стали ін-
тересно об'єктивні причини такого блискучого підйому інформаційної
науки ("computer science" - прим. пер.), і я провів деякі самостійно-
тільні вишукування на цю тему, які і хочу зараз запропонувати вашій
увазі. Оскільки сам я не можу претендувати на приналежність до хаке-
рам, тези цієї статті краще сприймати як свого роду думка "че-
ловека з боку ".
Проте, працюючи психологом у великій компанії, що займає-
ся розробкою великих програмних проектів, неможливо не спілкуватися з
програмістами, ніж я зазвичай і займаюся. Багато хто з моїх друзів - імен-
але програмісти, так що моя думка в першу чергу грунтується на їх
поглядах на життя в цілому і на свою професійну діяльність в годину-
тності.
Можу відразу ж попередити вас, що не бачу сенсу в розгляду-
нии розвитку комп'ютерних технологій. Ця сторона питання вже досить
висвітлена в спеціальних журналах, і тут, я вважаю, мені навряд чи вдасться
посперечатися навіть з найменш поінформованими з вас. Ця стаття - не про
комп'ютерах. Мене цікавлять не комп'ютери, а люди, які проводять іноді
по кілька діб поспіль у моніторів.
Я аналізую виключно людський фактор - і сподіваюся, що
мої викладки здадуться для вас цікавими.


1. ШЛЯХ ДО ПРОГРАМУВАННЯ

Чим керується людина, вибираючи для себе професію?
По-перше, особистими уподобаннями. Для програмування потрібен
певний склад розуму, а якщо вже ми говоримо про програмістів-разработчі-
ках програмного забезпечення, а не про "упертих в науку" зашорених тео-
Ретик, сформулювати особисті переваги саме по собі є до-
вільно цікавою і нетривіальним завданням. Чи знаєте ви, що програміста-
ти частіше мають технічним складом розуму, а не абстрактним, як, напри-
заходів, математики, фізики та інші? І що технічний склад розуму зустрічає-
ся частіше у письменників, музикантів, перекладачів, а зовсім не у механіків,
як це випливає з назви?
Так ми приходимо до розуміння того факту, що слово "програміст"
зовсім не є синонімом визначення "прикладної математик", хоча
багато хто і не відчувають різниці між цими поняттями. Наприклад, Пол Холь-
цер (Paul Holtser - прим. пер.), мій хороший приятель, каже букваль-
але наступне: "Я не використовую у своїй роботі практично нічого з вивчений
ченного в університеті. Математичний аналіз та інша абстрактна мате-
матики не дають мені способів написання елегантного і компактного коду
програм. Можливо, для людей, поставлених перед необхідністю прог-
раммірованія вузькоспеціальних завдань в галузі математики, ці знання міг-
Чи б знадобитися, але ми все-таки працюємо не над відображенням трьохмірний-
них графічних сцен, а займаємося завданнями іншого рівня ... Можу кість
але зізнатися, що займаюся програмуванням не з точки зору практи-
кують математика. Навпаки, я виконую роботу лінгвіста - перекладача
з повсякденної мови на комп'ютерний, пояснюючи комп'ютера, що і як
потрібно виконати, щоб прийти до бажаного результату ".
Що ж, у поєднанні з тим, що Пол вважається відмінним програміста-
тому і лідером багатьох проектів, його слова не можна просто відкидати.
Вони вимагають ретельного і вдумливого аналізу.
Пол цілком міг би стати перекладачем, літератором чи психоло-
гом, хоча і вчився на програміста. Поширене, але невірна думка
університетських викладачів звучить так: "Ви повинні знати теорію, а
практична реалізація тих чи інших речей настільки проста, що ми не
будемо її розглядати ". І хоча я знаю багато людей, які не зустріч-
Чи ніяких труднощів з теорією, всі вони насилу проходили практичних
кую реалізацію завдання. Зараз я можу з упевненістю сказати: їх мізки,
здатні з легкістю вирішувати найскладніші диференціальні рівняння, поп-
зростанню пасували, коли виникала необхідність перекласти свої Запределье-
ні викладки в зручний і, головне, ефективний текст кінцевої програми.
Зрештою, математиків, філософів і лінгвістів навчають на різних фа-
культетах, чи не так?
Але звичайний програміст - не стільки математик, скільки лінгвіст
і філософ в одній особі, активно застосовує положення формальної логіки.
Ви ніколи не зустрічали програмістів, які не можуть докладно і ясно
пояснити алгоритм вирішення того чи іншого завдання? Запевняю вас: з їх прог-
раммной продуктами краще не стикатися. Ці люди не мають точнос-
тью мислення і, як наслідок, виявляються просто не в змозі порож-
дати хоч скільки-небудь досконалий програмний код.

Повернемося до початкової теми, залишивши на деякий час рас-
судження про наших особистих схильностях і перевагах. Отже, що ще ми
можемо порахувати об'єктивними причинами для вибору цього шляху в житті?
Зрозуміло, це фінансова сторона справи.
За роботу в аналізованій області в наш час добре платять.
Напрямів для активної професійної діяльності стає все
більше і більше, а обсяги інформації, супутні їм, змушують прог-
раммістов набувати досить жорстку спеціалізацію: бази даних, мережеві
технології (і комунікації в цілому), графіка, прикладне програмування
ня під різні платформи ... Список можна продовжувати до безкінечності, але
ви й самі розумієте, наскільки MFC і Qt різняться між собою. Коли прог-
рамміст вирішує будь-яку задачу, йому волею-неволею доведеться тримати в
голові всі нюанси тієї системи, в якій він працює, і всі особливості
тієї платформи, під яку він пише - в іншому випадку супровід
цієї програми стане малореальним ще до закінчення робіт над першою,
отладочной версією.
У великих компаніях, що розробляють серйозні проекти, справа,
як правило, виглядає трохи інакше: роботу з базами даних нада-
Вят групі співробітників, яка чудово знайома з цією темою - і вже
явно не стануть турбувати цим завданням групу розробників драйверів.
Кожному - своє. Цей принцип лежить в основі всіх сучасних
компаній, що лідирують сьогодні на ринку програмного забезпечення. Тому
на роботу в такі компанії запрошують не всезнаючих "універсалів", ледь
Чи знайомих навіть з теорією, а умілих і активних експертів-практиків. І,
як наслідок, такі експерти-практики можуть собі дозволити багато чого.
Займатися програмуванням зараз прибутково і престижно - і
це не порожні слова.


2. ПРОГРАМУВАННЯ ЗСЕРЕДИНИ

Якщо ознайомитися з цим питанням докладно і предметно,
легко помітити, що програмування - це не тільки бізнес. В куди
Більшою мірою це творчість. Подивіться, хіба не схожі ваші знайомих
мі програмісти на представників богеми? Жартую, звісно, ​​- але каж-
дая жарт має під собою якусь першооснову.
Якби програмування не носило в собі рис творчості, зани-
маться їм було б нудно. Уявіть собі: вісім годин на день у вас
перед очима монітор, заповнений нескінченною низкою символів. Вам би
це набридло, чи не так? І мова тут йде не про гроші, а про ту від-
дачі, яка допомагає нам займатися своєю роботою від відпустки до відпусток-
ка. Якби програмісти не відчували морального задоволення від
своєї діяльності, вони б просто вимерли.
Отже, чому я можу з упевненістю заявити, що програмування
є творчістю? Тому, що в програмуванні ми використовуємо стра-
тегіі, дуже схожі зі стратегіями літераторів (письменників,
перекладачів). Відомі НЛП-практики (можу привести в приклад книгу "Ap-
plications of NLP "by Dilts, в якій є стаття" Creative writing ")
вчать тому, як правильно формувати художній текст і як оптимізувати-
зировать (поліпшити, спростити) сам процес написання. Ви замислювалися про
те, що читає книгу людина мимоволі уподібнюється комп'ютера, після-
довательно відстежуючи думка автора через всі глави і параграфи? І про те,
що пиша програмний код, ви забезпечуєте на деякий час компілятор
(А трохи пізніше - і систему) цікавим чтивом? У всякому разі, ваш мозок
давно знає і активно використовує цю схожість програмування і писа-
тва.
Якщо у двох видах діяльності виявляються схожі методики і
причинно-наслідкові ланцюжки, то суть цих видів діяльності єдина,
якщо розглядати її в загальному вигляді (а значить, так, як її розглядає
людський мозок).
Тепер поговоримо про відмінності якої іншої форми творчості та
програмування. Перше - і, без сумніву, саме значуще - відмінність
формулюється так: "Програмування не використовує рефлексію як
методу пізнання ". Дійсно, художник, композитор чи письменник, со-
зідая, вирішують власні душевні проблеми. Така мотивація всіх видів
творчості, і я радий, що з програмуванням все інакше. Хіба
має значення, на яку тему замислюється програміст в даний момент?
Навпаки, займаючись своєю справою, програміст відволікається від власних
переживань, повністю перемикаючись на роботу. Таким чином, навіть деп-
рессівние стану майже не можуть негативно вплинути на якість і
швидкість роботи програміста.
Друга відмінність я сформулював так: "програмує-
вання не спрямоване на душу споживача ". Програмні продукти можуть по-
могти вам у вашій роботі, розважити вас, пов'язати з іншими людьми, але вони
ніяк не позначаться на вашому душевному стані. (Якщо не говорити про курь-
езах кшталт "психотерапевта" в редакторі Emacs і залишити в стороні слу-
чаї, коли програми працюють неякісно, ​​шокуючи вас в зневіру.) Од-
ним словом, програміст творить як художник, а питають з нього як з
ремісника. По-моєму, це золота середина. А по-вашому?
Елемент рутини і ремісництва, якщо дивитися на речі реаль-
але, в програмуванні присутня лише тоді, коли справа доходить до
налагодження та супроводження, а й там, за наявності добре розробленого
проекту та плану роботи з пересічної "лову бліх" переростає у щось
більше.
І, головне, в програмуванні практично відсутній плагіат.
Дивіться самі: програміст вольний використовувати багато бібліотек, які
є "у відкритому доступі". Він може працювати з вихідними кодами, написаними
іншими людьми. Він реалізує свій продукт, який базується на чужих нара-
лення (будь то напрацювання його колег чи плід праці програмістів проек-
та GNU з Європи). Уявіть собі художника, що використовує чужі робо-
ти. Максимум, на що той здатний претендувати, - звання коллажіста,
ремісника від живопису. Програміст, який використовує стандартні бібліо-
теки, пародією на такого "художника" аж ніяк не є. Його робота са-
мостоятельное і цілком значима і гідна.
Таким чином, програмісти можуть працювати і спільно, і по від-
окремо. У першому випадку при ефективній організації роботи якість
вихідного продукту буде багато краще - що саме по собі не може не ра-
дова. Посудіть самі, чи буде твором мистецтва картина або кни-
га, яку створювали тридцять-сорок чоловік, причому іноді навіть не
зустрічаючись і не спілкуючись? Приклади програм, написаних в таких умовах
можна зустріти на кожному кроці - і ви легко можете переконатися, що це
не "буріме", а цілком професійно зроблене і дуже стабільне прог-
раммной забезпечення.

Отже, шляхом порівняння програмування та інших видів творчості
ми прийшли до того, що зазначено в назві статті: ПРОГРАМУВАННЯ -
КРАЩА ТВОРЧА СПЕЦІАЛЬНІСТЬ. (Тим не менш, у російській перекладі
стаття називається трохи інакше. Але, думаю, автор мені пробачить. -
прим. пер.)
Що ж із цього випливає?


3. ВИСНОВКИ

Повернімося ще раз до проекту GNU. Розробка програмних продуктів
на основі чужих бібліотек і програм, поставлена ​​на потік - це чи не
приклад спільності творчості програмістів? З їхньої співпраці народилося
декілька операційних систем і величезна кількість прикладних програм,
які, до речі, і поширюються безкоштовно. Останній факт я схильний
вважати своєрідним проявом етики хакерів старої школи, які
підводили солідну морально-філософську базу під своє гасло, що вимагає
доступності будь-якої інформації для всіх. Вони відкидали модний в наші дні
спосіб, коли команда розробників робить вихідні тексти своїх прог-
Рамм закритою інформацією, щоб конкуренти не змогли скористатися
алгоритмами і методиками, використовуваними в цих исходниках. І, як следс-
твіє, якість програм було цілком прийнятним - навіть на простеньких по
нинішніми мірками мікрокомп'ютерах з об'ємом ОЗУ не більше 64 Кб (на PDF10,
наприклад, відмінно працювала UNIX).
Реалії сучасного життя істотно відрізняються від того духу
загальної співпраці, який можна відшукати не тільки серед
студентів, а й серед молодих фахівців. Співпрацювати тоді було жит-
ненно важливо; зараз же дух конкуренції і комерції укупі зі звичайним
індивідуалізмом комп'ютерників-професіоналів часто вбиває будь сот-
руднічество. Рівень консультацій у конференціях Інтернет за останні
десять років сильно впав. Професіонали не бажають втрачати час на те, що-
б просвіщати своїх потенційних конкурентів, а тому новачки повинні
тепер переступати бар'єр власного незнання самостійно або обу-
чаясь на спеціальних курсах, де викладачі виявляються просто не в
змозі працювати з кожним із слухачів індивідуально.
Як наслідок, роз'єднаність комп'ютерного співтовариства неухильно
зростає, і програмісти в деяких компаніях іноді не бажають працювати
спільно. Такий стан речей сильно позначається на рівні стабільності
програмного коду, що породжується цими робочими групами.
Індивідуалізм і ескапізм програмістів - ось те, що мене нас-
торажівает. Багато хто з моїх знайомих так чи інакше вважають себе краще
інших, і це не страшно - але коли люди відмовляють один одному в сот-
руднічестве, керуючись тільки відчуттям власної значущості,
можна з упевненістю заявити, що справа погано. Наприклад, зараз багато
програмісти хизуються своїм віросповіданням (як правило, вони атеїсти)
та політичними переконаннями (комуністи чи щось подібне). При цьому вони
зовсім не поважають суджень інших людей, тому конфлікти в багатьох
групах відбуваються досить часто. Погіршення атмосфери в робочих колектив-
тівах програмістів все частіше і частіше призводить багатьох фахівців у тру-
догола і ініціює їх на вживання алкоголю і наркотиків. Я не ста-
ну багато говорити на цю тему і не буду наводити прикладів. Ви і
самі добре знаєте про це, якщо не боїтеся чесно подивитися на ізвес-
тні вам факти.
І ця сторона програмування - на жаль, також притаманна будь-якому з
видів творчості, - не може не лякати. Я щиро сподіваюся, що засилля
комерційної діяльності - не більше ніж дитяча хвороба нашого соціу-
ма, і пройде, як проходять вітрянка чи кір.
Я сподіваюся, що питання Хіллела послужать ще кількох поколінь-
ям програмістів (*). Я сподіваюся, що до людей, рухаються вперед проект GNU
приєднаються і інші. Я сподіваюся, що настігшіх наше суспільство психоло-
гический криза програмістів-практиків вирішиться Епохою Відродження.
Другим Ренесансом.


(*) ____________________________________________________________________

If I am not for myself, who will be for me?
If I am only for myself, what am I?
If not now, when?

Якщо я не живу для себе, хто буде жити для мене?
Якщо я живу тільки для себе, то хто я є?
Якщо не тепер, то коли?

(Переклад питань дається з перекладу Сергія Коропа статті Річарда Стіл-
лмена "Проект GNU", - прим. пер.).
________________________________________________________________________



(c) "Programming as the best creative speciality",
Сopyright (c) Richie O'Bower (obower@hotmail.com), 12 May 1997

(C) Дану статтю переклав російською мовою
Сергій Кашменскій (kashmensky@mail.ru), 20 вересня 1999

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

Verbatim copying and distribution of this entire article is permitted
in any medium, provided this notice is preserved.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*