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

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

Сейбел: И вы продвигали изменения по всей вертикали процесса? Или люди шли прямо к программистам: «В общем, мы поняли, заказчику нужен X»?

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

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

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

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

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

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

Сейбел: Итак, вы тогда возглавили крупный проект по созданию компилятора PTRAN; вы впервые стали работать с явным параллелизмом, а не со скрытым параллелизмом в конвейерах центрального процессора и так далее. Тогда это было в новинку — как для вас, так и для IBM.

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

Сейбел: Для какого языка предназначался компилятор PTRAN? Был ли это простой Фортран, без дополнительных конструкций для параллелизма?

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

Что касается PTRAN, то мы собирались использовать «пыльные колоды» (dusty decks), как мы их называли, то есть уже существующую базу кода, после чего автоматически задействовать предоставляемые железом параллельные компоненты.

Сейбел: То есть, по сути, речь шла о том, что сегодня мы называем симметричными мультипроцессорами?

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

Собственно, мы строили это на основе уже существовавших работ, в частности Дэйва Кука. Некоторые работы были из Нью-Йоркского университета. Мы наняли группу свежеиспеченных PhD из ряда мест, в которых уже к тому моменту был наработан определенный опыт. У нас было довольно много значительных результатов — и в практической, и в теоретической части; мы работали одновременно и над тем, и над другим. Я убеждена в том, что практика должна быть выражаемой в узнаваемых алгоритмах, в теории и способах представления решения задач, а алгоритмы должны применяться на практике, для того чтобы понять, насколько они ценны и как их применять. Я считаю, что в нашей области при работе над проектом лучше всего сочетать теорию и практику.

Сейбел: Во время работы над проектом PTRAN вы руководили командой. Вы тогда все еще писали код?