Недавно одной небольшой авиакомпании пришлось полностью прекратить работу из-за проблемы программного обеспечения планирования работы экипажей. Это происшествие вызвало беспокойство Конгресса, не говоря уже о пассажирах. Мой ноутбук может сохранить по 200 страниц текста (1/2 мегабайта) для каждого члена всех экипажей этой авиакомпании, только в оперативной памяти, и в 100 раз больше информации (целую энциклопедию из 20 тысяч страниц) для каждого члена экипажей на жестком диске. Но для планирования графиков работы нужны всего одна-две — максимум десять — страниц для одного члена экипажа. Даже учитывая все юридические документы — законы, соглашения с профсоюзами, местные и федеральные налоги, налоги разных штатов, ограничения рабочего времени, требования Федерального управления гражданской авиации относительно сертификации членов экипажа, — кто мог предположить, что с точки зрения компьютерной техники эта проблема непроста? Ведь нужно сохранить и обработать максимум десять страниц информации на человека, притом что мощность одного недорогого ноутбука позволяет сохранить и обработать в 2000 раз больше! Конечно, эта проблема сложна, но не запредельно. Все правила и законы, связанные с планированием рабочего времени экипажей авиакомпании, можно описать меньше чем на 1000 страниц — это 0,5% оперативной памяти ноутбука.

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

Почему так произошло? Я бы хотел использовать в качестве метафоры криптографию. Мы берем сообщение и зашифровываем его с помощью ключа, при этом для создания кода мы используем функцию, которую трудно воспроизвести. Программисты, следующие современной парадигме, сначала формулируют проблему — например, что Боингу-767 нужен пилот, второй пилот и семь человек экипажа, и каждый из них должен пройти определенную сертификацию. Затем они используют свои знания в сфере компьютерных наук и разработки компьютерного обеспечения. Именно так эти вводные данные можно закодировать на компьютерном языке и превратить в алгоритм. Процесс комбинирования — это и есть процесс программирования. Его результат — исходная программа. Так вот, как известно, программирование — это функция, которую трудно инвертировать, хотя возможно, и не по стандартам криптографии. Можно пошутить, что если авиакомпания хочет сохранить в тайне свои правила планирования рабочего времени, то может опубликовать вместо них код исходной программы, ведь никто никогда его не расшифрует. И даже не поймет, к чему этот код относится — к планированию рабочего времени или к поставкам запасных частей. Он может быть совершенно непонятным.

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

Упомянутая выше проблема авиакомпании очевидно упрощена. Но если рассмотреть эту проблему в кривом зеркале кодирования при разработке компьютерных программ, она становится почти неузнаваемой: в тысячу раз более бестолковой, бессвязной, и совершенно искусственной. Что здесь можно сделать? Следовать метафоре криптографии. Во-первых, сформулировать проблему — «первоначальное сообщение», как в нашем примере с полевым генералом. Это ни в коем случае не программа, а просто запись мнений экспертов по данному вопросу, на их профессиональном жаргоне, их собственными словами. Затем нужно поручить программистам разработать не программу для решения проблемы, а генератор программ, который будет комбинировать мнения экспертов с параметрами текущей ситуации и сам создаст окончательный код. Это называется порождающим или генеративным программированием. А генератор — механизированное выражение опыта и знаний программистов, что эффективно отделяет исходную проблему от проблемы разработки программного обеспечения. Поэтому изменения в одной из этих двух сфер не вызывают изменений в другой — ведь вклад другой стороны осуществляется либо посредством генератора, либо через формулирование проблемы. По этой причине я верю, что генеративное программирование — будущее программного обеспечения.

АЛАН КЭЙ — известный специалист в сфере компьютерных наук. В 1970 году пришел в исследовательский центр корпорации Xerox в Пало-Альто (PARC) и стал одним из его ведущих сотрудников. Участвовал в разработке прототипов рабочих станций, объединенных в единую сеть, на основе языка программирования Smalltalk. Один из «отцов» идеи объектно-ориентированного программирования и автор концепции Dynabook, ставшей основой для разработки ноутбука. Президент Научно-исследовательского института формирования убеждений и старший партнер Hewlett Packard Laboratories.

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

Например, в компьютерных науках существует очень мало доказательств, заслуживающих внимания. (Известный программист Дон Кнут из Стэнфордского университета любит повторять: «Бойтесь ошибок предложенного кода; я только проверил его правильность, но не применял его».) Нам бы хотелось доказать правильность компьютерных программ, но либо для этого у нас нет достаточной степени свободы или (о чем говорит Кнут) очень сложно быть уверенными в том, что мы учли все возможные ситуации. Поэтому в компьютерных науках догадки часто касаются архитектуры или набора эвристических правил.