Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Языки программирования. Концепции и принципы
.pdf
Заключительные замечания
441
левой, национальный или международный стандарт; в других случаях опреде
ление ЯП может иметь менее высокий официальный статус). К авторскому опре
делению предъявляются исключительно высокие требования. Их серьезное
обсуждение выходит за рамки книги. Но одно из таких требований стоит сфор
мулировать.
Авторское определение в идеале должно исчерпывающим образом фикси
ровать синтаксис и семантику ЯП. Другими словами, оно должно быть способно
служить единственным источником сведений о допустимых языковых конструк
тах и их смысле. Поэтому можно ожидать (и опыт уверенно подтверждает), что
авторское определение непригодно в качестве методического материала (а тем
более учебника) по созданию программ на этом языке. Точно, понятно и полно
описать ЯП – столь непростая задача, что не стоит ее усложнять погоней за двумя
зайцами.
Рассмотрим требования к реализации с точки зрения последовательных эта
пов ЖЦКПП.
Реализация с точки зрения этапа проектирования программы. Чтобы обеспе
чить эксплуатацию ЯП на этапе проектирования программы, требуется скорее
методический материал, чем авторское определение. Нужда в нем особенно оче
видна в случае базового языка индустриального программирования, ориентиро
ванного на массовое применение. Недаром в случае с Адой первые учебники по
явились практически одновременно с официальным определением языка (среди
них – уже упоминавшийся учебник Вегнера [18]). Так что первая важнейшая ком
понента реализации, необходимая в особенности при проектировании прог
раммы, – это методическое руководство (учебник) по программированию на рас
сматриваемом ЯП. Конечно, учебником не исчерпываются все потребности этапа
проектирования, которые призвана удовлетворять квалифицированная реализация.
В последние годы появились, в частности, программные средства, поддерживаю
щие пошаговую детализацию, проверку правильности, создание тестов, управле
ние проектом и другие элементы проектирования.
Реализация с точки зрения этапа эксплуатации. Сразу ясно, что здесь не обой5
тись без исполнителя соответствующего ЯП. Причем не абстрактного, а вполне
конкретного, материального, обладающего достаточными физическими ресурса
ми и приемлемыми характеристиками эффективности. Как известно, в настоящее
время исполнители для ЯП представляют собой комплекс аппаратуры и про
граммных продуктов, называемых трансляторами. Будем считать, что создание
аппаратуры выходит за рамки задач, связанных с реализацией конкретного ЯП
(хотя имеется тенденция к изменению этого положения). Тогда в качестве второй
важнейшей компоненты реализации выделим транслятор – без него невозможно
обеспечить этап эксплуатации программы. Ясно, что все потребности и этого эта
па не исчерпываются транслятором.
В частности, нужна операционная система, обеспечивающая нормальное функ
ционирование аппаратуры, нужен резидент, обеспечивающий нормальное выпол
нение целевой программы, и т. п.
442
Реализация с точки зрения этапа сопровождения. Анализируя этап сопро
вождения, обратим внимание на основную технологическую потребность этого
этапа – корректировать программу с минимальным риском внести ошибки. Чита
тель, конечно, знаком со средствами редактирования текстов (редакторами), по
зволяющими вносить изменения в исходные программы. Риск ошибиться умень
шается, если редактор «знает» ЯП и позволяет вносить исправления в терминах
ЯП: например, такому языковому редактору можно дать задание «в процедуре Р
заменить формальный параметр А на В».
Сравните указание обычному редактору «заменить А на В» и соответствую
щий риск заменить «не то» А. Итак, третьей важнейшей компонентой квалифици
рованной реализации служит языковый редактор.
Совсем хорошо было бы вносить исправления не в терминах ЯП, а в терминах ре
шаемой задачи (тогда редактор должен был бы «знать» и ЯП, и ПО, и задачу), но
это – дело будущего.
Итак, беглого взгляда на три этапа жизненного цикла программы хватило для
выделения трех важнейших компонент реализации ЯП: учебника, транслятора и
редактора.
Другие компоненты реализации. Ограничимся только компонентами, непос
редственно связанными с ЯП, считая, что реализация погружена в некоторую
многоязыковую систему программирования, предоставляющую необходимые об
щесистемные услуги, если они не определены в ЯП (базу данных, связь с другими
языками, фонды готовых программ, документов и т. п.).
Укажем этапы жизненного цикла, где применение названных компонент осо
бенно целесообразно (хотя очевидно, что они полезны и для других этапов, в том
числе и выпавших из нашего рассмотрения).
Этап проектирования – процессоры, помогающие готовить тексты исходных
программ. Примерами могут служить уже упомянутые препроцессоры, поддер
живающие метод пошаговой детализации программ, «знающие» определенный
ЯП. Они в состоянии воспринять запись шагов детализации и выдать текст закон
ченной (или еще не законченной) программы, попутно контролируя его правиль
ность (в диалоговом режиме, если нужно). Полезны процессоры, позволяющие
писать на структурных расширениях Фортрана, Кобола, ПЛ/1 и других «заслу
женных» ЯП. Еще один класс компонент реализации – отладчики.
Этап эксплуатации – средства контроля и измерений как программ, так и
трансляторов. Это комплект тестов, проверяющих соответствие исполнителя оп
ределению языка, оптимизаторы и конкретизаторы, настраивающие программы
на конкретные условия эксплуатации.
Этап сопровождения – уже упоминавшиеся измерительные средства; средства
для отслеживания и контроля изменений (версий); контролеры программ, прове
ряющие соответствие стандартам (это особенно важно для переноса программ в
другую среду) или выявляющие особо ресурсоемкие места.
Кроме того, следует понимать, что развитая реализация может содержать
учебники для различных категорий пользователей и программных сред, транс
Перспективы языков программирования
Заключительные замечания
ляторы с различными предпочтительными режимами эксплуатации (особо быст
рый, особо надежный, особо оптимизирующий), для различных компьютеров
или программных сред, языковые редакторы с различными уровнями «интел
лекта» и т. п.
Итак, будем считать достаточно обоснованным следующий тезис: квалифици5
рованная реализация ЯП – дело сложное, дорогое, длительное и многоплановое (для
«живого» ЯП – даже не ограниченное по времени). От качества реализации в этом
широком смысле слова зависят «потребительские свойства» ЯП. Реализация –
один из наиболее очевидных аспектов, переводящих понятие «язык программи
рования» из категории научнотехнической в социальную.
Дополнительную яркую социальную окраску этому понятию придают пользовате
ли ЯП, иногда официально объединенные в ассоциации. Так что ЯП, тем более
базовый язык индустриального программирования в наше время – явление соци
альное и именно такого подхода к себе требует.
На этом закончим разговор о реализации в целом. Сконцентрируем внимание
на более традиционной ее части – трансляторах, точнее компиляторах.
443
8.1.2. Компиляторы
Компилятором называется программный продукт, предназначенный для перево
да с исходного ЯП на целевой (объектный) язык (обычно – язык загрузки или
иной язык, близкий к машинному).
Если для целевого ЯП исполнитель имеется, то компилятор дает возможность
выполнять исходные программы в два этапа. На первом этапе – этапе компиля
ции (трансляции) – исходная программа переводится компилятором на целевой
язык; на втором – этапе исполнения – исполнителем целевого ЯП выполняется
переведенная (целевая) программа.
Современные языки индустриального программирования ориентируются
прежде всего на технологические потребности пользователей и поэтому довольно
сильно отличаются от наиболее распространенных машинных языков. Вместе
с тем, как мы видели, в них многое сделано для того, чтобы можно было позабо
титься о надежности и эффективности целевых программ еще на этапе компиля
ции (вспомните квазистатический аппарат прогнозированияконтроля). По этим
двум причинам компиляторы (а не, например, интерпретаторы) служат обяза
тельными компонентами реализации практически всех языков индустриального
программирования.
Мы не стремимся дать исчерпывающее определение компилятора. Дело в том,
что это понятие – скорее инженерное, чем математическое. Во всяком случае, хо
роший компилятор должен не только «переводить», но и сообщать об ошибках,
и накапливать статистические сведения об обработанных программах, и оптими
зировать свою работу с учетом особенностей потока программ. Возможны и иные
требования (гибкое управление свойствами целевой программы, трассировкой,
печатью листинга, диагностическими режимами и прочее).
444
Создать компилятор – дело очень непростое. Высококачественный компиля
тор с современного ЯП требует нескольких лет работы и может содержать сотни
тысяч команд. При этом не случайно не названо количество требуемых специали
стов. Несколько лет нужно независимо от того, можно ли выделить на это 10 или
200 человек. Близкая к оптимальной – группа из 5–15 человек.
Увеличение группы только удлинит сроки или приведет к полному краху (за
кон Брукса [40]), если не удастся найти для новых людей совершенно независи
мой работы (такой, например, как создание комплекта тестов, проверяющих каче
ство компилятора).
Технологии создания компиляторов посвящена огромная литература. Выде
лены важнейшие технологические этапы, основные компоненты компилятора,
предложены многочисленные методы реализации отдельных компонент, имеют
ся автоматизированные системы, предназначенные для создания компиляторов.
Их успешно применяют в относительно простых случаях, когда сами переводы
не слишком сложны и к ресурсоемкости компиляторов не предъявляют жестких
требований. В таких условиях дватри специалиста с помощью соответствующей
инструментальной системы могут изготовить компилятор примерно за месяц ин
тенсивной работы.
Однако ЯП развиваются, требования к качеству реализации повышаются, воз
можности аппаратуры растут. В результате разработка компиляторов для языков
индустриального программирования продолжает требовать значительных твор
ческих усилий (правда, теперь чаще приходится не столько изобретать методы
компиляции, сколько квалифицированно выбирать из имеющегося арсенала).
Полноценные учебники по созданию компиляторов еще ждут своих авторов.
Много интересного и полезного на эту тему можно найти в книгах [41, 42].
Перспективы языков программирования
8.1.3. Основная функция компилятора
Рассмотрим лишь одну, выделяемую традиционно, функцию компилятора –
строить целевую программу. Выделяется она потому, что лучше других отражает
специфику компилятора и соответствует его основному назначению. Однако и
остальные функции компилятора в определенных условиях могут оказаться ис
ключительно важными. Например, для студентов важнейшей может оказаться
диагностическая функция, то есть способность компилятора помогать отлажи
вать программу.
Итак, будем считать, что основная задача компилятора – перевести программу
с исходного языка на целевой.
Обозначим через LL1 исходный язык, а через LL2 – целевой язык для плани
руемого компилятора. Пусть L1 – множество текстов, допустимых в LL1 (то есть
определяемых синтаксисом LL1), а L2 – множество текстов, допустимых в LL2.
Переводом (проекцией) с языка LL1 на язык LL2 называется отношение р из
L1 в L2, то есть подмножество декартова произведения L1 * L2.
Легко догадаться, что всякий компилятор характеризуется единственной про
екцией (обратное неверно!). Этой проекции принадлежат те и только те пары
Заключительные замечания
(t1 , t2),
где t1 – из Ll, t2 – из L2, для которых t2 может быть получен в результате приме
нения компилятора к t1.
Данное выше определение проекции в виде отношения подчеркивает факт, что
компилятор может переводить не все тексты из L1 (например, для слишком длин
ных текстов может не хватить ресурсов), переводить различные тексты в один
(например, если они обозначают одно и то же), переводить один и тот же текст по
разному (например, в зависимости от режима трансляции – с оптимизацией или
без нее).
Данное определение проекции выглядит совершенно симметричным относительно
языков LL1 и LL2, хотя они содержательно играют различные роли. Чтобы подчерк
нуть эти роли, иногда говорят, что проекция – частичное многозначное отображение
р : L1 > L2.
445
8.1.4. Три принципа создания компиляторов
Небольшой опыт по созданию компилятора у нас уже есть. В модели МТ мы прак
тиковались в создании компилятора с языка обычных (инфиксных) выражений в
польскую инверсную запись (в язык постфиксных выражений). Наш компилятор
представлял собой программу из четырех предложений:
{ el + å2 } R -> { el } { å2 } +.
{ el * å2 } R -> { el } { å2 } *.
{ ( å ) } -> { å }.
{å}->å.
Проекция р, соответствующая этому компилятору, должна удовлетворять оп
ределяющему соотношению
p(F1 op F2) = p(F1) p(F2) op,
где F1, F2 – правильные инфиксные формулы, op – операция.
Уже на примере такого простого компилятора можно продемонстрировать три
важных положения.
Начнем с того, что созданию компилятора должна предшествовать разработка
связанной с ним проекции. Это не обязательно означает, что проекция полностью
фиксируется до начала программирования компилятора. Но, во всяком случае, ее
замысел предшествует разработке соответствующего алгоритма перевода и
последовательно уточняется, определяя всю разработку компилятора. Например,
четыре предложения нашего компилятора не могли бы быть написаны, если бы
мы фактически не «держали в голове» приведенное определяющее соотношение
для проекции.
Проекционный принцип. Указанные выше соображения можно оформить
в виде проекционного принципа [43]: создание компилятора можно разбить на
два технологически независимых этапа – Пэтап, или этап разработки проекции,
и Аэтап, или этап алгоритмизации проекции. Полученное на Пэтапе описание
проекции (например, в виде системы определяющих соотношений) может слу
446
жить техническим заданием (спецификацией) для работы на Аэтапе. Опыт пока
зывает, что в некоторых практически важных случаях Аэтап удается полностью
автоматизировать. Делаются попытки частично автоматизировать и Пэтап. Это
удается за счет предварительного формального описания как исходного, так и це
левого языка сходным образом на одном и том же метаязыке. В отличие от БНФ,
такой метаязык должен позволять описывать не только синтаксис, но и семантику
ЯП. В сущности, при этом приходится создавать проекцию описываемого ЯП на
метаязык. Так что Пэтап всегда носит творческий характер.
К реальным языкам индустриального программирования автоматизация
Пэтапа пока неприменима изза непрактичности метаязыков и соответствующих
систем построения трансляторов (СПТ).
Принцип вспомогательных переводов. Когда проекция достаточно прорабо
тана и можно приступать к ее алгоритмизации, полезно выделить две фазы ком
пиляции – фазу анализа и фазу синтеза. В нашем примере мы воплощали первую
фазу левой частью МТпредложения, вторую – правой.
При этом результаты первой фазы представляются на некотором промежуточ
ном языке, так что и анализ, и синтез иногда оказывается полезным, в свою оче
редь, считать трансляцией (соответственно, с исходного языка на промежуточ
ный и с промежуточного на целевой). С другой стороны, в отличие от исходного и
целевого ЯП, язык МТ выступает в нашем компиляторе в роли еще одного
вспомогательного ЯП (инструментального ЯП, то есть языка, на котором написан
компилятор).
Сказанное подчеркивает рекурсивную природу трансляции и может быть вы
делено как принцип вспомогательных переводов: транслятор можно построить
из трансляторов для вспомогательных языков. Это наблюдение широко использу
ется в различных методах и приемах создания трансляторов. Тройственную связь
исходного, целевого и инструментального ЯП удобно изображать Тобразной ди
аграммой
Перспективы языков программирования
L1 L2
С ее помощью легко описываются довольно сложные процессы, связанные
с жизненным циклом компилятора (в частности, так называемая раскрутка, ак
тивно использующая вспомогательные переводы и применяемая при переносе
компиляторов в новую программную среду).
Принцип синтаксического управления (структурной индукции). Анализ и син
тез далеко не всегда удается столь четко сопоставить некоторому определенному
конструкту инструментального ЯП, как это сделано в нашем простом примере.
>
I
Заключительные замечания
Дело в том, что в языке МТ непосредственными составляющими при анализе
выражения могут быть только выражения, термы и символы. При компиляции
с более сложных исходных ЯП приходится переводить операторы, объявления,
области действия и т. п. Анализ исходного текста и синтез соответствующего це
левого не удается представить в этих случаях одним предложением. И для анали
за, и для синтеза пишут специальные подпрограммы.
В первых компиляторах взаимодействие таких подпрограмм было довольно
запутанным. Но уже в начале 60х годов Айронсом был предложен принцип упо
рядочивания этого взаимодействия на основе иерархической структуры исход
ных текстов. Структура эта задается синтаксисом исходного языка, поэтому сам
принцип получил название принципа синтаксического управления трансляцией
(компиляцией, в частности).
В синтаксически управляемых компиляторах синтаксическим категориям ис
ходного языка ставятся в соответствие так называемые семантические действия.
Онито и синтезируют целевой текст в процессе так называемой структурной ин
дукции.
В этом процессе семантические действия, соответствующие определенным
синтаксическим категориям, используют результаты семантических действий,
соответствующих непосредственным компонентам этих категорий. Структура, по
которой ведется индукция, строится в процессе анализа (декомпозиции) исход
ного текста в соответствии с определением исходного ЯП.
Принцип синтаксического управления и структурную индукцию можно в пер
вом приближении понять на примере нашего компилятора для перевода выра
жений.
При этом левые части МТпредложений выполняют декомпозицию (выделяя
сумму, произведение, скобочную первичную формулу), а правые части – струк
турную индукцию, пользуясь уже готовыми переводами компонент соответству
ющих синтаксических категорий.
В нашем компиляторе анализ и синтез чередуются (компилятор однопроход
ный). Но можно сначала полностью проанализировать исходный текст, получив
в результате его структуру (обычно в виде синтаксического дерева – это вариант
промежуточного языка), а затем (на втором проходе) выполнить структурную
индукцию. Иногда применяют и большее число проходов (обычно при ограниче
ниях на память для размещения компилятора или при необходимости опти
мизировать программу).
Итак, мы выделили один из принципов, позволяющий структурировать про
цесс создания транслятора, – проекционный принцип; один из принципов, позво
ляющих структурировать сам компилятор, – принцип вспомогательных переводов,
и один из принципов, позволяющих структурировать синтез, – принцип синтак5
сического управления (несколько упрощая, можно отождествить его с принципом
структурной индукции).
Отметим, что термин «структурная индукция» обозначает также один из способов
доказательства свойств структурированных объектов.
447
448
Подчеркнем, что сам ЯП несравненно стабильнее (консервативнее), чем аппара
тура и методика реализации. С другой стороны, последняя авторская реализация
Модулы2 выполнена оправдавшими себя методами двадцатилетней давности –
еще одно подтверждение принципа чайника. В сущности, лишь вопрос о возмож5
ности или невозможности реализации в современных условиях кардинально влияет
на грамотно проектируемый ЯП. В остальном влияние реализаторской позиции
обычно преувеличивают.
Перспективы языков программирования
8.2. Классификация языков
программирования
8.2.1. Традиционная классификация
Изучение ЯП часто начинают с их классификации. Различают ЯП низкого, высо
кого и сверхвысокого уровней; процедурные и непроцедурные, диалоговые и па
кетные; вычислительной, коммерческой, символьной ориентации; выделяют ЯП
системного программирования, реального времени, «параллельные» ЯП; даже
классические, новые и новейшие.
Определяющие факторы классификации обычно жестко не фиксируются.
Чтобы создать у читателя представление о характере типичной классификации,
опишем наиболее часто применяемые факторы, дадим им условные названия и
приведем примеры соответствующих ЯП.
Выделяют следующие факторы:
Уровень ЯП – обычно характеризует степень близости ЯП к архитектуре ком
пьютера. Так, автокод (ассемблер) относят к ЯП низкого уровня; Фортран, Пас
каль, Аду называют ЯП высокого уровня; Язык Сетл [44], созданный известным
математиком Дж. Шварцем, служит примером ЯП «очень высокого уровня»
(иногда говорят сверхвысокого уровня) – его базис составляют теоретикомно
жественные операции, далекие от традиционной архитектуры компьютеров.
Встречаются и другие толкования уровня ЯП – это довольно расплывчатое, одна
ко часто используемое понятие.
В «Науке о программах» Холстеда [45] сделана интересная попытка придать
этому понятию точный смысл. Уровень ЯП, по Холстеду, определяется отличием
программы на этом ЯП от простого вызова процедуры, решающей поставленную
задачу. Выводится формула, численно выражающая уровень ЯП. Ясно, что в та
кой трактовке уровень ЯП непосредственно связан с классом решаемых задач –
один и тот же ЯП для разных классов задач имеет разный уровень (что в целом
согласуется с интуитивным понятием об уровне ЯП).
Специализация ЯП характеризует потенциальную или реальную область его
применения. Различают ЯП общего назначения (или универсальные) и ЯП с бо
лее определенной специализацией. Классическими примерами универсального
ЯП могут служить язык ассемблера ЕС или ПЛ/1. В свое время на эту роль пре
тендовали Алгол60, Симула67, Алгол68. Реально ее играют также Фортран,
Заключительные замечания
в частности его стандарты – Фортран66 (ГОСТ) и Фортран77 (стандарт ИСО),
Бейсик (в особенности его развитые модификации), Паскаль (в особенности диа
лекты, допускающие раздельную трансляцию), менее известные у нас такие ЯП,
как Корал (стандарт МО Великобритании), Джовиал (стандарт ВВС США),
а также отечественный Эль76.
Более выраженную специализацию обычно приписывают таким ЯП, как Ко
бол (коммерческая); Рефал, Снобол, Лисп (символьная); Модула, Ада (реальное
время). В Алголе60 и Фортране также можно усмотреть специализацию (науч
ные и инженерные расчеты).
Все названные ЯП в той или иной степени можно отнести к базовым ЯП широ
кого назначения. Обычно на их основе (или без них) строят более специализиро
ванные ПОЯ.
Алгоритмичность (процедурность) – характеризует возможность абстрагиро
ваться от деталей (алгоритма) решения задачи. Другими словами, алгоритмичность
тем выше, чем точнее приходится планировать выполняемые действия и их поря
док (или синхронизацию); она тем ниже, чем более язык позволяет формулировать
соотношения и цели, характеризующие ПО и решаемую задачу, оставляя поиск
конкретного способа решения (способа достижения целей) за исполнителем.
Типичные примеры алгоритмического (процедурного) языка – ассемблер,
Фортран, Ада; неалгоритмического (непроцедурного) языка – Пролог. Рефал за
нимает промежуточное положение – хотя мы рассматриваем его как естественное
развитие марковских алгоритмов, многие воспринимают Рефалпредложения
(особенно с мощными спецификаторами) как соотношения, удобные для непос
редственного представления знаний о предметных областях, а поиск подходяще
го Рефалпредложения – как автоматический выбор подходящего способа реше
ния задачи.
Динамизм (диалоговость, интерактивность) – характеризует степень измен
чивости программных объектов в процессе выполнения программы. Частично мы
обсуждали этот вопрос, когда занимались статическими, квазистатическими и
динамическими характеристиками объектов. С этой точки зрения различаются
статические, квазистатические и динамические ЯП.
Разделяют языки также по степени изменчивости текста программы. Один
крайний случай – текст программы в процессе ее работы менять нельзя. Этот слу
чай представлен «пакетными» языками (Фортран, Паскаль, Ада, Модула2 и т. д.).
Другой крайний случай – программист волен изменить программу на любом эта
пе ее исполнения. Этот случай представлен «диалоговыми» языками (Бейсик,
Апл и более современными Визикалк, Лого и др.). Промежуточный вариант –
программу в процессе ее исполнения может изменять лишь сама программа (но не
программист). Это крайний случай пакетного динамизма (представлен языками
Лисп, Инф и др.).
Связь концепции диалога с общей концепцией ЯП заслуживает дополнитель
ного анализа. Суть – в том, что концепция ЯП как средства планирования поведе5
ния исполнителя в чистом виде не обязана предполагать диалога (создатель про
граммы вполне может отсутствовать в период ее исполнения – и это типичный
449
450
для ЯП случай, тем более для ЯП индустриального программирования). Другими
словами, концепция ЯП в общем случае не предполагает обратной связи исполни
теля с создателем программы в процессе ее рабочего исполнения.
Концепция диалога обязана предполагать такую связь и поэтому в общем слу
чае требует специфических выразительных средств, отличающихся от средств
планирования (краткостью, менее жестким контролем, ориентацией на интерпре
тацию, использованием разнообразных органов чувств (слуха, зрения, осязания,
двигательных навыков) и т. п.). Так что управление диалогом – ортогональный
срез в системе средств общения с компьютером.
Перспективы языков программирования
8.2.2. Недостатки традиционной
классификации
Удовлетворительной классификации живых ЯП не существует. Тот или иной яр
лык, присваиваемый ЯП в программистском фольклоре или литературе, в луч
шем случае отражает лишь некоторые его характерные свойства. К тому же с раз
витием самого ЯП, сферы его применения, контингента пользователей, методов
программирования, критериев качества программ и т. п. относительное положе
ние ЯП, его оценка могут существенно измениться.
Например, Фортран начинался как язык высокого уровня для научнотехни
ческих расчетов. Однако его первый международный стандарт (ему соответствует
отечественный ГОСТ 23056–78) выделяется уже не столько особой пригоднос
тью для создания расчетных программ, сколько возможностью создавать мобиль
ные (легко переносимые из одной среды в другую) программы практически
произвольного назначения. Так что если хотите, чтобы ваша программа работала
на любой машине и практически в любой операционной среде, пишите ее на стан
дарте Фортрана, руководствуясь правилами, изложенными, например, в [46].
Аналогична судьба и других классических языков. Их современная оценка за
висит скорее не от технических характеристик, а от социальных (распространен
ность и качество реализаций, наличие устойчивого контингента пользователей
в определенной области знаний, объем парка эксплуатируемых программ и т. п.).
Так, Бейсик и Паскаль, появившись как учебные ЯП с весьма ограниченной
областью серьезных применений, стали, подобно Фортрану, практически универ
сальными ЯП на персональных компьютерах (еще одно подтверждение роли со
циальных факторов в судьбе ЯП – важно научить людей ими пользоваться, даль
ше действует принцип чайника).
8.2.3. Принцип инерции программной среды
К сожалению, системы программирования, поддерживающие разные ЯП, как
правило, несовместимы между собой в том смысле, что нельзя написать часть про
граммы на одном ЯП, часть – на другом или воспользоваться программой, напи
санной на другом ЯП. Если бы эта проблема модульной совместимости различ
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]