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

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

Если же все-таки усложнять, исчезнет язык или нет? Нет, не исчезнет. Мне кажется, C++ давно превысил этот уровень, а сколько народу им пользуется! Но тем самым вы побуждаете людей разбивать его на части. И почти в каждой известной мне лавочке, где используют C++, говорят: «Да, мы используем C++, но не применяем ни множественное наследование, ни перегрузку операторов». Есть свойства, которые вы не используете, потому что код тогда получается слишком сложным. Думаю, не стоит и пытаться. Каждый программист должен иметь возможность читать код любого из своих коллег, а в нашем случае эту возможность легко утратить.

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

Блох: Не знаю. Обобщенные типы по-прежнему мне нравятся — они находят за меня ошибки в моем коде. Эти средства помогают найти мне вещи, которые обычно включаются в комментарии, и перенести их в код, где компилятор может обеспечить их корректность. С другой стороны, когда я вижу сообщения об ошибке, связанные с параметризованными типами, а потом нахожу сделанные для этих типов обобщенные объявления, вроде моего Enum — class Enum<E extends Enum<E>>», то понимаю, что обобщенные типы не были достаточно хорошо проработаны, чтобы их включить.

Программист должен или быть оптимистом, или застрелиться. И мы говорим: «Конечно, мы это умеем. Мы знаем все об обобщенных типах еще с тех пор, как познакомились с языком CLU. Это технология 25-летней давности. То же самое сегодня можно слышать про замыкания, правда, о них говорят, что им уже 50 лет. «Это легко и не усложняет язык».

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

Если бы мы знали, как простые люди отреагируют на обобщенные типы, то, конечно, придумали бы что-нибудь другое. Значит ли это, что эти средства вообще не надо было изобретать? Наверное, все-таки не значит. Думаю, они полезны. Главный аргумент в их пользу — раз большинство коллекций однородны, а не разнородны, работать с однородными коллекциями должно быть легче. Кроме того, приведение типов вообще не очень хорошая штука. Оно не всегда срабатывает и не делает вашу программу красивой. Поэтому, полагаю, должна быть возможность задавать тип коллекции, и он должен проверяться автоматически. Но нужны ли для этого страдания из-за переусложненности средств? Нет. Видимо, нам все же стоило сделать их попроще.

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

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

Но при разработке программ мы часто чуем какие-то вещи нутром. Кто-нибудь просил меня о fоreach? Опять же нет. Но я знал, что стою на правильном пути, и это оказалось так — многие пользуются этим. Но большой грех для разработчика — создавать программы, которые просто отлично смотрятся, хорошо сделаны и так далее. Если вы не решаете реальные проблемы реальных пользователей — в нашем случае Java-программистов, — то не надо ничего добавлять.

Есть чудесное выступление Гослинга «The Feel of Java» (Почувствовать Java); в нем он говорит, что нужно трижды ощутить необходимость чего-то, прежде чем внедрять это. Нельзя добавлять программу только из-за ее красоты.

Но люди все равно добавляют. Что делают разработчики? Пишут код. И, работая над библиотекой или языком, они хотят добавить туда что-то свое. Некий внутренний голос должен подсказывать, какое сочетание свойств будет работать хорошо, что нужно добавлять, а чего не нужно. Ведь чаще всего вы можете добавить к языку больше, чем должны. Это означает не то, что ваши программы плохи, а лишь то, что надо правильно выбирать, не валя все в кучу.

Сейбел: Я читал книги «Java Puzzlers» и «Java Concurrency in Practice». Меня удивило, что в языке, который изначально был очень простым, столько секретов.

Блох: Секреты есть, но это неизбежно, они есть во всех языках. Можно было бы написать книгу «Си: головоломки».

Сейбел: Ну, этот язык — сплошная трудность.

Блох: Да, тут понадобилась бы целая книжная полка. В Java такие случаи особенно нужно отмечать, ведь его считают простым языком. В каждом языке свои проблемы, в Java их не так много, и они по большей части довольно забавны и интересны.

Сейбел: Говоря о программировании, есть ли что-то, чему научила вас работа над Java и обдумывание его структуры?

Блох: Очень многому. Об одном я упоминал в своем посте «Nearly All Binary Searches and Mergesorts Are Broken» (Почти все двоичные поиски и сортировки слиянием сломаны): невероятно трудно правильно написать даже небольшую программу. Мы обманываем сами себя, считая, что наши программы более-менее свободны от ошибок. Это не так. Большей частью наши программы не содержат ошибок лишь настолько, чтобы справляться с возложенной на них задачей.

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

Я укрепился в своем мнении насчет того, что нужна качественная документация API. Javadoc во многом способствовал успеху платформы, хотя не все это замечают. Качественная документация API всегда была частью Java-культуры, как я считаю, потому что Javadoc присутствовал с самого начала.

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

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

Тони Хоар как-то на вручении премии Тьюринга блестяще сказал о том, что есть два способа проектировать систему: «Один — сделать ее настолько простой, что в ней совершенно очевидно не будет недостатков, второй — сделать ее настолько сложной, что в ней не будет очевидных недостатков».

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

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

Блох: Не знаю. Как-то так получилось, что я моментально перешел с Си на Java. После окончания школы и до 1996 года я программировал почти только на Си, а потом — почти только на Java. Конечно, при определенных обстоятельствах я могу перейти на другой язык — но на какой? Может быть, такого языка еще нет в природе. По-моему, мир созрел для нового языка программирования, но инерция платформ сегодня куда сильнее, чем раньше. Современная платформа — это не только язык и несколько библиотек. Это множество инструментов, виртуальная машина, то есть гигантский комплекс. И перспектива создания новой платформы выглядит сейчас намного более пугающей.