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

Возьмем Паскаль. Что-то по каким-то причинам туда вошло, что-то не вошло, но проектирование языка был завершено. Если бы выяснилось, что чего-то не хватает, что работа со строками никуда не годится, что ж, не повезло. Вирт создал такой язык. ПЛ/1 и Ада были спроектированы таким же образом. Возможно, Ада и C++ стали едва ли не последними языками такого рода. В меньшей степени C++ — он все-таки развивался с течением времени.

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

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

Стил: Наверное, нет. Хотя должен был бы. Java менялся благодаря Java Community Process. Это касалось больше API, чем ядра. Последние 12-13 лет к языку добавлялись все новые свойства, но, наверное, его создатели в начале 1990-х думали, что создают совершенный язык для конкретных ограниченных целей. Вы знаете, их целью были ресиверы для телевизоров.

Сейбел: Верно.

Стил: Они не рассчитывали на Интернет или на такую широкую пользовательскую базу, как сейчас. По-моему, они хотели создать компактный, автономный базовый язык, над которым можно было бы надстраивать API для разных целей. Мой доклад «Выращивание языка» отчасти был посвящен этому процессу: тому, как Java оказался слишком маленьким, а пользователям нужно было больше свойств для их целей.

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

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

Сейбел: A Common Lisp, в создании которого вы участвовали, может служить в этом смысле примером?

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

Сейбел: Недавно три языка, которые вы в той или иной степени проектировали, прошли или еще проходят болезненный редизайн. Scheme прошел R6RS; JavaScript — ECMAScript — проходит через споры «ES4 против ES3». И с Java спорят по поводу того, надо ли, а если надо, то как добавлять туда замыкания.

Стил: Кстати, да.

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

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

Сейбел: А есть примеры языков, которые развивались легко?

Стил: Ну, думаю, Лисп может служить примером языка, который легко вырос — благодаря гибкости системы макросов. А отчасти тут сыграла роль атмосфера, царившая в группе разработчиков.

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

Сейбел: Выбор языка действительно важен? Есть ли серьезные доводы в пользу одного языка или другого? Или все это дело вкуса?

Стил: А что, вкус — плохой довод?

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

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

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

Например, проектируя алгоритмы, я смешиваю языки. Обдумывая что-то, я пишу на доске код на Java и тут же на Фортране, на APL. Я сам смогу разобрать, что у меня вышло, и это главное. Такая форма записи позволяет мне сделать каждый кусок алгоритма как можно более ясным и полезным.

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

С другой стороны, очень сложно создать язык, пригодный для всего сразу, — отчасти потому, что есть много способов сократить запись. Это как код Хаффмана: если в одном месте удалось быть кратким, в другом придется быть многословным. И проектируя язык, надо думать вот о чем: что именно хочешь сделать кратким для изложения, а что — легко доступным для понимания. Если это осознать и использовать для этих целей некоторые символы, получится, что какие-то другие вещи сказать уже сложнее.

Сейбел: Одно из решений как раз предлагает Лисп, где все записи средней длины. И пользователи могут делать свои синтаксические расширения на базовом уровне языка — в том же духе, с записями средней длины. Тем не менее многие не любят S-выражения. Многие лисперы самоуверенно считают, что недовольные этим языком просто не видят всей прелести этого решения. А вы достаточно самоуверенны, чтобы полагать, что если человек действительно понимает Лисп, то скобки не будут его раздражать?

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

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

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

Стил: Я заработал свои первые деньги, программируя на Коболе, еще в старшей школе. Я подрядился сделать систему по генерации табелей успеваемости для какой-то другой школы. Потом были Фортран, язык ассемблера IBM 1130, машинный язык PDP-10, APL. Снобол всерьез я не использовал. Ну и, конечно, Си, C++, Bliss, язык реализации для DECsystems, разработанный в университете Карнеги-Меллона, GNAL, основанный на Red, — его я использовал довольно серьезно.