В окружающем нас мире мы можем встретить два радикально противоположных взгляда на программирование:

Это противоречие можно объяснить тем, что в этих двух взглядах одно и то же слово «программирование» употребляется в двух совершенно различных значениях, и на этом успокоиться. Тем не менее то, какой из взглядов преобладает, А или В, оказывает глубокое влияние не только на кадровую политику организаций, использующих компьютеры, и учебные программы высших учебных заведений, но даже и на направление развития и исследований в самой компьютерной науке. Таким образом, представляется важным исследовать природу различий между этими двумя смыслами и по возможности выявить базовые предположения, которые делают каждый их них применимым. В этом и есть назначение данного документа.

В этом исследовании у меня есть одно препятствие: в этой дискуссии я не являюсь нейтральной стороной. Я – убежденный сторонник взгляда В и рассматриваю взгляд А как основную причину многих печальных заблуждений. С другой стороны, я не считаю, что наличие собственного мнения дисквалифицирует меня как автора, особенно если я заранее предупрежу об этом своих читателей и не буду притворяться нейтральным. В процессе анализа мы раскроем, как эти различные взгляды на программирование (которое является человеческой деятельностью!) связаны с различными мнениями Человека. Это уже само по себе является весьма ценным пониманием, так как объясняет почти религиозное рвение, с которым разворачиваются сражения между сторонниками противоположных взглядов (догм?).

Ранняя история автоматических вычислений делает взгляд А очень понятным. До того, как у нас появились компьютеры, программирование вообще не являлось проблемой. Затем появились первые машины: по сравнению с нашими нынешними машинами они были просто игрушками, и по сравнению с тем, что мы пытаемся делать сейчас, они использовались лишь для «микро-приложений». Если на этом этапе программирование и было проблемой, то весьма незначительной. Добавьте к этому источники трудностей, которые в то время поглощали – или лучше сказать узурпировали? – большую часть нашего внимания:

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

В течение следующих десяти-пятнадцати лет процессоры стали в тысячи раз быстрее, памяти стало в тысячи раз больше, и языки программирования высокого уровня вошли в обиход. И именно в это время с одной стороны программирование все еще прочно ассоциировалось с тесными башмаками, в то время как с другой – чувствовалось, что башмаки жмут все меньше и меньше, и ожидалось, что еще через пять лет технического прогресса проблемы программирования вовсе исчезнут. Именно в этот период появился взгляд А. Именно в конце этого периода, вдохновленный взглядом А, был разработан COBOL с провозглашенным намерением, что он должен сделать программирование, выполняемое профессиональными программистами, ненужным, позволив «пользователю» (не в это ли время слово «пользователь» стало общеупотребимым?) записывать то, что он хочет, на «простом английском», который любой может прочесть и понять.

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

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

Откуда взялся взгляд В? Были люди, которые чувствовали, что появление больших и быстрых машин заменит тесные башмаки хотя бы на башмаки по размеру, и что несмотря на это эффективность выполнения программ останется серьезной заботой программиста, заботой, которая станет даже более важной по мере роста машин и приложений, и что более сложные установки поставят более трудные проблемы. Также было замечено, что переключение с машинного кода на языки высокого уровня вовсе не гарантирует тех преимуществ, на которые возлагали столько надежд. В частности, программисты продолжали столь же охотно выдавать большие куски непонятного кода, и единственное различие было в том, что теперь они делали это в более грандиозных масштабах, и что высокоуровневые ошибки пришли на смену низкоуровневым. Они также поняли, что появление языков программирования высокого уровня не уменьшает потребности в тщательности: избыточность языков высокого уровня лишь уменьшает вредный эффект от некоторых видов небрежности. И тогда появился взгляд В. (Взгляд В не является реакцией на кризис программного обеспечения, который всплыл в 1968, так как он на много лет старше. Фактически взгляд В предсказал этот кризис, но даже это подтверждение не убило взгляд А).

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

Я придерживаюсь мнения, что программирование – один из наиболее сложных разделов прикладной математики, поскольку оно также является одним из наиболее сложных направлений инженерии, и наоборот. Когда я попытался разъяснить одному из моих коллег-математиков, почему я придерживаюсь этого мнения, он довольно бесцеремонно отказался выслушать мои доводы и вместо этого обвинил меня и моих единомышленников-компьютерщиков в том, что мы до сих пор не создали язык программирования, который сделал бы программирование настолько простым, насколько ему и подобает быть! Возможно, мне стоило бы спросить его, почему математики до сих пор не разработали нотацию, которая позволила бы любому, невзирая на отсутствие профессиональной подготовки, заниматься математикой?

Копнув чуть глубже, выясняется, что сторонники взгляда А не отрицают потенциальной сложности программ и их разработки, но верят, что жизнь программистов будет становиться все легче, поскольку все наиболее сложные части задачи будет брать на себя машина. Они указывают на появление языков программирования высокого уровня, которые уже сделали программирование гораздо легче, чем во времена старых машин, и опрометчиво экстраполируют, что в будущем программирование станет вовсе тривиальным. Но оправдана ли эта экстраполяция? Я много программировал, как в машинных кодах, так и на языках высокого уровня, и последние несомненно более удобны, поскольку в этом случае многие решения, относящиеся к внутренним деталям программы, такие, как распределение памяти, не приходится принимать явно, поскольку ими занимается алгоритм распределения памяти компилятора. Переход к языкам высокого уровня освобождает нас от многих тривиальных забот. Это сделало программирование деятельностью с небольшим количеством нудной работы, с преобладанием изобретательности: именно та часть работы, которая занимала целые дни, исчезла! Вывод, который следует из появления языков программирования высокого уровня, о потребности в программистах большего интеллектуального калибра, полностью подтвердился моими наблюдениями в Западной Европе (где я мог следить за разработками последнее время): в конце 60-х многие крупные организации, использующие компьютеры, испытывали проблемы в подборе подходящей работы для программистов, нанятых 50-е годы, поскольку профессия переросла их интеллектуальные способности.

Однако ни эти наблюдения, ни указания на провал попытки COBOL'а выжить профессиональных программистов не произвели никакого впечатления на правоверных. Они объяснят, что традиционные языки программирования высокого уровня потерпели крах из-за их «процедурности», и что провал COBOL'а очевиден, поскольку ввиду недостаточной интерактивности он на самом деле не является простым английским, но вот через пять или десять лет дальнейший прогресс в области Искусственного Интеллекта (для посвященных – AI, т.е. Artificial Intellect) позволит нам построить «контекстно-зависимые», «основанные на знаниях», «автоматизированные системы для мышления и понимания», такие, что «пользователю достаточно будет только побеседовать с ними».

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

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

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

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

Эта неразбериха, вне всякого сомнения, – плод усилий верховных жрецов AI. Преобладание в основном антропоморфной терминологии в компьютерной науке – «память», «интерпретатор», «язык программирования», «рукопожатие», «диалог», и это лишь немногие примеры, – это предупреждение, которое не следует игнорировать. Я не знаю, как думать и разговаривать, обходясь без метафор; я знаю также, что каждая метафора несет в себе опасность скрытого подтекста. В данном случае антропоморфной терминологии в компьютерной науке мы давно уже достигли стадии, когда опасность путаницы перевешивает достоинства аналогии.

Кроме того, кажется, что механический подход к людям среди компьютерных ученых (и их руководителей) распространен шире, чем представляется мне нормальным. Ибо я подозреваю, что именно этот механический подход ограничивает деятельность программистов механическими действиями по написанию кода, и затем измеряет «производительность труда программиста» количеством произведенных им строк кода. (Когда весьма широко известный и очень уважаемый ученый-компьютерщик использовал недавно эту меру производительности труда программиста в своей лекции, от слушателей поступило предложение говорить не о «количестве произведенных строк кода», а о «количестве израсходованных строк кода», и что лектор, следовательно, занес их не в ту графу учета баланса расходов и доходов. Лектор ответил, что он вынужден использовать эту меру производительности, поскольку не располагает никакой альтернативной, которая позволяет вести точный учет!) Это не может больше рассматриваться как безобидное заблуждение, поскольку принятие этой бессмысленной «меры производительности» профессиональными программистами гарантированно стимулирует их к написанию рыхлого кода.

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

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

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