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

Прошлые статьи цикла:

Точка входа

0. Лейбниц, Бэббидж и Лавлейс

1. Алан Тьюринг

2. Джон фон Нейман

3. Клод Шеннон

Через несколько дней после смерти Стива Джобса, о которой говорил весь мир, тихо умер человек, чей код лежит в основе большей части устройств, на которых этот самый мир об этом читал.

Это пятая статья цикла “Код как борьба: Кратчайшая история IT”. И сегодня у нас сдвоенная история - два человека настолько тесно переплетены в одной истории, что разделять их было бы просто нечестно по отношению к тому, что они сделали вместе.

Погнали.

Часть первая. Крах амбициозного проекта и рождение хобби на списанном железе

Кен Томпсон родился в 1943 году в Новом Орлеане, получил степень по электротехнике в Беркли. Деннис Ритчи - в 1941, в Бронксвилле, штат Нью-Йорк, образование по физике и прикладной математике в Гарварде. Оба присоединяются к исследовательскому подразделению Bell Labs - Томпсон в 1966, Ритчи годом позже.

И оба участвуют в проекте под названием Multics - Multiplexed Information and Computing Service. Это была амбициозная совместная разработка Bell Labs, MIT и General Electric, призванная создать операционную систему с разделением времени для множества одновременных пользователей.

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

К 1969 году руководство Bell Labs решает: хватит. Вложения неоправданны. Компания выходит из совместного проекта.

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

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

И вот показательная деталь про название. В 1970 году коллега Брайан Керниган придумывает для новой системы имя Unics - Uniplexed Information and Computing Service, ироничный каламбур над Multics: «UNIplexed» вместо «MULTiplexed», то есть система для одной задачи и одного пользователя за раз, в противовес амбициозной многозадачной Multics. Само слово при этом звучит по-английски подозрительно похоже на “eunuchs” - что, судя по всему, тоже было частью шутки. Позже название сократили до привычного нам Unix, хотя сам Керниган впоследствии признавался, что уже никто толком не помнит, кто именно предложил именно такое написание. Хотя в реальности Unix довольно быстро приобрёл полноценную многозадачность.

Насмешка над провалившимся амбициозным проектом становится именем системы, которая, в итоге, окажется несравнимо успешнее своего прародителя.

И вот ещё важная вещь - философия, которая определила дух всей последующей unix-подобной экосистемы. Программы должны делать одну вещь и делать её хорошо. Программы должны уметь работать вместе, обмениваясь простым текстовым выводом одной программы как входом для другой - это концепция pipe, конвейера.

И тут стоит рассказать, как именно она появилась, потому что история почти анекдотическая. Идею конвейера годами продвигал коллега Томпсона и Ритчи по Bell Labs, Дуглас Макилрой - ещё в 1964 году он сравнивал будущую связку программ с садовым шлангом: подкрутил ещё один отрезок, когда нужно обработать данные иначе. Осенью 1973 года Томпсон, судя по всему, устав слушать эти уговоры, наконец сказал “я сделаю это” - и буквально за одну ночь добавил в командную оболочку Unix символ вертикальной черты и переписал стандартные утилиты вроде cat и grep так, чтобы они умели читать друг у друга вывод. Наутро в лаборатории, по словам самого Макилроя, случился настоящий “пир одной строкой” - все принялись составлять из простых утилит неожиданные комбинации, которые никто из авторов этих утилит изначально не предполагал.

Простота и композиция предпочтительнее сложных монолитных решений.

Это прямая идеологическая противоположность подходу, погубившему Multics.

Часть вторая. Язык, придуманный, чтобы код не пришлось переписывать заново под каждую машину

Изначально Unix, как и большинство системного софта той эпохи, был написан на ассемблере - языке, крайне специфичном для конкретной модели процессора. Это делало систему физически непереносимой на другое оборудование без полного переписывания с нуля.

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

И вот в 1973 году Томпсон и Ритчи принимают решение, которое на тот момент выглядит крайне рискованным. Переписать ядро самого Unix с ассемблера на язык C.

Системное программирование тогда традиционно считалось областью, требующей прямого контроля над железом на уровне ассемблера. Высокоуровневые языки виделись слишком «медленными» и абстрактными для такой задачи.

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

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

В 1978 году Керниган и Ритчи публикуют книгу «The C Programming Language», в профессиональной среде программистов известную просто как K&R, по инициалам авторов. Она становится эталонным описанием языка на десятилетия вперёд и одной из самых влиятельных технических книг в истории программирования вообще. Этот текст, кстати, до сих пор изучается программистами, осваивающими системное программирование — за его лаконичность и ясность письма.

И вот ещё интересный поворот. Поскольку по антимонопольному соглашению 1956 года материнская компания Bell Labs, AT&T, была ограничена в праве заниматься каким-либо бизнесом за пределами телефонной связи - и, соответственно, не могла продавать Unix как коммерческий продукт - систему стали лицензировать университетам практически по себестоимости носителя и пересылки. Это приводит к взрывному распространению системы в академической среде и появлению множества независимых форков и важнейший из них, BSD в Беркли, породивший впоследствии macOS через промежуточные звенья.

То есть, по сути, антимонопольное регулирование, а не сознательная стратегия, стало невольным катализатором технологического распространения.

Часть третья. От Bell Labs до вашего смартфона

Давайте наглядно покажу масштаб влияния, потому что это действительно впечатляет.

Прямые потомки и Unix-подобные системы, включая Linux, macOS через BSD-линию наследования, Android, построенный поверх ядра Linux, iOS, построенный на Unix-подобном ядре Darwin.

Язык C и его прямые потомки - C++, Objective-C, отчасти Java и C#, синтаксически заимствовавшие многое от C, остаются языками, на которых написана значительная часть операционных систем, встраиваемых устройств и высокопроизводительного системного софта по всему миру.

А философия конвейеров и маленьких композируемых утилит легла в основу командной строки Unix и Linux, которой пользуются программисты по всему миру по сей день.

Два человека, оставшись без официального проекта после институционального провала, на списанном оборудовании создали систему и язык, которые полвека спустя лежат буквально под интерфейсом каждого смартфона на планете. Независимо от того, произведён он Apple или любой другой фирмой, использующей Android.

И вот что важно сказать напоследок

Смерть Ритчи в октябре 2011 года пришлась буквально через несколько дней после смерти Стива Джобса - Джобс умер 5 октября, Ритчи нашли мёртвым около 12 октября. И осталась почти незамеченной на фоне колоссального медийного внимания к уходу Джобса, несмотря на то, что язык C и Unix-подобные системы сделали для современной цифровой инфраструктуры больше, чем любой продукт Apple.

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

Итог

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

Вопросы, чтобы обсудить в комментариях

Первое - Unix родился не из формального технического задания, а фактически вопреки решению руководства свернуть финансирование. Насколько часто в истории технологий важнейшие прорывы случаются именно в подобных «внеплановых», низкобюджетных условиях? И что это говорит о природе институционального управления инновациями?

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

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

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

Источники и ссылки по фактам из статьи

Дополнительное чтение к данной статье

Брайан Керниган, Деннис Ритчи - “The C Programming Language” (1978, второе издание - 1988) Легендарная K&R. Если вы программист или хотите им стать - это стоит прочитать не только ради истории, но и как практическое руководство, которое актуально и сегодня.

Питер Сейбел - “Coders at Work: Reflections on the Craft of Programming” (2009) Сборник интервью с выдающимися программистами, включая содержательное интервью с самим Кеном Томпсоном, редкая возможность услышать историю в его собственном изложении.

Брайан Керниган - “Unix: A History and a Memoir” (2019) Написана человеком, который был непосредственным свидетелем и участником событий в Bell Labs. Пожалуй, самый достоверный и одновременно личный источник по истории создания Unix.

Эрик Реймонд - “The Art of Unix Programming” (2003, полный текст доступен бесплатно онлайн) Наиболее полная кодификация философии Unix, если хочется глубже разобраться именно в принципах, а не только в истории.

Материалы ACM о присуждении премии Тьюринга Томпсону и Ритчи в 1983 году Официальная документация о признании их вклада - включает лекции лауреатов, где оба рассказывают о разработке своими словами.

Некрологи и ретроспективные материалы об одновременной смерти Ритчи и Джобса в октябре 2011 года Стоит поискать материалы именно того периода (октябрь 2011) в архивах технологических изданий. Интересно увидеть контраст освещения обоих событий в реальном времени, а не в ретроспективе.