Сейбел:Как о строительстве нового завода.
Дойч:Именно. Объекты большей частью продавались из-за того, что хорошо спроектированные объекты можно использовать многократно, поэтому ваши вложения в их разработку окупаются с меньшими усилиями.
Я по-прежнему убежден в этом, хотя, возможно, и не так сильно, как прежде. В наши дни вещи, создаваемые пригодными для многократного использования, - это либо очень большие вещи, либо очень маленькие. Масштаб многократного использования, о котором шла речь, когда мы продвигали объекты, - классы и группы классов. Кроме случаев, когда имеется коллекция классов, воплощающих настоящие знания в области, - подобного я сейчас не вижу.
По моим наблюдениям, многократно использовать теперь можно либо очень маленькие вещи, например отдельные значки или отдельные дизайны веб-страниц, либо очень большие вещи, например целые языки или крупные приложения с расширенными архитектурами вроде Apache или Mozilla.
Сейбел:То есть сейчас вы уже не так твёрдо убеждены в истинности исходной идеи о многократном использовании объектов. Что-нибудь было не так с самой теорией или она просто не заработала в силу исторических причин?
Дойч:Причина, по которой я больше не называю себя специалистом в области компьютерных наук, частично заключается в том, что я наблюдал практику разработки ПО около 50 лет и за последние 30 лет не увидел значительных изменений в лучшую сторону.
Если взять языки программирования, могу вам убедительно доказать, что они не улучшились в качественном плане за последние 40 лет. Сейчас нет языка программирования, который превосходил бы по качественным характеристикам Симулу-67. Я знаю, что это звучит достаточно смешно, но я действительно так считаю. Java не намного лучше Симулы-67.
Сейбел:A Smalltalk?
Дойч:Smalltalk немного лучше Симулы-67. Но Smalltalk в его нынешнем виде ничем не отличается от себя же образца 1976 года. Я не говорю, что языки, которые существуют сегодня, не лучше языков, которые существовали 30 лет назад. Язык, на котором я пишу все свои программы сегодня - Python, - превосходит, на мой взгляд, любой из языков, что были доступны 30 лет назад. Мне он нравится намного больше, чем Smalltalk.
Я не зря сказал о качественных характеристиках. В каждом распространенном в наши дни языке программирования, известном мне, используется понятие указателя. И я не представляю, каким образом можно качественно улучшить ПО, созданное с применением этого фундаментального понятия.
Сейбел:Вы относите ссылки в Python и Java к указателям?
Дойч:Безусловно. Да, у всех программ на Python или Java, не считая очень небольших программ, те же проблемы, за исключением проблем с порчей данных, как в случае Си или C++.
Суть проблемы в том, что не существует языкового механизма понимания, постулирования, управления или вывода шаблонов доступа и разделения информации в системе. Передача указателя и хранение указателя - это локализованные операции, но их последствия неявно создают целый граф. Не говоря о многопоточных приложениях, даже в однопоточных приложениях данные перемещаются между разными частями программы. Есть и ссылки, которые распространяются на другие части программы. Даже в хорошо спроектированных программах найдутся две, три или даже четыре различные сложные модели протекающих процессов и не найдется способа, которым можно было бы описать, объяснить или охарактеризовать крупные блоки, не касаясь при этом того, что происходит на нижнем уровне. Предпринималось множество попыток решить эту проблему. Но я не припомню никаких открытий и прорывов в этой области. Думаю, в этой области нет каких-то общепринятых или общеиспользуемых решений.
Сейбел:А как насчет чисто функциональных языков - хотя они, наверное, и не являются широко используемыми?
Дойч:Да, у чистых функциональных языков совсем другие проблемы, но этот Гордиев узел они, конечно же, разрубают.
Время от времени у меня появляется соблазн разработать язык программирования, но я ничего не делаю и жду, когда этот порыв пройдет. Но если я поддамся этому соблазну, то в моем языке будет фундаментальное разделение между функциональной частью, отвечающей исключительно за значения и в которой не будет понятия указателя, и другой областью, которая будет отвечать за схемы совместного владения, ссылки и управление.
Поскольку я занимался написанием как компиляторов, так и интерпретаторов, то могу придумать множество способов реализации языка без необходимости постоянно копировать большие массивы. Но те, кто занимается функциональными языками, понимают в этом намного больше меня. Есть множество умных людей, которые работали и работают над Haskell и подобными языками.
Читать дальше
Конец ознакомительного отрывка
Купить книгу