Инструменты для проектирования языка

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

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

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

Оглядываясь назад, я жалею, что не нашел способа формализовать правила преобразования типов и сопоставления формальных и фактических арг}ментов. у меня есть подозрение, что никакой формализм не смог бы справиться с крайней нерегулярностью правил С в отношении встроенных типов и операторов.

У дизайнера языка есть большое искушение предоставить специальные средства там, где пользователям пришлось бы искать обходные пути. Недовольство по поводу отказа добавлять что-то обычно гораздо сильнее, чем жалобы на то, что добавлена еще одна бесполезная возможность . Это серьезная пробле.ма и для комитетов по стандартизации (см. раздел 6.4), и худший вариант в этом смысле -культ ортогональности. Многие думают, что если от добавления некоей возможности язык становится более ортогональным, то и спорить больше не о чем. Обычно же, вопреки всем благим намерениям относительно ортогональности, определение

комбинации средств все же требует дополнительной работы над справочным руководством и руководством пользователя. Чаще всего реализация комбинации, которую предписывают идеалы ортогональности, оказывается сложнее, чем многие себе представляют. В случае С++ я всегда учитывал, во что (с точки зрения времени и памяти) обойдется ортогональность тем, кто не использует данную комбинацию. Если цену нельзя было, по крайней мере, в принципе свести к нулю, то я очень неохотно шел на добавление новой возможности, какой бы ортогональной она ни была.

Мне казалось, да и сейчас кажется, что многие языки программирования и инструментальные средства дают решения, которые так и влекут за собой неприятности, и я ни в коем случае не хотел допустить, чтобы мою работу постигла та же участь. Поэтому я читаю литературу по языкам программирования, принимаю участие в дискуссиях на эту тему, но в основном ищу идеи для решения проблем, с которыми я и мои коллеги сталкивались в реальных приложениях. В других языках скрыта масса вдохновляющих возможностей, только надо тщательно просеять их, чтобы не поддаться соблазну, утратив чувство меры, и избежать внутренних противоречий. Основными источниками идей для С++ были Simula, Algol68, а позже - Clu, Ada и ML. Ключ к хорошему дизайну - глубокое понимание стоящих перед языком задач, а не включение самых передовых идей.

3.14. Книга Язык программирования С++

Осенью 1984 г. сидевший в соседнем с моим кабинете Эл Ахо предложил мне написать книгу по С++, организованную по образу и подобию книги Брайана Кер-нигана и Денниса Ричи Язык программирования С [Kernighan, 1978]. В основу труда должны были лечь мои статьи, внутренние отчеты и справочное руководство по С++. Работа над книгой заняла девять месяцев. Я закончил ее в середи1ге августа 1985 г., а первые экземпляры появились в середине октября. В предисловии упоминаются те, кто внес наибольший вклад в С++: Том Каргилл, Джим Коплиен, Стью Фельдман, Сэнди Фрэзер, Стив Джонсон, Брайан Керниган, Барт Локанти (Bart Locanthi), Дуг Макилрой, Деннис Ричи, Ларри Рослер, Джерри Шварц и Джонатан Шопиро.

С++ проектировался прежде всего для того, чтобы автору и его друзьям не приходилось программировать на ассемблере, С или современных языках высокого уровня. Основная задача С++ - сделать написание хороших программ более простым и приятным занятием для профессионального программиста , - говорилось вначале.

Объект моей работы - человек, индивидуум (неважно, является ли он членом какого-то коллектива или нет), программист. С годами я становился все более привержен этой идее и еще сильнее подчеркнул ее во втором издании [2nd], где гораздо глубже обсуждались вопросы проектирования и разработки программного обеспечения.

Книга Язык програ.ммирования С++ представляла собой определение языка С++ и введение в него. Она писалась с твердой решимостью не отдавать предпочтение никаким особым приемам программирования в ущерб всем прочим.

Книга Язык программирования С++

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

3.15. Статья Whatls?

После выпуска версии 1.0 и отправки оригинал-макета книги в издательство у меня появилось время вернуться к рассмотрению крупных вопросов и документировать весь ход проектирования. Как раз в это время мне позвонил из Осло Карел Бабчиски, председатель Ассоциации пользователей Simula (ASU), и пригласил выступить с докладом о С++ на конференции ASU 1986 г. в Стокгольме. Конечно, я хотел поехать, но был обеспокоен тем, что презентация С++ на конференции по Simula может быть расценена как вульгарная самореклама и попытка отвратить пользователей от этого уважаемого языка. В конце концов я сказал: С++ - не Simula, так почему пользователи Simula захотят слушать о нем? На это Бабчиски ответил: Да мы же не цепляемся за синтаксис . Это дало мне возможность написать не только о том, что такое С++, но и о том, чем он предположительно станет, и о том, где пришлось отступить от идеалов. В результате появилась статья What is Object-Oriented Programming ( Что такое объектно-ориентированное программирование ), [Stroustrup, 1986Ь]. Развернутый вариант работы представлен на первой конференции ЕСООР в июне 1987 г. в Париже.

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

В работе вновь подчеркивалась природа С++ как языка, поддерживающего несколько парадигм:

Объектно-ориентированное программирование - это программирование с применением наследования. Абстрагирование данных - это программирование с использованием определенных пользователем типов. За немногими исключениями, объектно-ориентированное программирование может и должно быть надмножеством абстрагирования данных. Чтобы эти методы были эффективны, необходима надлежащая поддержка. Поддержка абстрагирования данных требует языковых средств, а для объектно-ориентированного программирования нужна еще и поддержка со стороны среды. Чтобы претендовать на звоние языка общего назначения, язык, поддерживающий абстрагирование данных или объектно-ориентированное программирование, должен эффективно роботать с распространенной аппаратурой .

Особо говорилось о важности статического контроля типов. Други.ми словами, модель наследования и контроля С++, скорее, построена на базе Simula, чем Smalltalk:

Класс в Simula или С++ определяет неизменный интерфейс к множеству объектов, принадлежащих любому производному классу, тогда как в Smalltalk класс определяет начальный набор операций с объектами (любого подкласса). Иначе говоря, в Smalltalk класс - минимальная спецификация и пользователь может попробовать выполнить неукозонные операции, в то время