Читаем Кодеры за работой полностью

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

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

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

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

Ингаллс:

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

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

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

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

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

Ингаллс:

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

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

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

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

Перейти на страницу:

Все книги серии Профессионально

Кодеры за работой
Кодеры за работой

Программисты — люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они «подсели» на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.

Питер Сейбел

Биографии и Мемуары / Программирование / Прочая компьютерная литература / Документальное / Книги по IT
Человеческий фактор
Человеческий фактор

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

Тимоти Листер , Том ДеМарко

Деловая литература
97 этюдов для программистов. Опыт ведущих экспертов
97 этюдов для программистов. Опыт ведущих экспертов

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

Пит Гудлиф

Программирование, программы, базы данных

Похожие книги