Обратите внимание – приведён пример пользы от рассмотрения языковых концепций (связывания) с математической позиции.
С другой стороны, важно понимать, что формальные преобразования специализатора в компилятор и суперкомпилятор не отражают некоторых содержательных аспектов этих понятий.
Обычно компилятор применяют ради повышения скорости работы переведенных программ по сравнению с интерпретацией. Специализатор же в общем случае может выдать остаточную программу, состоящую в сущности из интерпретатора и обращения к нему. В таком случае неоткуда ждать выигрыша в скорости. При попытках "оптимизировать" такую программу за счет раскрытия циклов и т. п. она может стать непомерно длинной. Аналогичные соображения касаются и суперкомпилятора. Тем не менее в указанном направлении получены обнадеживающие результаты для частных видов специализаторов [4,5].
Не до конца улавливается приведенными соотношениями и сущность компиляции. Она - в переводе на другой язык, на котором может оказаться вовсе невозможно или очень невыгодно писать интерпретатор исходного языка L (например, это невозможно делать на небольшой встроенной бортовой машине). А ведь в наших соотношениях все программы (кроме р) написаны на объектном языке М. Сказанное не означает, что в подобных случаях непригодна математическая позиция. Просто нужны и другие математические модели компиляции. Например, проекционная, где компилятор рассматривается как реализация проекции (отображения языка L на М), а не как специализация написанного на М интерпретатора (последнего может и не существовать).
На этом закончим обсуждение связывания как самостоятельной абстракции. Как видим, оно оказалось весьма емким, глубоким понятием, взаимодействующим со многими концепциями программирования.
3.5. Принцип цельности
Считая достаточно обоснованной самостоятельную ценность каждой из трех выделенных абстракций, продемонстрируем на их примере один весьма общий принцип проектирования, который назовем принципом цельности. Его называют также принципом концептуальной целостности.
Суть принципа цельности в том, что детали проекта в идеале должны быть следствием относительно небольшого числа базисных, ключевых решений. Другими словами, в цельном проекте большинство деталей можно предсказать, зная базисные решения. Содержательно это означает, что проект выполнен на основе цельной концепции, единого замысла, а не представляет собой нагромождение случайностей.
Покажем, как принцип цельности проявляется на трех уровнях рассмотрения программного проекта, два из которых - языковые.
Первый уровень - собственно программа. Сначала несколько совсем общих соображений. Проектирование - это сочетание абстракции и конкретизации (принимая конкретное проектировочное решение, тем самым одновременно вводят абстракции нижнего уровня, предназначенные для реализации принятого решения, - вспомните появление новых имен при проектировании пакета управление_сетью). Цельная концепция в идеале должна воплощаться согласованными абстракциями, а отсутствие таковой проявляется в их несогласованности.
Согласованность (абстракций) понимается как удобство их совместного использования для удовлетворения определяющих потребностей.
Возвратимся к трем выделенным абстракциям. Заметим, что иметь с ними дело приходится независимо от того, насколько сознательно они выделяются в технологическом цикле проектирования программ. Покажем, как принцип цельности позволяет выработать естественные критерии качества языковых конструктов.
Следующие ниже соображения носят весьма общий, почти философский характер. Это естественно, так как рассматривается один из общих принципов "философии программирования". Вместе с тем получаются вполне осязаемые критерии и оценки.
В соответствии с принципом технологичности (который справедлив не только для ЯП, но и для создаваемых с их помощью программ) выделяемые абстракции призваны обслуживать определенные технологические потребности. Проявим критерии цельности ЯП с точки зрения потребностей пошаговой детализации.
Применяя эту технологию, следует исходить из хорошо понятной постановки задачи. Однако в понятной постановке задачи компонент мало. Следовательно, они содержательные, емкие, имеющие непосредственную связь с сутью решаемой задачи. Но тогда и операнды у этих операций обладают теми же свойствами. И их связывание должно опираться на средства доступа к таким емким операциям и данным. По мере детализации операций менее емкими становятся и операнды, и средства связывания.
Итак, в процессе пошаговой детализации свойства данных, операций и связывания должны на каждом шаге быть взаимно согласованными по степени детализации.
Упражнение. Проверьте это утверждение на нашем примере с сетями. Обратите
внимание на возможность вводить содержательные понятия, не слишком беспокоясь пока о возможности их реализации средствами ЯП.
Второй уровень - средства программирования. Следовательно, чтобы обеспечить технологические потребности пошаговой детализации, языковые конструкты должны обслуживать согласование указанных свойств на каждом шаге детализации. Мы пришли к важному критерию качества языковых конструктов: в хорошем ЯП конструкты, обслуживающие определение и использование каждой из упомянутых абстракций, должны быть согласованы по степени управления детализацией.
Упражнение. Приведите примеры нарушения этого требования в известных вам ЯП.
Подсказка. В Паскале функции вырабатывают только скалярный результат – нет прямого средства сопоставить "емкой" функции согласованную по "емкости" структуру данных. Например, нельзя определить функцию все_связи. Уже упоминалось отсутствие развитых средств связывания с контекстом.
Третий уровень - средства развития. Подчеркнем важный момент. Содержательные абстракции на каждом шаге детализации зависят от решаемой задачи. Как уже говорилось, для работы в конкретных прикладных областях создаются ПОЯ. Это и есть задача, решаемая с помощью базового языка. Решать ее естественно также методом пошаговой детализации (иногда его называют методом абстрактных машин). Например, мы создали абстрактную машину, работающую с сетью. Ее команды - наши пять операций доступа к сети. При реализации этой машины используется (но не оформлена нами явно) машина удаления связей. Никлаусу Вирту принадлежит глубокая мысль о том, что истинное назначение ЯП – предоставить средства для ясного и точного определения абстрактных машин. Следовательно, в базовых языках должны быть согласованы между собой и средства развития всех трех разновидностей абстракций. Другими словами, в ЯП, претендующем на универсальность, принцип цельности в идеале призван работать при проектировании как базиса ЯП, так и средств его развития.
Упражнение. Приведите примеры нарушения этого требования в известных вам ЯП.
Подсказка. Проще всего это сделать по отношению к связыванию - в традиционных ЯП этот аппарат развит слабо. Легко ли, например, на Паскале определить ПОЯ, в котором возможно раздельно определять заголовки и тела процедур, а связывать их но мере необходимости?
Итак, несмотря на свой весьма абстрактный характер (скорее, благодаря ему), принцип цельности, обнаруживает "точки роста" ЯП, намечает тенденции их развития: в частности, от языков (готовых) программ к языкам собственно программирования, позволяющим с исчерпывающей полнотой управлять связыванием компонент программы [3].
3.5.1. Принцип цельности и нормальные алгоритмы
Принцип цельности носит неформальный, почти эстетический характер. Способность оценивать уровень цельности языков и программ приходит только с опытом. Чтобы лучше прочувствовать этот принцип, попробуем оценить на его основе язык нормальных алгоритмов - модель Маркова. В этой модели всякая программа представляет собой линейную последовательность однородных операций (подстановок) над линейной последовательностью однородных данных (символов). Связывание также однородно - просматривается последовательность операций и последовательность данных, конкретная операция-подстановка связывается с подходящей последовательностью данных. Затем эта операция выполняется и происходит новый цикл связывания.
Отметим очевидную согласованность всех трех абстракций. Но эта согласованность обслуживает не пошаговую детализацию, а простоту исследования свойств нормальных алгоритмов (именно к этому и стремился их изобретатель). Вместе с тем очевидно, что как основные абстракции, так и средства развития в этой модели не удовлетворяют потребностям пошаговой детализации.
Вопрос. В чем это проявляется?
Таким образом, качество ЯП не определяется критерием цельности самим по себе. Влияние этого критерия на оценку качества ЯП зависит от того, какие технологические потребности признаются определяющими.
Известный тезис нормализации утверждает, что всякий алгоритм можно заменить
эквивалентным нормальным алгоритмом. Но важно хорошо понимать смысл слова
"можно" в этом тезисе. Можно заменить, если принять абстракцию потенциальной
осуществимости, отвлечься от таких “несущественных деталей”, как необходимые для этого ресурсы. Любой, кто писал нормальные алгоритмы, прекрасно понимает, что ни одной реальной программы непосредственно в исходной модели Маркова нельзя даже написать - она практически наверняка будет неправильной и отладить ее будет невозможно в обозримое время (даже если предположить сколь угодно высокую скорость выполнения самих марковских подстановок). Ведь все выделяемые при программировании абстракции, как данных, так операций и связывания, нужно подразумевать или хранить вне программы. Поэтому единственный разумный путь к практической осуществимости программирования на языке нормальных алгоритмов – моделировать на этом языке другой, более совершенный в технологическом отношении язык.
3.5.2. Принцип цельности и Ада. Критерий цельности
Как видно на примере Ады, в более современных ЯП принцип согласования абстракций (как между собой, так и с важнейшими технологическими потребностями) осознан и учтен в гораздо большей степени. Взглянем на шаги с 3.1 по 3.7 на стр 36-39 с точки зрения потребности согласовывать абстракции.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |


