Вадим Станкевич ЛЕДИ АДА

Часть первая

Есть спросить у программиста, о каких языках программирования он когда-либо слышал, он задумается надолго. Потому что разных языков в двоичном мире великое множество. Многие из них можно уже полноправно считать мёртвыми (например, «компьютерную латынь» — АЛГОЛ, ставший прототипом Паскаля и множества других языков, но так и не сумевший выдержать конкуренции со стороны потомков). Многие языки находятся в процессе разработки, и ежегодно появляются десятки новых языков программирования и их диалектов.

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

Вполне вероятно, что во втором десятке списка языков, который программист составит после такого вопроса, окажется один не очень известный в нашей стране язык программирования, который, между тем, даст фору по многим параметрам почти всем популярным и известным языкам. Не думайте, что это утверждение голословно. Дочитайте, пожалуйста, статью до конца, прежде чем делать выводы.

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

Ада — высокоуровневый объектно-ориентированный язык программирования, разработанный по заказу Пентагона международной группой экспертов. Вот уже отсюда начинается первая легенда об этом языке. Поскольку разработан для Пентагона, значит, ни для чего, кроме военных нужд, не годится. Но это не так. Множество гражданских и вполне мирных проектов написано на Аде. Самый известный из них — это, пожалуй, система управления поездами на одной из линий Парижского метро.

В качестве «родителя» для Ады куратор проекта по разработке этого языка Жан Ишбиа выбрал Паскаль. В итоге язык получился очень строгим — более строгой типизации нет ни в одном другом языке программирования. А ещё благодаря этому тексты программ легко читаемы. Например, традиционный и любимый программистами «Hello, world!» на Аде выглядит следующим образом:

with Ada.Text_IO;

procedure Hello_World is

begin

 Ada.Text_IO.Line("Hello, world!");

end Hello_World;

К сожалению, обратная сторона медали — это многословность Ады. На стойких адептов C/C++ она действует, словно красная тряпка на быка. Однако стиль программирования, в который Ада деспотично «вгоняет» программиста, способствует резкому снижению времени, нужного для отладки программы. Благодаря строгой типизации, явному объявлению всех используемых переменных и модулей, мощному механизму обработки исключений Ада даёт возможность (можно даже сказать, навязывает) писать максимально надёжные программы. Нельзя сказать, что средства для работы с исключениями отсутствуют в С++, а Паскаль — язык с нестрогой типизацией. Однако почему-то Ада сокращает время отладки программ на 60 %, увеличивая при этом среднее время написания проекта всего лишь на 10 %. Думаю, посчитать чистую разницу несложно. А поскольку отладка C/C++-проектов нередко занимает до двух третей общего времени разработки, экономия получается существенная.

Традиционно Ада из-за большого числа синтаксических средств считается сложным для изучения языком. Однако и здесь всё не так просто, как кажется. Благодаря тому, что язык поддерживает очень многое (например, многопоточное программирование) прямо на языковом уровне, не приходится использовать и изучать сторонние библиотеки, работа с которыми может оказаться гораздо сложнее, чем использование стандартных синтаксических конструкций языка. В этом плане она коренным образом отличается от C/C++, где возможности самого языка по замыслу создателей минимизированы, а вся нужная функциональность отдана на откуп стандартной библиотеке функций и объектов. Это тоже не в последнюю очередь влияет на надёжность программ и удобство их тестирования. А вообще-то, лучше об этом скажет выдержка из статьи об опыте разработке проекта на Аде, опубликованной в журнале «Мир ПК» в августе 1997 года: «В качестве языка реализации компилятора ведущий программист выбрал Аду. <…> Не перечисляя всех причин, побудивших нас отказаться от использования Си, укажем главную: из-за своей „бедности“ Си вынуждает программиста придумывать различные трюки, что снижает надежность программ и повышает затраты на тестирование».

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

В Аде много интересных моментов. Например, я уже упоминал встроенную прямо в язык поддержку многопоточности разрабатываемых приложений. Даже, пожалуй, можно говорить о чём-то большем, чем о простой многопоточности/многозадачности. В языке реализована концепция «задач», которые могут выполняться независимо друг от друга, и, таким образом, их можно распределить не только на разные потоки в рамках одного приложения, но даже на разные процессы, и, таким образом, средствами самого языка создать распределённую систему. Конечно, язык предоставляет средства, позволяющие задачам эффективно взаимодействовать и обмениваться информацией. Пожалуй, это одна из самых мощных возможностей, встроенных создателями Ады в своё детище.

Ещё один интересный, чисто языковой момент — реализация раздельной компиляции в Аде. Основана она на идеологии так называемых «пакетов», которые похожи на unit'ы из Паскаля. Только здесь пакет разделяется на два файла: в одном описывается спецификация реализованных в пакете объектов и функций (они, кстати, в Аде называются процедурами, независимо от того, возвращают ли они какое-либо значение или же нет), а во втором находится непосредственно реализация. Вот так изящно авторы языка решили извечную проблему Паскале-подобных языков, в которых размер текста модулей часто становился головной болью для программистов.

В отличие от классического