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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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