Третий участник проекта был (и есть) настолько талантлив как программист, что
мог с одинаковым успехом участвовать, кажется, решительно в любом программном
проекте. Базы данных и сети, протоколы обменов и многозадачность, графика и
издательские системы, вычислительные алгоритмы, распределенная обработка и
искусственный интеллект — во всем он чувствовал себя уверенно и имел на то
полное основание.
Так что шеф, глядя на нашу троицу с неподдельной гордостью, вполне мог считать,
что вместе мы горы свернем. Однако далеко не все было гладко…
В компиляторе есть проектные ошибки (хотя к настоящему моменту большинство из
них мы извели, поначалу их было немало). "Снаружи" эти ошибки практически никак
не проявляются и не дают покоя только нам, знающим наизусть все его
внутренности. Некоторые из них были просто неизбежны, так как, закладывая то
или иное решение несколько лет назад, мы никак не могли представить, к чему
приведет непредсказуемая эволюция языка. Другие ошибки объяснялись
недостаточным опытом — практически впервые мы пытались делать то, что
называется коммерческим программным продуктом и исходили только из
академических представлений о том, какова должна быть архитектура компилятора.
Но самая неприятная категория проектных ошибок — это те, которые возникли из-за
недостаточно тщательного анализа на начальных этапах проекта и, что хуже, из-за
того, что по некоторым принципиальным вопросам имелись различные мнения.
Принимать решение всегда сложно еще и потому, что чье-то мнение, как правило,
приходится отвергать. Тяжело и тому, кто отвергает, и неприятно тому, чье
мнение не учитывается. Зачастую бывает так, что трудно предпочесть какой-либо
конкретный вариант из нескольких альтернатив просто потому, что все они
достаточно обоснованы и могут быть использованы; в таких случаях необходимо
чье-то волевое решение, которое все участники должны безоговорочно принять. У
нас в свое время просто не хватило духу проговорить все до конца и определиться
полностью по всем принципиальным вопросам. В результате некоторые существенные
решения принимались "по умолчанию" тем или иным участником проекта без
согласования с другими. Винить в этом, естественно, следует прежде всего
старшего участника — автора этой статьи (как самого опытного, а не самого
умного!).
Так, компилятор сначала выполняет полный семантический анализ всего исходного
текста, и только потом генерирует для всей программы результирующий код. Почему
такая организация компилятора была выбрана третьим участником, до сих пор
непонятно. Какое-то объяснение было тогда дано, но оно тут же выпало из нашей
памяти, и вспомнить сейчас невозможно, а попытаться самим объяснить — не
получается. Такое решение (удивительно, но принятое без всякого обсуждения)
приводит к тому, что компилятор сохраняет полное дерево программы (и,
следовательно, вынужден сохранять и семантические таблицы, так как они друг с
другом сильно связаны) вплоть до завершения обработки всего исходного текста.
Более логичным и экономичным был бы подход, согласно которому для каждой
функции выполняется вся обработка, вплоть до генерации кода, после чего в
структурах компилятора сохраняется только информация из ее заголовка,
необходимая для компиляции вызовов. Исключение достаточно сделать для
встраиваемых (inline) функций, да и то не всегда.
