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

Сейбел:То есть если у вас есть печатное устройство, которое использует золотую краску, то вы просто добавляете дополнительную пластину.

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

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

Сейбел:То есть вами.

Дойч:Именно. Ghostscript задумывался исключительно для предварительного просмотра файлов в Postscript, потому что тогда других таких программ не было, a PDF еще не существовал. Если мне и предстояло извлечь урок из той истории, то вот он: требования всегда меняются, они всегда как минимум предпринимают попытку измениться в направлении, о котором ты даже не подозреваешь.

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

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

Мне кажется, суть проблемы заключается в противоборстве двух философий - ПО как статья расхода и ПО как долгосрочный актив. Я убежденный сторонник второй философии. Когда я еще работал в ParcPlace и Адель Голдберг проповедовала объектно-ориентированный подход к разработке, мы либо говорили об объектах, либо пропагандировали объектно-ориентированные языки и объектно-ориентированный подход к разработке нашим клиентам и потенциальным клиентам, и суть сводилась к следующему: “Вы должны рассматривать ПО как долгосрочный актив”.

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

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

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

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

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

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

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

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

Сейбел:A Smalltalk?

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

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

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

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

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