Выглядит логично, так? Но, к сожалению, те, кто создавал объекты в стеке, делали их слишком большими по тогдашним меркам. Массив из 100 элементов, по 4 Кбайт каждый, — всего 400 Кбайт в стеке одного потока. Получался перескок через красную зону стека в стек соседнего потока. И мы получали неверный идентификатор потока. Хуже того: когда поток обращался к локальным для потока переменным, он считывал переменные другого потока, поскольку его идентификатор использовался как ключ для доступа к этим переменным.
Итак, то, что мы приняли за безобидный недочет трассировочного пакета, оказалось признаком действительно серьезной ошибки. Событие приписывалось потоку 43 вместо потока 42, так как один поток невольно подменял собой другой, и это могло иметь катастрофические последствия.
Вот почему нам нужны языки с хорошими параметрами безопасности. Лучше обойтись без таких случаев. Недавно у меня был разговор в одном университете: там хотели обучать программистов сначала языкам Си и C++, а потом Java, так как они хотели, чтобы программисты овладели системой «на всю глубину». Меня спросили, что я думаю об этом.
Думаю, посыл здесь правильный, но выводы ошибочные. Да, студентам нужно изучать низкоуровневые языки, и даже язык ассемблера, и даже устройство чипов. Правда, чипы сейчас превратились в невероятно сложных чудовищ и теряют в производительности именно из-за своей сложности. Но знание того, что происходит на низших уровнях системы, сильно облегчает высокоуровневое программирование.
И я считаю, что все это важно изучать. Но это не значит, что надо начинать с такого низкоуровневого языка, как Си! Зачем студентам, только-только приступающим к программированию, сталкиваться с переполнением буфера, ручным выделением памяти и тому подобным?
Мы с Джеймсом Гослингом однажды обсуждали появление Java, и он сказал: «Время от времени нужно нажимать кнопку перезагрузки. Это едва ли не самое прекрасное, что может случиться». Обычно вам приходится поддерживать совместимость со старыми программами, но иногда — нет, и это здорово. Но к сожалению, как это случилось с Java, проходит десятилетие — и ваша система сама становится проблемой для других.
Сейбел: Значит ли это, что язык Java уже немного устарел и что он быстро усложняется, но при этом совершенствуется куда медленнее?
Блох: Очень непростой вопрос. Например, Java 5 вышел намного более сложным, чем мы хотели. Я даже не представлял, насколько обобщенные типы и особенно символы подстановки[56] усложнят язык. Надо отдать должное Грэму Гамильтону — он понял все это в свое время, а я нет.
Интересно, что он годами боролся за невключение обобщенных типов в язык. Но понятие вариативности — которая и лежит в основе символов подстановки — вошло в моду в то время, когда мы старались не снабжать Java обобщенными типами. Если бы они появились раньше и без всякой вариативности, мы бы теперь имели более простой и легкий в работе язык.
При всем том от символов подстановки есть реальная польза. Есть глубокая несовместимость между методом выделения подтипов и обобщенными типами, и символы подстановки позволяют во многом ее нивелировать. Но это достигается ценой переусложнения. Некоторые считают наилучшим решением вариативность на стороне объявления, в противоположность таковой на стороне использования, но я не сильно уверен.
Нельзя твердо судить о чем-то, если это не было использовано многими программистами в реальной рабочей обстановке. Есть языки, хорошо работающие в своей узкой области, и некоторые говорят о них: «Отличный язык, жаль, что им пользуется так мало народа». Иногда, однако, для этого есть веские причины. Надеюсь, какой-нибудь язык, где используется вариативность при объявлении, к примеру Scala или С# 4.0, ответит на этот вопрос раз и навсегда.
Сейбел: Что же дало импульс к появлению обобщенных типов?
Блох: Как часто бывает с идеями, которые на практике оказываются хуже, чем в теории, мы верили собственным заявлениям для прессы. Я представлял себе это так: почти все коллекции у нас однородны — список строк, хеш строк на целые числа и так далее. Но по умолчанию они создаются разнородными — все это коллекции объектов, которые надо приводить к нужным типам при выборке, — абсурд! Не лучше ли указать системе, что вот это, например, хеш строк на целые числа? Пусть она сделает приведение типов за меня, а во время компиляции укажет мне, если я допущу ошибку. Больше ошибок будет отслежено, система будет иметь больше высокоуровневой информации, а это хорошо.
Обобщенные типы, как и многое из того, что мы добавили в Java 5, казались мне средством автоматизации того, что раньше делалось вручную: пусть этим займется язык! Кое-где я попал в точку: цикл f or-each — отличная штука. Он скрывает от вас сложное устройство итератора или индексных переменных. Код становится короче, но площадь концептуальной поверхности при этом не увеличивается. Даже скорее уменьшается: мы ввели ложный полиморфизм массивов и других коллекций, и можно выполнять итерацию над ArrayList или над массивом, совершенно не интересуясь, над чем именно она выполняется.
Но главная причина того, почему эта идея не сработала для обобщенных типов, — они стали крупным прибавлением к системе типизации, и без того сложной. С системами типизации нужно обращаться осторожно, поскольку это может повлечь далеко идущие и непредсказуемые последствия для языка.
А урок таков: если вы совершенствуете зрелый язык, нужно больше чем когда-либо задумываться над балансом возможностей и сложности. Сложность во многих разделах языка растет квадратично: прибавив всего одно свойство, вы получаете куда более сложную структуру. Если язык близок к тому, чтобы превысить уровень понимания программистов, усложнять дальше просто нельзя — все пойдет прахом.
Если же все-таки усложнять, исчезнет язык или нет? Нет, не исчезнет. Мне кажется, C++ давно превысил этот уровень, а сколько народу им пользуется! Но тем самым вы побуждаете людей разбивать его на части. И почти в каждой известной мне лавочке, где используют C++, говорят: «Да, мы используем C++, но не применяем ни множественное наследование, ни перегрузку операторов». Есть свойства, которые вы не используете, потому что код тогда получается слишком сложным. Думаю, не стоит и пытаться. Каждый программист должен иметь возможность читать код любого из своих коллег, а в нашем случае эту возможность легко утратить.
Сейбел: Не кажется ли вам, что Java без обобщенных типов был бы сегодня лучше?
Блох: Не знаю. Обобщенные типы по-прежнему мне нравятся — они находят за меня ошибки в моем коде. Эти средства помогают найти мне вещи, которые обычно включаются в комментарии, и перенести их в код, где компилятор может обеспечить их корректность. С другой стороны, когда я вижу сообщения об ошибке, связанные с параметризованными типами, а потом нахожу сделанные для этих типов обобщенные объявления, вроде моего Enum — class Enum
Программист должен или быть оптимистом, или застрелиться. И мы говорим: «Конечно, мы это умеем. Мы знаем все об обобщенных типах еще с тех пор, как познакомились с языком CLU. Это технология 25-летней давности. То же самое сегодня можно слышать про замыкания, правда, о них говорят, что им уже 50 лет. «Это легко и не усложняет язык».
Черт возьми, конечно усложняет! Но, думаю, обобщенные типы послужили для нас хорошим уроком. Нельзя добавлять что-то к языку, пока не поймешь, как поведет себя концептуальная поверхность, пока не будет веских доводов в пользу того, что программисты смогут эффективно пользоваться новым свойством и оно облегчит им жизнь.
Если бы мы знали, как простые люди отреагируют на обобщенные типы, то, конечно, придумали бы что-нибудь другое. Значит ли это, что эти средства вообще не надо было изобретать? Наверное, все-таки не значит. Думаю, они полезны. Главный аргумент в их пользу — раз большинство коллекций однородны, а не разнородны, работать с однородными коллекциями должно быть легче. Кроме того, приведение типов вообще не очень хорошая штука. Оно не всегда срабатывает и не делает вашу программу красивой. Поэтому, полагаю, должна быть возможность задавать тип коллекции, и он должен проверяться автоматически. Но нужны ли для этого страдания из-за переусложненности средств? Нет. Видимо, нам все же стоило сделать их попроще.
Сейбел: Скажите, а пользователи требовали обобщенных типов? Кто-нибудь жаловался, что их отсутствие мешает писать программы?
Блох: Ну, что касается разработчиков, ответ, увы, отрицательный. Пожалуй, виноват здесь я — эта штука казалась мне красивой, и я думал, что стою на правильном пути.
Но при разработке программ мы часто чуем какие-то вещи нутром. Кто-нибудь просил меня о fоreach? Опять же нет. Но я знал, что стою на правильном пути, и это оказалось так — многие пользуются этим. Но большой грех для разработчика — создавать программы, которые просто отлично смотрятся, хорошо сделаны и так далее. Если вы не решаете реальные проблемы реальных пользователей — в нашем случае Java-программистов, — то не надо ничего добавлять.
Есть чудесное выступление Гослинга «The Feel of Java» (Почувствовать Java); в нем он говорит, что нужно трижды ощутить необходимость чего-то, прежде чем внедрять это. Нельзя добавлять программу только из-за ее красоты.
Но люди все равно добавляют. Что делают разработчики? Пишут код. И, работая над библиотекой или языком, они хотят добавить туда что-то свое. Некий внутренний голос должен подсказывать, какое сочетание свойств будет работать хорошо, что нужно добавлять, а чего не нужно. Ведь чаще всего вы можете добавить к языку больше, чем должны. Это означает не то, что ваши программы плохи, а лишь то, что надо правильно выбирать, не валя все в кучу.
Сейбел: Я читал книги «Java Puzzlers» и «Java Concurrency in Practice». Меня удивило, что в языке, который изначально был очень простым, столько секретов.