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

Я составлял списки того, что хотел задать на входе и получить на выходе, иногда приводил краткие примеры. Недавно я нашел одну из своих ранних программ на APL. Мне тогда было лет 15-16. То был кусок кода на APL — я набросал его на бумаге, прежде чем попробовать запустить. Рядом лежал другой клочок бумаги — примеры того, что у меня должно было быть на входе и на выходе. Там были ошибки, примеры были несовместимы с кодом, но, по крайней мере, я пытался дать примеры использования этой программы. Примеры того, что как я думал, увижу на терминале.

Когда я стал работать в проекте Maclisp, структура была уже определена. Почти все, что я делал, было добавлением новых функций к их и без того солидному набору. Там уже были готовые примеры документирования функций, надо было просто добавлять свои в том же стиле.

Сейбел: Вы говорили, что Йонл передал вам работу над интерпретатором, — до того он занимался и интерпретатором, и компилятором.

Стил: Мы вместе занимались проектированием, я был младшим программистом. Он мог сказать: «Нам нужна такая-то функция, работающая так-то, — давай, напиши код». Но чаще мы получали запросы от разработчиков Macsyma — мол, нам надо то-то и то-то, — и мы с Йонлом вместе выдумывали интерфейс, а потом я писал для него код.

Сейбел: Значит, в интерпретаторе и компиляторе надо было отразить новые языковые свойства, которые приобрел Maclisp?

Стил: Да, языковые свойства. Многие из них системно-ориентированного характера — управление ресурсами, выделение страниц. Я ввел новый тип данных, который назвал «hunk», и это оказалось настоящей катастрофой. Он представлял собой cons-ячейку более чем с двумя указателями. Это был акт отчаяния, потому что мы вышли за пределы адресного пространства PDP-10, которое, напомню, было 18-битным. Половина указателей в списке уходила на то, чтобы поддерживать структуру списка, в то время как в цепочке данных типа hunk на это уходила всего лишь восьмая часть указателей. В результате память использовалась лучше.

Сейбел:

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

Стил: Мы пару раз серьезно все переписывали. А однажды полностью пересмотрели структуру программы и реализацию всех операций ввода/вывода в языке — кажется, в 1975 или 1976 году. Старая система позволяла иметь один поток данных на входе и один на выходе и могла взаимодействовать с терминалом. Мы поняли, что получим гораздо более гибкую систему, если Лисп-объекты станут каналами ввода/вывода. И таких одновременно открытых каналов могло быть до 15.

Другим поводом было то, что Maclisp начали портировать на другие операционные системы. В разных местах использовался свой вариант операционной системы PDP-10, и, посмотрев на список клиентов, мы поняли, что придется поддерживать полдюжины различных операционных систем: TENEX, TWENEX, ITS, TOPS-10, WAITS и вариант CMU.

И вот тем летом мы с Джоном создали новый набор API. Тогда этот термин еще не употреблялся — были описания функций, пригодных для создания файловых объектов, их открытия и закрытия, систематизации процессов удаления и переименования и для получения перечня файлов в каталоге.

В какой-то момент я получил свежую распечатку всего Maclisp и на неделю засел в летнем доме родителей с шестью руководствами по ОС. Каждый день я шесть часов переделывал код.

Надо было разработать каждое свойство, например функцию «переименовать», потому что процесс взаимодействия с ОС при переименовании файла сильно различался во всех шести вариантах. В целом образовалось три основных группы вариантов — TOPS-20, TOPS-10 и ITS.

И я неделю занимался этим, проектировал, разрабатывал реализацию, и все это на бумаге, без компьютера. Потом я приехал в MIT и месяц набивал все это, занимался отладкой и тестированием.

Сейбел:

Почему именно так?

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

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

Стил: Так я и поступаю время от времени. Иногда просто приходится его выключать — вентилятор словно нашептывает: «Проверь почту, проверь почту». Я выключаю его или перевожу в режим сна, сажусь за стол на другом конце комнаты, раскладываю бумаги и начинаю думать, или пишу что-нибудь на доске, и так далее.

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

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

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

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

Питер Сейбел

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

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

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

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

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

Пит Гудлиф

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

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