на нескольких. На разных занятиях применялись разные языки. На занятиях по математике и естественным наукам - Фортран, на занятиях по программированию - Паскаль, SAIL, Симула или что-то в этом духе. А на занятиях по искусственному интеллекту мы работали на Лиспе.
Может быть, стоило освоить еще больше языков. Интересно, что всерьез заниматься объектно- ориентированным программированием (ООП) я стал довольно поздно. Java был первым объектно- ориентированным языком, на котором я работал по-настоящему, отчасти потому, что я так и не смог заставить себя работать на C++.
Сейбел: Когда это было?
Блох: Это началось в 1996 году, когда я пришел в Sun. Думаю, мне стоило познакомиться с этими концепциями чуть раньше. Однако я не считаю, что все они хороши. ООП - занятная штука. Это прежде всего две вещи. Первое - модульное построение, что очень удобно. Но оно было еще до ООП. Возьмите старую литературу, например работы Парнаса по скрытию данных, и вы увидите, что понятие о том или ином типе класса как об абстракции существовало до ООП. Второе - наследование свойств, но у меня, как и у многих сегодня, отношение к нему смешанное.
Кроме того, мне надо было попробовать себя в разных областях помимо компьютерных наук. Чем больше различных вещей вы узнаете в молодости, тем лучше для вас. Я очень мало занимался графическими интерфейсами пользователя - надо было заставить себя засесть за них. Мне отчего-то интереснее всего было заниматься библиотеками, готовить модули для других. Так что я десятилетиями занимался структурами данных и алгоритмами.
Сейбел: Есть ли книги, которые должен прочесть каждый программист?
Блох: Разумеется, “Design Patterns” (Шаблоны проектирования), хотя я отношусь к ней не совсем однозначно. Она дает общий для всех словарь. И в ней масса хороших идей. С другой стороны, мешанина стилей и языков; кроме того, этот труд частично уже устарел. Но прочесть его стоит, я твердо убежден.
Затем “Elements of Style” (Элементы стиля). Хотя она, собственно, не о программировании, прочесть ее нужно по двум причинам. Во-первых, потому, что разработчик ПО тратит значительную часть времени на написание прозы. Если вы неспособны создавать логичные, стройные, хорошо читаемые спецификации, вашими программами никто не сможет пользоваться. Поэтому все, что способствует улучшению стиля изложения, есть благо. И во-вторых, большинство высказанных там мыслей применимы и к программам.
Если же говорить о том, что бы я взял на необитаемый остров, то это будет несколько странный выбор. Например, для меня страшно важна “Hacker's Delight”[52].
Сейбел: Это же книга про перестановку битов?
Блох: Да. Люблю это дело, и оно напрямую связано с моей работой. Для тех, кто пишет библиотеки, компиляторы, криптомодули, создает низкоуровневую графику, она обязательна к прочтению. Уоррен собрал всю, так сказать, устную традицию и дал ей достойную строгую математическую обработку. Я был сам не свой, когда эта книга вышла.
Еще, конечно, “The Art of Computer Programming”[53] Кнута. На самом деле я не читал ее полностью - даже близко к этому не подходил. Но когда я работаю над тем или иным алгоритмом, то смотрю, что сказал по этому поводу Кнут. И часто нахожу то, что мне нужно, - там есть все.
Но у меня нет ни способностей, ни времени, чтобы прочесть ее от и до, так что на этот счет врать не буду. Очень важна, по-моему, старая книга “The Elements of Programming Style”[54]. Все примеры даны на Фортране IV и PL/1, так что она несколько устарела. Но учитывая возраст этой книги, удивительно, что высказанные там идеи все еще в силе.
Из старого назову также “Мифический человеко-месяц”[55] Фредерика Брукса. Ей уже сорок лет, но она актуальна, как будто вышла вчера. А читать ее - одно удовольствие. Это должен сделать каждый. “Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше”, - вот ее главная идея, и она ничуть не устарела. Но там есть и масса других важных вещей. Кое-что уже устаревает, но все равно — читать обязательно.
А сегодня непременно нужно читать литературу о параллельном программировании. Поэтому стоит взять в руки 4с Java Concurrency in Practice” (Java: параллельность на практике). Несмотря на заголовок, многое в ней применимо не только к Java.
Сейбел: Вы ее написали вместе с Брайаном Гетцем?
Блох: Мое имя стоит на обложке, но я так спокойно ее рекомендую, потому что на самом деле я тут ни при чем. В основном ее писали Брайан с Тимом Пайрлзом и все прочие - программисты, работающие над JSR-166, спецификацией Java, касающейся параллельных процессов. Правда, эти остальные упомянуты скорее из вежливости - мы поставляли материал, но ничего не писали.
Да, и еще 11-е издание словаря английского языка “Merriam-Webster”. Без него никуда. Его не то чтобы нужно
Сейбел: Про имена переменных и про уменьшение копирования-вставки все понятно. А что еще изменилось в вашем подходе к программированию с накоплением опыта?
Блох: С возрастом я понял, что надо не просто сделать работающую вещь - программа должна хорошо читаться, быть легкой в обслуживании и эффективной. В противоположность распространенному мнению, я считаю, что чем яснее и изящнее программа, тем быстрее она работает. А если нет, то заставить ее работать быстрее легко. Как говорится, легче оптимизировать правильный код, чем исправлять оптимизированный код.
Отчасти смена подхода касается конкретных свойств разных языков. Каждый язык снабжен набором инструментов. Для каждой конкретной работы нужно брать правильный инструмент - но правильный инструмент в одном языке может оказаться неправильным в другом. Банальный пример: если вы пишете на Java 5, использование enum вместо int или булевых выражений сильно упростит вашу программу, сделает ее безопаснее и прочнее.
Сейбел: С учетом этого, что вы можете сказать о приобретении беглости в пользовании новым языком?
Блох: Думаю, это во многом как с обычными языками. Один подход состоит в том, чтобы знать много языков: если вы освоили итальянский и испанский, а теперь желаете заняться португальским, вам будет не слишком трудно. Чем больше вы знаете, тем больше опираетесь на ваши знания.
Взявшись за новый язык, используйте все накопленные знания, но держите ум незашоренным. Я знаю тех, кто раз и навсегда решил, что все программы должны писаться таким-то способом. Не буду называть конкретные языки, но некоторые языки по тем или иным причинам способны толкнуть на этот путь. И если такой программист сталкивается с новым языком, то критикует его и может сказать, что, мол, в раю им не пользовались, - что бы это ни значило. И взявшись писать на новом языке, старается писать на первоначальном райском языке - насколько это возможно с новым языком. И тогда особенности языка теряются.
Представьте, что из всех инструментов вы владеете только молотком, и вдруг кто-то дает вам отвертку. И вы говорите: “Ну, молоток так себе, но попробую взять за жало и забивать гвозди ручкой”. И вот у вас никудышний молоток, который на самом деле отличная отвертка. То есть нужна непредубежденность и готовность пользоваться всеми своими знаниями. И, конечно, писать код! И еще раз: писать код! Чем больше вы применяете язык на практике, тем скорее его выучите.
Сейбел: Откуда этот фанатизм у приверженцев того или иного компьютерного языка?
Блох: Не знаю. Но выбирая язык, человек выбирает не только определенные параметры - он выбирает сообщество пользователей. Это все равно что выбирать бар. Вы хотите пойти туда, где наливают что-нибудь приличное, но это не главное. Главное - кто там собирается и о чем они говорят. Так же и с компьютерными языками. Со временем вокруг каждого образуется сообщество - оно включает не только людей, но и ПО: инструменты, библиотеки и так далее. Вот почему зачастую языки,
