Если Алан Кэй — отец языка Smalltalk, то Дэн Ингаллс — его мать: может, идея Smalltalk и блеснула Алану Кэю, но именно Ингаллс немало потрудился, чтобы явить его миру. Начав с первой реализации Smalltalk, написанной на Бейсике на основе одной страницы заметок Кэя, Ингаллс участвовал в реализации семи поколений Smalltalk — от первого прототипа до нынешней версии с открытым исходным кодом — Squeak.

Физик по образованию, Ингаллс начал программировать на Фортране, зарабатывал на продаже профилировщика, который написал еще в школе, и со временем оказался в Xerox PARC, где присоединился к Кэю и его группе исследования обучения, которая создала Smalltalk и исследовала применение компьютеров в обучении детей.

Работая в PARC, Ингаллс также придумал BitBIt — операцию, используемую в растровой графике, и запрограммировал ее в виде микрокода для компьютера PARC Alto, обеспечив ускоренную обработку растровой графики, благодаря чему стали возможны такие новшества пользовательского интерфейса, как всплывающие меню, которые сейчас кажутся нам совершенно обыденными. (На одной из первых внутренних демонстраций системы Smalltalk всплывающее меню так впечатлило Питера Дойча — интервью с ним в следующей главе, — что он вскочил и закричал: «Ты и правда сделал это — или мне показалось?»)

Ныне Ингаллс, выдающийся инженер Sun Microsystems, работает над Lively Kernel — программной средой типа Smalltalk, которая полностью выполняется в браузере с использованием JavaScript и предоставляемой браузером графики. За работу над Smalltalk он получил от Ассоциации вычислительной техники в 1984 году премию имени Грейс Мюррей Хоппер, а в 1987 году — премию ACM Software System Award. В 2002 году был удостоен награды Dr. Dobb's Excellence in Programming Award.

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

Сейбел: Для начала: как вы пришли в программирование?

Ингаллс: Давайте посмотрим. Я всегда хотел быть изобретателем, а для этого лучше всего подходит физика, так что в колледже выбрал ее в качестве специальности. Я пошел в Гарвард, и там был курс программирования на Фортране.

Сейбел: Когда это было?

Ингаллс: Я учился в Гарварде с 1962 по 1966 год. Программирование изучал по двум направлениям: курс Фортрана и курс по аналоговым компьютерам. В подвале одного из корпусов была отличная лаборатория, занимающаяся аналоговыми компьютерами, где приходилось думать совершенно иначе: вот большая коммутационная панель и куча схем — интеграторов, дифференциаторов, которые нужно связать воедино, чтобы решать все задачи в реальном времени. Но все начиналось с Фортрана, который я полюбил сразу же. Я все пытался понять, можно ли сделать программы короче и все такое.

В результате я решил, что, возможно, меня заинтересует электротехника. Я поступил на это направление в Стэнфорде, записался на несколько курсов по компьютерным наукам, и мне очень понравилось. Электротехника не занимала у меня много времени. Я попал на курс к Дональду Кнуту, это был курс по оценке программ, и он пришелся мне по душе. Я, собственно, уже работал над программой, которая анализировала бы другие программы, и ушел из Стэнфорда, чтобы сделать на ней бизнес. На следующий год я поступил в магистратуру, а потом ушел. В 1968 году, полагаю.

Сейбел: То есть вы бросили магистратуру?

Ингаллс: Да, на кафедре радиотехники факультета электротехники Стэнфорда.

Сейбел: Что представляла собой программа, с которой вы начали свое дело?

Ингаллс: Все началось еще у Кнута в рамках его семинара по оценке программ и их динамического поведения.

Сейбел: То есть по профилированию?

Ингаллс: Ну, да. Была программа, которая внедрялась в программу на Фортране и вставляла счетчики во все точки ветвления. Я сделал версию посимпатичнее, в ней было прерывание по таймеру, так что она могла записывать, сколько времени потрачено в разных частях программы.

Сейбел: То есть фактически дискретный профилировщик?

Ингаллс: Да. И что еще тут важно: раньше профилирование по времени обычно работало в терминах адресов памяти и требовалась чуть ли не квантовая механика, чтобы понять, что означают полученные результаты. Здесь же работа шла в терминах исходного кода, и вы видели: «Вот, все время расходуется здесь». То есть пользователь мог немедленно воспользоваться информацией. Я понял: «О! На этом можно сыграть».

Сейбел: Вы занимались этим, пока не пришли в Xerox PARC ?

Ингаллс: В общем, да. Вот как я оказался в PARC. Я много времени проводил в местных сервисных центрах: один принадлежал Control Data, а другой — IBM. И я носил свою программу в разные места, чтобы убедиться, что она запустится на конкретном компьютере.

Сейбел: Это по-прежнему был код профилирования Фортрана?

Ингаллс: Да. Но я выяснил кое-что интересное. Кто в основном использует Фортран? Те, кто работает с объемными научными вычислениями. А на кого они обычно работают? На правительство. Интересно им, насколько эффективна их программа? На самом деле, нет. Чаще всего они как раз хотят показать, что их компьютер перегружен, что им нужен новый компьютер и больше денег. Я показал свою программу в паре компаний, и там сказали: «Эх, вот для Кобола — было бы отлично».

Сейбел: Потому что больше денег для крутого железа под Кобол им бы никто не дал.

Ингаллс: Вот именно. И я написал такую же штуку для Кобола. Это было мое боевое крещение в плане Кобола. Помню, как писал завершающую процедуру, которая собирала статистику прерываний по таймеру. Завершающая процедура должна быть написана на том же языке, что и оцениваемая программа, чтобы в нее встроиться. Так что, наверное, я единственный в истории человек, который написал хеш-таблицу на Коболе.

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

Бегая по этим сервисным центрам, я как-то попал в центр CDC в Стэн-фордском индустриальном парке. Обычно работаешь поздно ночью, потому что дешевле. Там я познакомился с парнем, у которого была программа на Фортране для распознавания речи. У него были различные образцы речи, его программа анализировала спектр, группировала фонемы и все такое прочее. Я разговорился с ним и спросил: «Слушай, а не хочешь запустить свою программу с моим профилировщиком?» Так мы и сделали, а потом расстались.

Через пару недель он позвонил мне и сказал: «Я нанялся в Xerox, буду делать для них проект по распознаванию речи. Но тут никто не может мне помочь с разной рутиной, не хочешь со мной поработать?» И я согласился. Это был Джордж Уайт, который долгие годы занимался распознаванием речи. Так я оказался связан с Xerox, а также с Аланом Кэем, поскольку мой офис оказался прямо напротив его, так что доносящиеся оттуда разговоры привлекали мое внимание больше, чем распознавание речи.

Сейбел: Это распознавание речи оказалось таким скучным — или тут что-то связано с программированием?

Ингаллс: Нет, оно было интересным, даже захватывающим. Я в конце концов построил целую среду для персонального компьютера на том мини-компьютере Sigma 3. Использовались пачки перфокарт, работа велась главным образом на Фортране. Из всего этого я создал интерактивную среду. Я написал на Фортране текстовый редактор, а затем средство удаленного управления с терминала. Получилась симпатичная вычислительная среда, довольно затейливая.

Сейбел: Стремление к интерактивным средам красной нитью проходит через вашу карьеру. Например, первый Smalltalk вы написали на Бейсике, потому что он обеспечивал интерактивную среду. Когда вы впервые поняли, что главное условие решения проблемы — это интерактивная программная среда?

Ингаллс: Хороший вопрос. Думаю, немедленная отдача хороша сама по себе.

Сейбел: Где же вы впервые получили немедленную отдачу?

Ингаллс: Вспоминаю пару примеров. У меня была возможность поработать с наполовину интерактивным PL/I. А мой друг работал на IBM, когда у них была интерактивная среда APL. Не помню, что из этого было сначала. Кажется, APL. Она повлияла на меня во многих отношениях: как из-за немедленного взаимодействия — результаты сразу же возвращались, — так и из-за вычисления выражений, которое очень отличалось от ориентированного на операторы программирования на Фортране.

И это сохранилось до сих пор, просто здорово, — вся традиция Си/С++/ Java, хотя и развивается в объектно-ориентированном направлении, по-прежнему ориентирована на операторы. Но если есть возможность удобной работы с выражениями, то это дает совершенно другой опыт. Для меня это применение математики в жизни. Короче, вот один из этих двух примеров. Когда я пришел в Xerox, интерактивных языков, кроме Лиспа, не было. Но мне посчастливилось не подсесть на Лисп. Все сложилось бы иначе, если бы я на него подсел.

Сейбел: Как так?

Ингаллс: Думаю, я бы тогда полностью перешел на то направление. А поскольку я не перешел, мне хочется делать то же самое по-другому. Думаю, то, над чем мы работали с Аланом, было столь же симпатично и живо, но включало более естественное представление объектов и сообщений.

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

Сейбел: Алан Кэй сказал, что и у Лиспа, и у Smalltalk одна и та же проблема: они настолько хороши, что пожирают собственных детей. И если бы вы знали Лисп, то Smalltalk оказался бы первым съеденным ребенком.

Ингаллс: Возможно.

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

Ингаллс: Так и есть.

Сейбел: Нужно ли с этим бороться? Или это просто цена пространства для творчества? Или лучше бы нам больше понимать, что происходит в мире?

Ингаллс: Я за разнообразие. Из приведенного мною примера можно заключить: «Нет, пусть люди делают что хотят». Да, от незнания порой делаешь лишнее, но естественный отбор все исправит. И в конце концов все это помогает продвигаться в будущее.

Можно вспомнить множество областей, где попытки стандартизировать, привести все к общему знаменателю подавляли творческий импульс. Я работаю в компании, где используют Java, так что без подробностей. На конференции OOPSLA было хорошо видно, что когда появился язык Java, это не только замедлило и даже приостановило работу над другими объектно-ориентированными языками, но также сказалось на динамическом программировании в целом. Я считаю это большой потерей.

Но ничто не вечно. В итоге все поняли: «Так, минутку, Java имеет ряд преимуществ, из-за которых мы его используем, но у других динамических языков программирования есть и другие преимущества, так что пора вернуться к ним». Этот очевидный для меня пример, так как я сам был тому свидетелем.

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

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

Есть некоторая разница между компьютерными науками в сфере производства и компьютерными науками в сфере интеллектуального развития. Так, мне нравилось работать над Lively Kernel, хотя это в каком-то смысле тривиальный проект. В нем нет ничего нового: я использую все, что уже было. Он построен на JavaScript и графике, которую можно получить в браузере. Но мне было интересно, поскольку это тоже ядро, как и Squeak. Поскольку JavaScript и графика уже есть в браузере, работы над ядром немного. Оживить графику и построить небольшую вычислительную среду.

Занимаясь чем-то подобным, небольшим, это может понять любой. Если что-то выкинуть, например язык и графику, то возникнет вопрос: где же тогда ядро? И это интересный вопрос, на мой взгляд.

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

Сейбел: Говоря о ядре, вы имеете в виду программное ядро. В чем ключевая идея Lively Kernel?

Ингаллс: Под ядром я понимаю примерно следующее: вы сводите вместе достаточно материала, который может в каком-то смысле создавать себя или другие полезные вещи. Squeak, например, действительно способен создавать себя. Lively Kernel предполагает наличие JavaScript и кое-какой графики, но в итоге она позволяет редактировать графику, и вы можете создавать новые графические штуки и редактировать программы, создавая таким образом новые программы. То есть можно в итоге создать все приложения, которые вы хотели бы встроить в браузер.

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

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

В поисках того, что запускалось бы без установки в браузере, я был вынужден взять то, что было в самом браузере. А что в нем есть? JavaScript и графическая среда. Это был шанс отойти на шаг и сказать: «Что ж, есть ядра языка, есть графические ядра и еще один тип ядра — самостоятельное ядро среды пользовательского интерфейса».

Сейбел: И в Lively Kernel, и в Squeak, насколько я понял, немного с ними поиграв, часть этого ядра, которое не относится ни к языку, ни к графике, — это некое представление пользовательского интерфейса, которое можно программировать: все эти маленькие ручки, которыми можно управлять программно.

Ингаллс: Да.

Сейбел: Мне кажется, это запутывает. Я программирую или использую приложение? Хотелось бы, чтобы различия были более явными.

Ингаллс: Да, это палка о двух концах. И не думаю, что здесь есть простой ответ. Если говорить в целом, то прекрасно, что мы создаем компьютеры, которые позволяют любые изменения. Это и прямой доступ к памяти, и программирование. Мне важно, чтобы сохранялась живость, податливость, способность к изменениям. Если система динамичная и меняющаяся, то значительно проще ограничить ее и сказать: «Вот в этих рамках ничего изменить нельзя», — чем разработать что-то статичное и неизменное и пытаться потом это использовать.

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

Сейбел: Да, проще для всех, кроме тех, кто просто хотел ввести в Сеть немного текста.

Ингаллс: Видимо, так и есть. Но проще тогда добавить сверху слой вроде HTML. Думаю, базовые системы должны быть динамичными, насколько возможно. Затем можно наложить ограничения по типу или синтаксису — то, другое, третье, чтобы ее зафиксировать. Конечно, бывают ситуации, когда люди просто пользуются системой, и тогда нужна неизменность, а не гибкость. И даже, когда до них доходит, что система гибкая, это несколько пугает. Возьмем Lively Kernel: в том виде, как сейчас, это не то, что хотел бы получить конечный пользователь. Вряд ли кому-то захочется увидеть, как окно интерфейса внезапно наклоняется на 20 градусов.

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

Ингаллс: Да-да. На самом деле, это демоверсия для тех, кто хотел бы двигаться в этом направлении. И очень простая, можно добавить уровень, который сделал бы ее полезной, чтобы она не изменялась так сильно и малопонятно. Но да, это действительно компромисс между гибкостью и универсальностью, с одной стороны, и кодифицированностью и способностью использовать программу как справочник, чтобы она делала именно то, что вы от нее ожидаете, — с другой.

Сейбел: Вы действительно полагаете, что нынешняя Lively Kernel или какая-то из ее ближайших модификаций способна стать образцом создания приложений, или это очередной мысленный эксперимент от Sun Labs, чтобы показать людям, в каком направлении думать?

Ингаллс: Конечно, это мысленный эксперимент. Он предлагает пару интересных решений, которые могут воплотиться в реальных продуктах. Он имеет возможность очень быстро делать определенные вещи. Допустим, вы хотите нарисовать красное сердце, написать на нем сообщение и заставить его биться, а потом сохранить как веб-страницу — все это можно сделать внутри браузера, не устанавливая никаких других программ. Берете среду Lively Kernel, строите в ней эту динамическую штучку с небольшим скриптом, а среда создает новую веб-страницу и сохраняет ее по протоколу WebDAV.

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

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

Сейбел: Общеизвестно, что вы принимали участие в создании не то пяти, не то семи, не то вообще не знаю скольких поколений реализаций Smalltalk. Начнем с первого Smalltalk, который вы сделали на Бейсике. У вас было несколько страниц записей Алана Кэя, которые нужно было претворить в жизнь. Что вы делали?

Ингаллс: Я просто начал набивать код. Первым делом, кажется, я проверил модель исполнения. Требовалось всего несколько базовых структур — эквиваленты стекового фрейма. И я сделал — кажется, это был массив на Бейсике, — чтобы все заработало и можно было прогнать кусок кода.

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

Со временем все это улучшаешь. Затем в этом конкретном случае, уже после того как все заработало, нужно было внедрить уровень, по сути, парсер: в него вводился текст, и из него надо было получить структуру, макет которой был сделан. Потом добавлялась среда — и все мало-помалу становилось понятным.

И тогда говоришь: «Так, теперь я вижу, как это работает, пора писать это на ассемблере», — примерно в этом духе. А потом вдруг осеняет: «О, нам нужно автоматическое управление хранением данных. Как бы это устроить»? То есть одно следует за другим.

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

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

Если сравнивать с другими разработчиками, то я, возможно, ошибаюсь чаще всего на той стадии, когда надо заставить все заработать. Во многом это из-за того, что я настолько радуюсь, когда рождается что-то новое, что мне даже неважно, если поначалу это новое не работает. Дело в том, что как только программа оживает, она сама может рассказать, что с ней не так.

И обнаруживаешь, что да, возможно, стоило сделать управление хранением данных совершенно иначе, но действительно важные вещи, которые узнаешь по ходу работы, не имеют ничего общего с этими частными вопросами. Первые версии Smalltalk, которые я сделал, использовали для сборки мусора подсчет ссылок, хотя, наверное, следовало применить что-то иное. В результате возникли некоторые проблемы с подсчетом ссылок. Но это не играло большой роли: главное, что система родилась, стала жить и работать, и мы получили большой опыт в том, как работать с объектами, как обрабатывать числовые данные объектно-ориентированным образом, — и это действительно был прогресс.

Сейбел: Не знаю, насколько вы тут отличаетесь от большинства, по крайней мере от тех, у кого я брал интервью для этой книги. Хотя, Дон Кнут действительно написал ТеХ карандашом в блокноте за шесть месяцев, прежде чем начал набивать строки кода, притом он еще утверждал, что сэкономил время, поскольку ему не пришлось писать тесты для всего разрабатываемого кода, потому что он написал все оптом.

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

Возвращаясь к необходимости размышлений о том, как заставить программу работать правильно, не могу не вспомнить, что пару раз я так и делал. Первый пример, который приходит на ум, — это BitBlt. Когда я решил сделать то, что в итоге воплотилось в BitBlt, было несколько вариантов, и потому пришлось сидеть и размышлять пару ночей. Как более эффективно перенести все эти биты по границам битов через границы слов? В этом случае ни одна из существующих в мире альтернатив для меня не годилась. Я думал-думал — и в итоге придумал простую модель. До того никто этого не применял, но я посмотрел на все случаи, где мы использовали похожие операции — графические изображения, текстовые дисплеи, прокрутку, — и придумал, что нужно делать.

Сейбел: Может быть, вы в двух словах расскажете, какую проблему главным образом должен был решить BitBlt?

Ингаллс: Проблему несоответствия между необходимостью думать о дисплее как о пиксельном экране размером 1000x1000 и тем фактом, что память организована пословно. Если вы хотите взять четыре бита и перенести их туда, они могут быть в другой части слова, чем та, в которую вы их переносите. Собственно, эти биты могут располагаться в разных словах. Если вы пытаетесь переместить биты на экране, бывает так, что вы берете куски двух разных слов здесь и помещаете их туда, А когда вы их уже расположили, нужно сохранить и целое слово. То есть ваша задача — вставить биты в то, что здесь было до того, и все вокруг замаскировать. Полный бардак.

Далее, у нас есть растровый экран — построчный экран, два измерения. BitBlt умеет работать с ситуацией, когда источник и цель имеют различное число слов на сканирующую строку.

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

Я протестировал и убедился, что эта идея работает, сначала на Smalltalk, затем на ассемблере, а потом перегнал все в микрокод для Alto. В итоге мы могли проводить эти операции на полной скорости памяти, без задержек из-за этой мерзкой маскировки и переносов, поскольку все это можно было спрятать за временем цикла памяти.

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

То, что я придумал, пришло ко мне скорее в виде образа, чем чего-то другого: это было похоже на колесо. Если посмотреть на источник, цель и границы слова, то кажется, что колесо забирает целые слова здесь и переносит их туда, так что требуется только один перенос, — вот такая картина мне и явилась. Теперь оставалось только переложить это на язык кода.

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

Сейбел: Вернемся к варианту Smalltalk на Бейсике: получается, это был предтеча Smalltalk, даже еще до Smalltalk-72?

Ингаллс: Именно так. Как только он заработал, я тут же начал делать практически полную версию на языке ассемблера, который у меня был на Nova. Мы использовали ее для отладки, а параллельно создавался компьютер Alto. Как только он стал доступен, мы переключились на него. Так и появился Smalltalk-72.

Сейбел: Итак, Smalltalk-72 был написан на ассемблере — когда же, в таком случае, он стал самодостаточным? Часто можно услышать, что лучшее в Smalltalk — то, что многое в нем написано на нем самом.

Ингаллс: Это было уже намного позже. Smalltalk-72 содержал большое количество кода на ассемблере. Как, собственно говоря, и Smalltalk-76. Основная разница между Smalltalk-72 и Smalltalk-76 заключалась в том, что я предложил идею движка байт-кода для Smalltalk, у которого был синтаксис на основе ключевых слов и который компилировался. Так что классы и даже стековые фреймы были реальными объектами — это к вашему замечанию о самодостаточности.

Сейбел: Когда вы пришли к идее написать интерпретатор байт-кода?

Ингаллс: Меня захватила такая идея: синтаксический анализ (парсинг) Smalltalk-72 выполняется на лету, и как минимум по двум причинам нам нужно было уметь компилировать нечто с той же семантикой, но не требующее моментального парсинга.

И я предложил синтаксис Smalltalk-76, который во многом был близок синтаксису Smalltalk-80. Затем встал другой вопрос: как компилировать, чтобы эффективно заработало с новым синтаксисом? Впрочем, единственным моментом, с которым возникли сложности, были так называемые удаленные вычисления — переменные, которые вы объявляете в одном месте, вычисляются в другом. Так в Smalltalk появились блоки — эквиваленты замыканий в других системах.

Сейбел: А почему просто не компилировать в машинный код?

Ингаллс: Мы по-прежнему экономили память, и наш вариант выходил исключительно компактным по сравнению с любым другим. И он должен был быть компактным, потому что запускать это все равно предстояло на Alto с 96 Кбайт памяти. Потом вышли более объемные разновидности — 128 Кбайт. То есть была важна компактность.

Сейбел: Значит, порожденный код был меньше, потому что байт-код был богаче, чем машинные инструкции?

Ингаллс: Да. Я был в восторге от идеи, навеянной работой Питера Дойча над движком байт-кода для Лиспа. Это взаимодействие очень повлияло на меня: появилось еще одно ядро, которое могло поместиться в микрокод. С самого начала работы я старался уместить ее в микрокоде для Alto.

Сейбел: Микрокод был в памяти, так что вы могли бы внедрить туда ядро Smalltalk, а затем переключиться на Лисп и встроить туда интерпретатор байт-кода на Лиспе.

Ингаллс: Да.

Сейбел: Что стало следующим шагом?

Ингаллс: Smalltalk-76 унаследовал тот же графический багаж: много специального кода для отрисовки линий, вывода текста и так далее. Но в то же время я уже сделал BitBlt, так что я переписал ядро, чтобы вся графика использовалась только BitBlt и Smalltalk, в итоге ядро стало значительно меньше. Это был Smalltalk-78 — первый, который мы запустили на микропроцессоре — на 8086.

Но это по-прежнему не был Smalltalk на Smalltalk. Smalltalk на Smalltalk не существовал до появления Squeak. Для Smalltalk-80 были спецификации виртуальной машины — они были опубликованы в виде книги, но все реализации были на Си или на ассемблере.

Сейбел: А компилятор?

Ингаллс: Компилятор был написан на Smalltalk. Собственно, когда мы писали книги о Smalltalk-80, мы с Дэйвом Робсоном — в основном, впрочем, он — написали на Smalltalk эмуляцию интерпретатора байт-кода. Это должно было стать частью Smalltalk-80: мы хотели помочь людям создать собственные виртуальные машины. Мы обнаружили, что очень полезно знать, какие именно байт-коды и в каком порядке выполняются при первом запуске системы.

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

Сейбел: Итак, вы решили помочь людям создавать собственные виртуальные машины, потому что Smalltalk-80 был задуман как спасательный круг, и Smalltalk мог выйти в свет, даже если бы PARC решила от него отказаться?

Ингаллс: Именно так. Потом я ушел из индустрии, а когда вернулся, решил сделать Smalltalk для нового проекта. В то время все работало быстро: «Стоп, а почему бы не запустить версию этого на Smalltalk и не посмотреть, к чему это приведет?» Но главное «Ага!» заключалось в том, что нетрудно будет механически транслировать это в Си, и оно будет работать так же быстро, как и другие движки. Если вы хотели что-то изменить в виртуальной машине, можно было изменить это прямо в Smalltalk, нажать кнопочку, и все сразу оказалось бы в интерпретаторе.

Сейбел: Итак, вы взяли интерпретатор Smalltalk, написанный на каком-то подмножестве Smalltalk, и сделали специальный компилятор, который умеет компилировать это подмножество в Си?

Ингаллс: А транслятор Си был просто частью компилятора Smalltalk — с его помощью печатались синтаксические деревья. Это мы, собственно, уже делали в Xerox — Тед Кэглер написал на Smalltalk виртуальную память, а потом мы использовали тот же прием для ее перевода на BCPL. То же самое.

Сейбел: Когда Smalltalk-80 вышел в свет, уже существовали компании, работающие со Smalltalk, объекты были модным увлечением, журнал «Byte» посвятил Smalltalk целый выпуск. Предполагалось, что объекты станут повторно используемыми компонентами: программисты будут заходить в «Магазин подержанных объектов», покупать нужные и встраивать их в свою программу. Получилось ли так?

Ингаллс: И да и нет, думаю.

Сейбел: Что же произошло в итоге?

Ингаллс: Посмотрите на мир Java — там так все и есть. Есть большие массивы программ, которые хорошо работают вместе благодаря соответствующим интерфейсам. Думаю, это был значительный шаг вперед. В Smalltalk было несколько идей, которые более или менее укоренились в мире. Среди них — объектно-ориентированный дизайн и интерфейсы. Еще упомяну динамические языки и пользовательские интерфейсы. Они не победили, в истории можно найти случаи, когда можно было все сделать по-другому и притом лучше. Но не думаю, что из-за этого многое можно было потерять или приобрести. Мир движется вперед медленно. Победили другие принципы — значит, они были лучше. Обо всем заботится естественный отбор.

Сейбел: Но в результате естественного отбора могут появиться и довольно причудливые формы.

Ингаллс: Да, например Beta и VHS. Но ничто действительно хорошее не теряется.

Сейбел: Еще один аспект Smalltalk, что в последние годы постоянно подчеркивает Алан Кэй, — это язык не об объектах, а о передаче сообщений. C++ и Java не могут похвастаться такой передачей сообщений, как Smalltalk. Почему эта идея столь важна?

Ингаллс: Потому что она дает подлинную независимость. Последнее высказывание Алана — мне оно тоже нравится — гласит, что язык должен во многом напоминать Интернет. Мы всегда заботимся о безопасности и придумываем самые разные механизмы безопасности в программах, с которыми постоянно могут случаться всякие нехорошие вещи. Но независимость по типу Интернета — это реальный и наилучший вариант.

Итак, чем же так хороша пересылка сообщений? Дело вот в чем: она обеспечивает полное разделение внешнего и внутреннего, на 100%. По крайней мере, если ее сделать правильно. Есть и другие системы, которые в этой области продвинулись дальше, и думаю, что в этом направлении мы еще увидим многое.

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

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

Мы добились огромного прогресса в программировании систем и в знании языков. Но что если бы мы были столь же хороши в логическом программировании? И смогли бы его лучше интегрировать? Думаю, в этом случае мы бы смогли сделать значительно больше в области, относящейся к взаимодействию с человеком. Сейчас же все двигается в направлении искусственного интеллекта. Вы знаете, что в один прекрасный момент мы уже перейдем черту, за которой компьютеры будут думать лучше, чем мы сами.

Порой мне кажется, что мы сами бессознательно сдерживаем этот прогресс. До 1980 года в этой области было сделано многое. А компьютеры сейчас на порядки мощнее, умнее и быстрее. На моем последнем компьютере можно запустить музыкальный синтезатор на Smalltalk, способный рассчитать радиосигнал для радиостанции. Это трудно понять тому, кто еще помнит трудности простых арифметических вычислений.

Если сравнить нынешние достижения с возможностями в логическом программировании, в системах на основе продукционных правил, в искусственном интеллекте, то надо сказать, что тут еще есть куда идти. Я бы хотел проследить тот тип мышления, который привел в конце концов к Lively Kernel, — что такое ядро в отрыве от языка и пользовательского интерфейса? Какие еще ядра бывают? Что будет, если построить ядро на основе логического программирования, и что на основе этого можно сделать? Не думаю, что все, кто вокруг этого крутится, работают вхолостую. Господи, да с теми машинами, которые у нас есть сейчас, даже самое маленькое открытие ведет к совершенно невероятным вещам!

Сейбел: Smalltalk изначально планировался как образовательная платформа?

Ингаллс: Предполагалось, что это будет язык для детей — ребят любого возраста, если точно процитировать Алана. Думаю, всему проекту — и притом долгосрочному проекту, — среди прочего, помогло то, что мы не ставили задачу создать лучшую в мире среду для программирования. Мы собирались создать программное обеспечение для обучения, поэтому ориентировались главным образом на простоту и моделирование реального мира.

Эта образовательная цель побудила нас также сделать низкоуровневую часть насколько возможно проще. Поэтому там было множество вещей, которые работали не так быстро, как, возможно, вам бы этого хотелось. Первая система Smalltalk-72 была очень медленной; ее вторая редакция работала в 20-25 раз быстрее. Но у нас, слава богу, все заработало, мы использовали ее при работе с детьми и многому научились еще до того, как приступили ко второй версии.

Мы уделили серьезное внимание работе растровой графики и музыки, а также их сведению в относительно простом языке. Мы многому научились в ходе работы, и в итоге получился действительно хороший язык. После Smalltalk-72 мы сделали Smalltalk-76, который фактически представлял собой Smalltalk-80. И я понял, что это может быть серьезной программной средой для всей индустрии. У нас даже возник некий конфликт с Аланом, поскольку он не хотел углубляться в этом направлении.

Спустя некоторое время он ушел из Xerox, и наши пути разошлись. Это произошло, потому что мы кое-что выяснили. Например, время на внесение изменений в систему теперь исчислялось секундами, а вскоре должно было составить доли секунды. Система была жива и полностью функционировала. А это то, что мне, как и многим другим, очень нравится. Давайте строить такие же живые системы. Именно такой системой стал Smalltalk. Затем возникла новая цель, что породило Smalltalk-80. Squeak был в какой-то мере возвращением к той же концепции, но с добавлением возможности писать его на нем самом.

Сейбел: Итак, вы с Кэем пошли по разным дорогам. Разочаровались ли вы в изначальной концепции Smalltalk?

Ингаллс: Нет, ни в коем случае. Я уже говорил, что по образованию я физик, и в моей натуре, думаю, заложена привычка глядеть на мир и думать, как он работает, каковы действующие в нем силы, как движутся планеты, как дуют ветры и все такое, задавать вопросы об этом и ощущать тесную связь со всеми явлениями. В физическом мире, во всяком случае, это просто. Можно войти в явление с нулевым пониманием и выйти, полностью представляя себе, как оно работает.

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

Когда я ввожу в Smalltalk новичка, я обычно говорю: «Что вас интересует здесь: разбор текста? Работа с числами? Графика? Или работа с музыкой?» И потом мы начинаем углубляться в материал. Это во многом по-прежнему моя страсть — уверен, и Алана тоже: мы любим погружаться с новичками в том направлении, которое им интересно, а выныривают они оттуда уже с такими идеями, которые Алан называет мощными, — теми «Ага!», позволяющими оценить поразительное разнообразие, которое на деле получается из пары-тройки простых, самых общих работающих элементов.

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

Squeak — это среда для ученого, компьютерного специалиста. eToys — среда для детей, но, к сожалению, не столь понятная, как могла бы быть. Я до сих пор считаю, что мы ее не доработали, не добавив элемент, который мог позволить чисто интуитивно погрузиться внутрь и вынырнуть с физическим пониманием этих впечатляющих идей.

Я до сих пор ношусь с этим так же, как и со всем остальным. Почему я продолжаю заниматься подобными вещами — JavaScript и браузером? Мы уже очень близки к тому, чтобы поместить материал вроде Squeak на веб-страницу, которую можно просматривать любым браузером и с которой можно взаимодействовать каким-нибудь удобным и понятным образом. Это часть общей картины. Уверен, вскоре она изменится. Браузеры должны измениться. Мы возьмем другие языки, не только JavaScript. Я по-прежнему поддерживаю контакт с Аланом и его группой, которые предпринимают новую попытку зайти дальше и решить некоторые из текущих проблем более серьезно. Но подход при этом остается совершенно тем же самым.

Сейбел: Вы упоминаете четыре дисциплины: музыка, графика, математика и текст. Они стары почти как само человечество. Безусловно, у них есть свои впечатляющие идеи вне зависимости от всяких компьютеров: компьютер просто обеспечивает способ их исследовать, что без него могло бы быть сложнее. Есть ли также интересные идеи, внутренне присущие компьютерам? Является ли программирование или компьютерные науки еще одним, пятым фактором, в котором мы можем разобраться только сейчас, уже владея компьютерами?

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

Вот алгебра графики: примитивные объекты, суперпозиция переносов, вращений. Или музыка: ноты, временные интервалы, аккорды — то же самое. И это, полагаю, то же самое, что знать, как дует ветер и как вращаются планеты. Это приглашение к исследованию и пониманию того, как все происходит, того, что составляет алгебру — процессов и примитивных объектов. Да, пятый фактор, как вы его называете, существует и взаимосвязан со всеми предыдущими.

Сейбел: Как вы считаете, появятся ли те, кто, преуспев в трех или четырех первых отраслях, затем выучатся благодаря этому программировать? Или это может случиться, только если их интерес пойдет по определенному пути?

Ингаллс: Думаю, все бывает, и это тоже. Тем более что вы оттачиваете их мыслительные способности, знакомя их с предметом и заражая энтузиазмом. Но одни хотят программировать, а другие нет. Например, мой 12-летний сын, по-моему, хочет только делать повороты на 540 градусов на лыжах — что ж, всему свое время и место.

Сейбел: Вернемся в специальные области: как вы тестируете свои программы?

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

Сейбел: Допустим, вы начали работать с чем-то, что, по-вашему, принесет хороший результат. Первый тест — приемочный тест: вы рисуете окно на экране или делаете что-то другое? И как насчет более тонких тестов?

Ингаллс: Если вы только что сделали возможным что-то взять, переместить, положить, вам понадобится фреймворк, чтобы с этим работать. Такой ли это фреймворк, чтобы любой другой мог прийти и увидеть, что проводились такие-то тесты? У меня обычно не так. Это своего рода привилегия моего поколения, сейчас уже такое не пройдет. Я старпер, так что никто уже меня не заставит этим заниматься. Но, думаю, то, что я делаю, во многом приближается к такому варианту. Код Squeak, например, был полон комментариев о том, как что выполнить и как что проверить. А во многих тестах BitBlt имеются такие небольшие механизмы, которые берут что-то в одном месте экрана, проводят с этим некие операции и возвращают обратно, и если на экране что-то изменилось, значит, этот механизм не работает, и это написано в комментарии. Мне кажется, это и есть тест.

Сейбел: Поговорим о совместной работе. Группа по исследованию обучения в PARC была известна своей сплоченностью. Как вы сотрудничали в работе непосредственно над кодом?

Ингаллс: Просто постоянно были на связи и периодически вносили беспорядок в чужую работу. Мы никогда не были большой группой, у каждого была своя сфера деятельности. Сегодня очень развито командное программирование, но я, честно говоря, ничего в нем не понимаю. Вот сейчас, например, в Lively Kernel часть, относящуюся к ядру, сделали мы вдвоем с еще одним сотрудником, Кшиштофом Палачем. И мы сразу договорились о разделении сфер нашей деятельности. Да, мы действительно сейчас используем репозиторий кода, и в нашей команде есть другие ребята, которые занимаются более прикладными вещами, ядром совсем немного. И я вижу, что действительно очень удобно иметь общий репозиторий, просто замечательно. Следующий для Lively Kernel шаг — это интеграция с репозиторием: в Lively Kernel можно вносить изменения, но только в работающую версию; они не попадают в репозиторий и не сохраняются на будущее. Это следующий шаг, который мы должны сделать.

Сейбел: Занимались ли вы когда-нибудь парным программированием?

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

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

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

Сейбел: Вы работали на многих уровнях: от побитового переноса в BitBlt и написания микрокода до довольно высокоуровневого программирования на Smalltalk. Насколько программистам необходимо знать о различных уровнях программного и аппаратного обеспечения, с которым они имеют дело?

Ингаллс: Хороший вопрос. Чтобы думать не по шаблону, нужно выйти за рамки шаблона. Если в вашем обычном подходе к языку нет того, из чего можно извлечь преимущество, надо проявить интуицию, расширить обычные рамки, показать понимание и способность к контролю.

Если говорить о создании языка, то, возможно, вы захотите работать с процессорами, которые вам не очень знакомы; в этом случае вам не надо знать о них ничего, кроме того, как работает кэширование и все такое, — это необходимо для обеспечения нормальной производительности. Думаю, надо остановиться и спросить: «Какие границы я здесь пересекаю?»

Сейбел: Оставим вопрос о том, как много нужно знать, если речь идет о программе. Одни утверждают, что начинать нужно с высокоуровневого языка, чтобы ухватить некие общие идеи. Другие — что начинать надо с ассемблера и двигаться вверх, чтобы полностью понять, что же происходит. Что из этого вам ближе?

Ингаллс: Откровенно говоря, ничего. Я учился так, и мне нравились такие-то вещи. Но, думаю, всегда будут те, кому по душе придется тот или иной уровень. Но не думаю, что существует какой-то один путь, как нет единой дороги в искусстве.

Есть и другие вещи, столь же захватывающие, а в наши дни, возможно, еще и более подходящие, которые еще только предстоит изучить. Господи, да мы задумывались о создании искусственного интеллекта четверть века назад! Машины стали неизмеримо быстрее, а мы почти ничего не делаем в этой области, мы по-прежнему остаемся почти на уровне Фортрана. Долгое время был популярен Пролог; с логическими программами можно сделать все, что угодно. Если требуется узнать об ассемблере и о том, как он работает, нужно немного погрузиться в то, что находится за рамками шаблона; возможно, это стоит отложить на будущее.

Так что я не говорю «нет» языку ассемблера — я говорю, что необходимо изучить другие действенные технологии, так чтобы вы могли извлечь из них выгоду, когда будете думать о том, куда двигаться дальше. Если говорить о том, как начать, то для меня всегда большую роль играла возможность немедленно получить какой-то результат. Когда я хочу научить кого-то языку Smalltalk, то обычно провожу небольшой опрос: «Что вас интересует больше всего? Игра с текстом? Или то, что можно сделать с числами, с графикой, с музыкой?» И начинаю с того, что выберут.

В разбиении и сведении текста много такого, от чего можно получить настоящее удовольствие. То же относится и к числам, различным системам счисления, плавающим и фиксированным запятым. То же самое с музыкой: берете ноты и объединяете их в мелодии и аккорды. То же самое с графикой: суперпозиции и повороты. Любой вариант из этого — интересное поле для исследования. Точно так же, если собираетесь научить кого-то программировать на компьютере, то можно начать с вычисления выражений, а можно с логического программирования. Можно начать и с пользовательского интерфейса. Нужно натаскать человека в одной отрасли, откуда он будет уже продвигаться вглубь.

Сейбел: Насколько я понимаю, изначальное предназначение Smalltalk состояло в том, чтобы научить своего рода азам программирования. Как вы считаете, это то, чем должен владеть каждый, подобно тому, как каждый должен уметь читать и знать что-то из математики? Должны ли все уметь немного программировать на компьютере, просто потому что это полезный способ мышления?

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

Компьютеры несут ряд впечатляющих идей, а также могут привнести в жизнь другие впечатляющие идеи. Самое чудесное в компьютерах — это то, что они воплощают в жизнь математику. В этом отношении они прекрасный инструмент. Если же говорить о впечатляющих идеях, необходимых в обычной жизни, то я не могу сказать, сколько таких идей заключено в данной области.

Сейбел: Сеймур Паперт писал в книге «Mindstorms» (Мозговые штурмы) об отладке как о важном элементе интеллектуального арсенала: идея программирования заключается не в том, чтобы найти обязательно верный ответ, но в том, чтобы найти какой-нибудь ответ и затем отладить его.

Ингаллс: Вот именно! Нам нужно научиться ясно мыслить и задавать вопросы. Для меня это просто основополагающее понятие. Если вы живете в семье, в которой, если дверца шкафа не закрывается, то ее осматривают и видят, что из петли выпал винтик, — это одно, а если в такой, где в данном случае просто говорят: «О, дверца сломалась, надо кого-то вызвать», — то это другое; чувствуете разницу? Думаю, не надо быть экспертом по компьютерам, чтобы понять, когда то, что вы видите, не работает. Спрашивайте. Смотрите. И думайте, как устранить проблему, если вы с ней столкнулись. Мне кажется, что это так просто и в духе человеческой натуры, что передается из поколения в поколение.

Компьютеры — безусловно, необходимый в этом случае посредник. Но это ведь только компьютеры. Они могут передать что угодно, но мне кажется, что все основное заключено в человеке, поэтому вряд ли мы сможем просветить весь мир, просто научив его пользоваться компьютерами.

Сейбел: Вы помните первую интересную программу, написанную вами?

Ингаллс: Дайте-ка подумать. В любом моем программистском опыте было нечто нешаблонное. Так, изучая VisiCalc, я написал табличную программу для перевода с помощью VisiCalc английских слов в «поросячью латынь». На мой взгляд, это интересно, поскольку табличная метафора была сродни параллельному программированию. Такой анализ текста был и интересен, и познавателен.

Сейбел: То есть в VisiCalc имелись примитивы для разбиения строк?

Ингаллс: Да, там можно было разбивать строки. Правда, может, на самом деле у меня был Lotus 1-2-3, а не VisiCalc, потому что я что-то не уверен, были ли в VisiCalc строковые примитивы. У меня был маленький Poqet PC — один из первых настоящих наладонников. Он работал от двух батареек, я поставил на него 1-2-3, и когда летел на самолете через всю страну, то думал, что бы такого сделать.

Сейбел: Вероятно, это было гораздо позже того, как вы научились программировать, потому что когда вы начинали, никаких Poqet PC явно не было.

Ингаллс: Да, позже. Самое интересное из того, что я сделал на Фортране: я взял статью Вэла Шорра о МЕТА II — это отличный, очень простой компилятор компиляторов — и написал его реализацию на Фортране. Вдруг оказалось, что можно пользоваться другими языками в чисто фортрановой среде. Это было самое интересное, что я сделал на Фортране — ведь здесь Фортран использовался для освобождения от мира Фортрана.

Сейбел: Интересно получается: таблица с «поросячьей латынью», потом это, потом хеш-таблица на Коболе для профилировщика — можно ли сказать, что какая-то часть вашей души любит идти против течения?

Ингаллс: Мне не кажется, что я иду против течения, но каждый раз, когда у меня есть возможность поиграть в вычислительной среде, я стараюсь пробовать что-то новое. Вот почему мне так нравилось делать все эти системы на Smalltalk. Начинаешь, можно сказать, с нуля, и первая задача — понять, что нужно ассемблировать и заставлять работать в первую очередь, что поможет сделать следующий шаг и определит направление, в котором двигаться.

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

Сейбел: Сильно ли изменились со временем ваши представления о программировании?

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

Что еще слегка изменилось: теперь я не занимаюсь в своей группе квантовой механикой. Я нахожусь на более высоком уровне. Это означает, что я провожу больше времени, определяя цели и занимаясь политикой, и меньше занимаюсь кодом. Я создаю контекст. Раньше мне везло, я работал с уже существующим контекстом, мне не нужно было его создавать. Но время от времени я все же сажусь и пишу довольно серьезный код.

Сейбел: Я читал одну из ваших работ в 1970-е о профилировщике для Фортрана. В предисловии вы с восторгом говорили о том, как этот инструмент изменил ваши представления о программировании: сначала вы обдумывали, как собираетесь писать, писали и отлаживали, а теперь, обдумав, что будете писать, пишете очень простую версию, затем профилируете ее и оптимизируете. Вы по-прежнему работаете таким же образом?

Ингаллс: Я действительно сначала ищу явные эффекты — пикселы на экране или что-то в этом духе, — потому что они очень мотивируют, и нередко узнаешь что-то новое о том, что хотел сделать, просто взглянув на то, что происходит.

Если нужно профилирование, то занимаюсь им. Или может оказаться, что все делается неправильно, не совсем то, что нужно, так что приходится менять цели или образ действий. Но когда речь идет о производительности, я по-прежнему работаю, как описал. Мы сделали действительно отличный профилировщик на Smalltalk, а затем на Squeak, с помощью которого можно получить качественную обратную связь. Отчасти здесь речь о производительности, но отчасти — о структуре и архитектуре. Можно обнаружить, что некоторые элементы почти совсем не используются, так что от них можно отказаться, сделав что-то иначе. Это просто другая точка зрения.

Сейбел: Наверное, почти у каждого программиста есть книга Кнута «The Art of Computer Programming». У одних она просто стоит на полке, другие используют ее постоянно. А кое-кто вообще прочитал ее от корки до корки и знает назубок. Собственно, вы-то общались с Кнутом в Стэнфорде. Вы читали книгу?

Ингаллс: Мне нравилось работать с Доном, один семестр я посещал его курс по MIX в Стэнфорде, и это было очень полезно. Думаю, мы с Доном серьезно отличаемся друг от друга, но что мне в нем нравится, так это то, что у него отличный математический ум, при этом он любит и глубоко погружаться в мелочи, то есть в прагматическую сторону вещей. Я тоже люблю прагматизм, но мне недостает строгости подхода Дона.

Я по образованию физик, и для меня проблемы, над которыми я работаю, выглядят физическими задачами. Говоря о других перспективах программ, я представляю их себе как вещи, которые можно потрогать — и почувствовать ответную вибрацию.

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

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

Сейбел: Как вы считаете, в каком объеме программистам необходима математика? Дейкстра заявил, что компьютерные науки — просто отрасль математики. А понимание «Искусства программирования» требует недюжинного знания математики.

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

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

Сейбел: Вы сказали, что не очень-то любите читать. Есть ли тем не менее какие-то книги, которые вы могли бы порекомендовать?

Ингаллс: Нет. Уверен, что тут я в меньшинстве. Я и в детстве читать не любил. Иногда я читаю очень тщательно и не прерываясь, пока не закончу. Конечно, я могу назвать несколько статей, и, вероятно, некоторые из них выросли потом в книги. Одна из них — это статья Вэла Шорра о META II. Потом есть книга о Lisp 1.5. Есть еще APL, но книга Айверсона, по-моему, не лучшее пособие для обучения. Пусть ее математики читают. Даже не помню, что я про это читал, но мне понравилось. Думаю, вместо чтения книги можно потратить время на какой-нибудь язык. Например, на Smalltalk.

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

Ингаллс: Да, я люблю само программирование. Последние пару лет были интересны, потому что я оторвался от той среды, к которой так привык, то есть Smalltalk и затем Squeak, где просто замечательный инструментарий. Пришлось сделать небольшой шаг назад, работая с JavaScript в браузерах и в обычных средах разработки. В итоге иногда отладка занимала у меня больше времени, чем я привык, но общий процесс появления идеи и воплощения ее в жизнь — это то, чем я продолжаю наслаждаться.

Сейбел: Как вы считаете, программирование — удел молодых?

Ингаллс: Нет, не думаю. Самое важное — это иметь способности к исследованию того, что происходит, и ту бесконечную энергию, которой, кажется, у меня больше нет. Но я все еще люблю взять проблему, посидеть над ней и сделать так, чтобы все заработало. Вот такая аналогия: я стал учиться играть на фортепьяно сравнительно поздно. Мне говорили: «О, вам надо было раньше начать, вы так быстро все схватываете». Хотя далеко я не продвинулся, но могу сделать вывод, что неверно, будто бы в молодости обучение всегда дается проще; у них просто больше времени. Когда я тратил достаточно времени, прогресс был.

Примерно то же самое я думаю и о программировании. Когда я оглядываюсь назад, на свою молодость, то понимаю, что тогда у меня времени было сколько угодно. Работай себе и работай. Сейчас же в моей жизни происходит и многое другое, у меня есть обязанности, которые не исчерпываются программированием. Это несколько отвлекает.

Сейбел: Программирование требует времени, но не нужны ли для него также и трудолюбие, и концентрация? Говорят, что это непрерывный процесс, что если отвлекать человека каждые пятнадцать минут, то он ничего не сделает, потому что требуется много времени даже для того, чтобы начать раскладывать идеи по полочкам в голове.

Ингаллс: Это мне напоминает то, что я когда-то сказал кому-то в PARC. У меня появились другие обязанности, кроме возни со Smalltalk, но мы уже сильно продвинулись на пути создания из него действительно очень продуктивной системы. Я пошутил, что спешу улучшить среду Smalltalk, чтобы в промежутках между этой деятельностью можно было наконец заняться нормальной работой. Так что я привык к тому, что у меня есть минут 15, и в это время я успевал посидеть и придумать что-нибудь полезное.

Другая сторона проблемы — то, что вы работаете с другими. Я работаю с молодежью, и это прекрасно. Возможно, я чуть больше размышляю о целях, политике и том, как заставить все работать, а они делают то, чего мне не хватает: у них достаточно времени для действительно глубокого проникновения в суть вещей.

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

Ингаллс: Просто я люблю то, что делаю. И мне нравится сотрудничать с другими. Они могут работать вглубь или вширь, так что несложно найти рабочие задачи для разных людей. Мне всегда нравилось работать с другими. Работа идет то лучше, то хуже — бывают разные фазы. Иногда понимаешь буквально все, что надо сделать, и нужно только сказать людям, что делать. А бывает и по-другому: не знаешь, что нужно сделать, и пытаешься это выяснить. Это два очень разных состояния.

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

Ингаллс: Во-первых, нужно ясно дать понять, что вы пытаетесь сделать. Нужно обеспечить всем недвусмысленное представление о работе. Если вы в курсе дела, то можете сами увидеть, как собираетесь реализовать ту или иную идею, чтобы начать понимать, как она будет работать, если этим займутся несколько человек одновременно, и как все это увязать.

Иногда я работал над проектом — и мне было все понятно. Это удача, потому что когда кто-либо начинал испытывать затруднения, я мог сразу ответить, какие должны быть следующие шаги или как обойти возникшее препятствия. И люди чувствуют, когда ты действительно знаешь то, чем руководишь. Они немедленно понимают: да, этот мужик специалист. И это придает команде уверенности.

Сейбел: Бывало ли так, что слишком ясное представление о цели, наоборот, лишало людей мотивации: мол, раз все и так понятно, то доделывать это неинтересно?

Ингаллс: Ну, тут можно просто не вмешиваться в то, как они работают над своей частью общей задачи, и только иногда осуществлять самое общее руководство, когда требуется. Нередко это и к лучшему. Мне повезло долгое время работать со множеством сотрудников, которым я доверял. Очень важно доверять тем, с кем вместе работаешь. Еще один важный фактор — уверенность. Когда цель ясна, быть уверенным легко. Плохим управление бывает как раз тогда, когда беспокоишься, не чувствуешь себя в безопасности и боишься, что нужно постоянно за всем и за всеми следить.

Сейбел: Когда вы еще были рядовой рабочей пчелой, попадался ли вам действительно выдающийся руководитель?

Ингаллс: Лучшим боссом в моей жизни, конечно, был Алан Кэй. Я работал под его началом в Xerox, пожалуй, в ключевые годы моей жизни, и это была интересная комбинация, потому что он знал, чего хочет, но почти никогда не говорил, как я должен работать. При этом у него было столько технической смекалки во всем, что это делало его отличным критиком. И я, и мои коллеги отличались в то время большой продуктивностью, так что, полагаю, он чувствовал, что при таком уровне прогресса ему совершенно необязательно вмешиваться. Но он прикрывал и меня, и всех нас, и у него в голове была четкая картина того, что он хочет получить на выходе.

Сейбел: Когда люди работают в группе, какой подход лучше избрать? Тот, при котором у каждого разработчика есть свой кусок системы: «Вот это мой код, не трогайте его». Или вся команда занимается всем кодом, и любой может работать на всех участках?

Ингаллс: Не знаю. Вот как мы сейчас работаем над проектом Lively Kernel: у разных людей разные участки работы, но никаких преград при этом нет. Это во многом вопрос квалификации, концентрации или целей. Пытаюсь вспомнить, как мы работали в те времена, которые были действительно успешными. Никогда не работал в больших командах, так что действительно получается так, что в большинстве случаев люди единолично трудились каждый над своим кодом.

Сейбел: Если говорить об отладке, то какую самую страшную ошибку вам когда-либо удалось найти?

Ингаллс: Она была связана со сборкой мусора. Сборка мусора — самое плохое, потому что проблема проявляется намного позже того, как что-то случилось. Исправление таких сложных ошибок напоминает мне взлом кодов. Мой отец работал в Управлении стратегических служб, они там работали в командах и главным образом просто собирали информацию, чтобы быть в курсе дела. Затем появлялось закодированное сообщение с фрагментом чего-то, что они видели в новостях, и таким образом они его расшифровывали.

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

Сейбел: Это было, полагаю, на Smalltalk. У вас был символический отладчик или вы смотрели шестнадцатеричные дампы памяти?

Ингаллс: Это был отладчик более низкого уровня, чем тот прекрасный отладчик Smalltalk. Деталей сейчас не приведу, но если находишь ошибку, она приводит к низкоуровневым отладчикам. То есть смотришь на память как на восьмеричные значения. И потом видишь, что один объект указывает на другой, а этого быть никак не может. И начинаешь думать: «Как такое могло случиться?» Там были закономерности, были догадки по поводу того, что именно могло вызвать ту или иную неполадку, так что на их основе и нужно было работать.

Сейбел: Это было на самом низком уровне. Но работая в такой замечательной среде, как Smalltalk, вы, скорее всего, используете символические отладчики. Приходится ли вам прибегать к выводу на печать?

Ингаллс: Честно говоря, не знаю никого, кто бы так делал, имея возможность пользоваться хорошим отладчиком. Потому что куда вы помещаете print? Туда-то. А не лучше ли самому быть там-то и посмотреть все, а не распечатывать? Сейчас я довольно часто применяю отладку с помощью вывода на печать, но это потому, что нередко у меня нет под рукой хорошего отладчика для JavaScript.

Сейбел: Чем так хорош отладчик для Smalltalk?

Ингаллс: Можно остановиться на любом месте программы и посмотреть на все связывания всех переменных. Можно исполнять фрагменты кода и вычислять выражения прямо в контексте.

Сейбел: В любом месте стекового фрейма?

Ингаллс: Да, и далее можно внести существенные изменения и продолжить. Затем можно вернуться к ошибке, вывести ее на экран, сохранить полностью состояние системы, перебросить его кому-нибудь другому, кто сидит за компьютером с Windows, а не на Маке; он может запустить тот же самый образ, попасть туда же, где сейчас находитесь вы, внести исправление и продолжить. Полное сохранение состояния, несмотря на различные варианты операционных систем.

Сейбел: Инварианты — это другой тип инструментов отладки. Многие очень озабочены формальными входными и выходными условиями всех их методов и инвариантами классов. Некоторые относятся к этим вопросам проще. Каково ваше мнение относительно инвариантов?

Ингаллс: Вероятно, я принадлежу к менее формальному лагерю. Во многом из-за того, что считаю, что вещи должны быть насколько возможно простыми. То же самое я думаю относительно типов. Типы по сути являются предположениями по поводу программы. И я думаю, что очень полезно делать все максимально простым, даже не заикаясь о каких-либо типах. Думаю, если серьезно подходить к системе, то неплохо иметь возможность добавлять подобные вещи: например, можно ввести подразумеваемые типы и видеть их только при желании.

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

Сейбел: Что вы думаете по поводу формального доказательства корректности программ?

Ингаллс: Я никогда этим не занимался. Я больше склонен к тому, чтобы сосредоточиться на архитектуре — так проще делать утверждения для разных вещей. Если внутри программы можно делать самые разные опасные вещи, то искать формальное доказательство оказывается очень трудно, так как на каждом шагу приходится говорить: «Это могло случиться, вот это могло случиться, да и вот это тоже». Если архитектура хорошая, то и формальное доказательство может быть столь же очевидным: достаточно прочесть код. Просто говоришь: «Так, это может произойти только из-за того-то. Мы в безопасности».

Сейбел: Вы когда-нибудь работали с C++?

Ингаллс: Нет. И с Си — тоже.

Сейбел: Но вы программировали на BCPL и ассемблере, то есть нельзя сказать, что низкоуровневым программированием вы не занимались вовсе.

Ингаллс: Да. Кстати, мы действительно немного писали на Си для отладки некоторых вещей, сгенерированных с помощью Squeak. Но я помню, что когда мы делали Squeak, то моей целью, среди всего прочего, было создать такую систему, для управления которой не нужно было бы знать ничего, кроме Squeak. Так что я решил даже ничего другого не учить. Джон Мэлоуни сделал транслятор с Squeak на Си в качестве практического примера. По правде говоря, я мог посмотреть код на Си, но сделал так, чтобы ничего этого делать было не нужно.

Сейбел: Но вы наверняка смотрели C++, когда он вышел, поскольку вы входили в группу, которая — возможно, наряду с изобретателями Симулы — может с наибольшими основаниями заявлять о том, что придумала объектно-ориентированное программирование.

Ингаллс: Я им особенно не интересовался. Конечно, во многих отношениях это был шаг вперед по сравнению с Си, но все же этот язык не оправдал тех надежд, которые мы на него возлагали. Если бы нужно было проводить еще одно внедрение с нуля, мы бы, возможно, использовали вместо машинного кода C++. Я знаю пару человек — настоящих мастеров C++, и мне нравится смотреть, как они с ним работают, потому что, думаю, они не полагаются на него при работе с теми областями, в которых он не особенно хорош, часто используют его как язык мета-программирования.

Сейбел: Поговорим о чтении кода. Как вы работаете с новым куском кода?

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

Сейбел: Мы уже упоминали интервью Кнута. Еще одна его любовь — литературное программирование. Занимались ли вы им когда-нибудь или, может быть, читали такой код?

Ингаллс: Мне нравится так работать, когда у меня достаточно времени. Когда я только начинаю писать, никаких комментариев не делаю. Когда все начинает работать, я пишу комментарии. Если мне нравится то, что я сделал, или мне кажется, что разобраться с этим будет сложно, я пишу более подробные комментарии. Но мне не нравится идея комментировать все подряд. И еще мне кажется, что чем лучше язык, тем меньше нужны комментарии. Лучше использовать разумные имена переменных. Вот почему мне нравятся именованные параметры в Smalltalk. Они действительно существенно облегчают читаемость. Есть еще такая отличная штука, которую можно использовать в различных местах JavaScript. Хотя это несколько расточительно, в JavaScript применяется запись объекта в фигурных скобках, так что можно использовать ключевые слова, и они действительно похожи на ключевые слова Smalltalk, потому что заканчиваются двоеточиями; поэтому можно применять объекты в фигурных скобках для передачи нескольких аргументов. Так получаются и впрямь очень симпатичные программы.

Сейбел: Гм. Выглядит одновременно и симпатично, и отвратительно.

Ингаллс: Именно.

Сейбел: Удалось ли вам кого-то еще убедить перенять этот стиль?

Ингаллс: Да я узнал, что так работают другие, еще до того, как начал делать это сам.

Сейбел: Кем вы себя считаете: инженером, ученым, художником или ремесленником?

Ингаллс: Всем сразу. Думаю, мое образование в области физики пошло мне на пользу. Я часто сталкиваюсь с проблемами, которые очень напоминают физические, — с проблемами приложения сил к телу. Это то, что вы используете по отношению к системе: смотрите, как на нее можно воздействовать. И очень похоже на физику то, что я испытываю по отношению к пространственным объектам: то, как они работают, что есть общего в разнородных вещах и как из них можно сделать лучшую архитектуру.

Помню одну из своих первых лекций о Smalltalk. Я сказал тогда: «То, чем занимается наша группа, напоминает научный метод: вы проводите наблюдения, выдвигаете теорию для объяснения результатов и ставите эксперимент для проверки». Именно так мы и работали со всеми поколениями Smalltalk. У нас была теория относительно того, как все это работает. Мы строили систему, она как-то работала. Мы использовали ее некоторое время, а потом выясняли: «Так, лучше бы мы сделали вот это, это и то по-другому», — и создавали новую систему. Все двигалось по спирали, как и должен развиваться научный поиск и прогресс.

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

В данном контексте понятия инженер и ремесленник — практически идентичны. Инженер трудится на ниве технологий. Иногда я себя так и ощущаю, но это совсем особые случаи — когда я делаю что-то низкоуровневое. Помнится, я работал над самыми глубокими частями BitBlt или движком байт-кода Smalltalk — и это была действительно ремесленная работа. У меня была возможность несколько раз сделать то же самое, пока все не стало работать оптимально, а это ремесло.

Сейбел: Разница между инженером и ремесленником, на мой взгляд, заключается в том, что инженер — это тот, кто говорит: «Здесь как в мостостроении. Мосты не падают. В мостостроении есть повторяемый инженерный процесс». Ремесленник же говорит: «Нет, здесь больше от работы по дереву. Каждое дерево уникально, есть правила его обработки, но ни один метод не гарантирует результата».

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

Сейбел: Вы сказали, что на время покинули индустрию, а потом вернулись. Устали от компьютеров или просто были изменения в жизни?

Ингаллс: В жизни были другие приоритеты. Кроме того, отдых от компьютеров пошел на пользу, потому что, вернувшись, я заметил, что почти ничего не изменилось, кроме того, что все теперь стало в сотни раз быстрее.

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

Ингаллс: Думаю, прежде всего надо пройти хороший курс компьютерных наук. Я бы организовал его так: сначала нужно выучить несколько разных языков, у которых разные сильные стороны. Так, Smalltalk имеет множество преимуществ, но не является универсальным ответом. Есть логическое программирование. Есть функциональное программирование. Smalltalk можно использовать в функциональном стиле, эта сторона в нем отлично развита. Но помните, что я рассказывал про Lotus 1-2-3 и перевод с английского на «поросячью латынь»? Думаю, полезно было бы взять несколько разных вычислительных сред и одну задачу и попытаться решить ее в каждой из них. Так проявится сила данного языка — или же это побудит вас от него отказаться.

Сейбел: Как вы считаете, сильно ли изменилось программирование, а следовательно, и те люди, которые могут в нем преуспеть? Можно ли быть отличным программистом, работая на высоком уровне, но без знания ассемблера, или Си, или даже тех алгоритмов, которые можно почерпнуть из чтения Кнута, поскольку сейчас мы используем высокоуровневые языки, у которых эти алгоритмы есть в библиотеках?

Ингаллс: У разных людей разные уровни, на которых они могут работать, чувствуя себя профессионалами. Думаю, в наши дни программист может с полной уверенностью пользоваться готовыми библиотеками, не программируя их сам. Это значит, что он просто работает на другом уровне. Честное слово, я вовсе не представляю, что кто-то, желая работать с графикой, станет писать BitBlt. He обязательно делать элемент И-НЕ: можно просто использовать язык ассемблера. Думаю, работать можно на любом уровне. Если вы чувствуете потребность, то можете забраться глубже, а если вы полны энтузиазма, вы захотите забраться глубже.

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

Ингаллс: И да, и нет. В значительной степени он тот же самый, что, надеюсь, с течением времени будет только сильнее проявляться. Но сейчас есть такие сферы, где все исчерпывается работой по заданной формуле, и другие, которые имеют дело с примитивными вещами.

Сам я физик, друзья мои — математики, и я никогда не считал, что у меня такой же мозг, как у них. Но и у меня, и у них получались хорошие вещи. Думаю, в случае с компьютерами то же самое. Те, кто работает над доказательством программ, отличаются от специалистов по графическим системам. Поэтому нужно просто найти свои сильные стороны и то, над чем вы хотите работать и над чем не хотели бы. Это вопрос как природы, так и воспитания, и он всегда будет таковым.

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

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

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

Сейбел: Я работал над проектом, призванным предоставить программную среду для биологов, притом им было нужно, чтобы каждый раз программа соответствовала их случаю. Нельзя создать приложение один раз и этим довольствоваться, потому что биологи не вполне знают, что им нужно, пока не придут к определенным биологическим данным и не скажут: «Я хочу знать X», — а единственный способ найти X — это, разумеется, написать программу.

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

Сейбел: Есть ли что-то, что вы считаете важным, а я вас об этом не спросил?

Ингаллс: Нередко, читая об известных людях, я задаю себе вопрос: как им удалось обустроить свою жизнь? Как они относятся к вещам, которые не составляют предмет их интереса, как у них обстоят дела с семьей, с финансами, как они сочетают все эти факторы? Или просто залегают на дно и посылают все остальное к черту, пока не закончат с любимой работой?

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

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

Сейбел: Но в итоге-то вы получили от сына «Приз великого отладчика».

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