Сейбел: Разница еще и в том, что сегодня не понять, как устроена система сверху донизу. Проблема не только в выборе, но и в том, что не во всех используемых «черных ящиках» хочется разбираться.
Армстронг: Ну да. Если «черные ящик» работает неважно и надо что-то в нем подкручивать, то легче взять и написать все самому. А вот что точно не работает, так это повторное использование кода. С этим совсем плохо.
Сейбел: Вы создали не только 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, до крайности просто. На входе — файл. Регулярное выражение. На выходе — набор (поток) строк, соответствующих этому выражению. Но это не означает, что действующий внутри «черного ящика» алгоритм прост — он может быть предельно сложным.
