Читаем Кодеры за работой. Размышления о ремесле программиста полностью

Стил: Отчасти да, отчасти нет. В коде на Java плохо улавливается связь между параметрами. Скажем, у нас есть массив данных и есть целое число, и это целое число должно быть корректным индексом этого массива. В Java выразить это не так просто. А это важно. В Fortress это можно сделать.

Сейбел: Это скомпилировано в утверждения (asserts) времени выполнения или проверяется статически?

Стил:

Зависит от того, как удобнее. И так, и так. Мы стараемся, чтобы в Fortress такие связи улавливались. Ранее мы говорили об алгебраических связях, о том, что некоторые операции ассоциативны. Мы хотим, чтобы в Fortress это можно было указывать явно. Вряд ли каждый прикладной программист будет останавливаться и думать: “Ага, подпрограмма, которую я написал, ассоциативна”.

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

Сейбел: А как насчет того, чтобы язык не позволял совершать ошибки? Одни думают так: “Если сделать язык достаточно закрытым, то невозможно будет писать плохой код”. Другие же, наоборот, говорят: “Забудьте, такой подход обречен, мы можем с тем же успехом оставить все широко открытым, а программистам надо просто быть умнее”. Как здесь найти баланс?

Стил:

Важно понять, что тут все равно будет компромисс. Невозможно искоренить весь плохой код. Можно устранить самые вероятные ошибки, требуя, чтобы код спрашивал: “Мама, можно я?..”: когда что-то сделать чуть труднее, человек задумается и скажет себе: “Да, я имел в виду именно это”. А можно некоторые вещи сделать намеренно трудными или невозможными, чтобы стало невозможно повредить, скажем, систему типов. Здесь есть плюсы и минусы - очень сложно писать драйверы устройств для голого железа на типобезопасном языке, потому что уровень абстракции будет слишком высок для голого железа. Можно попробовать добавить конструкции вида: “Эта переменная - действительно такой-то регистр устройства по абсолютному адресу ХХХХ”. Но все равно это не очень безопасно.

Сейбел: Есть ли в современных языках какие-нибудь интересные сюрпризы?

Стил: Python очень неплох - в том смысле, что хорошо структурирован. Но Гвидо изначально не добавил сборку мусора, и мне это не нравилось. Потом он вроде бы пересмотрел свое решение, как я и предвидел. Там есть интересные синтаксические находки: отступы, например, и двоеточия в конце некоторых конструкций; это очень остроумно. Реализация объектов и замыканий тоже довольно любопытна.

Сейбел:

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

Стил: Это правда. Однако Гвидо приходилось идти на компромисс между ясностью, возможностью реализации и так далее. И все равно получился интересный набор свойств. Я сделал бы по-другому, но он работал для определенного пользовательского сообщества. Я понимаю, почему он в каждом случае поступил так, а не иначе, и уважаю его выбор. Haskell - красивый язык, я люблю его, хотя использую мало.

Сейбел: Итак, любя Haskell, вы сейчас проектируете язык, но Fortress - это не чисто функциональный язык?

Стил: Сейчас в Haskell используются монады: монада ввода/вывода, монада транзакционной памяти. Есть теория, что это очень функционально; может, это и правда помогает в работе. Но с другой стороны, кажется, что язык становится все более императивным. Как там говорил Белый Рыцарь из “Зазеркалья”? “Но я обдумывал свой план, как щеки мазать мелом, а у лица носить экран, чтоб не казаться белым”[67]

. Монады для меня - как раз такой экран: сначала вы вытаскиваете ввод/вывод, потом пытаетесь его скрыть обратно - и в итоге непонятно, есть побочные эффекты или нет.

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

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

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

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

Перейти на страницу:

Похожие книги

100 мифов о Берии. Вдохновитель репрессий или талантливый организатор? 1917-1941
100 мифов о Берии. Вдохновитель репрессий или талантливый организатор? 1917-1941

Само имя — БЕРИЯ — до сих пор воспринимается в общественном сознании России как особый символ-синоним жестокого, кровавого монстра, только и способного что на самые злодейские преступления. Все убеждены в том, что это был только кровавый палач и злобный интриган, нанесший колоссальный ущерб СССР. Но так ли это? Насколько обоснованна такая, фактически монопольно господствующая в общественном сознании точка зрения? Как сложился столь негативный образ человека, который всю свою сознательную жизнь посвятил созданию и укреплению СССР, результатами деятельности которого Россия пользуется до сих пор?Ответы на эти и многие другие вопросы, связанные с жизнью и деятельностью Лаврентия Павловича Берии, читатели найдут в состоящем из двух книг новом проекте известного историка Арсена Мартиросяна — «100 мифов о Берии».В первой книге охватывается период жизни и деятельности Л.П. Берии с 1917 по 1941 год, во второй книге «От славы к проклятиям» — с 22 июня 1941 года по 26 июня 1953 года.

Арсен Беникович Мартиросян

Биографии и Мемуары / Политика / Образование и наука / Документальное