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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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