прочее. Были и структуры для отслеживания системы виртуальной памяти. Но стали появляться и некоторые проблемы, связанные с интерфейсом. Не в рамках самой операционной системы, нет, поскольку она была настолько мала, что ядро было создано как единый кусок, монолит.
Но были две важные области, в которых стали появляться проблемы программного интерфейса. Одна из них - интерфейс между пользовательскими программами и ядром. Какими должны быть системные вызовы? Как должны быть размещены параметры? Я знаю, что в первых версиях системы 940 основные операции для чтения и записи файлов были эквиваленты вызовам read и write в UNIX, когда вы просто даете базовый адрес и смещение. Это все было очень хорошо, но большую часть времени это было не тем, что нужно. А нужен был попросту потоковый интерфейс. Но в те дни мы и понятия не имели, что можно взять функции операционной системы и затем обернуть их кодом пользовательского уровня, чтобы получился интерфейс получше - вроде того, когда getc и putc надстраиваются над read и write. To есть в более поздних версиях операционной системы мы просто добавили системные вызовы, эквивалентные getc и putc.
Другое место, в котором стали появляться проблемы, связанные с интерфейсом, - вновь на базе режима MULTICS - с самого начала мы строго различали ядро и то, что сегодня называется оболочкой. Это был достаточно ранний этап развития операционных систем, и мы не понимали, что можно на самом-то деле создать оболочку, не обладающую никакими особыми привилегиями. Оболочка была программой, работающей в пользовательском режиме, но у нее было множество особых привилегий. Были небольшие вопросы касательно того, какие функции ядро должно было передать оболочке, - что оболочка должна была делать сама, а что - через вызовы ядра.
Принимая решения по организации интерфейсов, мы исходили из каждой отдельной задачи. Именно в этот момент карьеры ко мне начало постепенно приходить понимание того, что интерфейсы между сущностями нужно разрабатывать по отдельности, что интерфейсы между ними были действительно важной задачей для разработчика.
Поэтому ответ на ваш вопрос о том, изменился ли мой метод программирования после того, как я перестал работать с небольшими кусками кода и перешел к работе с более крупными системами, - да, изменился. По мере того как я создавал все более крупные системы, я стал замечать, что, садясь писать кусок кода, я все чаще и чаще первым делом задавался вопросами: “Каким будет интерфейс между вот этим и всем остальным?”, “Что будет на входе?”, “Что будет на выходе?”, “Какая часть задачи будет отдаваться каждой из сторон этого интерфейса?”. Подобные вопросы начали становиться все более крупной частью моей работы. И это, видимо, оказывало влияние на то, как я писал отдельные, более маленькие куски кода.
Сейбел: И это было естественным следствием работы с более крупными системами - в конце концов системы становятся настолько большими, что приходится думать, как разбить их на части.
Дойч: Именно. В этом смысле я согласен, что ПО фрактально, поскольку декомпозиция - процесс многоуровневый. Я хотел сказать, что не уверен в том, что декомпозиция на более высоких уровнях качественно не отличается от декомпозиции на более низких уровнях. Когда занимаешься декомпозицией на более низком уровне, можешь не думать, например, о выделении ресурсов; когда же занимаешься декомпозицией на более высоком уровне, от этого никуда не деться.
Сейбел: Приходилось ли вам работать с людьми, которые, на ваш взгляд, были очень хорошими программистами и тем не менее могли работать только с задачами определенного уровня? Например, они могли хорошо справляться с задачами определенного масштаба, но их склад ума не позволял им разбирать системы на составные элементы, видеть их насквозь?
Дойч: Мне приходилось работать с очень сильными программистами, которым не хватало опыта, чтобы работать на более высоком, системном уровне. Например, во время работы над Ghostscript у меня были достаточно серьезные разногласия с двумя инженерами, которые попали в мою команду, когда началась ее передача компании, которую я создал. Оба инженера были очень умными, очень трудолюбивыми, очень опытными. Мне они казались очень хорошими программистами, хорошими разработчиками. Но оказалось, что они не могли мыслить системно. Они не только не могли думать в терминах влияния или ветвления изменений - им даже в голову не приходило, что подобными вопросами вообще нужно было задаваться. На мой взгляд, одни понимают, какие вопросы нужно задавать при более масштабном подходе к разработке ПО, а другие - по какой бы то ни было причине - вообще не задаются такими вопросами.
Сейбел: Но как вам кажется, эти люди - когда они не пытаются разработать всю систему целиком — делают свою работу хорошо?
Дойч: Да. Те два инженера, о которых я сейчас говорил, приносили огромную пользу компании. Первый работал над одним крупным проектом - это была достаточно неблагодарная работа, но весьма важная с коммерческой точки зрения. А второй переделал крупные фрагменты моего графического кода, и с его кодом мы получили более приятное глазу визуальное воплощение. Они оба хорошие, умные, опытные ребята. Просто они видят не все части картины - по крайней мере, у меня осталось такое впечатление о них.
Сейбел: Есть ли у вас какие-то особенные навыки, которые, по вашему мнению, помогли вам стать хорошим программистом?
Дойч: Я отвечу вам сейчас в духе Нью-эйдж. Вообще говоря, меня нельзя назвать приверженцем Нью-эйджа, хотя и я в свое время носил длинные волосы. Будучи (по собственным оценкам) на пике своих возможностей, я обладал чрезвычайно надежной интуицией. Я просто делал какие-то вещи, и само собой получалось, что я делал их правильно. Где-то мне везло. В каких-то случаях, уверен, дело было в том, что я настолько слился со своим опытом, что мне даже не нужно было сознательно участвовать в процессе принятия решения. Но мне кажется, что у меня просто был к этому талант. Понимаю, что объяснение не очень-то убедительно, но я действительно верю, что кое-что из того, благодаря чему я стал хорош в своем деле, просто было у меня.
Сейбел: Когда вы были не по годам развитым подростком и проводили много времени в MIT, думали ли вы о ком-нибудь: “Да, этот парень очень умен, но он не знает, как делать вот эту штуку, а я знаю”?
Дойч: Нет, такого не было. Хотя, нет, помню один случай, когда я начинал переписывать текстовый редактор на PDP-1 Денниса - мне, наверное, было лет 15 или 16. Исходный код был написан одним или двумя парнями из Клуба технического моделирования железной дороги. Это были умные ребята. Я смотрел на этот код и часто думал про себя: насколько же он ужасен!
Я бы не сказал, что речь о разнице между мной и теми, с кем я работал. Речь о разнице между тем, каким код должен был быть в моем представлении, и тем кодом, который я видел перед собой. Я бы не стал исходя из этого наблюдения делать какие-то обобщающие выводы о людях.
Я всегда достаточно комфортно чувствовал себя в том, что называю символическим миром, в мире символов. Символы и их сочетания - вот что я обычно ем на завтрак. Этого же не скажешь о других. Например, о моем партнере. Мы оба музыканты. Мы оба композиторы. Мы оба вокалисты. Но я рассматриваю музыку в первую очередь с точки зрения символов. Я часто сочиняю, просто сидя за столом с ручкой и листом бумаги. Я записываю ноты, но не играю их тут же на фортепиано. Я их слышу, и у меня есть план.
В то время как у него большая часть процесса сочинения музыки происходит непосредственно с гитарой в руках. Он что-то на ней играет, дурачится с ней, иногда побацает на фортепиано немного, потом играет все сначала. И никогда ничего не записывает. Может, если на него надавить, то он и запишет последовательность аккордов, и, насколько я понимаю, в какой-то момент он записывает слова. Но он подходит к процессу сочинения музыки не с символической точки зрения.
То есть кто-то устроен так, кто-то иначе. Если бы мне нужно было сделать из этого наблюдения какой-то вывод - что ж, повторюсь еще раз, я немного элитист, - я бы сказал, что программированием должны заниматься люди, которые чувствуют себя в мире символов как рыба в воде. Если вы не очень-то комфортно ощущаете себя в этом мире, что ж, может быть, программирование - это просто не ваше.
Сейбел: Были ли у вас учителя, которым вы многим обязаны?
Дойч: Их было двое. Один из них уже не с нами - его звали Кэлвин Муэрс. Он был
