Программистские басни

Одной из форм научной деятельности Дейкстры являются письма, которые он время от времени посылает своим корреспондентам (а также нанимателям: живя в Голландии в г. Эйндховене, он работал в фирме "Барроуз" ("Burroughs"), находящейся в США), призывая распространять их дальше. Сборник, содержащий некоторые из этих писем, был опубликован в 1982 г. Когда взгляды Э. Дейкстры стали известны широкому кругу программистов, они вызвали сильную (и далеко не всегда положительную) реакцию. С некоторыми сокращениями приводятся 2 эссе Э. Дейкстры.

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

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

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

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

Теперь, когда все туалеты находились на равных расстояниях, компания была уверена в успехе, однако пассажиры продолжали беспокоиться: хотя до ближайшего туалета было не больше одного вагона, но не было ясно, с какой стороны он находится. Чтобы решить и эту проблему, внутри вагонов были нарисованы стрелки с надписью "ТУАЛЕТ", сделавшие необходимым правильно ориентировать и вагоны без туалетов.

На сортировочных станциях новая инструкция вызвала шок: сделать требуемое вовремя было невозможным. В критический момент кто-то, чье имя сейчас невозможно установить, заметил следующее. Если мы сцепим вагон с туалетом и без оного так, чтобы туалет был посередине, и никогда их не будем расцеплять, то сортировочная станция будет иметь дело вместо N ориентированных объектов с N/2 объектами, которые можно во всех отношениях и со всех точек зрения считать симметричными. Это наблюдение решило проблему ценой двух уступок. Во-первых, поезда могли теперь состоять лишь из четного числа вагонов - недостающие вагоны могли быть оплачены за счет экономии от сокращения числа туалетов, и, во-вторых, туалеты были расположены на чуть-чуть неравных расстояниях. Но кого беспокоит лишний метр?

Хотя во времена, к которым относится наша история, человечество не знало ЭВМ, неизвестный, нашедший это решение, был первым в мире компетентным программистом.

Я рассказывал эту историю разным людям. Программистам, как правило, она нравилась, а их начальники обычно сердились все больше и больше по мере ее развития. Настоящие математики, однако, не могли понять, в чем соль.

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

Чтобы подбросить вам идей, касающихся этой проблемы, перечислю некоторые из таких истин. (Почти все знакомые мне ученые-программисты согласятся в основном со всеми из них. Однако мы вынуждены позволить миру действовать так, как будто мы их не знаем).

Программирование - одна из наиболее трудных отраслей прикладной математики: слабым (poor) математикам лучше оставаться чистыми (pure) математиками.

Научно-технические расчеты - простейшее применение вычислительной техники.

Средства, которые мы применяем, оказывают глубокое (и тонкое) влияние на наши способы мышления и, следовательно, на нашу способность мыслить.

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

ПЛ/1 - "роковая болезнь" - принадлежит скорее к области проблем, чем к области решений.

Практически невозможно научить хорошо программировать студентов, ориентированных первоначально на БЕЙСИК: как потенциальные программисты они умственно оболванены без надежды на исцеление.

Использование Кобола калечит ум. Его преподавание, следовательно, должно рассматриваться как уголовное преступление.

АПЛ - ошибка, доведенная до совершенства. Это язык будущего для программистской техники прошлого: он открывает новую эру для любителей кодирования.

Проблемы управления в целом и базами данных в частности чрезвычайно сложны для людей, которые думают на смеси "ЕС-овского с нижегородским" (буквальный перевод: в терминах фирмы IBM, смешанных с неряшливым английским).

Об использовании языка: невозможно заточить карандаш тупым топором. Столь же тщетно пытаться сделать это десятком тупых топоров.

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

Многие компании, которые поставили себя в зависимость от оборудования фирмы IBM (и, поступив так, продали душу дьяволу), потерпят крах под весом неуправляемой сложности своих систем обработки данных.

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

Использование антропоморфной терминологии в отношении вычислительных систем - признак профессиональной незрелости.

Провозглашая себя работающими в области программного обеспечения (software), слабые (soft) ученые делают себя еще более смешными (но не менее опасными). Вопреки своему названию, software (буквально: мягкое оборудование) требует [жесточайше] твердой научной дисциплины для своей поддержки.

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

Проекты, предлагающие программирование на естественном языке, гибельны по своей сути.

Разве не достаточен этот список, чтобы дать повод для беспокойства? Но что мы собираемся делать? Вероятно, заняться повседневными делами...

Если предположение о том, что "вы предпочли бы, чтобы я не волновал вас пустяками, посылая вам это", справедливо, то можете добавить его к списку неприятных истин.