Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста

Сейбел:Выиграла ли UNIX от того, что была написана на Си, в то время как другие ОС - например TENEX и ITS - создавалась на языке ассемблера и, следовательно, их нельзя было так запросто переносить на другое оборудование, как UNIX?

Томпсон:Были и другие хорошие языки системного программирования, на которых писались такие вещи.

Сейбел:Например?

Томпсон:NELIAC был версией Алгола-58 для системного программирования.

Сейбел:BLISS тоже относится к той эре?

Томпсон:BLISS, кажется, был позже. В этих языках акцент делался на то, чтобы они хорошо компилировались. Думаю, с самого начала было вполне ясно, что из-за хорошей компиляции нельзя так уж убиваться. Нужно делать это хорошо, но вовсе не обязательно безупречно. Дело в том, что пока вы дорастаете до безупречной компиляции, закон Мура вас все равно обгонит. Вы можете повысить качество на 10%, но пока вы это делали, быстродействие компьютеров выросло вдвое и, возможно, появилось еще что-то более значимое для оптимизации, вроде кэшей. Думаю, по большей части стремление к совершенству здесь - пустая трата времени. Это очень тяжело: вы порождаете столько же ошибок, сколько устраняете. Нужно остановиться и не тратить 100% времени на 10% работы.

Сейбел:Вы, наверное, слышали о статье Ричарда Гэбриела “Worse Is Better” (Чем хуже, тем лучше).

Томпсон:Нет.

Сейбел:Он сравнивал два стиля - стиль Массачусетского технологического института (MIT), где на первом месте правильность, и стиль Нью-Джерси (то есть Bell Labs), где высоко ценят простоту реализации. Его теория состоит в том, что стиль Нью-Джерси, который он также называет “Чем хуже, тем лучше”, обеспечивает возможность немедленного запуска проекта и исправления в нем ошибок на ходу.

Томпсон:Думаю, у MIT всегда был некий комплекс неполноценности по поводу UNIX. Я выступал с лекцией о UNIX в MIT, и меня представлял, кажется, Майкл Детрузос. Он объяснял, почему UNIX не была написана в MIT, хотя именно так и должно было быть. Почему у них были возможности, люди и все такое, но тем не менее ничего не произошло. И тут меня осенило, что все это время в них сидит дух соперничества. У меня ничего подобного не было. Мы сделали UNIX, а они сделали MULTICS, настоящего монстра. Это явно синдром второй системы.

Сейбел:Где MULTICS была вторичной по отношению к операционной системе MIT CTSS?

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

Сейбел:Как я понимаю, большинство специалистов MIT придерживается именно такого мнения о MULTICS. Они предпочитали построенные ими же системы ITS и те, что были основаны на Лиспе. Похоже, после MULTICS получилась вилка. UNIX вышла в свет, как вам хорошо известно, и в MIT все эти любители Лиспа стали срочно работать на PDP-10 и строить основанные на Лиспе системы, которые в конце концов, думаю, и породили Лисп-машины.

Томпсон:Да-да. Я знал всех этих ребят. Я считал, что это сумасшедшая работа. Не думал, что Лисп - настолько уникальный язык, чтобы делать под него свою машину. И я, видимо, был прав. Все это время я говорил: “Вы с ума сошли”. Вот PDP-11 - отличная Лисп-машина. PDP-10 - отличная Лисп-машина. Зачем строить машину под Лисп, которая не будет быстрее? Да и вообще нет никакого смысла строить машину под Лисп. Это глупо, в конце концов.

Сейбел:Были ли у MULTICS такие черты, которые вам нравились, но тем не менее не были перенесены в UNIX?

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

Сейбел:И все это вы перенесли в свою систему, там не осталось ничего, о чем бы вы жалели?

Томпсон:Нет.

Сейбел:Судя по тому, что я читал по истории UNIX, вы действительно использовали тот процесс проектирования, который здесь описали. Вы долго думали, а потом, когда жена и ребенок на месяц уехали, сказали: “Отлично! Теперь я могу написать код”.

Томпсон:Да... Мы собрались группой и поговорили о файловой системе. Нас было трое или четверо. Единственный, кто сейчас не очень хорошо известен, - это Радд Кэнеди (Rudd Canady). В те дни в Bell Labs были потрясающие удобства: можно было позвонить по телефону и потом получить распечатку вызова. То есть оставляешь заявку на то, чтобы оно было записано, и на следующий день в твоем почтовом ящике появится распечатка. И после того как мы обсудили файловую систему с помощью доски и мела, Кэнеди снял трубку, набрал номер и зачитал данные с доски.

Распечатка пришла, и получившееся оказалось так близко к проектной документации, которую мы тоже сделали, что были просто невероятные совпадения. И я взял и реализовал эту файловую систему, только на PDP-7. В какой-то момент я решил, что мне необходимо тестирование. И написал разные загрузочные штуки. Но у меня были проблемы при написании программ для файловой системы. Хотелось чего-нибудь интерактивного.

Сейбел:И вам просто хотелось поиграть с написанием файловой системы? В тот момент, получается, вы не собирались писать именно ОС?

Томпсон:Нет, это была просто файловая система.

Сейбел:И вы, таким образом, написали ОС, чтобы создать наилучшую среду для тестирования файловой системы.

Томпсон:Да. Примерно на полпути я понял, что это была настоящая система разделения времени. Я писал оболочку для запуска файловой системы. И еще пару программ, запускавших ее. Тут я подумал: “Осталось только сделать редактор, и у меня есть целая операционная система”.

Сейбел:Какую самую страшную ошибку вам приходилось отлавливать?

Томпсон:В основном это были ошибки, связанные с порчей памяти. Больше такого не бывает. Не знаю почему. Но поначалу мы постоянно работали с различным экспериментальным оборудованием, и в нем были ошибки.

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

Томпсон:Мог быть указатель. Могло быть оборудование. Или и то, и другое. Та ошибка, которая мне сейчас вспомнилась как один из худших примеров, случилась на PDP-11. Там не было блока умножения, но его можно было докупить отдельно и подключить как периферию ввода/вывода. Сохраняешь числитель и знаменатель и запускаешь. Проходит цикл ожидания, затем выдается ответ - частное и остаток. И это было сделано под PDP-11 без управления памятью, а потом к нам пришло первое экспериментальное оборудование для PDP-11 с управлением памятью, и в результате блок умножения конфликтовал с управлением памятью.