О создании языковОтрывок из книги Питера Сейбела «Кодеры за работой. Размышления о ремесле программиста». Книга состоит из 15 интервью с заслуженными программистами. Далее отрывок из интервью с Гаем Стилом. Гай Стил — настоящий программист-полиглот. Он приложил руку к созданию двух основных существующих сейчас диалектов общего назначения языка Лисп: Common Lisp и Scheme. Он участвовал в работе комитетов по стандартам, определивших облик языков Common Lisp, Фортран, Си, ECMAScript и Scheme. Билл Джой нанял его, чтобы он помог в написании официальной спецификации языка Java.. Стил — член Ассоциации вычислительной техники (АСМ), Американской академии искусств и наук, Национальной академии инженерных наук. Он лауреат премии имени Грейс Мюррей Хоппер (1988) от АСМ и премии Dr. Dobb's Excellence in Programming Award (2005). Сейбел: Кстати о создании языков: как менялся ваш подход с течением времени? Стил: Главную перемену я описал в своем докладе «Growing a Language» (Выращивание языка) на конференции по объектно-ориентированному программированию OOPSLA 1998 года. В 1970-е годы создатель языка готовил для него проект, реализовывал его и на этом всё. Или не всё; но вы оставались с мыслью, что язык завершен. Возьмем Паскаль. Что-то по каким-то причинам туда вошло, что-то не вошло, но проектирование языка был завершено. Если бы выяснилось, что чего-то не хватает, что работа со строками никуда не годится, что ж, не повезло. Вирт создал такой язык. ПЛ/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, — его я использовал довольно серьезно. Кроме них всяческие разновидности Лиспа, включая Common Lisp, Scheme, Maclisp. И версию Лиспа, которую мы с Диком Гэбриелом создали для S-1 — S-1 Lisp; потом он стал одной из четырех или пяти частей, которые вместе образовали Common Lisp. Я разработал Connection Machine Lisp, но вроде ничего серьезного на нем не писал. Он, кажется, был реализован на *Lisp. He надо путать *Lisp и Connection Machine Lisp — это два разных языка. Довольно много я писал на С* — его мы тоже разработали для Connection Machine. Java, конечно же. Писал на некоторых скриптовых языках — JavaScript, Tel. Всерьез я имел дело также с Haskell — работал с ним больше месяца, написал длинный фрагмент кода. Фокал, ранний интерактивный язык для компьютеров DEC, похожий... немного на Бейсик, немного на JOSS. Помнится, на Бейсике я тоже писал. ТЕСО (Text Editor and Corrector) — я пользовался им для создания ранней версии Emacs, значит, его тоже можно отнести к языкам программирования. На ТЕСО пришлось писать очень много. И еще ТеХ, если и его рассматривать как язык программирования. Думаю, это основные. Сейбел: Из сказанного вами я делаю вывод, что на вопрос «Какой ваш любимый язык программирования?» ответом будет дзэнское «му».Стил: У меня трое детей: кого я люблю больше всех? Они все хорошие — это разные личности с разными способностями. Сейбел: А есть языки, которыми вам просто не нравится пользоваться? Стил: Удовольствие так или иначе доставляет любой язык. Но с некоторыми сложнее, чем с остальными. Когда-то мне очень нравился ТЕСО, но возвращаться к нему я не хочу. С ним были проблемы: если я через месяц брал собственный код на ТЕСО, то не понимал, что там написано. На Perl я писал слишком мало, чтобы говорить уверенно, но он меня не привлек. И C++ тоже. Я писал код на C++. Думаю, все, что делается на C++, можно так же хорошо сделать на Java, но с меньшими усилиями. Если во главу угла не ставится эффективность. Но я вовсе не хочу ставить под сомнение усилия Бьерна Страуструпа. Он ставил целью создать объектно-ориентированный язык, полностью обратно совместимый с Си. Трудная задача. Мне кажется, он с ней справился — по структуре язык великолепен. Но с учетом программистских задач, которые стоят передо мной, думаю, это желание добиться полной обратной совместимости с Си было роковой ошибкой. И исправить тут ничего нельзя. Система типов в Си никуда не годится. Она помогает кое в чем, но в ней есть слабые места и на нее нельзя полагаться. Сейбел: Как по-вашему, языки становятся лучше? Вы продолжаете их проектировать, а значит, считаете, что это дело стоящее. Легче ли стало этим заниматься благодаря достигнутому прогрессу?Стил: Да, сейчас намного легче писать те программы, которые мы пытались писать 30 лет назад. Но ведь и наши амбиции непомерно выросли. Поэтому программировать сейчас труднее, чем 30 лет назад. Сейбел: Из-за чего именно труднее? Стил: Думаю, сегодня есть такие же умные люди, как и 30 лет назад, которые используют свои возможности до последнего. «30 лет назад» — это такая произвольная дата, просто я тогда окончил школу. В чем разница? Я уже говорил: сейчас нельзя охватить все, что происходит в какой-нибудь области. Даже думать, что можешь, больше уже нельзя. Сегодняшние программисты противостоят более сложной среде, при этом проявляя такой же уровень мастерства, но в среде, которую все сложнее охватить. И мы создаем все более совершенные языки, чтобы помочь им справиться с изменчивостью этой среды. Сейбел: Интересно, что вы сказали «все более совершенные языки». Есть такое течение — его можно назвать «поклонники стиля Scheme». Его представители считают, что единственный способ победить сложность — делать все, включая языки программирования, очень простым. Стил: По-моему, язык должен передавать все, что программист хочет сообщить компьютеру, чтобы все было зафиксировано и учтено. Сейчас у разных программистов разные взгляды на то, что именно им нужно. Мое понимание этого менялось. Думаю, нужно гораздо больше сообщать о структурах данных и об их инвариантах. То, что есть в Javadoc, — это то, что нужно сообщить компилятору. Мне кажется, все, что имеет смысл сообщить другому программисту, имеет смысл сообщить и компилятору. Сейбел: Ведь в Javadoc мы видим главным образом вполне читаемую прозу, которая развилась из кода? Стил: Отчасти да, отчасти нет. В коде на Java плохо улавливается связь между параметрами. Скажем, у нас есть массив данных и есть целое число, и это целое число должно быть корректным индексом этого массива. В Java выразить это не так просто. А это важно. В Fortress это можно сделать. Сейбел: Это скомпилировано в утверждения (asserts) времени выполнения или проверяется статически? Стил: Зависит от того, как удобнее. И так, и так. Мы стараемся, чтобы в Fortress такие связи улавливались. Ранее мы говорили об алгебраических связях, о том, что некоторые операции ассоциативны. Мы хотим, чтобы в Fortress это можно было указывать явно. Вряд ли каждый прикладной программист будет останавливаться и думать: «Ага, подпрограмма, которую я написал, ассоциативна». Но создатели библиотек вынуждены думать об этом. Ведь если они используют изощренные алгоритмы, то правильность алгоритма сильно зависит от таких моментов. И если это так, то нам нужно выражать это на языке, понятном компилятору. По-моему, это важно для будущего — придать языку свойства, необходимые программисту. Сейбел: А как насчет того, чтобы язык не позволял совершать ошибки? Одни думают так: «Если сделать язык достаточно закрытым, то невозможно будет писать плохой код». Другие же, наоборот, говорят: «Забудьте, такой подход обречен, мы можем с тем же успехом оставить все широко открытым, а программистам надо просто быть умнее». Как здесь найти баланс?Стил: Важно понять, что тут все равно будет компромисс. Невозможно искоренить весь плохой код. Можно устранить самые вероятные ошибки, требуя, чтобы код спрашивал: «Мама, можно я?..»: когда что-то сделать чуть труднее, человек задумается и скажет себе: «Да, я имел в виду именно это». А можно некоторые вещи сделать намеренно трудными или невозможными, чтобы стало невозможно повредить, скажем, систему типов. Здесь есть плюсы и минусы — очень сложно писать драйверы устройств для голого железа на типобезопасном языке, потому что уровень абстракции будет слишком высок для голого железа. Можно попробовать добавить конструкции вида: «Эта переменная — действительно такой-то регистр устройства по абсолютному адресу ХХХХ». Но все равно это не очень безопасно. Сейбел: Есть ли в современных языках какие-нибудь интересные сюрпризы? Стил: Python очень неплох — в том смысле, что хорошо структурирован. Но Гвидо изначально не добавил сборку мусора, и мне это не нравилось. Потом он вроде бы пересмотрел свое решение, как я и предвидел. Там есть интересные синтаксические находки: отступы, например, и двоеточия в конце некоторых конструкций; это очень остроумно. Реализация объектов и замыканий тоже довольно любопытна. Сейбел: Большинство лисперов, вероятно, думают, что замыкания там убогие, лямбда-выражения весьма ограниченные. Стил: Это правда. Однако Гвидо приходилось идти на компромисс между ясностью, возможностью реализации и так далее. И все равно получился интересный набор свойств. Я сделал бы по-другому, но он работал для определенного пользовательского сообщества. Я понимаю, почему он в каждом случае поступил так, а не иначе, и уважаю его выбор. Haskell — красивый язык, я люблю его, хотя использую мало. Сейбел: Итак, любя Haskell, вы сейчас проектируете язык, но Fortress — это не чисто функциональный язык? Стил: Сейчас в Haskell используются монады: монада ввода/вывода, монада транзакционной памяти. Есть теория, что это очень функционально; может, это и правда помогает в работе. Но с другой стороны, кажется, что язык становится все более императивным. Как там говорил Белый Рыцарь из «Зазеркалья»? «Но я обдумывал свой план, как щеки мазать мелом, а у лица носить экран, чтоб не казаться белым». Монады для меня — как раз такой экран: сначала вы вытаскиваете ввод/вывод, потом пытаетесь его скрыть обратно — и в итоге непонятно, есть побочные эффекты или нет. Скажу вот что: примерно раз в месяц у меня возникает чувство, что в работе с Fortress надо было бы идти со стороны Haskell к Фортрану и Java, а не брать Фортран и Java и двигаться в сторону Haskell. Проектируя библиотеки для Fortress, мы все больше применяем функциональный подход — и все чаще встречаем трудности в создании эффективных параллельных структур данных. Сейбел: Вы пишете много прозы, этот род деятельности вам также интересен. Как по-вашему, писать прозу и код — занятия одного порядка или нет?Стил: Скорее разного: я четко сознаю, что у читателя прозы иная система обработки данных, чем у компьютера. И я не могу, скажем, в той же мере использовать рекурсию. Правда, для утонченных читателей я порой прибегаю к этому приему. Но всегда ясно сознаю, как читатель будет обрабатывать текст в уме и понимать его. Иногда я очень беспокоюсь, когда пишу прозу, — с кодом я волнуюсь куда меньше. Это из-за неоднозначности слов. Мне все время кажется, будто меня поймут не так. И я провожу много времени, пытаясь отточить стиль моей прозы, употребляю конструкции, которые сложно понять двояко. У меня есть любимый скетч из передачи «Saturday Night Live» — тот, где Эд Эснер изображает сотрудника АЭС, который уезжает в отпуск на две недели. Перед уходом он говорит: «Всем пока! Помните, в ядерном реакторе не может быть слишком много теплоносителя». И дальше минуты три все обсуждают, что же он хотел сказать. Сейбел: Итак, вы видите очевидный контраст между текстами для человека и текстами для компьютера. Но ведь многие, как Кнут, указывают, что написанный вами код обращен и к человеку — не меньше, чем к компьютеру.Стил: О, это так. Сейбел: Значит, в этом плане программисту полезно писать прозу? Стил: Конечно. Работая над кодом, я все время думаю: поймет ли компьютер, чего я от него хочу? Скорее даже так: поймет ли он меня однозначно? А не в смысле, что совсем не поймет. Часто сказать что-то правильно можно разными способами. И тут я начинаю переживать за человека, читающего код. И одновременно за эффективность кода.
Это опять же компромисс: если важна эффективность, мы прибегаем к разным уловкам. Но тогда оказывается сбитым с толку человек. И надо добавлять комментарии или как-то еще делать код читаемым. Обычно выбор имен переменных и организация кода — забота скорее о читателе, о форматировании, которое безразлично компьютеру, но облегчает чтение человеку. Сейбел: По мере того как языки улучшаются или хотя бы становятся дружественными к программисту — в сравнении с временами ассемблера и перфокарт, — избегать ошибок в программах вроде бы становится легче. Есть компиляторы, сигнализирующие об ошибках, и так далее. Так можно ли отдать предпочтение — пусть небольшое — читаемости кода перед правильностью? Как говорят разработчики на Haskell: «Если ваша программа на Haskell выполняет проверку типов, можно спать спокойно».Стил: Думаю, это страшное заблуждение. В пропущенных через компилятор программах всегда слишком много ошибок, чтобы спать спокойно. А ещё есть ошибки, которые собьют с толку не только компьютер, но и человека, читающего код. Программирование — глубоко неестественный вид деятельности, и ему надо как следует учиться. Люди привыкли, что их слушатели сами восстанавливают лакуны в речи. И с компиляторами мы обращаемся в какой-то мере так же. Говоря: «Мне нужна переменная с именем foo», — вы не заботитесь о регистре имени. Люди неточны, часто неряшливы в своей речи. Но когда мы даем команды машине, детали важны, потому что мелкая погрешность может изменить ход всего процесса. Мне кажется, люди привыкли к использованию рекурсии в ограниченном виде — кажется, это показал Ноам Хомский. Но на деле люди редко углубляются больше чем на три уровня, а если и углубляются, то обычно в стиле хвостовой рекурсии. Понимание рекурсии есть сложнейшее искусство. А ведь рекурсия — один из самых мощных инструментов программиста, если его как следует освоить. И поэтому заботиться о корректности надо всегда. Сейбел: Тем не менее многие пытались разработать языки или системы, дающие возможность написать программу непрограммисту. Считаете ли вы эти попытки обреченными на неудачу — ведь дело не в правильности синтаксиса, а в том, что программирование неестественно по природе.Стил: Да. И, кроме того, люди сосредоточены на главном, они не думают о пограничных случаях, о сложных случаях, о маловероятных случаях. А именно в таких случаях начинаются разногласия — как сделать правильно. Опубликовано: 2019.09.23, последняя правка: 2020.09.23 20:10 Написать автору можно на электронную почту |
Продолжение цикла и выход из него