Эврика! Дом творческих и вдумчивых людей
Добро пожаловать на первый в Латвии мультитематический и межвузовский научный портал!

Сделать стартовой
Добавить в избранное
Контакты
 
   Главная      Эврика      Библиотека      Досуг      Контакты     БДС  

Библиотека : Мировая наука : Психология математики





                              РИЧИ О'БАУЭР

              ПРОГРАММИРОВАНИЕ КАК ВЫСШАЯ ФОРМА ТВОРЧЕСТВА


                              ПРЕДИСЛОВИЕ

        В  наше время -- эпоху информационного бума -- число программис-
тов  стремительно и неуклонно растет. Какое-то время назад мне стали ин-
тересны  объективные причины столь блистательного подъема информационной
науки ("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.


Добавлено: 2005-05-25
Посещений текста: 2039

[ Назад ]





© Павел Гуданец 2004-2017 гг.
 инСайт

При информационной поддержке:
Институт Транспорта и Связи