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

Сейбел: Как о строительстве нового завода.

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

Я по-прежнему убежден в этом, хотя, возможно, и не так сильно, как прежде. В наши дни вещи, создаваемые пригодными для многократного использования, — это либо очень большие вещи, либо очень маленькие. Масштаб многократного использования, о котором шла речь, когда мы продвигали объекты, — классы и группы классов. Кроме случаев, когда имеется коллекция классов, воплощающих настоящие знания в области, — подобного я сейчас не вижу.

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

Сейбел: То есть сейчас вы уже не так твёрдо убеждены в истинности исходной идеи о многократном использовании объектов. Что-нибудь было не так с самой теорией или она просто не заработала в силу исторических причин?

Дойч: Причина, по которой я больше не называю себя специалистом в области компьютерных наук, частично заключается в том, что я наблюдал практику разработки ПО около 50 лет и за последние 30 лет не увидел значительных изменений в лучшую сторону.

Если взять языки программирования, могу вам убедительно доказать, что они не улучшились в качественном плане за последние 40 лет. Сейчас нет языка программирования, который превосходил бы по качественным характеристикам Симулу-67. Я знаю, что это звучит достаточно смешно, но я действительно так считаю. Java не намного лучше Симулы-67.

Сейбел: A Smalltalk?

Дойч: Smalltalk немного лучше Симулы-67. Но Smalltalk в его нынешнем виде ничем не отличается от себя же образца 1976 года. Я не говорю, что языки, которые существуют сегодня, не лучше языков, которые существовали 30 лет назад. Язык, на котором я пишу все свои программы сегодня — Python, — превосходит, на мой взгляд, любой из языков, что были доступны 30 лет назад. Мне он нравится намного больше, чем Smalltalk.

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

Сейбел: Вы относите ссылки в Python и Java к указателям?

Дойч: Безусловно. Да, у всех программ на Python или Java, не считая очень небольших программ, те же проблемы, за исключением проблем с порчей данных, как в случае Си или C++.

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

Сейбел: А как насчет чисто функциональных языков — хотя они, наверное, и не являются широко используемыми?

Дойч: Да, у чистых функциональных языков совсем другие проблемы, но этот Гордиев узел они, конечно же, разрубают.

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

Поскольку я занимался написанием как компиляторов, так и интерпретаторов, то могу придумать множество способов реализации языка без необходимости постоянно копировать большие массивы. Но те, кто занимается функциональными языками, понимают в этом намного больше меня. Есть множество умных людей, которые работали и работают над Haskell и подобными языками.

Сейбел: А эти ребята не придут и не скажут: «Да, именно так это и есть у нас в монадах, и это разделение у нас реализовано в системе типов»?

Дойч: Знаете, я никогда не понимал монады в Haskell. Я, наверное, перестал следить за функциональными языками после ML.

Если вы посмотрите на Е — это не тот язык, о котором все знают, чтобы о нем можно было говорить, — он из тех языков, что основаны на очень четком понятии «способности». Он связан с акторными языками Хьюитта и с операционными системами, основанными на этом понятии. В нем есть порты, или коммуникационные каналы, для обеспечения фундаментальной связи между двумя объектами. Основная идея заключается в том, что ни один из участников коммуникации не знает другого участника коммуникации. То есть это очень сильно отличается от понятия указателя, который направлен в одну сторону, и где объект, держащий указатель, достаточно хорошо представляет себе, что находится на другом конце. В нем очень важную роль играет элемент непрозрачности.

У меня есть идея — предварительная, непроработанная, — согласно которой в языке должны быть функциональные вычисления и не должно быть совместного владения объектами. Должны быть своего рода сериализованные порты. Каждый раз, когда нужно обратиться к тому, что знаешь, только по ссылке, в соответствии с природой самого языка, понимаешь: что бы это ни было, это что-то взаимодействует с многочисленными источниками коммуникации и соответственно следует ожидать, что оно должно уметь сериализовывать данные или что-нибудь в этом роде. Не должно быть понятия доступа к атрибуту и уже точно не должно быть возможности записи в атрибут.

Есть языки, в которых API непрозрачны, чтобы реализации могли иметь инварианты; но это опять же ничего не говорит о более глобальных моделях коммуникации. Например, одна распространенная модель: у тебя есть объект, ты передаешь его кому-то еще, просишь этого кого-то выполнить с этим объектом определенное действие и затем в какой-то момент просишь вернуть этот объект. Это модель совместного владения. Ты, вызывающий, можешь никогда на самом деле не отдавать все указатели на объект, который ты передал. Но ты говоришь себе, что не будешь ссылаться через этот указатель до тех пор, пока это третье лицо не выполнит те действия, о которых ты просил.

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

Возможно, самая серьезная причина, по которой я на самом деле не предпринимаю попытку создать язык, — я не уверен, что знаю, как нужно описывать модели совместного владения и коммуникации на достаточно высоком уровне и так, чтобы их можно было реализовать. Но я считаю, что именно поэтому индустрия разработки ПО так мало продвинулась за последние 30 лет.

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

Раньше идея корректности программы заключалась в существовании неких утверждений, которые являлись выражениями того, что вы хотели от своего кода, — причем чтобы это можно было механическим способом проверить в самом коде. Этот подход был связан с множеством проблем. Сейчас я считаю, что путь к ПО, которое с большей вероятностью будет делать то, чего мы от него хотим, лежит не через использование утверждений или индуктивных утверждений, а через использование более качественных, более мощных и глубоких декларативных систем обозначения.