Два взгляда на программирование

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

• Точка зрения А: программирование в сущности очень просто.
• Точка зрения В: программирование по сути очень сложно.

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

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

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

1) арифметические блоки были медленными для того, что мы хотели сделать: почти всегда было как в тесных ботинках и во имя эффективности программ в кодировании допускались всевозможные уловки и очень немногие их не применяли;

2) разработка и изготовление арифметических блоков напоминало написание романа и, следовательно, было сложной задачей и если очередная аномалия в системе команд могла избавить от каких-либо кульбитов, то, обычно, этим спасались — ведь мы имели так мало опыта в программировании, что не слишком хорошо могли осознать «аномалию системы команд» и в результате этого использовали трюки кодирования, тем более, что для этого были отличные возможности;

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

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

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

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

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

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

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

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

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

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

Может я неисправимый скептик, но нахожу что мне очень трудно поверить обоснованности таких претензий. Они являются конкретным экземплярам расчетов на то, что мы увидим (я цитирую из недавно полученного письма ) — «… в общем, передача более совершенному компьютеру того, что мы сегодня называем человеческим мастерством, знаниями и интеллектом». У меня нет никакого желания приводить выдержки из жарких дискуссий о значении искусственного интеллекта (см., например, [1]), впрочем, здесь в этом нет никакой необходимости.

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

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

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

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

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

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

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

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

[1] Flowers, B.H. «Artificial Intelligence: a paper symposium» April 1973, Science Research Council, State House, High Holborn, London WC1R 4TA.