ОРЛОВСКИЙ

ГОСУДАРСТВЕННЫЙ

УНИВЕРСИТЕТ

ДЕКАДА

НАУКИ

2006

ФИЗИКО-МАТЕМАТИЧЕСКИЙ

ФАКУЛЬТЕТ

www.phys-math.ru

МАТЕРИАЛЫ СЕКЦИИ-СЕМИНАРА

Языки программирования и технологии «Оберон»:

перспективы для индустрии и образования (сокращённая версия, исправлены ссылки, 14.05.2013) 30 марта 2006 г.

ООО «ОРЛОВСКИЙ

ЦЕНТР

ПРОГРАММНОЙ

ИНЖЕНЕРИИ

«МЕТАСИСТЕМЫ»

www.metasystems.ru, blackbox.metasystems.ru, sources.metasystems.ru

СОДЕРЖАНИЕ СБОРНИКА

Программная инженерия вчера и сегодня: эволюция императивного программирования............. Критерии эффективности языков программирования. Сравнение Pascal- и C-семейства языков. Введение

Эффективность

Критерии эффективности

Сравнение Pascal- и C-семейства языков

Заключение

Литература

Язык программирования Компонентный Паскаль и среда разработки BlackBox Component Builder

I. Компонентный Паскаль – язык компонентно-ориентированного программирования.......... II. Экскурсия по языку

III. Среда разработки BlackBox Component Builder

BlackBox в образовании. Проект Информатика-21

Авторский спецкурс «Программирование и дискретная математика» в лицее №1 г. Орла.......... Проект "1C:Образование" - критический взгляд

Программная инженерия вчера и сегодня: эволюция императивного программирования Ермаков И.Е.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Ч-А. Хоар I. Обзор. Цель данной статьи краткий обзор состояния, проблем и перспектив современной программной инженерии (ПИ). Под ПИ будем понимать создание технических систем программного обеспечения (ПО). На сегодняшний день в ПИ существует несколько фундаментальных, ортогональных друг другу методологий программирования (МТП). В основе МТП лежит какая-либо модель алгоритма, абстрактная машина. Основные МТП: императивная (машина Тьюринга), функциональная (лямбда-исчисление), логическая (логика предикатов)1. Выбор МТП определяет стиль мышления, инструментарий и набор доступных разработчику приемов. Выбор диктуется особенностями задачи, но в целом можно говорить как о достаточной универсальности всех основных МТП, так и об их взаимопроникновении.

Очевидно, что наиболее распространена в индустрии императивная МТП. Однако последние 15 лет острие лабораторных исследований направлено именно на альтернативные МТП – основные надежды (часто чрезмерные) возлагаются на декларативные подходы, в частности, 4GL2, и может создаться впечатление, что в области императивных 3GL ничего нового не происходит. На самом деле это не так, что мы и постараемся показать далее. Таким образом, мы будем рассматривать современную ПИ с позиций императивной методологии.

II. Эволюция императивного программирования (ИПР). Императивный алгоритм представляется в виде последовательности команд для некоторого исполнителя, которые переводят данный исполнитель из одного состояния в другое. Выполнение алгоритма это прохождение последовательности состояний, в процессе которого решается задача вычисление, обработка данных, управление некоторым процессом3.

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

В этом развитии особую роль сыграли три ключевых нововведения: зарождение ЯВУ (50-е гг.), структурный подход (70-е гг.) и объектный подход (80-е гг.). После появления каждого из них эффективность ПИ резко возрастала, поскольку в распоряжении разработчиков оказывались некоторые новые абстракции для конструирования программного кода. В первых ЯВУ этими абстракциями стали: оператор минимальная логическая единица выполнения (абстрагирует нас от нескольких физических единиц выполнения), переменная именованная единица данных (абстрагирует от физического размещения и представления в памяти), подпрограмма – составная единица выполнения (позволяет явно выделить логически цельную последовательность операторов). Видим, что уже присутствует составная единица выполнения, однако отсутствуют составные единицы данных насущной потребности в них не было, так как на заре ИТ преобладали вычислительные задачи. Нет никаких абстракций для управления выполнением: арифметический IF4, GOTO и CALL первых ЯВУ эквивалентны соответствующим машинным командам. Построение кода на прямых передачах управления получило название «стиль спагетти» он порождал огромные трудности при написании больших программ, зачастую делал невозможным их сопровождение и развитие. Низкая производительность программистов и крайне низкая надежность ПО привели к первому кризису программирования (60-е Есть и некоторые другие, например, автоматная. См. [3].

4th Generation Programming Languages – «языки 4-го поколения», позволяют пользователю описывать (в т.ч. графически) требуемый результат без программирования алгоритма для его достижения.

3GL – «языки 3-го поколения» - классические универсальные языки программирования.

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

Арифметический IF передавал управление по одной из 3-х возможных веток в зависимости от значения числового параметра: x < 0, x=0, x>0.

гг.). Очередным прорывом явились идеи структурного программирования (СП), провозглашенные Э. Дейкстрой, Н. Виртом и Ч. Хоаром (70-е гг.)1.

Основные принципы СП: декомпозиция – разбиение решаемой задачи на набор подзадач, их независимая реализация и затем организация взаимодействия; блочность – организация кода в виде отдельных блоков для каждой подзадачи, каждый блок – это подпрограмма (процедура) с одним входом и одним выходом, минимальное использование глобальных переменных сокрытие данных внутри процедур; структурная организация кода отказ от GOTO, использование для управления выполнением исключительно составных операторов. СП вводит абстракцию для управления выполнением – составной оператор. Вводятся три составных оператора: последовательный, выбора, повторения. Любой алгоритм может быть записан в терминах этих и только этих операторов. В этом случае любой блок кода имеет ровно один вход и один выход. Можно определить предусловия/постусловия, истинность которых ожидается на входе/выходе, и инварианты – условия, которые истинны на протяжении выполнения данного блока. Это дает возможность математически доказывать правильность алгоритмов. Такое доказательство трудоемко и не всегда оправдано, но его облегченный вариант постоянно выполняется опытным программистом в уме, и это позволяет строить действительно надежные программы.

Еще одним китом СП становятся структуры данных. Как мы уже отмечали выше, ранее в ЯВУ отсутствовали составные единицы данных, однако к концу 60-х специфика разнообразных при- предметная техническое П Программная система в СП представляется как наархитектура III. Модульное ПО. В конструировании лю- компиляция [статическая компоновка] Р ности: система разрабатывается и собирается из на- программная СИСТЕМА Э ствуют друг с другом только через небольшое коли- распространение развертывание П зывается интерфейсом модуля) по строго опреде- загрузка [динамическая компоновка] А чает эксплуатацию и обслуживание техники, так как модули разных производителей, даже различающиеся по своему внутреннему исполнению, будут взаимозаменяемы (самый яркий пример – архитектура IBM PC). Другая сторона модульности – это инкапсуляция, представление модулей «черными ящиками», обладающими опреЭти идеи были реализованы сначала в Алголе (1968 г.), а затем в завоевавшем всемирное признание Паскале Н.Вирта (1970 г.).Появившийся в то же время «высокоуровневый ассемблер» С в основных аспектах также ориентирован на структурный стиль программирования.

Н. Вирт: «Исключительного использование сильно типизированного языка является фактором, в наибольшей степени определяющим возможность проектирования сложной системы в короткий срок». Идеально сбалансирован ный структурный язык – Модула-2 (Вирт), наследница Паскаля (активно используется в российских военно-кос мических проектах). Богатейший набор типов предоставляет язык Ада (стандарт военной отрасли США). Оба языка сильно типизированы. Линейка С-образных языков придерживается обратного подхода – «все, что не запрещено, то разрешено», что приводит к низкому качеству и большим затратам на отладку – тестирование – сопровожде ние программных систем.

деленным интерфейсом и поведением, но полностью скрывающими свое внутреннее устройство от доступа извне.

Этапы жизненного цикла ПО изобразим следующим образом (см. рис.) 1. На этапе анализа выделяются сущности ПрО, которые формулируются в типах данных (ТД) ЯВУ (если информация о внутреннем устройстве ТД скрывается внутри модуля, то он называется абстрактным ТД). Процессы обработки данных ПрО формулируются в терминах процедур ЯВУ. На этапе проектирования принимается решение об архитектуре, выделяется набор модулей, описываются их интерфейсы и протоколы взаимодействия. На основе полученных абстракций и архитектуры выполняется непосредственно программирование.

Неоспоримым преимуществом является возможность проектировать и реализовывать систему в терминах одного и того же языка. Современный ЯВУ должен позволять непосредственно выражать архитектурные решения. Именно этот критерий в настоящее время является главным, т.к. в плане «программирования в малом» все современные императивные ЯВУ приблизительно одинаковы. Эталоном модульного языка стала Модула-2 (1980). В ней модуль является единицей ПО во всех отношениях – единицей написания кода, инкапсуляции, компиляции, импорта другими модулями. В языке Ада модули носят название пакетов. В С-семействе (включая С#) в принципе нет единой абстракции модуля 2. В совокупности с трудночитаемым синтаксисом это затрудняет проектирование в терминах ЯВУ. Вводятся дополнительные нотации проектирования, например, Буча или UML, однако переход от одного представления к другому отнимает время и вносит ошибки3; контроль соответствия кода архитектуре нельзя переложить на компилятор.

В то же время удачность единой абстракции модуля позволила Вирту в языке Оберон- (1989) и одноименной ОС сделать прорыв в новое измерение – к компонентному программированию (КП). Модуль становится единицей не только разработки, но и распространения, развертывания и загрузки в память, двоичным кирпичиком как ПО, так и ОС в целом. Фаза статической компоновки модулей была исключена, Модули динамически загружаются, связываются, выгружаются, заменяются в любой момент прямо во время работы ПО. Механизм метапрограммирования позволяет выполнять динамический анализ модулей и работать с типами, переменными, процедурами, неизвестными на этапе компиляции. Для КП обязательна строгая типизация, динамический контроль типов и границ массивов, сборщик мусора – в противном случае организовать надежное взаимодействие многих модулей от разных производителей просто невозможно4. На основе идей Оберона была создана Java (1994). Сегодня мы имеем три промышленных компонентных языка: Java, Компонентный Паскаль (Оберон-2) и C#.

IV. Модульность + ООП: Оберон-парадигма. Суть объектно-ориентированного (ОО) подхода – в рассмотрении ПрО как множества взаимодействующих объектов. Объект обладает состоянием (полями) и поведением (методами). Класс множество объектов со сходной структурой и поведением. Чистые ОО-языки (Smalltalk) не предоставляют никаких абстракций кроме классов и объектов («все есть объект»). Однако многие механизмы ПО лучше выражаются в процедурном, нежели в ОО-стиле. Общепринятый подход надстройка структурных ЯВУ абстракциями класса, объекта и метода. Но (по мнению Вирта) в ООП нет почти ничего нового по сравнению со СП, кроме названий, вносящих путаницу: класс = тип данных, объект = запись, метод = процедура. Модула-2 позволяет писать программы в «почти ОО» стиле. Единственно новое в ООП – это наследование, которое Вирт называет расширением типа. В Обероне- ООП реализовано на основе расширяемых записей, полиморфизм процедур – на основе динамической проверки типа (x IS SomeType), виртуальные методы – на основе полей процедурного типа (это позволяет каждому экземпляру типа иметь особое поведение). В Обероне-2 добавлены связанные процедуры, которые позволяют оформлять код в привычном стиле ООП (object.Отметим, что схема отражает техническую сторону процесса ПИ, но не организационную – организационно выделенные этапы обычно проходят не последовательно, а одновременно и/или циклически.

В С++ пространства имен являются всего лишь логической единицей, единицей написания – текстовые файлы, единицей компиляции и импорта – объектные файлы (сборки в.NET), единицей инкапсуляции – классы. Это порождает путаницу и не позволяет разделить систему на полностью непересекающиеся части.

Б. Мейер: «От модели UML до реального программирования дистанция огромного размера». Н. Вирт: «Это даже шаг назад - на заре программирования было принято записывать программы в виде графов. Такая схема приводит к слишком большому количеству ошибок, как только программа усложняется».

Новейший процессор Эльбрус e2k (разработан в России), благодаря использованию аппарата тегов, поддерживает в полной мере защищенное программирование (для модулей единого адресного пространства).

Do). Аналогично вводится ООП в Ада-95. При таком подходе идеология и синтаксис языка становятся гораздо проще, стройнее и логичней. К тому же в языках типа С++ из-за отсутствия модулей на класс возлагается двойная нагрузка – он становится и ТД, и единицей инкапсуляции, «модулем» ПО. Однако модуль и ТД – принципиально различные вещи. ТД – это абстракция ПрО, модуль – элемент архитектуры ПО. Для системного ПО типичны группы классов, которые должны взаимодействовать напрямую в обход инкапсуляции. Модульность дает элегантное решение проблемы под некоторую группу тесно связанных ТД выделяется один «кукловод»модуль, который инкапсулирует их поведение и взаимодействие, при этом внутри модуля нет сокрытия информации между типами 1. Оберон-парадигма гармонично сочетает ООП, структурный стиль и модульность: ПО строится как набор модулей, связанных процедурными шинами, по которым передаются объектно-ориентированные данные.

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

Огромным потенциалом идей для преодоления кризиса ПИ обладает швейцарская школа Н.

Вирта, в частности Оберон-направление.

1. http://oberon2005.ru Европейский центр программирования.

2. http://blackbox.metasystems.ru/ – русский портал по BlackBox и Оберонам.

3. Одинцов И.О. Профессиональное программирование. Системный подход 2-е изд-е, СПб.: БХВ-Петербург, 2004.

4. Szyperski С. Component Software. Beyond Object-Oriented Programming, Addison Wesley 5. Pfister C., Component Software Русский перевод: Ермаков И.Е., http://blackbox.metasystems.ru/, раздел “Статьи”.

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

Критерии эффективности языков программирования.

В настоящее время существует огромное число языков программирования (ЯП). Мы будем рассматривать в основном императивные языки, которых сейчас большинство. Одни из них разрабатывались как универсальные, предназначенные для решения широкого круга задач; другие - как специализированный инструмент для решения задач в конкретной области.

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

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

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

Цели данной статьи: во-первых, выделить основные параметры, по которым можно сравнить эффективность языков. Во-вторых, на основе этих критериев сравнить широко распространенные Pascal- и C-семейства языков.

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

Программирование – человеческая деятельность, целью которой является разработка/сопровождение программы или набора программ – программного продукта (ПП), предназначенного для решения определенных задач и обладающего заданными свойствами. Разработка – проектирование "с нуля" и реализация. Сопровождение – исправление выявленных в результате эксплуатации ПП дефектов и добавление новых функциональных возможностей в ПП с сохранением его архитектуры.

Выполнение ПП – "деятельность" компьютера, направленная на решение задачи.

Главный ресурс для выполнения ПП – машинный: время вычислений, объемы оперативной и внешней памяти и т. п. Его затраты определяются:

- способами реализации ПП (более быстрый алгоритм и т. п.);

- надежностью (при сбоях результаты работы могут быть потеряны и ее придется делать Основным ресурсом программирования можно назвать человеко-часы – время, которое понадобится программистам для реализации ПП. Его затраты определяются такими параметрами, как:

- квалификация программистов;

- требования, предъявляемые к ПП (надежность, используемые машинные ресурсы);

- используемые инструменты – средства разработки (в основном – ЯП).

Если говорить о сопровождении ПП, то сюда добавятся также параметры, влияющие на машинный ресурс:

- способы реализации ПП (гибкость архитектуры ПП – насколько ПП расширяем функционально в пределах исходной архитектуры);

- надежность (меньше сбоев – меньше выявлять и исправлять ошибок; защита кода от ошибок – если произошел сбой, как трудно выявить ошибку).

Т. о., говоря об эффективности ПП, мы подразумеваем меньшую его требовательность к машинным ресурсам. Эффективность программирования – меньшая затрата времени на разработку ПП и большая эффективность созданного ПП, т. к. последняя влияет на сложность сопровождения.

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

Рассматривая конкретный язык, будем отмечать, как он влияет на остальные параметры эффективности программирования:

(A) Требуемую квалификацию программиста. Основной вопрос – подготовка (переподготовка) специалиста, если он не обладает необходимыми знаниями.

(1) Знание базовых средств языка – необходимо.

(2) Знание дополнительных средств языка. Некоторые возможности можно не использовать, поэтому их знание не обязательно. Если же они используются, то программист должен разбираться в них основательно.

(3) Специальные знания. Некоторые средства языка могут требовать знаний в других областях информационных технологий.

(B) Требуемое время:

(C) Эффективность ПП с точки зрения:

(1) меньших затрат машинного ресурса;

При указании влияния на параметры групп B и C будем пользоваться следующими обозначениями: +параметр – положительное влияние, -параметр – отрицательное влияние.

Например, +B1, -B2. При указании только буквы подразумевается вся группа, например +C +С1, +C2.

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

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

(1) История создания.

1. Для какой области задач разрабатывался язык? Очевидно, что наиболее эффективным будет естественное использование языка.

2. Как разрабатывался язык? Существовал ли проект, целью которого был сам язык, или язык появился как инструмент решения какой-то другой задачи? Более вероятно, что специально спроектированный язык будет обладать лучшими качествами.

3. Существует ли строгое формальное описание (стандарт) языка? Наличие стандарта способствует стандартизации средств разработки, что положительно влияет на мобильность ПП. Часто ли подвергается стандарт изменениям и/или исправлениям, что сказывается на изменчивости языка, и отклонении существующих средств разработки от стандарта: этот факт отрицательно сказывается на мобильности ПП.

(2) Средства разработки. Выбор средства разработки полностью влияет на эффективность программирования.

1. Доступность. Как много реализаций существует, какие платформы охватывают, способ распространения, производители.

2. Соответствие стандарту (напрямую влияет на мобильность ПП).

Большинство стандартов оставляют специфические (не поддающиеся стандартизации) моменты на усмотрение реализации. Реализация таких моментов. Расширения стандарта.

(3) Средства языка. Различные средства языка (конкретизация при сравнении).

2. Специфические, расширения (для рассмотренных в 2.2 реализаций).

Среди большого числа ЯП выделяются два обширных семейства: Pascal и C. Общие черты языков этих семейств можно назвать "противоположными":

- синтаксис языка: криптованный, сокращенный – стремление уменьшить размеры лексем языка (C) и человекоподобный – стремление приблизить синтаксис к "разговорному" языку (Pascal);

- автоматический контроль корректности кода во время выполнения (проверка правильности индексов массивов, соответствия типов): отсутствует – вся ответственность за безошибочность кода перекладывается на программиста (C) и присутствует – с генерацией компилятором дополнительного кода и ограничением возможности программиста полностью определять исполняемый код (Pascal);

- стиль программирования "можно все, что не запрещено" (C) и "можно только то, что разрешено" (Pascal).

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

Я хотел бы постараться дать объективную характеристику положительных и отрицательных особенностей каждого семейства. В качестве представителей C-семейства (очевидно) выберем C и C++. В основном C отдельно рассматриваться не будет, так как он практически полностью является подмножеством C++. В качестве представителей Pascal-семейства рассмотрим языки Компонентный Паскаль (КП) (как последний на данный момент этап эволюции Паскаля) и Ада (как один из наиболее мощных и богатых возможностями).

Приводимая оценка базируется на личном опыте, данных из различных источников, отчасти на стандартах языка, поэтому не может рассматриваться как полностью объективная и точная. Наиболее объективно было бы провести сравнение стандартов языков, однако стандарты Ады, C и C++ очень объемные, и одному человеку провести такую работу в приемлемые сроки не представляется возможным.

1. История создания Рассмотрим категории 1.1-1.3 для каждого языка по отдельности.

1. Язык C разрабатывался как универсальное средство системного программирования.

2. В 1970 г. в фирме AT&T Bell Laboratories был разработан язык B как модификация языка BCPL (Basic Combined Programming Language) для написания ранней версии операционной системы UNIX для компьютера PDP-11.

Язык C получился из B устранением недостатков, выявленных в процессе его использования (1972 г., Д. Ритчи, фирма AT&T Bell Laboratories). Основным улучшением было введение типов данных, которые в B отсутствовали.

C получил широкое распространение (в частности, как основной ЯП в операционных системах UNIX).

3. Первая редакция международного (ISO) стандарта языка C была выпущена в 1990, далее было два исправления 1994 и 1996 гг. Действующая версия стандарта: ISO/IEC 9899: (объем – 538 с., платная 281$), к ней выпущено два исправления: 2001, 2004.

С++ 1. С++ разрабатывался как универсальный язык программирования, поддерживающий ООП, абстракцию данных и сохраняющий возможности системного программирования – язык C как свое подмножество.

2. С++ начал развиваться с 1980 года в исследовательской группе Б. Страуструпа как "C с классами", для написания программ моделирования, управляемых прерываниями. Все работы (проектирование, реализация и документирование) выполнялись в соответствии с текущими потребностями авторов и велись вокруг двух положений:

- сохранение языка C как подмножества;

- включение в язык возможностей, обеспечивающих абстракцию данных и ООП. Основные идеи касательно ООП были заимствованы из SIMULA-67.

В июле 1983 г. С++ впервые вышел за пределы исследовательской группы и получил свое настоящее название. Число пользователей языка увеличилось, и дальнейшее развитие в основном было связано с преодолением проблем, с которыми столкнулись пользователи. В результате такого развития, язык пополнился и новыми возможностями, не связанными непосредственно с ООП. Наиболее значительным можно назвать введение шаблонов функций и классов (приблизительно 1988 г.) – механизма поддержки обобщенного программирования. Частично идеи были позаимствованы из языков Ада и CLU.

Лавинообразный рост числа пользователей и появление нескольких производителей компиляторов в итоге привели к необходимости стандартизации языка. Работы были начаты в 1987 г.

3. Первая редакция международного стандарта C++ была издана в 1998. В 2003 году – вторая, действующая на данный момент: ISO/IEC 14882:2003 (757 с., 291$). При этом следует учитывать, что текущий стандарт базируется на стандарте языка C 1990 года.

Сейчас (как и последние лет десять) бурное развитие языка идет в области шаблонов.

Это отрицательно влияет на стабильность языка.

1. Цель создания КП – увеличить контроль в плане безопасности за проектируемыми свойствами сложной компонентной системы. КП можно считать универсальным ЯП за исключением в общем случае низкоуровневого программирования – наличие этих средств не требуется стандартом языка.

2. КП представляет собой модификацию языка Оберон-2, сделанную (1997 г.) в Oberon microsystems, Inc.

Появился КП в итоге нескольких десятилетий исследовательской работы и эволюции нескольких языков, начиная с Паскаля и заканчивая Обероном-2. Более подробно см. [2].

3. Стандартом языка является его определение 1997 г. (32 с, бесплатно).

Ада 1. Ада – универсальный ЯП. Из руководства к языку: "Язык Ада был разработан с учетом трех взаимно перекликающихся концепций: надежность программирования и сопровождения, программирование как человеческая деятельность и эффективность".

2. В 1975 г. Министерство Обороны США разработало и распространило список требований к языку, который должен был служить средством разработки ПО для встроенных компьютерных систем (например, систем наведения ракет). Ни один из существующих языков не удовлетворял этим требованиям, и было предложено создать новый.

Этот новый язык был предметом конкурсного пересмотра в широких индустриальных и академических кругах. Из большого числа было отобрано четыре, затем из них два. В финале выбрали проект представленный компанией Cii-Honeywell Bull, разработкой данного проекта руководил Жан Ишбиа. Язык получил название Ада.

Официальная дата появления языка – 1983 г., когда был утвержден национальный стандарт США (ANSI/MIL-STD-1815A-1983).

3. Первый международный стандарт – 1987 г. В 1995 году выпущена вторая редакция стандарта, в основном связанная с поддержкой ООП, и действующая сейчас – ISO/IEC 8652:1995 (511 с., 281$), в 2001 - исправления.

Итог язык?

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

** Отсутствуют низкоуровневые средства.

ный проект?

Стандарт:

* Стандарт C++ базируется на стандарте C 1990 г, однако поскольку C является подмножеством C++ (за малым числом исключений), то должна быть выполнена доработка (чтобы текущий стандарт C++ базировался на текущем стандарте C), и добавочно указаны цифры, соответственно текущему стандарту C (1999 г.).

2. Средства разработки Рассмотрим категории 2.1-2.2 для каждого языка по отдельности.

1. Существует большое число реализаций от разных производителей под большое число платформ, как коммерческие2, так и некоммерческие. Стоит отметить компилятор GNU CC, распространяемый по лицензии GPL (бесплатно, в открытых кодах).

2. Многие реализации соответствуют стандарту (про все сказать невозможно), и часто предоставляют различные расширения языка/стандартной библиотеки.

Однако, следует отметить факт, что для таких компиляторов как GNU CC, Borland, Microsoft говорится о соответствии национальному стандарту США (ANSI), а не международному (ISO).

C++ 1. Аналогично С, за исключением того, что из-за большей сложности языка число реализаций, поддерживаемых платформ меньше.

2. Поскольку выпускаться компиляторы различными производителями стали гораздо раньше (порядка 15 лет) появления стандарта, то с появлением такового здесь сложилась интересная ситуация.

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

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

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

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

1. На данный момент существуют две реализации КП: BlackBox Component Builder (Windows, Mac; производитель - Oberon Microsystems, Inc), Gardens Point Component Pascal (.NET, выполнена в австралийском Queens University).

Система Blackbox является профессиональным инструментом; версия для Windows распространяется бесплатно в открытых кодах по лицензии BlackBox Open Source License, совместимой с GPL.

2. BlackBox полностью поддерживает стандарт КП. Существуют различные расширения, для поддержки платформенно-специфичных средств. Например, подсистема SYSTEM (низкоуровневые операции), расширение компилятора Direct-to-COM для поддержки COM-программирования под Windows.

Ада 1. Существует немало реализаций, под широкое число платформ. Большое число производителей, распространение в основном коммерческое. Свободно доступны компиляторы ObjectAda от Aonix (правда со значительными ограничениями по сравнению с коммерческой версией) – для Windows и Solaris, и GNAT 3.15p от Ada Core Technologies (под лицензией GPL) – для большого числа платформ. К сожалению, AdaCore закончила выпуск публичных бесплатных версий на 3.15p.

2. Имя "Ada" зарегистрировано как торговая марка. Поэтому, вы не имеете права распространять компиляторы языка программирования Ада до тех пор, пока они не пройдут тестирование на совместимость (позднее эти требования были ослаблены, и теперь защищенное название звучит как "Validated Ada"). Таким образом все версии компиляторов Ады полностью соответствуют стандарту, а все расширения идут в рамках стандарта (те пункты, которые оставляются на усмотрение реализации).

Итог Соответствие реализаций не полное для полное * Всего две реализации: BlackBox Component Builder (полное), Gardens Point Component Pascal (неизвестно).

ветствующих стандарту) * Поскольку многие реализации не полностью соответствуют стандарту, то перенос с одной реализации на другую может быть проблематичен. Хороший пример (того насколько эта задача может оказаться сложной) – проект STLPort, цель которого – реализация единой стандартной библиотеки шаблонов (STL) для большого числа реализаций.

** Переносимость не будет полной, если будут использоваться платформенно-специфичные средства которые полностью не описаны в стандарте и оставлены на усмотрение реализации.

нофункциональных средств разработки * Хотя GNAT 3.15p – полнофункциональное средство, оно будет устаревать, и его использование будет все менее и менее оправданным.

3. Средства языка При рассмотрении средств языка, будем сравнивать специфические особенности следующих реализаций: GNU CC 2.8.1 (C++), GNAT 3.15p (Ada), BlackBox 1.5 (КП).

Богатство средств языка Влияние: A1, A2, +B, +C.

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

Ниже приведена схема, отображающая сложность (число лексем) в основных ЯП (из доклада Свердлова С. З. на II Всероссийском совещании по ИТ-образованию, [2]). Из нее видно, что в основном развитие языков идет за счет их усложнения, с добавлением новых (возможно многочисленных) возможностей. Противоположностью являются языки Оберон-семейства, в которых наряду с включением новых средств исключаются малоиспользуемые и несущественные; пока это дает в результате более простой язык, однако нет гарантий, что эту тенденцию удастся сохранить.

Читабельность и самодокументируемость кода Насколько понятны для программиста будут действия, описанные языком программирования (читабельность)? Насколько просто можно будет понять алгоритм, реализуемый фрагментом программы без дополнительной документации или комментариев (самодокументируемость)?

Хорошо написанный и понятный программный код может значительно сократить время сопровождения (+B2), время разработки (+B1) – особенно если речь идет о крупном проекте, в котором задействовано большое число программистов. Уменьшается вероятность ошибок, проще реализовать сложный алгоритм (+C).

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

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

1. Синтаксис языка криптованный человекоподобный человекоподобный 3. Неявные преобразования присутствуют отсутствуют только точные ций 5. Неоднозначность базовых значительно незначительно незначительно средств 1. Криптованный синтаксис позволяет сократить тексты программ путем минимизации языковых конструкций, в частности за счет интенсивного использования спец. символов; такие конструкции обычно интуитивно малопонятны. Негативное влияние на читабельность проявляется для:

- начинающих и не опытных программистов, которые еще просто не привыкли к специфике синтаксиса;

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

2. Наличие препроцессора сказывается на читабельности в общем случае негативно.

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

3. В Ada преобразования из одного типа в другой могут быть только явными.

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

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

4. Операции (записываемые в ЯП при помощи знаков) – по сути математические функции, которые прежде всего имеют определенный результат. Это их естественный смысл, который легко воспринимается.

В C++ в категорию операций входят операции присваивания (простого и вычисляемого) и инкремента/декремента, которые прежде всего изменяют свои аргументы (это их основной смысл) и как операции обладают результатом (основной смысл операций). К побочному эффекту тут можно отнести и то и другое – в зависимости от того, что трактовать как основное понятие: действие присваивания – операция или операция присваивания.

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

Все это – большой минус для читабельности.

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

В общем случае этот вопрос рассмотрен в пункте "Богатство средств языка". Здесь мы остановимся на базовых (простейших) средствах ЯП. Неоднозначность этих средств, когда проявляется в большом числе возможных вариантов, негативно сказывается как на читабельности так и на самодокументируемости, т. к. у каждого программиста складывается свой стиль реализации базовых алгоритмических конструкций (последовательные действия, ветвление, циклы).

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

Последовательные действия Представлены синтаксической конструкцией "операторная последовательность", которая может быть включена в тело процедуры/функции или в какой-либо составной оператор.

Ада С++ Представлены составным оператором, который может использоваться в составных операторах и выступает в качестве тела функции.

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

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

if (0 Visual Basic Pascal => Borland Delphi Составление алгоритмов на естественном языке => 1С Предприятие. Как говорится, без комментариев...

Блок "Turbo Pascal" содержит обычный курс программирования в этой среде, 14 уроков.

Описаны основные операторы (условный, циклов), работа с различными типами. И заключительный штрих - работа с графикой (куда без нее?) и вызовы процедур. Ни словом ни затронуты принципы структурного программирования, записи, работа с файлами. Да и зачем? Школьников ждут гораздо более важные вещи - рисование окошек в Visual Basic и конфигурирование 1C.

Остальные блоки - Visual Basic, Delphi и 1С построены по принципу "щелкните мышкой туда и туда, посмотрите, что получится, запомните, но не думайте, почему это так", потому что научить школьников работать в профессиональных средах за 12 уроков просто невозможно.

На первых 2 урока курса по Visual Basic (не считая самого начала, посвященного открытию среды и компиляции) излагаются: объектно-ориентированный подход и событийно-управляемая модель программирования. Затем описывается работа с формами, и только на 15 уроке изучается оператор присваивания. Как могут понять и научиться использовать ООП школьники, не знакомые со структурным программированием? Не говорим уже о событийно-управляемом программировании... (Видимо, авторы курса просто убеждены, что это - изобретение Microsoft, впервые примененное в Visual Basic.) За этими двумя формулировками стоят десятилетия исследований и технического поиска. Объяснить ООП на первом занятии, может быть, и можно, в самом объектном взгляде на мир нет ничего сложного, но невозможно понять, какую роль оно играет в создании технических систем, каковы его преимущества и недостатки, если перед этим не написать хотя бы несколько небольших программ в структурном стиле. Мы в нашем спецкурсе в Орле даем ООП только в 11 классе, после того, как за спиной у учащихся уже были такие самостоятельные проекты, как простая база данных, игра "Тетрис" и т.п.

Блок по Delphi выстроен аналогично. Единственное отличие в том, что венчают его три урока по работе с базами данных: "Программирование модулей. управляющих базами данных".

Нет спору, навык неплохой, но как научить ему за три урока школьников, в предыдущих знаниях которых (благодаря тому же курсу от 1С) к тому есть большие пробелы, если те же три урока придется посвятить общему знакомству с отраслью СУБД и основными понятиеми реляционной модели?

Собственно, обучения построению программ и решению технических задач в курсе вы не найдете. Это - одна большая презентация, за которой ничего нет. Презентация либо на слайдах, либо на примерах, когда учащемуся говорят: "сделай то и это и посмотри, что получилось!" Такой подход не приводил к успеху даже в относительно простом TurboPascal, не говоря уже о современных средах разработки.

Что можно сказать про попытки преподавать в школе Visual Basic и Delphi? На VB даже останавливаться не будем - если сравнивать с Delphi, то у него нет ни одного весомого преиму щества. Зато среда и язык прививают плохой стиль, построены совершенно сумбурно. Сколько потом усилий придется потратить в ВУЗах на инженерных специальностях, чтобы переучить юных "рисовальщиков окошек"? Единственный способ переучить пользователя (по другому не назовешь) Visual Basic на профессионального программиста - заставить забыть все, чему научили в школе.

Что касается Delphi, то, при всем нашем уважении к этой замечательной среде, надо сказать, что для начального обучения программированию она не особенно подходит. Единственный способ - начинать с написания консольных приложений, заменив на этом этапе старый TurboPascal. В среде Delphi есть большая концептуальная ошибка - слишком тесная связь логики и интерфейса разрабатываемых программ. Это проявляется, например, в наличии большого количества так называемых невизуальных компонентов - объектов, которые имеют системное назначение, но при этом являются наследниками TComponent и кладутся на формы так же, как, например, кнопки. Но, скажите мне, какое отношение имеет сокетное TCP/IP-соединение к пользовательскому интерфейсу? Это все равно, что монтировать блок развертки телевизора на его переднюю панель...

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

Но главная проблема, по которой эти среды графической разработки нельзя брать для начального обучения программированию, заключается в том, что даже для самой простой оконной программы требуется знание ООП. А, как мы уже сказали, преподавать ООП без предварительного формирования навыков структурного программирования - безумие. Можно ли решить эту проблему? Действительно, любая современная реализация GUI построена на ООП. Однако при внутреннем объектном устройстве системы можно предложить гораздо более простой подход для того, кто создает на ее основе программы. Такой подход, например, предлагает среда BlackBox.

В целом про курс можно сказать одно: не оставляет ощущение, что его делали бухгалтера из финансового отдела 1C, а не инженеры и тем более не математики.

4. Сложность или сумбурность?

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

На самом деле, сложность для понимания бывает двух видов: сложность концептуальная, заставляющая человека приложить серьезные усилия для овладения материалом, и сложность от сумбурности, от отсутствия логичности и последовательности как таковой. Многие школьные и университетские курсы сегодня являются примером последней. На самом деле нормальной способностью и стремлением человеческого сознания является обобщение информации, желание уловить самую суть, пусть даже она будет и тяжелее для восприятия, чем набор конкретных навыков. Если же в процессе обучения это естественное стремление не только не удовлетворяется, но подавляется лавиной примитивщины, которая не дает за деревьями увидеть леса, то нормальное сознание либо деградирует, либо отказывается воспринимать подаваемый материал вообще (этакий защитный механизм). Чего стоят школьные программы физики, которые предлагают запоминать набор второстепенных формул и то, куда и в какой момент их следует "приткнуть", вместо того, чтобы научить сначала анализировать задачу качественно, затем на основе базовых формул составлять систему уравнений, описывающую ее количественно, и затем грамотно решать эту систему...

Завершим затянувшиеся размышления высказыванием известного ижевского ученого и преподавателся Н.Н. Непейводы, сказанной, правда, по поводу университетского обучения, но в не меньшей степени применимой к школьному: "Чтобы подготовить хороших специалистов (программистов), нужно готовить аналитиков. Чтобы попасть в цель, нужно целиться выше цели. Все равно не более 20% [учащихся] станут аналитиками, но оставшиеся станут специалистами именно того класса, который нужен российским фирмам".