Полчаса с Джеймсом Гослингом

Ведущий инженер корпорации Sun Microsystems рассказывает о ходе работ по развитию языка Java

Джеймс Гослинг: «Конечно, хотелось бы, чтобы на любой вопрос можно было дать четкий и правильный ответ, но политические игры начинаются всякий раз, когда в комнате собирается больше одного человека.»

Корреспондент электронного журнала JavaWorld Билл Веннерс, сам являющийся активным пользователем языка программирования Java, не в первый раз беседует с Джеймсом Гослингом, одним из ведущих инженеров корпорации Sun Microsystems, создателем Java.

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

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

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

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

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

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

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

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

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

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

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

Некоторые из подобных изолированных приложений, находящихся на одной машине, включают в себя миллионы строк кода. Как можно иметь с ними дело? Большинство людей не имеют понятия об этом. Сегодня нам доступны все виды инструментов, начиная с организационных, получаемых на основе объектно-ориентированной методологии, и заканчивая средствами, построенными на их базе, например, моделями UML.

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

Безусловно. Я всегда помню о том, что совершенствование вычислительной техники подчиняется закону Мура — а это геометрическая прогрессия.

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

Правильно, потому что стоит их открыть, как сразу станет ясно, что с ними действительно ни в коем случае нельзя расставаться.

Я полагаю, что при проектировании всегда нужно стараться найти наиболее простой путь. Если этого не получится, вы окажетесь погребенными под грузом проблем. Справиться с подобными трудностями совсем не просто.

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

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

Да.

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

Да, без поддержки иерархии наследования. Вместо создания подклассов вы используете чистые интерфейсы. Речь идет не о том, что технология наследования классов плоха сама по себе. Но при ее использовании возникают определенные трудности.

На пляжах Санта-Круз большой популярностью пользуется игра Whack-a-Mole («Ударь крота»). На игровом поле находится стол с 16 отверстиями. Маленький механический крот на секунду высовывает из дырки голову. Ваша задача — ударить его палкой. Голова крота появляется в одном из отверстий, вы ударяете по ней, после чего она показывается в другом отверстии и т.д.

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

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

Конечно, хотелось бы, чтобы существовало какое-то четкое правило, поскольку и сам довольно часто оказываюсь в состоянии неопределенности. Могу сказать лишь, что лично я применяю наследование чаще, чем какую-либо другую технологию.

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

Правильно. Сегодня я являюсь скорее незаметным наблюдателем.

Один из самых важных моментов — соглашение о реализации справочного руководства. Чернила на спецификациях не высохнут до тех пор, пока кто-то продолжает эти спецификации дописывать.

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

Это на самом деле непростой вопрос. В истории компьютерной отрасли полно примеров, когда решения принимались недостаточно компетентными людьми. Поэтому отдельные компоненты технологии оставляли желать лучшего.

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

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