The fruits of misunderstanding. EWD854.
Такое впечатление, что некоторые вещи возможны только в мире ИТ (computing). Объявлено о разработке новой продукции, и все глотают слюнки в предвкушении её увидеть. Но, когда продукция готова, люди начинают пользоваться ею и видят, что она самым бесстыдным образом не способна выполнять своё предназначение. Это означает провал, и это должно быть ясно каждому. Даже в голове не укладывается следующее развитие событий: все забывают о первоначальной цели и считают продукцию удачной.
Подумайте о другом примере, я говорю о языке Кобол, главной целью которого было сделать профессионального программиста излишним и который сейчас является главным инструментом трёх из каждых четырёх программистов. Во имя «облегчения программирования», «читабельности», «понимабельности» его многословность рассматривалась как добродетель; в реальности та самая многословность оказалась наиболее выпуклым его дефектом.
Кобол не был исключением. Когда в 60-х годах «высокоуровневые» языки программирования не принесли обещанного спасения, решили, что медленная реакция компьютера при пакетной обработке делает невозможным эффективную отладку, и во имя быстрой реакции в широких масштабах внедрили «интерактивное программирование». На его распространение не повлияло даже то, что контролируемые эксперименты показали в лучшем случае маргинальную выгоду от средств интерактивной отладки.
В 1968 году Сюзи Майер (Susie Mayer) сообщила нам в рекламе, счастливо улыбаясь, что она решила все свои программистские нужды с помощью языка PL/I. Но, когда через несколько лет Харлан Д. Миллз и Тед Бейкер выполняли «разработку модели» (model development) системы для «Нью-Йорк таймс», им пришлось усилить свою команду экспертом по PL/I.
Но это всё в прошлом и не повторится, потому что недавно мы обнаружили, что:
Мы оставляем в качестве упражнения придумать рекламные девизы, которые объясняют, почему панацеи (i), (ii) и (iii) превратились в кошмар.
Грубые факты состоят в том, что большая часть истории ИТ состоит из многомиллионных провалившихся проектов. Конечно, это происходит и в других дисциплинах, но у ИТ есть уникальная особенность, состоящая в том, что там провал проектов был очевиден с самого их начала. Это длинная история воздушных замков, следующих один за другим. Феномен является настолько стойким, что требует объяснения. Как мы можем объяснить повторяющиеся ошибки в оценке технических нюансов?
Большое количество провалов можно объяснить тем, что мир ИТ наводнён сознательными лжеучёными и мошенниками, но я отвергаю это объяснение потому, что оно, во-первых, слишком горькое, чтобы быть здравым, во-вторых, неправильное: в общем и целом, люди искренне надеются на успех. Очевидно, что мы столкнулись с распространённым непониманием, настолько стойким, что его невозможно игнорировать.
Как большинство людей понимают? Что большинство людей понимают под «пониманием»? Мы организуем наши впечатления, пока не удовлетворимся результатом. Деревья в саду сегодня беспокойны, и дымоход очень шумит. Но эти наблюдения не беспокоят меня. Я знаю способ обработать их, который меня удовлетворяет: я регистрирую их под заголовком «ветрено» и забываю. В другой раз на морской прогулке я вижу беспокойные волны, и это тоже не беспокоит меня: в конце концов, какая разница между волнующейся водой и волнующейся листвой? Разницы нет, если нам удобно не замечать её. С возрастом мы придумываем метафоры, усваиваем методы мышления. (Вы заметили, что я назвал деревья «беспокойными»? Это было не нарочно!) Они показывают, как мы организуем впечатления и используем язык.
Вышеизложенное показывает самый известный способ справиться с новизной; когда мы сталкиваемся с чем-то новым и неизвестным, мы пытаемся связать его с тем, что нам знакомо. Чтобы достичь этого, мы придумываем аналогии.
Ясно, что этот способ понимания мало помогает, когда мы сталкиваемся с чем-то настолько радикально новым и беспрецедентным, что все аналогии бесполезны, потому что слишком слабы или поверхностны. Так бывает во время появления радикально новой технологии. Распространённость недоразумений о программировании указывает на то, что родилась радикально новая технология, а конкретнее, автоматический компьютер. (Другой пример разрыва, который не может быть сшит аналогиями, — ядерное оружие.)
Существует другой подход к новизне, которым пользуются гораздо реже. Очевидно, он не является «естественным», потому что нужно много тренироваться, чтобы его применять. Этот подход состоит в том, что человек не пытается связать новый опыт с прошлым опытом (понимая, что прошлый опыт не подходит, так как собран случайно). Наоборот, человек подходит к новинке с разумом настолько чистым, насколько возможно, и пытается понять эту новинку, исходя только из её внутренних закономерностей. (Когда вы учите иностранный язык, не переводя слова с иностранного языка на родной язык и наоборот, вы применяете этот подход. Это единственный выход, если языки предназначены для выражения разных мыслей: человек должен научиться «думать» на новом языке.) Я полагаю, что ИТ являются настолько беспрецедентным явлением, что только второй подход адекватен, и поэтому мы обязаны прекратить подходить к ИТ с помощью аналогий.
Чтобы было легче освободиться от аналогий, давайте рассмотрим, почему общеизвестные метафоры и аналогии заводят в тупик.
Я считаю, что антропоморфизм является самой вредной сказкой. Программы «пытаются что-то сделать», «хотят что-то сделать», «считают, что нечто истинно», «знают что-то» и так далее. Не утешайте себя наивно, что это всего лишь невинные обороты речи. Они соблазняют программиста отождествить себя с исполнением программы, практически толкают его на применение операционной семантики.
Мы не поймём большое множество, рассмотрев «достаточное количество» его элементов, потому что это чрезвычайно неэффективно. В идеале отдельные элементы пропадают, человек работает непосредственно с определением множества. Когда мы пытаемся понять программу, мы не должны смотреть на отдельные вычисления, в идеале (то есть ради эффективного мышления) мы должны работать с целой программой, временно забывая, что можно интерпретировать исполняемый код. Всё это хорошо известно, и это называется «аксиоматический метод». Суть в том, что использование антропоморфных терминов возводит стену на пути этого метода. Антропоморфизм приводит к тому, что наиболее эффективный метод разработки программ и рассуждений о программах отвергается как «контринтуитивный» или «слишком абстрактный». Это очень серьёзно.
Я приведу лишь некоторые из многочисленных недоразумений, которые возникли из-за того, что программные формализмы были названы «языками». Есть генерал, который написал: «Конечно, НАТО не заинтересован в таком искусственном языке программирования, как Паскаль». Таким же образом родилась идея, что «живой» язык программирования лучше «мёртвого». Недавно один из филиалов промышленного предприятия получил из штаб-квартиры запрошенную программу, но программа была написана на Паскале. Филиал заказал другой фирме переписать эту программу на Фортране, «потому что Паскаль не поддерживается».
Сейчас пошла мода делать всевозможные «умные» системы и компоненты. Если выпарить воду, то этот почин сводится к разработке пушистого интерфейса между пользователем и компьютером, который делает компьютер как можно меньше похожим на компьютер: необходимо любой ценой замаскировать сильнейшую сторону компьютера — эффективное воплощение формальной системы. Достаточно об антропоморфизме. (Сегодня утром я отказался писать популярную статью на тему «Могут ли машины думать?» Я сказал редактору, что я считаю вопрос плохо сформулированным и таким же неинтересным, как вопрос «Могут ли подводные лодки плавать?» Но редактор, а он занимался общественными науками, остался невозмутим: последний вопрос он тоже считал весьма интересным.)
Изобретение термина «инженерия ПО» дало жизнь ещё одной пустой аналогии. Продукт компетентного программиста рассматривается как продукт инженера, то есть нетривиальный надёжный механизм. Но на этом аналогия заканчивается.
В отличие от продукта инженера, сделанного из физических компонентов, программа является абстрактным механизмом, сделанным, так сказать, из нулей и единиц. И это существенное различие.
Начнём с того, что программа не изнашивается, не рвётся, не требует поддержки, то есть обслуживания (maintenance). И всё равно термин «поддержка ПО» возник, добавив путаницы.
Во-вторых, поскольку механизм является абстрактным, производство этого механизма включено в его проектирование. Это делает программу похожей на поэму: нельзя написать поэму, не написав её. Но люди относятся к программированию как к производственному процессу и измеряют «продуктивность программиста» в «произведённых строках кода». При этом они записывают это число не в ту колонку: мы должны говорить о «затраченных строках кода».
В-третьих, более высокое качество, более высокая надёжность, более высокая точность физического механизма всегда требуют бо́льших затрат. Но в случае программ корреляция является обратной, так как бо́льшие затраты и ненадёжность растут из одного корня — из того, что мы не смогли овладеть сложностью. Тем не менее, многие оправдывают ненадёжность коммерческого ПО тем, что доводить программу до ума слишком дорого.
Наконец, инженерная парадигма разработки не годится. Инженер проектирует машину на пределе своих возможностей, изготавливает прототип и испытывает его. Если прототип работает неудовлетворительно, инженер дорабатывает конструкцию и повторяет цикл. В некоторых обстоятельствах это интерактивное проектирование имеет смысл; необходимо, чтобы цепочка обратной связи была замкнутой. И мы знаем, что с программами это невозможно. (Это возможно, пожалуй, со смехотворно тривиальными программами.) Многие менеджеры, которые знают единственную парадигму, — доработку прототипа, настолько обескуражены этим препятствием, что они его просто игнорируют. Неудивительно, что так называемая «инженерия ПО» стала движением, ищущим, как «программировать, если ты не умеешь программировать».
Существует докомпьютерный объект, который больше всего похож на хорошо спроектированный программный код. Это математическая теория. Но и эта аналогия не безгрешна. У неё есть социальная проблема: она не очень популярна. Покупатели вычислительных систем считают недружественным к пользователю всё, что имеет легчайший запах математики. У этой аналогии также есть техническая проблема.
Массив традиционной математики очень неформален: математики не манипулируют формулами, формулы обозначают что-то. Для математики характерно прыгать от формулы к её интерпретации и обратно, и интерпретация должна обосновывать манипуляции с формулой. Манипуляции разрешены не потому, что выполняются по явным правилам, а потому, что эти манипуляции выглядят «очевидно» в интерпретации. В общем и целом, математические результаты намного менее формальны, чем думают сами математики.
Если вы спросите, «хорошо» это или «плохо», то ни то ни другое. (Математики, имеющие пуританскую жилку, стыдятся этого факта.) Дело в том, что в ИТ эта неформальность в большинстве случаев неприемлема, если вы хотите подойти к программированию математически. Есть 2 причины, по которым она неприемлема.
Во-первых, каждая вычислительная система воплощает некоторую формальную систему. Мы, конечно, можем скрыть этот факт, снабдив её таким огромным количеством сложных и плохо документированных свойств, что её будет невозможно использовать. Иногда это делают случайно, иногда специально, для того, чтобы получить инструмент для неформальной работы: скажем так, компьютер симулирует некомпьютер; в нашем случае можно не обращать внимания на эту область.
Во-вторых, неотъемлемая дискретность обработки символов делает программирование настолько тонкой работой (опять же, если мы хотим подойти к нему математически), что просто необходимо применять формальные техники. Ради безопасности необходимо выполнять рассуждение в основном путём манипулирования неинтерпретированными формулами по явным правилам. Если мы будем обосновывать это манипулирование интуитивно, то будем делать много ошибок по комбинаторным причинам.
Есть и другой аспект, которым информатика как раздел математики отличается от докомпьютерной математики. Традиционная математика разделилась на множество различных областей, каждая из которых имеет собственный массив знаний. (До такой степени, что стала обычной жалоба, что математики из разных областей не понимают друг друга.) Как раздел математики, информатика отличается тем, что она имеет довольно малый объём математических знаний. Когда-то я обвинял в этом молодость дисциплины. Я решил, что добыча новых знаний будет достойной целью. Однако эта цель так и не получила официального статуса, а с возрастом просто поблекла. Некоторая нерелевантность специального знания к ядру темы становится понятной при ретроспективном взгляде: она следствие того, что компьютеры действительно являются «универсальными» приборами. Стремление добывать знания поблекло, когда «quo modo» стало поглощать моё внимание больше, чем «quod». (Мне всегда не нравилось, что образование называют «передачей знаний»; теперь я понимаю, почему этот термин неадекватен по крайней мере в информатике.)
Если (как я начинаю верить) знание будет играть скромную роль в этой области, то это отразится на методах преподавания. То, что сейчас называют «методологией», будет играть более важную роль в преподавании информатики, чем в преподавании математики. Во всём мире математическая работа и преподавание математики тесно связаны, и в информатике этот аспект чувствуется ещё сильнее. Его невозможно проглядеть. Многие информатики не любят подчёркивать, что их область имеет математический характер, потому что боятся, что их слова примут за просьбу включить в учебную программу «больше анализа, больше статистики, больше алгебры с теорией групп», тогда как они просили «больше строгости, больше элегантности, больше гигиены, более убедительной логики».
И тут возникают самые разные трудности. Мы вынуждены планировать завтрашний день сегодня, пользуясь вчерашними словами, и слова не помогают разобраться с такой беспрецедентной трудностью, как ИТ. Если мы не придумаем новые термины, мы должны вложить новый смысл в старые термины. К сожалению, в мире ИТ больше любят придумывать новые термины со старым смыслом (или вообще без смысла).
|
Нидерланды
5671 AL NUENEN
Plataanstraat 5
|
19 мая 1983 года
prof. dr. Эдсгер Вибе Дейкстра
Burroughs Research Fellow
|