DRAKON.SU

Здравствуйте.

Я недавно начал изучать языки программирования. И начал с изучения тенденций развития. Хочу поделиться впечатлениями от знакомства с алгоритмическим визуальным языком Дракон, которые появились на первый взгляд. Прошу меня извинить, если подниму вопросы, которые много раз обсуждались на форуме или проблемы, решение которых уже очевидно. У меня нет возможности детально следить за обсуждаемой темой и ходом разработки Дракон-редактора.

1. Дракон-схемы (Дракон-редактор версии от 09.09.2008) удобно использовать специалисту, который пользовался в своей работе принципиальными и функциональными схемами аналоговой аппаратуры. Для реализации же в аппаратуре современной схемотехники применяются многослойные печатные платы. Принцип многослойной печатной платы возможно было бы использовать и для визуализации программирования. Таким образом возможно решить проблему формата.
2. Например, создатели языка программирования UML подчеркивают, что их язык – это язык моделирования, но не метод. Технология ГРАФИТ-ФЛОКС использует «принцип строгого разграничения процедурных и декларативных знаний. Для этих целей языковые средства данной технологии расщепляются на два относительно самостоятельных языка: процедурный язык ГРАФИТ и декларативный язык ФЛОКС». Как мне кажется, попытки вписывать код на языке Oberon в Дракон-схему – это обратный процесс. Происходит смешение языков, но где там метод или процесс я не нашел.

С точки зрения автоматизации процесса программирования.
Если продолжать сравнение среды разработки программ с «железом», то готовым программным аналогом многослойной печатной платы является табличный процессор (Excel, Calc). Перед визуальными языками программирования табличный процессор имеет преимущество. Как в любой матрице, его данные могут быть организованы с математической точностью. В том числе, листинг программы, составленной определенным образом, может собирать и проверять макрос. Таким образом составленную программу возможно использовать в Blackbox’e. Если я правильно понимаю, то модуль для взаимодействия с Excel отсутствует в свободно распространяемом Blackbox’е по лицензионным соображениям.

С точки зрения эргономики.
«Принцип эргономизации – один из ключевых принципов, положенных в основу информационной технологии ГРАФИТ-ФЛОКС». Но эта технология совсем, почему-то, не обсуждается.

Подсистема Ctl.

У меня установлен BlackBox Component Builder 1.5. В подсистеме Win есть модуль WinCtl ["COMCTL32.dll"]. А в примере ObxExcel требуются модули CtlT, CtlExcel := CtlExcel9, но таких модулей и самой папки-подсистемы Ctl нет.

В русской сборке она была вырезана. Скачайте оригинальную версию - и оттуда возьмите её.

В какой-такой "русской сборке"?

Качать нужно "базовую" версию с сайта Информатики-21. Или университетскую. Там ничего не вырезано, но русификация и примочки сделаны. Что-то вырезано было только в школьной версии.

Честно говоря, сам не помню от куда скачивал Blackbox, но русификацию устанавливал отдельно и только на документацию. Сейчас переустанавливать что-либо нет возможности, но, все равно, спасибо за подсказку. Кроме того, хочется взглянуть на эту проблему шире. Если Blackbox установлен на эмуляторе Wine в Linux’е, тогда что потребуется для написания модуля взаимодействия с Calc ?

Таблицы более универсальны, но что-то я не могу вспомнить ни одного примера, где они были бы нагляднее Дракона. Если таблица будет изображать только один слой (для чего, кстати, она изначально и придумана), то преимущество будет у Дракона. А если таблица имитирует несколько слоёв, то её чтение крайне затрудняется. Её можно будет использовать только для поиска одной конкретной строчки, а не для полного прочнения.

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

Скопировал из другой системы папку Ctl. Обнаружилось, что у меня еще не было подсистемы Dtf.

Я где-то читал, что существует версия Blackbox для Linux, но в причинах ее меньшей распространенности не разобрался. Будут ли модули Linux’овой версии, если позволяет лицензия, работать через эмулятор Wine?

С точки зрения визуализации в табличном процессоре не так все плохо. Например, если
Лист1:А1 содержит графический блок «Поле ввода параметра»,
Лист2:А1 содержит указание на ввод значения типа INTEGER,
Лист3:А1 содержит число 2.6,
то при переходе с одного листа на другой при настройках, сохраняющих номер ячейки, заметить ошибку не сложно.

Извиняюсь за оффтоп.
Предполагая что Вы качали русскую редакцию, замечу - в таблице, содержащий ссылку на скачивание написано (http://oberoncore.ru/blackbox/environment):


Гуёвой версии под Linux пока нет. Можете запускать под Wine виндовую версию. Обычно (зависит от версии wine) работает. См. viewforum.php?f=34

См. http://etersoft.ru/ Вроде слышал от кого-то, что у них есть реализация wine/прилад офиса под wine которые транслируют автоматизацию виндового офиса в вызовы для линухового опен офиса. Не факт что она бесплатная...

Dtf сильно специфичная вещь и на практике не нужна. Из 1.6 была исключена, поэтому я её вывел и из нашей сборки. Атавизм это, короче говоря.

А ещё, товарищи, с обсуждением BlackBox прошу в соответствующие ветки.

За основу своих рассуждений о языке ДРАКОН я взял статью «Зачем нужна информационная технолгия «ГРАФИТ-ФЛОКС»?».
http://store.oberoncore.ru/lib/paper/GrafitFloks.pdf Прочитав статью и разобрав примеры в Дракон-редакторе с блок-схемами, куда была перенесена программа на Oberon’е, я потерял связь между теорией и практической реализацией идеи. Поэтому, как альтернатива возникла идея в Blackbox’е с Excel/Calc. Я совсем не утверждаю, что это правильное решение, но вполне реальное.

Я полагаю, что Дракон-схема – это процедурная часть языка ДРАКОН(т.е процедурный язык ГРАФИТ). Тогда, что считать декларативной частью, если в Дракон-схему вписывается код на языке Oberon?

А как Вам идея, что Дракон - это "контейнер", позволяющий устанавливать определённые "маршрутные" связи?

Чтобы не было недопонимания.
ГРАФИТ-ФЛОКС - это отнюдь не теория. Это конкретная практическая реализация.
Здешний редактор со вставляемым кодом - это другая (экспериментальная) реализация.

Никто не мешает сделать ещё сколько угодно реализаций.
Никто не мешает развивать теорию по мере необходимости.

Этот «контейнер» не возможно в полной мере раскрыть на ограниченном формате листа.

Вы не считаете, что такая реализация – это шаг назад в технологии, из-за отсутствия строгого разграничения процедурных и декларативных знаний?

Почему Вы так считаете?