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

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

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

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

Сейбел:Назовите языки, с которыми вам хочется повозиться больше всего.

Блох:Например, Scala, хотя у меня есть сомнения насчет его будущей популярности. Я очень уважаю Мартина Одерски - он реализовал в своем языке немало красивых идей. Но, возможно, этот язык сложноват и слишком академичен, чтобы иметь широкий успех. Честно говоря, я еще не изучил его толком, так что могу быть неправ.

Затем Python. Из старых - Scheme. Будет неплохо несколько месяцев поизучать “Structure and Interpretation of Computer Programs” вместе с сыном. Говорят, это отличная книга. В качестве первого шага я купил ее. Но для освоения нужно время.

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

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

Сейбел:Что это за конкуренты?

Блох:Как я считаю, C++ и С#.

Сейбел:А как насчет Erlang или транзакционной памяти?

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

У Erlang свой подход к параллелизму - акторы: если они окажутся успешной находкой, то могут быть реализованы во многих языках. Как вы знаете, Одерски с компанией уже реализовали их в Scala. Пока я не уверен, что акторы - лучшее из придуманного для многоядерного параллелизма, но если все же это так, то и в Java вы скоро увидите их.

Сейбел:Итак, Java, по вашим словам, имеет блоки, позволяющие получить портируемый доступ к параллельным потокам, предоставляемым операционной системой, а также конструкции более высокого уровня в рамках API Java.util.concurrent. Но все равно, это ведь средства довольно низкого уровня в сравнении с Erlang или транзакционной памятью?

Блох:Не уверен. Некоторые конструктивные блоки в Java действительно низкоуровневые, например Atomiclnteger; есть среднеуровневые, например CyclicBarrier, и наконец высокоуровневые - ConcurrentHash-Мар и ThreadPoolExecutor. Уверен, что транзакционная память и акторы найдут свое место в наших конструктивных блоках для многопоточных задач, как только народ убедится, что эти новинки работают хорошо. Если, конечно, они будут работать хорошо.

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

Тому есть несколько причин. Первая из них состоит в том, что если вы пытаетесь делать автоматическую блокировку или оптимистичное управление параллелизмом, основываясь только на чтении и записи на уровне байтов, то между потоками происходит “мнимый конфликт”: физические конфликты не соответствуют логическим. Если вам нужны блокировки, то убедитесь, что захвачены лишь те, которые помогают решить логические конфликты.