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

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

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

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

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

И обнаруживаешь, что да, возможно, стоило сделать управление хранением данных совершенно иначе, но действительно важные вещи, которые узнаешь по ходу работы, не имеют ничего общего с этими частными вопросами. Первые версии 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 Кбайт. То есть была важна компактность.