DRAKON.SU

Отделено по предложению тов. Паронджанова. Определитесь с ним что/куда лучше --- переделаю.

Последовательно:
1) Основной вопрос (как раз близкий к теме об изучении Дракона в вузах). Меня не устраивает позиция Паронджанова. Я жду от него дальнейшего развития и теоретических разработок по когнитивной эргономике, но получаю только новые книги, закрепляющие сложившийся Дракон. А это меня уже интересует совсем мало.
2) Пока Паронджанов молчит (уже три года молчит на подобные замечания), в тему влезает Тышов и говорит, что проблем нет, есть замечательный инструмент для работы с Драконом. Это меня интересует ещё меньше, но приходится навскидку накидать очередных замечаний, что не всё так гладко и в инструменте.
3) Подключаются другие участники, и тема совсем сворачивает на мелкие технические вопросы.
4) Модератор отделяет тему от неприкосновенного Паронджанова, чтобы уж совсем уйти в сторону от основного вопроса.

Как хотите, конечно. Можно продолжать обсуждать мелкие технические вопросы...

Максималистская у меня позиция, конечно, и потребительская, сознаю... ну да что ж теперь...

Вместо перехода на личности и клевет (неверных выводов) советую занять конструктивную позицию. Для начала --- успокоиться и внимательно перечитать сообщение viewtopic.php?p=62827#p62827

Вопрос не в том, какая о Вас позиция и не в том, как Вы относитесть к Владимиру
Даниеловичу и к языку ДРАКОН.
Вопрос в том, какие у Вас конкретные предложения в области визуального программирования,
пусть даже и не связанные напрямую с языком ДРАКОН (типа таких, какие я предложил в
моем предыдущем посте).

Я, не знаю, заметили Вы или нет, в программе ав 2.ХХ я достаточно сильно отклонился от
классической реализации языка ДРАКОН, и ничего страшного при этом не случилось.
Еще раз могу повторить - все что выложено на форуме - это всего лишь более или менее
детализированные макеты и информация к размышлению, а вовсе не икона (тут это слово
употреблено в смысле "предмет религиозного поклонения", а не как обозначение блока
визуальной схемы).

Да всё спокойно вообще-то. Сорри, Ваше сообщение пропустил... Тогда так:

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

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

К сожалению, конкретных предложений нет. На это нужно время... А приоритет, увы, далеко не первый... Поэтому и говорю, что моя позиция пока остаётся потребительской. Но в успехе дела-то ведь заинтересован!

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

При потребительском интересе, вполне достаточно книг В.Д. Паронджанова и ИС Дракон.

Примером является успешное использование С. Ефановым ИС Дракон в разработке и программировании устройств.

Алексей, Вы поднимаете, IMHO, очень важные вопросы. И потому всё-таки - есть у Вас для представления на обсуждение свои "макеты" и "информация к размышлению" - как должны выглядеть те языки представления знаний о деятельности, которые можно было бы изучать в вузах?

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

В ИС Дракон верификация имеется - в контекстном меня схем предусмотрен пункт "Проверить". Пользуйтесь.

На что проверяется? На выполнение инвариантов процесса?

Хороший подход - демонстрировать работу и инструментом (тем более не воображаемым... но и это нужно). Я бы ещё добавил:
4) Комбинированное по формам записи описание, напр., как предлагается для Pure Builder - процедуры текстом, а их организация - граф-схемно.
5) Свободное конструирование схем, как в DesignIDEF - сочинитель вводит модель поэлементно и сам соединяет связями в конструкции, а редактор проверяет грамматику и отвергает недопустимое.

http://forum.oberoncore.ru/viewtopic.php?p=62837#p62837

Пожалуйста, есть оценка использования ИС Дракон в коллективе.
От 09 Декабрь, 2010.

http://forum.oberoncore.ru/viewtopic.php?p=62840#p62840
Не знаю, что такое инвариант процесса. Не видел ни одного программиста, которые употребляют в каком либо виде инварианты. Скорее всего в практике программирования можно обойтись без инварианта, имейте отлаженный алгоритм до программирования. Должна использоваться парадигма программирования АОП - алгоритмо ориентированное программирование.

На что проверяется? -
'. Отсутствует текст (т.е. ?...) в иконе(ах) - '
'. Имеются критические точки ввода - '
'. Отсутствует адрес в иконе(ах) "Адрес" - '
'. Отсутствует икона "Конец" для схемы являющейся функцией, вставкой.'
'. От икон "Заголовок" нет маршрута до икон(ы) "ИмяВетки" - '
'. От икон(ы) "ИмяВетки" - '+Str+' нет маршрута до иконы "Конец".'
'. Отсутствует програмное приложение к иконе(ам) - '
'. Отсутствует начальная часть (до "//Схема") програмного приложения к схеме.'
'. Отсутствует конечная часть (после "//Схема") програмного приложения к схеме.'
'. Отсутствует начальная часть (до "//Схема") програмного приложения к иконе "Модуль" - '
'. Отсутствует конечная часть (после "//Схема") програмного приложения к иконе "Модуль" - '
'. Должно отсутствовать програмное приложение к схеме, иконе(ам) - '
'. Должны отсутствовать "УзелПаралДействие", т.к. предусмотрено программирование.'
'. Отсутствует шампур к "УзелПаралДействий" - '
'. Веточный цикл не замкнут для икон(ы) "Адрес" - '

Вопрос - каким образом отлаженный? Очевидный путь с учётом развития верификации - проверять "модельную программу" (точную спецификацию), построенную подобно тому, как в этом примере, в среде верификации (кстати, там есть и применение инвариантов ). Но туда ещё надо выгрузить модельный текст... и без "кросс-операций" по "редактированию шаблонов".
Т.о. возвращаемся к описанному в этом сообщении. Главное - что все составляющие прогтекста должны визуализироваться без "программных приложений" - вне основного текста вершин только сведения для человека и атрибуты моделирования (если оно поддерживается) - и без специальной сборки. Обоснования см. здесь.
Да, в редакторе схем подобные проверки удобны... хотя некоторые обусловлены исключительно подходом к представлению описаний в Ты-среде.

Потребительская позиция (не интерес, а позиция) означает "я за вас свою работу делать не буду!"
Не прикидывайтесь, что не понимаете, о чём речь.

Ну и я использую, что с того?
Цель-то не достигается. Работать тяжело, выгоды в производительности нет, скорее, наоборот.

Возможно, было бы действительно интересно попробовать технологию Паронджанова в "чертёжно-бумажном" варианте формата А1. Но у меня нет ни принтера, ни бумаги таких размеров

Возможно, на ограниченном видуальном поле нужны какие-то принципиально другие решения.

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

Наверное, оговорка: "я за вас вашу работу делать не буду"
У меня тоже... поэтому использую старый добрый метод "рекле" - см. визуализацию здесь - так-то он большинству знаком Правда, в редакторе он д.б. поддержан... см. правила ДВ, ДЖ здесь.
Как и любой формальный текстовый язык, Хаскелл, очевидно, м.б. визуализирован... но т.к. это не язык "программирования напрямую", то надо смотреть оправданность и метод...

Нет, это классическое крылатое выражение, почти по-дзеновски описывающее взаимоотношения в социуме

Ну что ж, сопоставим подходы:


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

2. Все "в темах" разработки (хотя и переключаются между проектами). Что облегчает задачу и делает сочинителей/читателей менее требовательными к качествам среды (особенно программистов с учётом п. 1).

3. Судя по "выискивать", используется "наивная отладка", применение которой с позиций гарантоспособности д.б. ограничено "некризисными" задачами. Что получается, если этому не следовать - см. вторую часть этого сообщения.

4. Также высказана необходимость в эргономических улучшениях Ты-среды.

Т.о., никаких принципиальных расхождений со сказанным ранее мною.

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

Ясно
Кстати, по ИП-результатам, упомянутым здесь - выдержки дал в этом сообщении.

Алексей Донской пишет:
>Исходя из реальности - надо на дисплей ориентироваться.

Тогда что Вы, Алексей, можете сказать по поводу использования в программе
dal_vjaz минимизированной формы представления визуальной схемы и по поводу
структурно-текстового интерфейса ввода визуальной схемы ?