Can computing science save the computer industry? EWD920.
Да-да, именно так: может ли информатика спасти компьютерную отрасль (computer industry)? Очень хороший вопрос. В нём чувствуется дух дискуссии. Кафедры информатики всех вузов работают (и получают финансирование) на основании неявного предположения, что ответ несомненно утвердительный. (Это предположение принимается в тех кругах настолько неявно, что его никогда не обсуждают.) Однако компьютерная отрасль работает, также исходя из настолько же неявного предположения, что — хвала Господу! — информатика ничем не может помочь в её деле, которое — как всем известно — в основном относится к области маркетинга, зависит от умения придумать подходящий к текущему моменту девиз, под которым новый воздушный замок будет выдаваться за солидное предприятие.
Пока дела идут хорошо, ни у кого нет желания касаться этого вопроса. Но ситуация меняется. Отрасль в кризисе, потому что затраты на разработку и поддержку растут и обыватели разочаровываются в продуктах отрасли. Вузы тоже испытывают трудности — бум ИТ сократил штат и увеличил педагогическую нагрузку, что касается информатики, то у преподавателей уже не хватает на неё времени и студентов она не интересует. Так давайте поднимем этот вопрос.
* * *
Сначала мы должны рассмотреть некоторые факты.
(A) Суть задачи, которую взяла на себя информатика, — как не запутаться в созданных нами вещах. Далее заметим, что в тех областях, где информатика целенаправленно решала эту задачу (например, разработка программ), она добилась заметных успехов.
(B) Я жду такой стадии развития техники — которая ещё не достигнута — когда все продукты компьютерной отрасли — например, микропроцессоры — станут (в некотором смысле) дешевле своей документации. Составление компактной и исчерпывающей функциональной спецификации — традиционно занимающее месяцы, если не годы, происходящее пост-фактум, если вообще происходящее — считается трудной (или невозможной) задачей. Короче говоря, компьютерная отрасль не может сделать достаточно простыми и ясными даже свои независимые продукты.
(C) Главным источником сложности являются так называемые «стандарты де-факто», будь это языки программирования (Фортран, PL/I, Кобол, Ада), СУБД или сетевые протоколы. Чтобы добиться существенных успехов — например, в программировании — игнорирование этих стандартов де-факто является необходимым условием. На самом деле стандарты де-факто настолько ужасны — все! — что если компьютерная отрасль будет настаивать на их сохранении — по так называемым «здравым коммерческим соображениям» — то информатика не сможет спасти её.
(D) Компьютерная отрасль отзывается о своих клиентах крайне презрительно: с пользователем (которого иногда для усиления называют «конечным пользователем») обращаются как со слабоумным, например, «делая наши системы настолько дружественными, что их может использовать даже домохозяйка». Они унижают даже своих работников. В действительности, менеджмент часто использует невежество работника, его нежелание учиться, его неумение писать ясно и кратко как оправдание для того, что невозможно сделать работу более качественно. До тех пор, пока менеджмент настаивает на этих оправданиях, информатика не может спасти компьютерную отрасль.
(Побочное замечание. Если безграмотные инженеры проектируют, а технические писатели описывают разработку — это тупиковое разделение труда: разработчик не получает обратной связи, в которой нуждается. Разработка языков программирования научила нас принципу — который был практически проигнорирован в процессе разработки языка Ада! — что формулирование точных определений регистрирует зарождающуюся сложность на ранних этапах.)
(E) Пристрастие отрасли к поиску лучших «инструментов» — это отражение презрительного отношения, упомянутого в (D). Это отражение философии менеджмента, что ради сохранности и стабильности организации она должна как можно меньше опираться на индивидуальные способности работников. Забудем, что эта традиция намного старше высокотехнологичной компьютерной отрасли и по этой причине, скорее всего, является неадекватной. Пока менеджеры рассматривают разработку программ как производственный процесс — так они и делают! — и выражают «производительность программиста» в «количестве строк кода в день» — так они и делают! — их интеллектуальные категории действительно неадекватны. На моих лекциях для программистов по программированию самой частой реакцией было «Какая жалость, что этого не слышит наш менеджер!» Я заключаю, что если компьютерная отрасль не может обновить — обучив или заменив — технически некомпетентный менеджмент, то информатика не может спасти компьютерную отрасль.
Некоторые читатели могут подумать, что условия (C), (D) и (E) настолько «нереальны», что уже доказано, что информатика не может спасти компьютерную отрасль. Этим людям не стоит читать дальше. Дальнейший текст написан исходя из предположения, что в один прекрасный день компьютерная отрасль окажется мудрой или растеряется настолько, что поймёт, что нереально ждать радикальных улучшений без радикальных изменений.
(F) Продолжаем наши наблюдения. Прагматичный разработчик обычно пользуется парадигмой под названием «индукция для нищих», то есть он верит, что его изделие работает корректно до тех пор, пока не столкнётся с фактом, что это не так. (Тогда он «дорабатывает» своё изделие.) Тот, кто разрабатывает на основе научных принципов, верит в корректность, потому что он понимает, почему изделие будет работать при любых условиях. Переход от прагматичной разработки к научной действительно является радикальным шагом для компьютерной отрасли.
(G) Наоборот, если индустрия не перейдёт от прагматичной разработки к научной, то её интеллектуальные силы будут узурпированы бесконечной «поддержкой» систем, которые не были спроектированы должным образом.
(H) Складывая (F) и (G), получаем главную ответственность отраслевых исследований по информатике: сделать переход от прагматичной разработки к научной реальным. Я считаю её «главной» в том смысле, что — смотри (G) — эта цель критична, так как, если она не будет достигнута, мы приходим к выводу, что информатика не может спасти компьютерную отрасль.
(I) Ответственность, описанная в (H), является математической задачей, но с задачами такого масштаба мы раньше не сталкивались. Математические традиции, зародившиеся в предыдущих столетиях, хотя и освящённые временем, больше неадекватны, и мы должны научиться рассуждать на порядок эффективнее, чем умеем сейчас. Отсюда следует, что «математическая методология» должна стать главным объектом исследований информатики (и что компьютерная отрасль должна понять, что математическая элегантность — не роскошь, а решающий фактор технического успеха компьютерной продукции).
(J) Есть несколько аргументов за то, что исследования математической методологии будут щедро вознаграждены. Во-первых, этой областью практически не занимались; не случайно «Concise Oxford Dictionary» в 1976 году дал следующее определение математики: «Абстрактная наука о пространстве, числах и количестве». Во-вторых, кодификация того, как люди думают (точнее, как люди должны думать, чтобы не допускать ошибок), традиционно была призванием логики — «служанки философии»; хотя математическая логика развивается, наше освобождение от оков естественных языков с помощью логических формализмов только начинается. В-третьих, если существует аналогия между программированием и математикой — а я думаю, что существует глубокая аналогия, — то стоит надеяться, что исследование математической методологии будет настолько же полезным, насколько полезным было исследование методологии программирования. (Можно возразить, что сегодняшняя математика так же парализована концепцией «среднего математика», как программирование парализовано концепцией «среднего программиста».)
(K) Ожидается, что по техническим причинам всё большая часть математических рассуждений будет выполняться путём формальных вычислений, то есть путём манипулирования неинтерпретированными формулами. Этот переход будет сделан ради эффективности и независимо от того факта, что формальные вычисления пригодны для механической верификации. Такие инструменты следует одобрять потому, что они обеспечивают надёжность, а не из-за (тщетной) надежды, что они помогут справиться со сложностью. Информатика должна учитывать, что использование инструментов может выйти боком. (Чем легче исправлять ошибки, тем больше ошибок будут делать.) Глядя на то, как САПР для производства микросхем всё больше деградирует до автоматического генератора разноцветных плакатов всё большего и большего размера, я сомневаюсь, что компьютерная отрасль будет сдерживаться после того, как осознает возможности и потенциал механической верификации. Но предупреждение не повредит, даже если оно не будет услышано.
* * *
Вернёмся к начальному вопросу — «Может ли информатика спасти компьютерную отрасль?» Мой ответ — «Если что-то и может спасти компьютерную отрасль, то только информатика». Но до того момента, когда отрасль — особенно крепко стоящие на ногах фирмы — согласится с этим утверждением, может пройти много времени. Без сомнения, это займёт больше времени, чем тот ограниченный период, на который они планируют свою деятельность. В ближайшем будущем у научного сообщества — которое традиционно имеет далеко идущие планы — есть только один вариант. Оно должно совершенствовать понятие о вычислениях на пределе своих возможностей и обучать ему; чем уступить давлению и распространять ущербные практики сегодняшнего дня, лучше закрыть контору.
Не надо напоминать мне, что неизбежная обязанность готовить неприспособленных людей создаёт трудности. Да, создаёт и для университетов, и для преподавателей, и для студентов. Я никогда не говорил, что путь науки усыпан лепестками роз. Чем больше неприспособленных людей мы подготовим, тем быстрее закончится переход — об этом надо думать. Если ущербная практика будет продолжаться и дальше, компьютерная индустрия рухнет, и невозможно будет спасти то, чего нет.
Остин, 1 мая 1985 года.