Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Всерьез я имел дело также с 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 — красивый язык, я люблю его, хотя использую мало.