В этом сообщении изложена Часть 3, которая содержит мои ответы на замечания, изложенные на форуме до 24 февраля 2008 года (то есть до моего первого сообщения).
Примерно через десять дней последует Часть 4, в которой я продолжу отвечать на вопросы и критические замечания.
С глубоким уважением Владимир Паронджанов
Часть 3. Ответы Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», представленные до 24 февраля 2008 года.Замечания обсуждаются в том порядке, в каком они появились на форуме.
Ярослав Романченко Четверг, 31 Май, 2007 16:15Почему бы не сделать гремучую смесь Дракон+Оберон?
Ответ ПаронджановаПолностью поддерживаю Вашу инициативу. Если Вы и Ваши коллеги действительно решите построить гибридный язык Дракон-Оберон, я готов сделать все от меня зависящее, чтобы помочь Вам довести Вашу разработку до победного конца.
GUEST Четверг, 19 Июль, 2007 17:41Насколько я понимаю, всё дело в редакторе. Пока его нет, интересоваться действительно нечем.
Ответ ПаронджановаУважаемый GUEST! Не могу с Вами согласиться. Мне кажется, Вы слишком осторожны и проявляете чрезмерный пессимизм. In my humble opinion, дело обстоит несколько иначе. Моя точка зрения такова.
Поскольку в открытом доступе дракон-редактор отсутствует, можно занять две существенно разные позиции:
• Сидеть сложа руки и ждать, когда редактор сделает кто-нибудь другой. И только после этого взяться за дело.
• Не ждать у моря погоды, а стать хозяином положения. То есть сделать редактор самому. Или в составе команды — вместе с друзьями и единомышленниками.
Возможно, Вы скажете, что это слишком трудная работа. Опять не соглашусь. Не так страшен черт, как его малюют. Сделать редактор не так уж сложно — было бы желание. На этом форуме в обсуждении языка Дракон участвуют чрезвычайно сильные, опытные, знающие специалисты. Для таких зубров и ассов создание дракон-редактора — в этом я абсолютно уверен — не составит большого труда.
Конечно, если нет желания тратить на подобную работу драгоценное время, тогда другое дело. На нет и суда нет.
Подробный ответ на вопрос: «Как сделать дракон-редактор?» дан в моей книге (см. главы 14 и 15). Если возникнут вопросы, я, разумеется, всегда готов помочь.
Уважаемый GUEST! Допускаю, что мои аргументы могут показаться неубедительными. Поэтому сделаю добавление. Мне известны два случая, когда люди проявляли инициативу и создавали редактор.
• В первом случае это была команда, работавшая в интересах негражданского заказчика (не имевшего никакого отношения к ракетной технике). До начала разработки ко мне приехали инициаторы разработки. Мы беседовали часа четыре или пять. После этого они приступили к работе и совершенно самостоятельно создали большую систему, в которой дракон-редактор (они назвали его «редактор алгоритмов») — один из многих элементов. Мне известно, что разработка доведена до конца. Она прошла все необходимые испытания, сдана заказчику.
• Другой пример. Николай Сенюгин ознакомился с моей книгой, (издательство «Радио и связь»). По собственной инициативе, в одиночку (без каких-либо контактов со мной) он разработал редактор и систему проектирования. И показал ее мне лишь тогда, когда его проект был уже почти закончен.
http://old.osp.ru/w2k/cgi-bin/forum.cgi?action=thread&id=1808В каком состоянии его проект сегодня? Мне кажется, на этот вопрос должен ответить он сам.
Борис Рюмшин Четверг, 19 Июль, 2007 18:39 В вычислительных задачах графические схемы бесполезны. Там формул вполне хватает и они намного выразительнее.
Ответ ПаронджановаУважаемый Борис! Благодарю за критику, но согласиться с Вами не могу. В вычислительных задачах есть и ветвления и циклы. В том числе вложенные. Графика дракон-схем облегчает и ускоряет их восприятие. Кроме того, деление задачи на ветки позволяет быстро или даже почти мгновенно увидеть структуру решения вычислительной задачи.
Для убедительности приведу пример из жизни. В начале 1990-х годов в Институте повышения квалификации руководящих работников и специалистов нашей ракетно-космической отрасли я и мои коллеги организовали курсы по изучению языка Дракон (двухнедельный курс с отрывом от производства). Каждый слушатель обязан был сделать выпускную работу. Откуда взять тему выпускной работы? Тему мы не навязывали. И говорили слушателям: вы на работе что-то делаете? Вот и опишите свою производственную задачу на Драконе. Слушатели так и поступали.
Перейду к изюминке. Один слушатель (программист-математик) сделал хорошую работу. Что-то сложное и математическое. В его дракон-схемах были десятки (если не сотни) формул. В общем, формулы на формулах едут и формулами погоняют.
Но самое интересное было потом. Мне позвонил начальник лаборатории, в которой работал этот слушатель. И сказал, что в выпускной работе использован придуманный им (начальником) новый метод решения сложной вычислительной задачи. Метод, который он рассматривает как свое крупное достижение и изобретение. Изобретение, которое он не хотел бы разглашать. Потому что он еще не опубликовал свою идею.
И добавил: раньше я не опасался, что у меня украдут идею. Потому что в традиционной записи все это очень сложно. Но теперь, глядя на дракон-схемы, любой дурак поймет суть идеи и может ее украсть. Это его подлинные слова. Он взял с меня обещание, что я никому не буду показывать схемы, сделанные его подчиненным и моим слушателем.
Этот рассказ я привожу для того, чтобы подчеркнуть простую мысль. Дракон делает непонятное понятным. То, что выглядело сложным и запутанным, в дракон-схемах оказывается прозрачным и очевидным. Смутное — отчетливым. Абстрактное — наглядным. А прежде скрытые ошибки видны, как на ладони. Это, разумеется, метафора. Но в ней изрядная доля истины.
Уважаемый Борис! Вы правы, но при одном условии. При условии, что ЯСНОСТЬ И ПОНЯТНОСТЬ алгоритмов и программ для вычислительных задач НИКОМУ НЕ НУЖНЫ. В таком случае Драконом можно пренебречь.
Но если ясность и понятность являются главным требованием, Дракон, безусловно, полезен.
По моему мнению, там, где требование УДОБОПОНЯТНОСТИ процедурного программирования выходит на передний план, язык Дракон не имеет конкурентов.
Впрочем, если Вы со мной не согласитесь, я буду уважать Ваше решение.
Илья Ермаков Четверг, 19 Июль, 2007 19:06По реализациям Дракона в сети глухо... Ловить на "ДРАКОН" слишком общо, попробовал на конкретные реализации из книжки: Дракон-Модула, Дракон-Си...
Ответ ПаронджановаЭто не совсем точно. Выражение «конкретные реализации» здесь не очень подходит. Я имею в виду, что Дракон-Модула и Дракон-Си нельзя считать «конкретными реализациями».
На сегодня (в нашем Научно-производственном центре) существует и успешно эксплуатируется только одна реализация языка Дракон — это технология Графит-Флокс.
Да, действительно, в моей книге есть примеры программ на гибридных языках Дракон-Си, Дракон-Модула, Дракон-Паскаль. Но эти системы (нами) не были реализованы, они не существуют в природе.
Зачем же даны эти примеры? С единственной целью: показать, что Дракон (как идея и как графический синтаксис) — это не один язык, а семейство языков.
Чтобы построить новый Дракон-язык, надо доопределить язык, то есть к предлагаемому графическому синтаксису добавить текстовый синтаксис.
Как это сделать? Об этом в книге рассказано. Для иллюстрации даны конкретные примеры (Дракон-Си, Дракон-Модула, Дракон-Паскаль). Из примеров с очевидностью следует, что гибридные языки создать в принципе можно. Причем это не такое уж сложное дело. Но на практике эти языки (у нас) не были реализованы (для наших целей это не нужно).
Иван Кузьмицкий Вторник, 24 Июль, 2007 12:55Ага, у них там введены серьёзные топологические ограничения, сразу напомнило Оберон.
Формализации содержимого икон я что-то не приметил, надо будет плотно подойти к вопросу. Отчего бы формальным схемам не выливаться в исходный текст на Обероне, а оберон-программам не отображаться в формальную схему? Автоматически.
Ответ ПаронджановаБлагодарю за чрезвычайно интересное замечание. В Вашем высказывании содержатся три важные мысли. Я отвечу на каждую мысль отдельно.
Первая мысль Ивана Кузьмицкого Ага, у них там введены серьёзные топологические ограничения.
Ответ Паронджанова на первую мысль КузьмицкогоВы правы, в дракон-схемах есть топологические ограничения. Но я бы не называл их серьезными (в смысле — чрезмерно жесткими). Суть в том, что это очень мягкие ограничения. По сравнению с жесточайшими ограничениями, которые господствуют сегодня в процедурном программировании. Эти жесточайшие ограничения введены Эдсгером Дейкстрой, его сторонниками и продолжателями его дела. С современных позиций указанные ограничения ничем не оправданы.
Дракон снимает значительную часть прежних ограничений. То, что раньше было нельзя, теперь можно. Дракон — это не только переход от текста к эргономичной графике. Прежде всего, это прыжок из царства необходимости в царство свободы.
В самом деле, выбор «заготовки-примитив» и операции «Ввод атома» позволяет создать структурную программу в традиционном смысле слова (то есть в соответствии с требованиями Дейкстры).
Но есть и важное отличие от прежних канонов. Использование «заготовки-силуэт», операций «Пересадка лианы» и «Заземление лианы» (которые опираются на фундаментальное понятие «валентных точек») позволяет резко расширить класс разрешенных программ. Дракон разрешает писать программы, на которых раньше стояло позорное клеймо «неструктурности».
Таким образом, язык Дракон предоставляет алгоритмистам и программистам принципиально новые возможности и (что крайне важно!) высшую степень интеллектуального комфорта.
(Для тех участников дискуссии, кто не читал мою книгу и не рисовал дракон-схемы, последнее высказывание может показаться голословным. Но ведь нельзя ожидать, что я смогу пересказать содержание книги на данном форуме. При всем желании это невозможно).
Вторая мысль Ивана Кузьмицкого Формализации содержимого икон я что-то не приметил, надо будет плотно подойти к вопросу.
Ответ Паронджанова на вторую мысль КузьмицкогоВы не заметили формализацию содержимого икон? Все правильно. Такой формализации в книге нет. Это принципиальный момент. Я предлагаю только графический синтаксис. Про текстовый синтаксис я молчу. Моя книга — это обращение к пытливым умам. Ребята! Если вам по душе идея Дракона, создайте такой текстовый синтаксис, какой посчитаете нужным.
Мы, конечно, создали текстовый синтаксис для себя. Но он годится только для ракет. Для ваших целей он не подходит.
Если вы хотите создать гибридный язык Дракон-Оберон, флаг вам в руки. Для этого надо взять текстовый синтаксис процедурной части Оберона, слегка изменить его и получить правила заполнения дракон-схем Оберон-формализацией. На выходе дракон-редактора вы получите исходный текст Оберона (только процедурную часть). А декларативная часть Оберона — это отдельный вопрос. Например, ее можно вообще не менять и оставить все как есть.
Спешу сделать оговорку. Конечно, в книге есть тройка-другая примеров формализации содержимого икон (см. главы 8—12). Но они не предлагаются в качестве эталона. Они играют скромную роль — роль придуманной иллюстрации. Цель этих примеров проста — показать, как может выглядеть подобная (эргономичная и математически строгая) формализация.
Третья мысль Ивана Кузьмицкого Отчего бы формальным схемам не выливаться в исходный текст на Обероне, а оберон-программам не отображаться в формальную схему? Автоматически.
Ответ Паронджанова на третью мысль КузьмицкогоВаша мысль заслуживает одобрения и всяческой поддержки. В нашей системе сделано только прямое преобразование. Обратного нет.
В отличие от нас, Вы предлагаете реализовать не только прямое, но и обратное преобразование. Это высший шик (хотя кое-кто может посчитать это «архитектурным излишеством. Но я так не думаю). Я хорошо помню, что мне рассказывал Ковалев, сотрудник Игоря Вельбицкого — автора Р-технологии. Ковалев сказал, что когда они сделали и прямое, и обратное преобразование, это произвело на сторонних программистов ошеломляющее впечатление. (Прошу не рассматривать мои слова как высказывание в поддержку Р-технологии).
Думаю, если Вы, уважаемый Иван, сумеете реализовать «туда-сюда» преобразование, это будет просто здорово! Восхищаюсь Вашим дерзким предложением!
Конец ответов Паронджанова на предложения КузьмицкогоДобавление Паронджанова к ответу на замечание GUEST Четверг, 19 Июль, 2007 17:41Выше я упомянул, что команда разработчиков, работавшая в интересах негражданского заказчика, построила дракон-редактор, входящий в состав большой системы. Сделаю пояснения.
Пошарив в своих архивах, я обнаружил написанную ими статью, опубликованную в 2003 году. Эта статья у меня не в электронном, а в бумажном виде. Поэтому привожу ее в сокращенном виде.
Ниже приведены начало и конец статьи (середина опущена).
Статья представителей команды разработчиков, работавших в интересах негражданского заказчикаСтатья опубликована в журнале «Приборостроение и средства автоматизации. Энциклопедический справочник №10 2003г». Стр.57—60.
Название статьи:
Средство визуального программирования «Силуэт»Авторы статьи:
Д.А.Щелкунов, П.В. Павлов, И.А.КнязевВ настоящее время разработка компьютерных программ подразумевает знание хотя бы одного алгоритмического языка, а в большинстве случаев и знание современных технологий программирования. Естественно, это отпугивает многих специалистов-предметников (инженеров, технологов и т.д.) от написания собственных программ из своей предметной области. Так, по мнению В.Д. Паронджанова [1], сложность явилась камнем преткновения информатики, которая превратила формализацию профессиональных знаний и разработку сложных компьютерных программ в сверхтрудный интеллектуальный процесс, доступный сравнительно узкой социальной прослойке и недоступный всем остальным. Сегодня, несмотря на все усилия, значительная часть специалистов, не научившись разбираться в языках программирования, оказалась отстраненной от плодотворного взаимодействия с программным обеспечением компьютера, что не позволяет им эффективно обрабатывать собственные и чужие профессиональные знания.
Исходя из классической формулировки Н.Вирта, по которой любую программу можно интерпретировать как «Алгоритм + Структуры данных» [2], мы считаем, что одним из способов повышения эффективности программирования является придание визуальной образности формам спецификации данных и описанию алгоритмов. Неслучайно, что в настоящее время делается много попыток создания средств визуального программирования.
В Международном центре по информатике и электронике (ИнтерЭВМ) разработано средство визуального программирования (СВП) «Силуэт», в котором способ программирования приближен к образному способу визуального мышления человека.
СВП «Силуэт» предоставляет возможность специалистам-предметникам создавать собственные программы, не прибегая при этом к сложным и запутанным современным языкам программирования. В СВП «Силуэт» специалист-предметник оперирует понятными ему программными объектами из своей предметной области, задавая алгоритм решения задачи с помощью визуальных графических элементов. Повышение производительности труда программиста связывают в этом случае с большей наглядностью (понятностью) программ и более комфортными условиями труда, что в конечном итоге приводит к повышению надежности результирующих программных продуктов.
В основу технологии СВП «Силуэт» положены графический способ представления проектируемой программы, объектное представление данных и автоматизированная интеграция объектов в алгоритм разрабатываемой программы.
Графическое представление алгоритма
Графический способ представления логики проектируемой программы основывается на использовании так называемых ДРАКОН-схем, описывающих ход выполнения программы, т.е. порядок передачи управления между различными ее модулями. Процесс написания исходного текста заменяется процессом построения программы из элементов визуального языка ДРАКОН [1], соединяемых по определенным правилам в соответствии с логикой работы алгоритма.
Построенная в графическом редакторе ДРАКОН-схема представляется в памяти компьютера в виде древовидной динамической структуры объектов.
Примечание Паронджанова. Далее следует середина статьи, которую я опускаю. Приведу лишь названия разделов:Раздел «Объектное представление данных»
Раздел «Архитектура СВП «Силуэт»»
Раздел «Пример разработки программы с помощью СВП «Силуэт»»
Раздел «Генерация кода и компиляция»
Раздел «Отладка программы»
Примечание Паронджанова. Ниже приведены заключительные разделы статьи: Сохранение файла проекта
На любом этапе можно сохранить проект программы. Файлы проекта записываются на ХML-подобном языке с сохранением той вложенной структуры, которую образуют элементы схем и объекты данных в памяти компьютера. Каждый элемент схемы и сам объект сохраняет и считывает то, что ему нужно и может руководить сохранением и загрузкой тех объектов, которые расположены в нем.
Расширяемость СВП «Силуэт»
Программное ядро СВП «Силуэт» реализовано таким образом, что для добавления нового объекта данных или элемента схемы достаточно просто скопировать специальным образом подготовленную динамическую библиотеку в нужную директорию. Средство автоматически «подцепит» эту библиотеку.
Программные интерфейсы, определенные в ядре СВП «Силуэт» являются достаточно универсальными, что позволяет при необходимости реализовать различные графические представления алгоритма. Версии СВП «Силуэт» разработаны с использованием кросс-платформенной библиотеки Qt и могут работать под управлением операционных систем Windows и Linux.
Перспективы СВП «Силуэт»
Представленный в данной статье пример использует минимальные возможности СВП «Силуэт». В настоящее время разрабатывается большой набор библиотек объектов, связанных с GUI, базами данных, математикой и другими направлениями.
Особо перспективным направлением является создание средства моделирования на базе ядра СВП «Силуэт». Предполагается, что в данном средстве пользователь сможет составлять некую сцену из объектов, задавать их поведение, после чего средство будет эту модель проигрывать. Примером таких моделей могут быть системы массового обслуживания, технологические процессы и др.
СВП «Силуэт» расширяет «армию труда» в сфере программирования, поскольку к узкому кругу профессиональных программистов, в новых условиях, подключается большое количество «любителей», способных разрабатывать качественные программы на этом средстве программирования.
По мнению разработчиков, СВП "Силуэт" может оказаться очень полезным специалистам в различных научных, производственных и других областях.
Литература
1. Паронджанов В.Д. Как улучшить работу ума: алгоритмы без программистов — это очень просто! — М.: Дело, 2001.
2. Вирт Н. Систематическое программирование. Введение. — М.: Мир, 1977.
Конец статьи.Примечание Паронджанова. Эту статью в сети я не нашел. Есть лишь ссылка на оглавление журнала и название статьи http://www.tgizd.ru/mag/spravoch/spravoch_3_10.shtmlКонец Части 3. Конец ответов Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», появившиеся до 24 февраля 2008 года.Продолжение (Часть 4) последует примерно через 10 дней.