Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Но нет таких долгосрочных активов, которые не требуют постоянных затрат на содержание. Необходимо ожидать, что если вы собираетесь поддерживать разрастающуюся библиотеку ПО многократного использования, то это потребует определенных расходов. И это сделает вашу бухгалтерскую отчетность более сложной, поскольку вы не можете списывать стоимость создания элемента ПО на проект или клиента, для которого необходимо создать данное ПО в данный момент. Вам нужно думать о нем как о долгосрочном активе.
Сейбел: Как о строительстве нового завода.
Дойч: Именно. Объекты большей частью продавались из-за того,
Я по-прежнему убежден в этом, хотя, возможно, и не так сильно, как прежде. В наши дни вещи, создаваемые пригодными для многократного использования, — это либо очень большие вещи, либо очень маленькие. Масштаб многократного использования, о котором шла речь, когда мы продвигали объекты, — классы и группы классов. Кроме случаев, когда имеется коллекция классов, воплощающих настоящие знания в области, — подобного я сейчас не вижу.
По моим наблюдениям, многократно использовать теперь можно либо очень маленькие вещи, например отдельные значки или отдельные дизайны веб-страниц, либо очень большие вещи, например целые языки или крупные приложения с расширенными архитектурами вроде 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.
Если вы посмотрите на Е — это не тот язык, о котором все знают, чтобы о нем можно было говорить, — он из тех языков, что основаны на очень четком понятии «способности». Он связан с акторными языками Хьюитта и с операционными системами, основанными на этом понятии. В нем есть порты, или коммуникационные каналы, для обеспечения фундаментальной связи между двумя объектами. Основная идея заключается в том, что ни один из участников коммуникации не знает другого участника коммуникации. То есть это очень сильно отличается от понятия указателя, который направлен в одну сторону, и где объект, держащий указатель, достаточно хорошо представляет себе, что находится на другом конце. В нем очень важную роль играет элемент непрозрачности.
У меня есть идея — предварительная, непроработанная, — согласно которой в языке должны быть функциональные вычисления и не должно быть совместного владения объектами. Должны быть своего рода сериализованные порты. Каждый раз, когда нужно обратиться к тому, что знаешь, только по ссылке, в соответствии с природой самого языка, понимаешь: что бы это ни было, это что-то взаимодействует с многочисленными источниками коммуникации и соответственно следует ожидать, что оно должно уметь сериализовывать данные или что-нибудь в этом роде. Не должно быть понятия доступа к атрибуту и уже точно не должно быть возможности записи в атрибут.