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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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