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

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

Я мечтал, что разработчики избавятся от подробностей текстового кода и начнут строить системы на более высоком диаграммном уровне. В самых дерзких мечтах программисты вообще становились лишними. Архитекторы могли строить целые системы по диаграммам UML. Ядро системы – огромное, бесстрастное и равнодушное к бедам обычных программистов – преобразует диаграммы в исполняемый код. Так выглядела великая мечта модельно-ориентированной архитектуры (MDA, Model Driven Architecture).

К сожалению, у великой мечты имеется один крошечный изъян. MDA предполагает, что проблемы создает код. Однако код сам по себе не создает проблем и никогда не создавал. Проблема заключается в детализации.

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

Какими же подробностями мы управляем?

Вы знаете, чем различаются два символа \n и \r? Первый, \n – перевод строки (line feed), а второй, \r – возврат каретки (carriage return). Что такое «каретка»?

В 1960-х и начале 1970-х годов основным устройством вывода для компьютеров был телетайп. Модель ASR33 была самой распространенной.

Устройство состояло из печатающей головки, которая могла печатать до 10 символов в секунду. Печатающая головка состояла из цилиндра, на котором были нанесены рельефные символы. Цилиндр поворачивался так, чтобы к бумаге был обращен правильный символ, после чего молоточек ударял по цилиндру и прижимал его к бумаге. Между цилиндром и бумагой проходила красящая лента, краска с которой переносилась на бумагу в виде символа.

Печатающая головка перемещалась на каретке. С каждым символом каретка сдвигалась на одну позицию вправо, вместе с ней смещалась и печатающая головка. Когда каретка доходила до конца 72-символьной строки, каретку приходилось возвращать в начало строки, отправляя символ возврата каретки (\r = 0x0D); без этого печатающая головка продолжала бы печатать символы в 72 столбце, и от многократной печати там появился бы черный прямоугольник.

Конечно, этого было недостаточно. Возврат каретки не приводил к смещению бумаги к следующей строке. Если бы после возврата каретки не передавался символ перевода строки (\n = 0x0A), то новая строка была бы напечатана поверх старой.

Итак, для телетайпа ASR33 строки должны были завершаться последовательностью «\r\n». Однако и здесь была необходима осторожность, потому что возврат каретки мог занять более 100 миллисекунд. Если ограничиться отправкой «\n\r», то следующий символ мог оказаться напечатанным во время обратного хода каретки, а в середине строки появился бы смазанный символ. Для надежности символы конца строки часто дополнялись одним или двумя символами «забой» (0xFF).

В 1970-е годы, когда телетайпы стали постепенно выходить из употребления, в операционных системах UNIX последовательность конца строки сократилась до \n. Однако другие операционные системы – например DOS – продолжали использовать обозначение \r\n.

Когда вам в последний раз попался текстовый файл, использующий «неправильное» обозначение? Я сталкиваюсь с этой проблемой не реже раза в год. Два идентичных файла с исходным кодом не сравниваются, а их контрольные суммы различаются, потому что в них используются разные завершители строк. Текстовые редакторы некорректно переносят слова или разделяют строки двойным интервалом, потому что они интерпретируют \r\n как две строки. Некоторые программы понимают \r\n, но не распознают \n\r… И так далее.

Вот что я имею в виду под детализацией. Попробуйте-ка закодировать логику обработки завершителей строк на UML!

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

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

В завершение представьте, что в один прекрасный день будет изобретен действительно полезный диаграммный язык. Но ведь рисовать диаграммы будут не архитекторы, а программисты. Диаграммы попросту станут новым кодом, и программистам придется «рисовать» этот код – ведь в конечном итоге все сводится к подробностям, а управлять ими приходится именно программистам.