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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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