Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
- Название:Кодеры за работой. Размышления о ремесле программиста
- Автор:
- Жанр:
- Издательство:Символ-Плюс
- Год:2011
- Город:Санкт-Петербург
- ISBN:978-5-93286-188-2
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста краткое содержание
Программисты - люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они “подсели” на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.
Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.
Кодеры за работой. Размышления о ремесле программиста - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Что касается Smalltalk, то там это делать неудобно - если вы работаете в Smalltalk в режиме образов, то там не бывает программы как таковой. В VisualWorks - Smalltalk от ParcPlace - есть три или четыре разных понятия того, как сделать так, чтобы вещи превосходили лишь один класс, и они изменились со временем, и они не очень-то хорошо поддерживаются инструментами разработки, по крайней мере визуально. Есть несколько инструментов, позволяющих сделать ясными, очевидными и механически проверяемыми взаимозависимости в программе. То есть работая в режиме образов, вы не можете никому ничего передать - только образ целиком.
Если вы делаете то, что называется filing out, то есть пишете программу в текстовой форме, у вас нет абсолютно никакого способа узнать, возможно ли считать только что записанную программу еще раз, вернуть ее и сделать ту же операцию еще раз, потому что состояние образа совсем не обязательно совпадает с тем, которое было произведено или которое могло быть произведено путем считывания из набора в исходном коде. Вы могли сделать любые вещи в рабочем пространстве, у вас могли быть статические переменные, значения которых изменились с течением времени. Вы этого просто не знаете. Вы не можете уверенно выполнить ни одно действие.
Я подписан на рассылку разработчиков Visual Works, и темы, которые там постоянно обсуждаются, - их просто нет в языках, не использующих понятие образа. Понятие образа похоже на множество других вещей, характерных для мира, в котором все стремятся быстро набросать опытную модель, быстро сделать программу. Это идеальный вариант для проектов, которые ведутся одним человеком и которые навсегда останутся только в собственном пользовании этого человека. Но это ужасный вариант, если вы хотите сделать ПО активом, если вы хотите, чтобы вашим ПО пользовались другие. Мне кажется, что именно в этом заключается настоящий минус подхода к разработке ПО, исповедуемого Smalltalk, - и минус очень серьезный.
Вторая причина, по которой мне нравится Python, - и, может быть, дело просто в том, как мой мозг изменился за эти годы, - что я больше не могу удерживать столько информации в голове, сколько раньше. Теперь для меня более важно, чтобы вся информация была перед моими глазами. Поэтому тот факт, что в Smalltalk вы фактически не можете использовать больше одного метода на экране, меня просто бесит. По мне, тот факт, что я редактирую программы, написанные на Python, с помощью Emacs, является преимуществом, поскольку я могу видеть больше 10 строк одновременно.
Я говорил с друзьями, которые до сих пор работают в VisualWorks, о том, чтобы открыть код ядра, JIT-генератора кода, который, несмотря на то, что его написал я, превосходит, по моему мнению, многие из современных аналогичных программ. Подумать только, у нас есть Smalltalk, у которого действительно великолепные инструменты для генерации кода, это проверенная технология - ей уже около 20 лет, и она очень надежна. Это сравнительно простой, сравнительно легко перенастраиваемый и достаточно эффективный JIT-генератор кода, который разработан для эффективной работы с языками без объявления типа. С другой стороны, у нас есть Python - прекрасный язык с прекрасными библиотеками и очень медленной реализацией. Было бы неплохо совместить их, не так ли?
Сейбел:Разве не эта же идея легла в основу вашего проекта pycore - переписать Python на Smalltalk?
Дойч:Эта. Я дошел с этим проектом до того этапа, когда понял, что мне нужно будет сделать намного больше работы, чем я думал, чтобы эта затея по-настоящему удалась. Несоответствия между объектными моделями в Python и в Smalltalk были достаточно серьезными, поэтому были вещи, которые нельзя было просто отобразить один к одному, это нужно было делать с помощью дополнительных уровней вызовов методов, и еще много чего нужно было сделать.
Даже тогда Smalltalk с JIT-генерацией кода был - для кода, только что написанного на Python, - того же уровня, что и интерпретатор, написанный на Си. Я-то думал, что если бы была возможность открыть исходный код генератора кода Smalltalk, то задача совместить этот генератор кода с объектной моделью и представлением данных в Python не должна быть особенно сложной.
Но это нельзя сделать. Элиот Миранда, возможно, наиболее радикально настроенный из всех моих знакомых, связанных с VisualWorks, попытался, но Cincom заявила: “Нет, это стратегический актив, мы не можем открыть его исходный код”.
Сейбел:Что ж, вы и сами говорили, что ПО нужно рассматривать как долгосрочный актив.
Дойч:Но это не должно означать, что ваша лучшая стратегия - не давать другим пользоваться этим активом.
Сейбел:Помимо того что вы еще в незапамятные времена были приверженцем Smalltak, вы еще были и одним из первых фанатов Лиспа. Но и его вы сейчас уже не используете.
Дойч:Моя диссертация представляла из себя 600-страничную программу на Лиспе. Я преданный фанат Лиспа, начиная с PDP-1, Alto, Byte и заканчивая Interlisp. Причина, по которой я больше не программирую на Лиспе, - мне ненавистен его синтаксис. Синтаксис имеет значение, это правда жизни.
Языковые системы держатся на трех китах - язык, библиотеки и инструменты. Успешность языка зависит от сложного взаимодействия между этими тремя вещами. Python - отличный язык, у него отличные библиотеки и практически никаких инструментов.
Сейбел:Под “инструментами” вы в том числе подразумеваете и непосредственную реализацию языка?
Дойч:Конечно, можно и это сюда включить. Лисп как язык фантастически гибок, но его невозможно читать. Не знаю, как сегодня обстоят дела с библиотеками для Common Lisp, но мне кажется, что синтаксис - это очень важно.
Сейбел:Кому-то синтаксис Лиспа очень нравится, кто-то его на дух не переносит. Почему так?
Дойч:Я говорю только за себя. И могу сказать, почему я больше не хочу работать с синтаксисом Лиспа. На это есть две причины. Во-первых, и я об этом уже говорил, чем старше я становлюсь, тем для меня важнее высокая плотность информации на квадратный дюйм экрана перед моими глазами. Плотность информации на квадратный дюйм в инфиксных языках выше, чем в Лиспе.
Сейбел:Но практически все языки на самом деле префиксные, не считая небольшого количества арифметических операторов.
Дойч:Это не совсем так. Если говорить о Python, например, то это неверно для создания списков, кортежей и словарей. Это делается с помощью скобок. Построковое форматирование - инфиксное.
Сейбел:Так же, как и в Common Lisp - с помощью команды FORMAT.
Дойч:Ну хорошо, ладно. Но есть вещи, которые не делаются с помощью инфиксов; самые простые - циклы и условные операторы - не префиксные. Они выполняются с помощью чередующихся ключевых слов и того, к чему они применяются. В этом отношении они даже более многословны, чем Лисп. И здесь я перехожу к другой части, другой причине, по которой мне больше нравится синтаксис Python, - Лисп очень однообразен в лексическом плане.
Читать дальшеИнтервал:
Закладка: