некоторые из тех задач, которые стоят перед программистом, однако средства решения этих задач не очень-то похожи на написание программ.

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

Знаете старую байку о телефоне и телефонных операторах? Дело в том, что когда телефон только входил в обиход и когда стало ясно, что популярность телефонов стремительно растет, требовалось все больше и больше телефонных операторов, поскольку тогда еще не было автоматических телефонных аппаратов. Кто-то подсчитал уровень роста и воскликнул: “Боже, через 20-30 лет абсолютно всем людям придется стать телефонными операторами”. Собственно говоря, так все и произошло. Мне кажется, нечто подобное происходит сейчас и в некоторых крупных областях программирования.

Сейбел: Возможен ли исход, при котором та же история произойдет и с программистами, - что их заменят?

Дойч: Это зависит от того, какую программу нужно написать. Один из вопросов, который я себе постоянно задавал на протяжении последних пяти с лишним лет: “Почему программирование - такая сложная штука?”

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

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

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

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

Глядя по сторонам, я не вижу ничего, что напоминало бы мне адрес или указатель. Я вижу объекты - не те странные вещи, которые специалисты в области информационных технологий по какому-то недоразумению называют “объектами”.

Сейбел: Не говоря о масштабе. 264 чего бы то ни было - это много, а когда какое-то действие происходит несколько миллиардов раз в секунду - это быстро.

Дойч: Но в реальном мире нас этот масштаб не заботит. Вы ведь знаете число Авогадро - 1023? Мы живем в мире, где одновременно сосуществует невероятное количество мелочей. Но нас это не заботит, потому что мир устроен таким образом, что нам не нужно понимать, к примеру, вот этот стол на субатомном уровне.

Физические свойства материи таковы, что в 99,9% случаев мы можем воспринимать ее в целом. Все, что нам необходимо о ней знать, мы можем узнать, воспринимая ее целиком. И по большому счету этот принцип не работает в мире ПО.

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

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

Сейбел: То есть нужно лишь преодолеть технические проблемы или просто все дело в сущности самого процесса?

Дойч: Нужно все начать заново. Для начала нужно забыть обо всех языках, в которых существует понятие указателя, потому что в реальном мире нет такого понятия. Нужно смириться с фактом, что информация занимает пространство, существует какое-то время и размещена в определенном месте.

Сейбел: По мере того как вы переходили от работы над небольшими фрагментами кода к созданию крупных систем, вы писали эти маленькие фрагменты с помощью прежних методов и просто приобрели новый взгляд на более крупные системы или это повлияло на ваш подход ко всей работе в целом?

Дойч: Это изменило мой подход к работе в целом. Первыми значительными программами, которые я создал, стали программы на UNIVAC в Гарварде. Следующие несколько программ я сделал на PDP-1 в MIT. В то время - 1960-е, когда я учился в старших классах, - мною были созданы три действительно разные программы, или системы.

Для серийного PDP-1 я написал интерпретатор Лиспа. Я написал какой-то кусок кода операционной системы для причудливо модифицированного PDP-1 Джека Денниса. Кроме того, я написал текстовый редактор для PDP-1 Денниса.

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

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

Переход случился во время работы над моим следующим крупным проектом - во время учебы на старших курсах в Беркли в рамках проекта Genie - над системой разделения времени 940 и над текстовым редактором QED. Еще я написал программу отладки для ассемблера, но почти ничего о ней не помню.

Наиболее системной частью того проекта была операционная система. Я бы погрешил против истины, если бы сказал, что написал всю операционную систему целиком, но это не так. Но я по большому счету написал все ядро на ассемблере. Сейчас речь уже идет о немного более крупных программах - возможно, порядка 10 000 на ассемблере. Там были планировщик процессов, виртуальная память, файловая система. На самом деле там было несколько файловых систем.

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