Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
- Название:Кодеры за работой. Размышления о ремесле программиста
- Автор:
- Жанр:
- Издательство:Символ-Плюс
- Год:2011
- Город:Санкт-Петербург
- ISBN:978-5-93286-188-2
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста краткое содержание
Программисты - люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они “подсели” на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.
Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.
Кодеры за работой. Размышления о ремесле программиста - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Сейбел:Кажется, Ларри Уолл сравнил этот язык с тарелкой овсяных хлопьев, перемешанных с обрезками ногтей.
Дойч:Ну, я бы описал подобным образом Perl, только еще добавил бы, что все это вышло из собаки, причем понятно, откуда именно. На мой взгляд, силе духа Ларри Уолл а можно позавидовать, если он еще позволяет себе высказывать какие-то мысли о разработке языков программирования, ведь Perl - просто отвратительный язык. Но не будем об этом.
Если есть кусок кода на Лиспе и нужно понять его значение, то необходимо сделать две вещи, которые не нужно делать в схожей ситуации при работе с языком вроде Python.
Во-первых, придется отфильтровать все эти чертовы скобки. Это не интеллектуальная работа, но понимание в вашем мозге происходит на многих уровнях, и мне кажется, первое, что он делает, - это распознавание символов. Поэтому он воспринимает все эти скобки, и затем нужно отфильтровать их уже на более высоком уровне. Таким образом, механизму распознавания символов мозга приходится выполнять дополнительную работу.
Возможно, сейчас арифметические функции в Лиспе записываются с помощью их общепринятых наименований, то есть знака плюс, знака умножения и так далее.
Сейбел:Да, именно так.
Дойч:Хорошо, вторую вещь, о которой я хотел сказать, сейчас уже делать не нужно - понимать все эти вещи с помощью распознавания токенов, а не символов, что также происходит на более высоком уровне мозга.
Есть еще третья вещь, которая может показаться незначительной, но мне она таковой не кажется. В инфиксных языках каждый оператор располагается рядом с двумя своими операндами. В префиксных языках это не так. Для того чтобы увидеть другой операнд, приходится делать больше работы. Знаете, все это кажется незначительным. Но для меня самым важным и значительным является плотность информации на квадратный дюйм.
Сейбел:Но тот факт, что базовый синтаксис Лиспа, лексический синтаксис, достаточно близок абстрактному синтаксическому дереву программы, позволяет языку поддерживать макросы. И макросы позволяют создавать синтаксические абстракции, а это лучший способ уплотнить информацию, на которую вы смотрите.
Дойч:Да, это так.
Сейбел:В моей книге о Лиспе есть глава, посвященная синтаксическому анализу двоичных файлов, и я привожу в качестве примера ID3-теги в МРЗ-файлах. Что здесь интересно - можно программировать так: выбираете спецификацию, в этом случае ID3, помещаете ее в скобки и делаете из нее код, который вам нужен.
Дойч:Верно.
Сейбел:То есть мое описание парсинга ID3-заголовка по сути содержит столько же токенов, сколько и спецификация ID3-заголовка.
Дойч:Примечательно, что я сделал точно то же самое, работая с Python. Мне как-то пришлось анализировать один очень сложный файловый формат - один из наиболее сложных музыкальных файловых форматов. Поэтому я написал в Python набор классов, которые отвечали и за парсинг, и за красивую картинку.
Связь между созданием класса и наименованием метода осуществляется в общем родителе. То есть это все делается в объектно-ориентированном стиле - макросы не требуются. Это выглядит не так красиво, как можно было бы сделать иным способом, но на выходе получается примерно так же читаемо, как и аналогичные макросы Лиспа. Есть вещи, которые на Лиспе делаются более гладко и внятно. С этим я не спорю.
Если вы взглянете на код Ghostscript, он целиком написан на Си. Но это Си, дополненный сотнями макросов препроцессора. В итоге, поэтому, для того чтобы написать код, который станет частью Ghostscript, нужно знать не только Си, но и то, что необходимо для создания расширенной версии этого языка. Вы можете делать подобные вещи в Си - и делаете их, когда это нужно. И подобное происходит во всех языках.
Что касается Python, то и здесь мне приходилось делать небольшие дополнения. Это не синтаксические дополнения; это классы, примеси [70] В английской литературе принято название mixin. - Прим. науч. ред.
- многие из этих примесей дополняют то, что большинство людей привыкло считать семантикой языка. В Python за это отвечает один набор инструментов, в Лиспе - другой. Кому-то нравится одно, кому-то другое.
Сейбел:Что заставило вас отказаться от программирования и заняться сочинением музыки?
Дойч:По большому счету, я “перегорел” во время работы над Ghostscript. Ghostscript был одним из моих основных технических интересов с 1986 года, а где-то с 1992-1993 года был моим единственным крупным техническим проектом. Примерно в 1998 году я почувствовал, что сгораю, потому что не только делал всю техническую работу, но и занимался всей технической поддержкой, всеми административными вопросами. Это была компания из одного человека, и рано или поздно это должно было превысить мои возможности. Я нанял человека, чтобы создать компанию, и он стал нанимать инженеров.
После чего понадобилось еще два года, чтобы найти человека, который смог бы меня заменить. После чего потребовалось еще два года, чтобы по-настоящему передать ему все дела. К 2002 году я уже “наелся”. Я уже не мог больше видеть Ghostscript.
Поэтому я сказал: “Ладно, отдохну полгодика, осмотрюсь и решу, чем заняться дальше”. Мне тогда было 55 лет, и я не чувствовал себя старым. Я чувствовал, что могу сделать еще один крупный проект, если захочу что-то сделать. Поэтому я стал смотреть, что же происходит вокруг.
Один проект, который меня одно время интересовал, был связан с моим давним приятелем по работе в Xerox, Джеем Стротером Муром, который является - или являлся - заведующим кафедры информатики в Техасском университете в Остине. Одним из его величайших достижений стало то, что он вместе с еще одним парнем из SRI по имени Боб Бойер построил просто отпадную программу по доказыванию теорем. Вокруг этой программы он создал целую группу разработчиков, построил большие библиотеки теорем и лемм по отдельным предметным областям.
И вот была эта небольшая преуспевающая группа, которая доказывала теоремы; я о них писал в своей диссертации, и мне всегда это было интересно. И они добились потрясающего результата, работая над арифметическим блоком центрального процессора AMD. И я подумал: “Хм, эта группа обладает множеством хороших качеств: они занимаются интересными мне вещами; ими управляет человек, с которым я знаком и который мне нравится; их технология базируется на Лиспе. Это действительно по мне”.
Поэтому я отправился туда и прочитал там лекцию о том, как доказывание теорем могло бы - если, конечно, могло в принципе - помочь повысить уровень надежности Ghostscript. К тому времени у системы отслеживания ошибок Ghostscript была уже богатая история. Я нашел 20 ошибок, более или менее в произвольном порядке, взглянул на каждую из них и сказал: “Так, для того чтобы технологию доказывания теорем можно было бы с пользой применять для обнаружения или предотвращения этой проблемы, что должно еще произойти? Что здесь еще должно было бы появиться?”
Читать дальшеИнтервал:
Закладка: