К 89-му дню рождения Никлауса Вирта

Богатырёв Р.

15 февраля… Сегодня исполняется 89 лет швейцарскому проф. Никлаусу Вирту (Niklaus Wirth), едва ли не последнему из могикан компьютерных наук и технологий. По масштабу и глубине своих работ он в этой области стоит примерно на той же вершине, что и Иоганн Себастьян Бах в классической музыке. Да, я не оговорился.

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

Знаменитый европейский триумвират, три друга, три титана европейской школы программирования, несколько десятилетий назад определявшие и ключевой вектор развития советской науки: голландец Эдсгер Дейкстра, англичанин Энтони Хоар, швейцарец Никлаус Вирт… Сегодня здравствуют Хоар и Вирт. Обоим исполнилось по 89 лет. Хоару в январе, Вирту — в феврале.

Другим атлантам, сопоставимым им по уровню, поменьше: американцам Дональду Кнуту — 85, Кену Томпсону — 80. И эти юбилеи были в январе и феврале 2023 г. Как, вы о них не слышали? Да неужели? Неудивительно. Мир сильно деформировался ментально. Даже в этой едва ли не самой главной интеллектуальной сфере…

А ведь все имена, что перечислил, — по сути Нобелевские лауреаты. Точнее, лауреаты награды, аналогичной Нобелевке, — лауреаты Премии Алана Тьюринга (Turing Award): Эдсгер Дейкстра (1972), Энтони Хоар (1980), Никлаус Вирт (1984), Дональд Кнут (1974), Кен Томпсон (1983).

Не может не радовать, что есть ещё «опытная молодёжь», про которую при номинации на Премию Тьюринга умудрились-таки вспомнить в пандемийном 2020 г. Те самые отцы-основатели теории трансляции — Альфред Ахо и Джеффри Ульман. Правда, первому «всего» 81 год, а второму — 80.

Сколько же лет должно пройти, пока в области компьютерных наук и технологий появится свой Пантеон, подобный Пантеону классической музыки? О котором будут знать миллионы. Или хотя бы десятки тысяч. Не исключаю, что ещё не одно десятилетие. А, быть может, и несколько столетий. Если принять во внимание сильное измельчание нашего прогрессивного человечества.

В 2005 г. мне довелось не одну неделю тесно общаться с проф. Никлаусом Виртом. Тогда совместно с коллегами организовывал его Большое турне по ведущим университетам России. Огромного масштаба личность. Достойная не одной книги.

Но сегодня почему-то вспомнилась его скромная статья «A Plea for Lean Software» (1995). Она вышла в переводе на русский язык в 1996 г. в журнале «Открытые системы».<

Иными словами, была написана почти 30 лет назад! Да, в тот год (1995), когда появились Java, PHP, Internet Explorer. На горизонте ещё не было Рамблера, Яндекса и Гугла. До Facebook и YouTube было почти 10 лет.

Приведу здесь свою избранную подборку фрагментов той статьи. Составил её так, чтобы аналогии были понятны практически для любой сферы деятельности передового и прогрессивного человечества. Будь то политика, экономика, наука или искусство. Просто замените слова «аппаратура», «память» понятием ресурса.

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

====

/ Никлаус Вирт. Долой «жирные» программы // Открытые системы, 1996, № 6.

« Стало правилом: всякий раз, когда выпускается новая версия программного продукта, существенно — порой на много мегабайт — подскакивают его требования к размерам компьютерной памяти. Когда такие запросы превышают имеющуюся в наличии память, приходится закупать дополнительную. Когда же дальнейшее расширение невозможно, то надо приобретать новый, более мощный компьютер или рабочую станцию. Но идут ли большая производительность и расширенная функциональность в ногу со всё увеличивающимися запросами на вычислительные ресурсы? В большинстве случаев ответ будет — нет.

Лет 25 тому назад (т.е. лет 50 тому назад — прим. Р.Б.) интерактивный текстовый редактор мог быть спроектирован из расчёта всего лишь 8000 байтов памяти — современные редакторы текстов программ требуют в 100 и более раз больше. Операционная система должна была обслуживать 8000 байтов, и компилятор должен был умещаться в 32 Кбайт, в то время как их нынешние потомки требуют для своей работы многих мегабайтов.

И что же: это раздутое программное обеспечение стало быстрее и эффективнее? Наоборот. Если бы не аппаратура с её возросшей в тысячи раз производительностью, современные программные средства было бы просто невозможно использовать. Считается, что расширенная функциональность и удобства пользователя оправдывают всё возрастающие размеры программ; однако, более пристальный взгляд обнаруживает шаткость подобных оправданий. Тот же текстовый редактор всё ещё выполняет достаточно простую задачу по вставке, удалению и переносу фрагментов текста; компилятор по-прежнему транслирует текст в исполняемый код; и операционная система, как и в былые времена, управляет памятью, дисковым пространством и циклами процессора. Эти базовые обязанности вовсе не изменились с появлением окон, стратегии «вырезание-вставка» и всплывающих меню, так же как и с заменой текстовых командных строк изящными пиктограммами.

Столь явный взрывной рост размеров программного обеспечения был бы, конечно, неприемлем, если бы не ошеломляющий прогресс полупроводниковой технологии, которая улучшила отношение цена/производительность в степени, не имеющей аналогов ни в какой другой области технологии. Так, с 1978 по 1993 гг. для семейства процессоров Intel 80х86 производительность увеличилась в 335 раз, плотность размещения транзисторов — в 107 раз, в то время как цена — только в 3 раза. Перспективы для постоянного увеличения производительности сохраняются, при том, что нет никаких признаков, что волчий аппетит, присущий ныне программному обеспечению, будет в обозримом будущем утолён <…>

Следующие два «закона» чрезвычайно хорошо (хотя и с долей иронии) отражают нынешнее положение дел:

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

Неконтролируемый рост размеров программ принимается как должное также и потому, что потребители имеют затруднения в отделении действительно существенных особенностей программного продукта от особенностей, которые просто «хорошо бы иметь». <…>

Причины громоздкости программного обеспечения

Итак, два фактора вносят вклад в приятие потребителями программного обеспечения всё более растущих размеров:

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

Но, быть может, более важно, чем просто найти причины для такой толерантности, попытаться понять, что же обуславливает дрейф программного обеспечения навстречу сложности.

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

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

Сложность как эквивалент мощности

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

Возможно, эта тенденция происходит от сомнительной веры в то, что до некоторой степени таинственное средство сообщает ауру чего-то сверхестественного пользователю (хотя что оно действительно «сообщает», так это чувство беспомощности, если не бессилия). Поэтому, соблазн сложности как стимула для продаж легко понятен; сложность способствует поддержанию зависимости потребителя от поставщика. <…>

Конечно, клиент, который платит — вперёд! — за договорный сервис, являет собой более стабильный источник дохода, чем клиент, который полностью самостоятельно освоил продукт. Промышленность, вероятно, преследует цели, весьма отличные от принятых в академическом мире; следовательно, можно сформулировать ещё один «закон»: зависимость клиента более доходна, чем его обучение. <…>

Времени всегда не хватает

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

Ещё одной характерной чертой компьютерной индустрии является тот факт, что поставщик, которому удалось первым выбросить продукт на рынок, как правило, получает ощутимые преимущества над конкурентом, чей аналогичный — и лучший по качеству! — продукт появляется вторым. Тенденция принимать первый появившийся продукт в качестве стандарта de facto — это крайне прискорбный феномен, вызванный к жизни всё той же спешкой.

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

Тщательная инженерная работа не приносит дивидендов в лихорадочных гонках на короткие дистанции... <...>

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

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

Об авторе: Руслан Богатырев — директор Европейского центра программирования им. Леонарда Эйлера, главный редактор арт-журнала «Пантеон».
Помещена в музей с разрешения автора 15 января 2023