Армстронг: Да, и потом соединять их. Не знаю, можно ли это назвать обучением программированию. Потом я поступил на физическое отделение Лондонского университетского колледжа. Кажется, программирование там начиналось уже на первом курсе. Время обработки заданий составляло часа три. Но при запуске одновременно четырех-пяти программ все шло быстрее.
Сейбел: А в старших классах были уроки информатики?
Армстронг: Нет, был факультатив - что-то вроде компьютерного клуба. Помню, как мы ходили смотреть на компьютер. Множество серьезных, взрослых людей в белых халатах, с ручками в кармане, двигались торжественно, как в церкви. Компьютер был очень дорогой.
Сейбел: Вы изучали физику. А как вы перешли к программированию?
Армстронг: Когда я был на последнем курсе, на некоторых занятиях требовалось писать программы. Мне это нравилось. Я очень хорошо освоил отладку и делал ее для других, если ничто больше не помогало. Стандартной таксой была бутылка пива. Дальше все зависело от сложности - двухбутылочная задача, трехбутылочная задача и так далее.
Сейбел: То есть сколько человек должен был вам за отладку его программы - две, три бутылки?
Армстронг: Да. Исправляя ошибки, я обычно читал программу и говорил: "Тут можно бы сделать и попроще", - и переписывал ее. Меня поражало, что народ пишет такие сложные программы. Я понимал, как обойтись пятью строчками, а другие писали их десятками! И я удивлялся: как можно не видеть простого решения.
Но по-настоящему я занялся программированием после того, как стал бакалавром и решил, что буду писать диссертацию. И вот я начал трудиться над диссертацией по физике высоких энергий и присоединился к группе, которая работала с пузырьковой камерой. У них был компьютер Honeywell DDP-516. Я мог работать с ним сам! Да, там были перфокарты, но я мог запускать программы - вставляешь карту, нажимаешь кнопку - трррр! - и машина тут же выдает ответ. Просто восторг! Я написал для этого компьютера шахматную программку.
Тогда применялась память на магнитных сердечниках, которые соединяли вместе пожилые тетеньки. Если вы заглядывали внутрь, то видели магнитики и кучу проводов. Страшно дорогая штука - двадцать дисков весом под пятнадцать кило, на которых умещалось мегабайт десять. И телетекстовый интерфейс, чтобы настукивать программы.
А потом появился один из первых дисплеев - можно было набирать программы и редактировать их. Фантастика! Никаких больше перфокарт. Помню, мы разговорились с сотрудником, который обслуживал компьютер, и я сказал: "Когда-нибудь такой будет у каждого". А он мне в ответ: "Ты с ума сошел, Джо!" - "Почему?" - "Да потому, что это слишком дорого".
Вот тогда я и научился программировать всерьез. Мой научный руководитель говорил: "Тебе надо бросить диссертацию по физике и заняться компьютерами, раз ты так их любишь". Я возражал, что хочу закончить ее, если уж начал. Но он был прав, как видим.
Сейбел: Так вы написали диссертацию или нет?
Армстронг: Нет. У меня закончились деньги, и я поехал в Эдинбург. Когда я изучал физику, то, как и другие, занимался в физической библиотеке. В уголке там прятался стеллаж с компьютерными книгами. Среди них были четыре коричневых тома под названием "Machine Intelligence" (Машинный интеллект), изданные отделением машинного интеллекта Эдинбургского университета. Я в принципе изучал физику, но с жадностью поглощал эти книги и думал: "До чего же занятно!" Поэтому я написал Дональду Мичи, который возглавлял это отделение, о том, что все это мне очень интересно, и спросил, нет ли у него какой-нибудь работы. Мне пришел ответ. Мичи писал, что работы пока нет, но он был бы рад познакомиться, посмотреть, кто я такой.
Через несколько месяцев Мичи не то позвонил, не то написал мне, что в ближайший вторник будет в Лондоне и хотел бы встретиться со мной. Так как он пересаживался на эдинбургский поезд, то предлагал увидеться на вокзале. Мы встретились, и Мичи сказал: "Хм, здесь не очень-то поговоришь - пойдемте в паб". Мы поболтали в пабе, и чуть позже он написал мне: "У меня в Эдинбурге есть место в лаборатории, не хотите ли поработать?" Я переехал в Эдинбург и стал помощником Мичи по исследовательской части. Вот так я бросил физику ради компьютерной науки.
Во время Второй мировой Мичи работал с Тьюрингом в Блетчли-парке, и ему достались все бумаги Тьюринга. У меня был стол в библиотеке Тьюринга, так что я сидел среди тьюринговских бумаг. Год я проработал в Эдинбурге. Потом все там рухнуло. Дело в том, что правительство поручило математику Джеймсу Лайтхиллу выяснить, как в Эдинбурге обстоят дела с искусственным интеллектом. Лайтхилл выяснил и заявил, что ничего коммерчески ценного из этого не вырастет.
Вообще, все это напоминало гигантский детский манеж. Я был членом-основателем Британской робототехнической ассоциации, и нам казалось, что все это - дело чрезвычайной важности. Но те, кто финансировал нашу работу, не хотели и слышать о роботах! Где-то около 1972 года финансирование прекратилось. Народ стал говорить: "Что ж, занятная была работа, теперь надо искать что-то другое".
Итак, надо было возвращаться к физике. Я приехал в Швецию и стал заниматься физическими компьютерными программами в научной ассоциации EISCAT. Мой начальник, старше меня, пришел из IBM; я должен был разрабатывать спецификацию, аон- реализовывать ее. Мы спорили по этому поводу. Он говорил: "Плохо то, что у нас нет описания задания и подробной спецификации". А я отвечал: "Так это же прекрасно, что нет описания, - можно самому определять задание для себя". Через год он ушел, а я занял его место - место ведущего разработчика.
Я спроектировал то, что сейчас бы назвали прикладной операционной системой, то, что работает как надстройка над обычной ОС. К тому времени компьютеры уже заметно подешевели. У нас были норвежские NORD-10 - кажется, они задумывались для конкуренции с PDP-11.
Там я провел почти четыре года, а потом получил работу в Шведской космической корпорации, разработал еще одну прикладную операционную систему для управления "Викингом", первым шведским спутником. Проект был интересный. Я работал на машине, названия которой не помню, но это был клон компьютера Amdahl. Только строковые редакторы, никаких полноэкранных. Все программы хранились в одном каталоге. Не больше десяти букв в имени файла, не больше трех в расширении. Плюс компилятор Фортрана или ассемблер - вот и вся система.
При этом я думаю, что все эти современные штуки с наворотами вряд ли делают вас продуктивней. Как работа может улучшиться при иерархической файловой системе? Как бы то ни было, программы создаются главным образом в голове. Мне кажется, что работа с такой довольно простой системой дисциплинирует мышление. Если все файлы надо складывать в один каталог, нужна строжайшая дисциплина. Если нет системы управления версиями, нужна строжайшая дисциплина. И если работать дисциплинированно, то, по-моему, нет особой нужды ни в иерархической файловой системе, ни в системе управления версиями. Они не решают главную проблему. Пожалуй, с ними удобнее работать вместе нескольким людям. Если же работать одному, то разницы я не вижу.
Кроме того, сейчас у нас что-то вроде избытка выбора. У меня имелся только Фортран - помнится, не было даже консольных скриптов. Командные файлы для запуска программ, компилятор Фортрана - и все! Ну и ассемблер, наверное, если кому-то он был нужен. Никакого мучительного выбора, как сейчас. Думаю, быть сегодня молодым программистом просто жутко: двадцать языков, десятки фреймворков и операционных систем - можно погибнуть, выбирая. А в то время - ничего подобного. Просто начинаешь работать, потому что язык и программы выбирать не приходится. Просто берешь и работаешь.
Сейбел: Разница еще и в том, что сегодня не понять, как устроена система сверху донизу. Проблема не только в выборе, но и в том, что не во всех используемых "черных ящиках" хочется разбираться.
Армстронг: Ну да. Если "черные ящик" работает неважно и надо что-то в нем подкручивать, то легче взять и написать все самому. А вот что точно не работает, так это повторное использование кода. С этим совсем плохо.
Сейбел: Вы создали не только Erlang, но и Open Telecom Platform - платформу для разработки приложений. Что вы скажете о ее многократном использовании?
Армстронг: В какой-то мере это возможно. Но возникает все та же проблема. Если эта платформа полностью решает вашу задачу, если какой-нибудь программист, ничего не знающий о структуре ОТР, посмотрит на нее через несколько лет и скажет: "Вот именно то, что мне нужно", - отлично, вы уложились в эту меру повторного использования. Если же этого не случится, проблема останется.
Не так давно мне говорили: "Все это как-то искусственно, мы все время стараемся впихнуть код в этот ОТР". Я отвечал: "Ну что ж, переделайте ОТР". Но ведь этого не сделаешь. При этом фреймворк - всего лишь программа, довольно простая по устройству. Действительно простая. Я залезаю в нее, и она делает то, что нужно этим людям, после чего они соглашаются: "И правда, просто". Но при этом заявляют: "Наши менеджеры не хотят, чтобы мы возились с фреймворком". Ну так назовите это по-другому, и все.
Сейбел: А как по-вашему, реально ли на самом деле вскрыть все эти "черные ящики", заглянуть внутрь, понять, как они работают, и приспособить их для своих нужд?
Армстронг: С годами я, кажется, все чаще допускаю вот эту типичную ошибку: боюсь вскрыть "черный ящик". Он кажется мне таким непроницаемым, таким сложным, что я не хочу открывать его. Один-два я все же открыл; я хотел сделать оконную графическую программу для Erlang и подумал: "А не запустить ли ее на X Windows". Что такое X Windows? Это сокет с протоколом поверх. Открываешь сокет и транслируешь через него сообщения. Зачем библиотеки? Erlang основан на сообщениях. Идея в чем? Вы посылаете сообщения по какому-то адресу, и там что-то делается. То же и в X Windows - у вас есть окно, вы посылаете сообщение, и начинается выполнение. Если же вы делаете что-то в окне, сообщение вам возвращается. Очень похоже на Erlang. Однако программирование в X Windows происходит при помощи библиотек с обратными вызовами. Это не философия Erlang. Послать сообщение, чтобы начала выполняться команда, - вот философия Erlang. Итак, оставайтесь подключенными и обращайтесь непосредственно к сокету, без библиотек.
И знаете, это очень легко. Х-протокол принимает 80-100 сообщений, а вам нужно, скажем, только 20. Вы отображаете их в Erlang, стоит чуть поколдовать - и вы можете отправлять сообщения прямо в окна, а те уже займутся всем. К тому же это быстро работает. Правда, выглядит не очень - я мало заботился о графике, о внешнем виде, над этим надо еще поработать. Но главное - это легко.
Кроме того, я создал программу верстки, где границей абстракции, которую я перешел, был PostScript. Подходя к этой границе, боишься ее пересекать, поскольку думаешь, что за ней что-то невероятно сложное. Но и тут все оказывается легко. Это язык программирования. Хороший язык программирования. Границу абстракции пересечь легко, и это очень полезно.
Когда издавалась моя книга по Erlang, издатель сказал: "У нас есть софт для рисования схем". Но все такие программы обычно ставят стрелку не совсем туда, куда надо. Да и рука после них болит. Я подумал, что это должно занять всего несколько часов - программа, которая бы выдавала PostScript-файлы и ставила стрелку точно в нужное место. Времени тратится на создание схем с помощью программ примерно столько же, сколько в системах WYSIWYG. Но у последних есть два преимущества. Во-первых, рука не болит и, во-вторых, при увеличении даже в 10 000 раз стрелка показывает туда, куда надо.
Конечно, начинающий программист не обязан осваивать все эти абстракции. Но надо держать в уме такую возможность, не отвергать ее, понимая, что прямой путь может быть эффективнее пакетного. Вообще, думаю, приобретая написанную кем-то программу, обычно тратишь много времени, чтобы приспособить ее к своим нуждам: программа делает не совсем так, как надо, а чуть по-другому.
Сейбел: Вы сказали, что с повторным использованием кода дело обстоит "совсем плохо". Но ведь открытие каждого "черного ящика" и возня с его содержимым едва ли исправит эту ситуацию.
Армстронг: Думаю, проблемы с повторным использованием кода есть в объектно-ориентированных, а не в функциональных языках. Ведь объектно-ориентированные языки тянут за собой всю неявно окружающую их среду. Вы хотели только банан, а получили еще и гориллу, которая держит этот банан, и все джунгли впридачу.
Если у вас образцово прозрачный код, если у вас чистые функции - все данные вводятся через их аргументы, все возвращается и не оставляет за собой никакого состояния, - программа более чем пригодна для повторного использования. Можно использовать ее где угодно. Если надо применить ее в другом проекте, вы просто вырезаете код и вставляете его в другой проект.
Программисты научились пользоваться разными языками, но не научились пользоваться легкими способами склейки программ. Конвейеры UNIX - "А переходит в Б переходит в В" - банально простой способ склейки. Пользуются ли ими программисты? Нет, они берут несколько API и связывают их в одной и той же области памяти, что очень сложно и не позволяет поддерживать разные языки. Если языки из одного семейства, это проще - с императивными языками, например, все прекрасно. А если, допустим, у нас есть Пролог и Си? У них совершенно разное представление об управлении памятью. Их невозможно скомпоновать. То есть повторное использование кода тоже невозможно. Вероятно, тут замешаны крупные коммерческие интересы: кому-то очень не хочется, чтобы все это работало вместе. Появляются тысячи рабочих мест для консультантов, тысячи утилит для решения проблем, которых нет, - они решены много лет назад.
Удивительно, но очень мало языков программирования описывают взаимодействие между программами. Вернемся к склейке программ и способам описания протоколов. У нас нет способов описания межпрограммных протоколов: если я шлю вам вот это, вы присылаете мне вон то. У нас есть способы описания пакетов и типов пакетов, но что касается протоколов - таких способов очень мало.
Программирование полностью отличается от того, как мы конструируем вещи в реальном мире. Допустим, вы автопроизводитель. Вы покупаете компоненты у субподрядчиков - батареи у Lucas, генераторы еще у кого-то - и соединяете их вместе, последовательно. Когда вы строите дом, то кладете кирпичи один на другой и помещаете дверь там-то. Именно так делаются чипы: есть готовая плата, обеспечивающая эти соединения. Покупая чипы, вы соединяете их ножки проводами. Хорошо бы и программы делать так, но мы не делаем.
Причина, по которой мы этого не делаем, связана с параллелизмом. Чипы, соединенные последовательно, выполняют операции параллельно. И они посылают сообщения. Они основаны на парадигме обмена сообщениями - той парадигме программирования, в которую я верю. Но сегодня она не применяется для создания программ. Erlang мог пойти по этому пути - во всяком случае, я бы этого хотел: эволюционировать в сторону компонентного строения. Пока я еще этим не занялся, но хотел бы разработать графический внешний интерфейс для создания компонентов и начать писать программы для связывания их воедино. Потоковое программирование крайне декларативно. В нем нет такого понятия, как последовательные состояния. В нем нет программного счетчика, который в них переходит. Что-то просто есть, и все. Декларативная модель легка для понимания. Но в большинстве языков она не реализована.
Я не хочу этим сказать, что содержимое "черного ящика" не может быть сложным. Возьмите, например, такую утилиту, как grep. Если глядеть извне, это что-то вроде квадратика. На входе - поток данных, файл. Можно сказать cat foo | grep, и grep получает некие аргументы, регулярное выражение, которому нужно найти соответствие. Хорошо. И grep выдает все строки, соответствующие этому регулярному выражению. На уровне восприятия то, что делает grep, до крайности просто. На входе - файл. Регулярное выражение. На выходе - набор (поток) строк, соответствующих этому выражению. Но это не означает, что действующий внутри "черного ящика" алгоритм прост - он может быть предельно сложным.
Происходящее внутри "черного ящика" может быть предельно сложным. А процесс склеивания сложных компонентов необязательно сложен. Использовать grep совсем несложно. Вот чего я не вижу в архитектуре систем: четкого различия между склеиванием составных частей и устройством, порой очень сложным, самих частей.
Соединяя программы при помощи API языка программирования, мы не получаем абстракцию "черного ящика". Мы отправляем их в одну и ту же область памяти. Если grep есть модуль, который предоставляет вызовы в своем API, и вы снабжаете его указателем char*, и вам надо выделять для этого память, и вы занимаетесь глубоким копированием этой строки - можно ли создать параллельный процесс, делающий все это? В таком случае это становится трудным для понимания. Не знаю, почему люди склеивают программы таким замысловатым образом. Надо выбирать методы попроще.
Сейбел: Если сравнить то, что вы думаете о программировании сейчас, и то, что думали в начале карьеры, в чем главное отличие?
Армстронг: Главные отличия в том, как я думаю о программировании, не имеют ничего общего с аппаратным обеспечением. Да, оно становится быстрее и мощнее, но наш мозг в миллион раз мощнее лучших программных инструментов. Я могу писать программу и вдруг, через много времени, обнаружить, что в ней ошибка: если произойдет вот это, и вот это, и вот это, случится сбой. Смотрю в код - и правда, ошибка! Хотя ничто в работе программы не говорит об этом. А теперь скажите, какая среда разработки на такое способна? Поэтому перемены, которые со мной произошли, - это перемены в моей голове.
Есть две перемены, связанные с опытом программирования. Вот первая: когда я был моложе, то обычно, закончив писать программу, переставал работать над ней. Ведь все закончено! Потом наступало озарение: "Что за бред?! Я идиот! Надо переписать". И потом снова то же самое.
Помню, как размышлял: не лучше ли сначала все продумать, а потом записать? Не лучше ли испытать озарение, еще не написав программу? Думаю, теперь у меня получается. Поэтому я считаю, что в течение двадцати лет учился программированию. Сейчас я знаю, как это делается. Я ставил эксперименты, чтобы научиться. Теперь я умею программировать и не нуждаюсь в экспериментах.
Иногда, правда, я ставлю совсем небольшие эксперименты - пишу крошечные программы, только чтобы ответить на какой-то вопрос. Я все продумываю, и программа более-менее работает по моему плану, потому что я продумал ее. Это, конечно, занимает много времени. Пишешь программу, потом наступает озарение, все переписываешь - написание программы может занять год. Поэтому теперь я предпочитаю целый год думать над ней. Просто я ничего не набираю на клавиатуре.