Тенденции в истории развития языков программирования.

В развитии способов и средств разработки ПО следует отметить такую тенденцию, как смещение акцентов от программирования отдельных деталей к программированию более крупных компонент [26]. Данная тенденция проявляется в переходе от языков, указывающих компьютеру, что делать (императивные языки), к языкам, описывающим ключевые абстракции проблемной области (декларативные языки). И в каждом следующем поколении ЯВУ менялись и поддерживаемые этими языками данные механизмы абстракции.

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

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

На рисунке 2.7. показана топология, типичная для большинства языков первого поколения и первой стадии второго поколения.

Рис. 2. 7. Топология языков первого и начала второго поколения

Топология - это основные элементы языка программирования и их взаимодействие.

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

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

В языках позднего второго и раннего третьего поколения использование подпрограмм как механизма абстрагирования имело уже три существенных последствия:

во-первых, были разработаны языки, поддерживавшие разнообразные механизмы передачи параметров;

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

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

Архитектура языков программирования этого периода (рис. 2.8.), схожа с архитектурой предыдущего поколения [25]. Однако в нее внесены усовершенствования, направленные на усиление управления алгоритмическими абстракциями.

Рис. 2.8. Топология языков позднего второго и раннего третьего поколения

В топологии языков конца третьего поколения начал развиваться новый важный механизм структурирования. Разрастание программных проектов означало увеличение размеров и коллективов программистов, а, следовательно, необходимость независимой разработки отдельных частей проекта. Ответом на эту потребность стал отдельно компилируемый модуль, который сначала был просто более или менее случайным набором данных и подпрограмм (рис. 2.9.), где собирали подпрограммы, которые планировалось изменять совместно [25].

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

Рис. 2.9. Топологии языков конца третьего поколения

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