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

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

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

Порочный круг был однажды разорван, когда распространился Паскаль. При поддержке коллег-единомышленников и в упорном противостоянии рутинерам, Паскаль распространился в учебных заведениях и проник в индустрию. Это произошло несмотря на могучую конкуренцию со стороны индустрии и других больших организаций, в соперничестве с языками PL/1, Алгол 68 и Ада. Однако наследники Паскаля, существенно его превосходившие, Модула-2 и Оберон, не получили должного внимания среди преподавателей, и сами пали перед лицом самого недостойного из соперников — C. Самого недостойного, т.к. в этом языке были нарушены все открытые к тому времени принципы серьезного программирования. Он запутывает студентов, допуская разный смысл для x = y и y = x и принуждая всех писать x = = y вместо обычного x = y. Только за одни эти пороки он заслуживает изгнания из учреждений образования. Однако сей уродливый синтаксис был целиком воспроизведен в языке Java, принятие которого академическим сообществом произошло по меньшей мере отчасти благодаря этой преемственности.

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

Начинаться сжатым введением в основные понятия программного проектирования.
Использовать лаконичную формальную нотацию, строго определенную не более чем на примерно 20 страницах.
Основываясь на этой нотации, вводятся основные понятия итерации, рекурсии, логического утверждения <assertion> и инварианта.
Центральная тема — структурирование утверждений и типизация данных.
За этим следуют концепции упрятывания информации, модульности и проектирование интерфейсов, продемонстрированные образцовыми примерами.
Книга устанавливает терминологию, которая столь же интуитивна, сколь и точна.
Книга имеет умеренный размер.


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

LVV>Класссс!!!!!

Безопасность пилотов и пассажиров должна начинаться уже на уровне компиляторов.

Взрыв 4 июня 1996 г. ракеты Ариан-5, стоившей пол-миллиарда долларов, имел причиной программную ошибку, которую компилятор Оберона/Компонентного Паскаля просто не пропустил бы.

Отношение объемов описаний языков — 16 стр. для Оберона, 200 для Java и больше 1000 для C++.

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

Наконец, как ни парадоксально это звучит, даже если бы компьютерные системы действительно были надежнее "традиционных", то это вовсе не обязательно означает, что они обеспечивают большую безопасность. Дело в том, что надежность ПО традиционно определяется степенью его соответствия зафиксированным в спецификациях требованиям; однако, часто бывает так, что ПО делает именно то, что ему и было предписано, и авария Ariane 5 – классический тому пример: и злополучное вычисление посторонней для полета величины горизонтального отклонения Инерциальной Платформы, и реакция на него вплоть до выведения из строя всех навигационных систем и бортовых компьютеров – все это случилось в полном соответствии с Требованиями, которые были частично унаследованы от Ariane 4 и не отражали новых реальностей. Более того, по сравнению с ошибками в коде именно спецификационные ошибки обычно ведут к более тяжелым последствиям – компетенции разработчиков ПО недостаточно для обнаружения таких ошибок. Программный комплекс – сложная система, однако реальный мир, отражаемый в спецификационных требованиях – еще более сложен и требует специальных экспертных знаний. Так что надежность ПО и его безопасность – понятия, хотя и перекрывающиеся, но не идентичные.