DRAKON.SU
https://forum.drakon.su/

Визуальный язык программирования ДРАКОН
https://forum.drakon.su/viewtopic.php?f=141&t=493
Страница 10 из 19

Автор:  Илья Ермаков [ Понедельник, 07 Апрель, 2008 21:49 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

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

Сергей, да ведь нет никакой разницы - образуется несуществующее значение позиции в предусловии (в случае UNTIL-цикла, перед которым значение позиции = "перед начальным элементом", -1) или в постусловии (в случае WHILE-цикла и неуспешного поиска, по окончании которого значение позиции = "после конечного элемента", LEN).

Автор:  Александр Ильин [ Понедельник, 07 Апрель, 2008 22:04 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Илья Ермаков писал(а):
Сергей, да ведь нет никакой разницы - образуется несуществующее значение позиции в предусловии ... или в постусловии ....
Зачем присваивать "-1" и тут же следующей операцией делать инкремент? Алгоритм работает верно, но понимабельность программы замусоривается.

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

Аналогичное правило можно сформулировать для отрицания (в обсуждаемом алгоритме не нарушается): чем меньше отрицаний в условии, тем легче оно воспринимается. Что проще понять: "~(a # b)" или "(a = b)"? В первом случае опять мозг должен выполнять интерпретацию, сокращать выражение, чтобы уяснить позитивный смысл: а что же автор хотел сказать.

Автор:  Сергей Оборотов [ Понедельник, 07 Апрель, 2008 22:14 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Владимир Паронджанов писал(а):
Давайте изменим ТЕКСТОВЫЙ синтакис. Мы имеем право менять его ЛЮБЫМ СПОСОБОМ, который сочтем подходящим (в пределах разумного).
Мне кажется, двигаясь таким путем, мы сможем достичь желанного консенсуса.
С уважением Владимир Паронджанов
Давайте. Зачем например ставить слова поясняющие варианты выбора на графической схеме. Не разумнее ли согласиться на что-либо иное? Из области схем, например.

Автор:  Info21 [ Вторник, 08 Апрель, 2008 09:03 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Александр Ильин писал(а):
Аналогичное правило можно сформулировать для отрицания (в обсуждаемом алгоритме не нарушается): чем меньше отрицаний в условии, тем легче оно воспринимается. Что проще понять: "~(a # b)" или "(a = b)"? В первом случае опять мозг должен выполнять интерпретацию, сокращать выражение, чтобы уяснить позитивный смысл: а что же автор хотел сказать.


Ну, если (a # b) это условие поиска, то как раз в WHILE лучше оставить вариант с отрицанием, потому что именно (a # b) будет предикатом, выполняющимся после завершения цикла, и сразу ясно, к чему мы стремимся -- это же важно :-)

Автор:  Александр Ильин [ Вторник, 08 Апрель, 2008 11:54 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Info21 писал(а):
Ну, если (a # b) это условие поиска, то как раз в WHILE лучше оставить вариант с отрицанием, потому что именно (a # b) будет предикатом, выполняющимся после завершения цикла, и сразу ясно, к чему мы стремимся -- это же важно :-)
Да, я писал об изолированных, отдельно стоящих условиях.

В вашем примере предикат и его отрицание визуально перекликаются, создавая позитивную связь - узнавание - между частями текста программы. Поэтому при чтении алгоритма не приходится преобразовывать ~(a # b) = (a = b), а значит, отрицание не скрывает смысл выражения, а помогает увидеть структуру алгоритма. Тут вы, Info21, конечно правы.

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

Автор:  Александр Ильин [ Вторник, 08 Апрель, 2008 13:36 ]
Заголовок сообщения:  Re:

Владимир Лось писал(а):
Ярослав Романченко писал(а):
Почем-бы не сделать гремучую смесь Дракон+Оберон?
О!бекон!
:о)

Дрон!

Автор:  Alexey_Donskoy [ Среда, 09 Апрель, 2008 13:57 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Посмотрел Дракон-редактор. Пока только с эргономической стороны.

1. Написать "if then else" в разы быстрее и проще, чем в Дракон-редакторе (даже с учётом потенциально возможных его усовершенствований).

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

3. Конструкции вида пары вложенных циклов (например, транспонирование матрицы или простейшая сортировка массива) мне представляются более читабельными в текстовом представлении.

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

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

Автор:  ==== [ Среда, 09 Апрель, 2008 19:24 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Alexey_Donskoy писал(а):
Посмотрел Дракон-редактор. Пока только с эргономической стороны.

1. Написать "if then else" в разы быстрее и проще, чем в Дракон-редакторе (даже с учётом потенциально возможных его усовершенствований).

Могу сказать следующее:
1. ДРАКОН это алгоритмический язык, а не язык программирования. Лучше именовать тему форума "Визуалный алгоритмический язык ДРАКОН".
2. Дракон-схема это алгоритм, т.е. определяет цели и действия для их достижения в конкретной области деятельности. Дракон-схема отображает знания и служит наглядным средством общения и взаимопонимания.
3. Если область деятельности виртуально переносится в компьютер, то приступать к программированию компьютера следует после завершения написания алгоритма в виде Дракон-схемы. Программировать следует в среде программирования.
4. Данная версия Дракон-редактора имеет дополнение в виде примечаний к элементам и уэлам. Программисту можно рекомендовать в примечаниях писать фрагменты декларативных и командных частей программного кода. Маршрутную часть кода писать не следует, т.к. она наглядно отображена Дракон-схемой. Смотрите сообщение Владимира Паронджанова от 04 апреля 2008 21:13 часть 4.

Спасибо всем, кто смотрит Дракон-редактор и делится своими впечатлениями.

Автор:  Илья Ермаков [ Среда, 09 Апрель, 2008 21:23 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Геннадий Тышов писал(а):
2. Дракон-схема это алгоритм, т.е. определяет цели и действия для их достижения в конкретной области деятельности. Дракон-схема отображает знания и служит наглядным средством общения и взаимопонимания.
3. Если область деятельности виртуально переносится в компьютер, то приступать к программированию компьютера следует после завершения написания алгоритма в виде Дракон-схемы. Программировать следует в среде программирования.

Да, но кто мешает делать "знания" непосредственно исполняемыми? Никто. Имеет смысл рассматривать это как цель.

Автор:  ==== [ Среда, 09 Апрель, 2008 22:05 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Илья Ермаков писал(а):
Да, но кто мешает делать "знания" непосредственно исполняемыми? Никто. Имеет смысл рассматривать это как цель.

Это проблема, не для Дракон-редактора, а для интегрирования производственного процесса. Элементами интеграции являются: разработчики, документация, программисты, средства программирования, исполняющий компьютер, система отладки программ и управляемого оборудования. Примером является система "Графит-флокс", о чем нам рассказал В. Паронджанов.

Вспомните о детях, которые учились и учиться по книге В. Пароджанова "Занимательная информатика". Книга с 1998 года выдержала 3 издания. Дети ждут Дракон-Редактор. Чтобы язык ДРАКОН и Дракон-редактор пришли в школу и высшую школу вместе с языком Компонентный Паскаль, надо рассказать о них на сайте "Информатика-21" http://www.inr.ac.ru/~info21/.

Программисты тоже не забыта, я писал выше. Можно создать программу, которая обработает выходной файл Дракон-редактора -.drt и сформирует текст программного кода.

Автор:  Alexey_Donskoy [ Четверг, 10 Апрель, 2008 09:48 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Геннадий Тышов писал(а):
Дети ждут Дракон-Редактор. Чтобы язык ДРАКОН и Дракон-редактор пришли в школу и высшую школу вместе с языком Компонентный Паскаль, надо рассказать о них на сайте...

Друзья! А вам не кажется такая позиция несколько безответственной?
Прежде, чем нести что-либо в школу, неплохо бы сначала убедиться, что это - лучшее из всего, что есть.
А также оценить последствия такого решения. Сколько поколений школьников изучали не Программирование, а просто Бейсик (за неимением? или за нежеланием? а ведь Форт был раньше Бейсика, и компактнее, и на два порядка интереснее... значит, просто за ограниченностью кругозора?). И каковы последствия сегодня?

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

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

В дополнение в сказанному вот какая оформилась мысль. В Драконе визуальная форма отрывается от содержания, она присутствует как бы отдельно и даже раньше. Это особенно хорошо видно при работе с Вашим редактором - можно нарисовать большую и... абсолютно пустую алгоритмическую схему. Которую потом можно заполнять... а можно и не заполнять... Предполагаю, что дело тут не в редакторе, просто он обострил и показал ещё одну интересную проблему. Я даже пока затрудняюсь оценить её значение, подумайте и над ней тоже!

Автор:  Илья Ермаков [ Четверг, 10 Апрель, 2008 10:41 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Alexey_Donskoy писал(а):
В дополнение в сказанному вот какая оформилась мысль. В Драконе визуальная форма отрывается от содержания, она присутствует как бы отдельно и даже раньше. Это особенно хорошо видно при работе с Вашим редактором - можно нарисовать большую и... абсолютно пустую алгоритмическую схему. Которую потом можно заполнять... а можно и не заполнять... Предполагаю, что дело тут не в редакторе, просто он обострил и показал ещё одну интересную проблему. Я даже пока затрудняюсь оценить её значение, подумайте и над ней тоже!

Ну, можно сказать, что имеем разделение алгоритма как системы на два уровня: структура связей и содержание в узлах этой структуры. Содержание может быть выброшено - останется чистая, предельно формальная структура. Соответственно (как и всё предельно формальное) - бессодержательная.

Автор:  Alexey_Donskoy [ Четверг, 10 Апрель, 2008 11:11 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Илья Ермаков писал(а):
Ну, можно сказать, что имеем разделение алгоритма как системы на два уровня: структура связей и содержание в узлах этой структуры. Содержание может быть выброшено - останется чистая, предельно формальная структура. Соответственно (как и всё предельно формальное) - бессодержательная.

Это-то понятно, а вот хорошо это или плохо? К каким последствиям может привести?

Автор:  Илья Ермаков [ Четверг, 10 Апрель, 2008 11:33 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

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

Автор:  Alexey_Donskoy [ Четверг, 10 Апрель, 2008 13:01 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

"Поэтому вопрос ещё уже: какие есть (если есть) отрицательные моменты?"

Еще Вы говорите о верифицируемости... Мне кажется, стоит обратить внимание вот на что. Предположим, я ошибся и использовал не ту переменную... Взвел не тот флаг, вместо переменной цикла взял что-то другое... Ошибки такого рода достаточно гнусные и имеют большой вес как в смысле последствий, так и затрачиваемых ресурсов на отладку...
Так вот, визуальный алгоритмический язык вообще никак не помогает здесь. То есть подобные ошибки находятся в слое, ортогональном алгоритмическому. Но я скажу больше - намеренное выделение алгоритмического слоя задачи в "чистую форму" провоцирует подобные ошибки.

Автор:  TMX [ Четверг, 10 Апрель, 2008 16:18 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Мы используем ДРАКОН около трех лет в проектах для встроенных систем на микроконтроллерах.
Пишем на С.
Рисуем в Edge Diagrammer на высоту листа. Печатаем, склеиваем, складываем гармошкой.
ДРАКОН очень удобен для представления конечных автоматов, в частности протоколов.
Рассматривали другие варианты: в основном, UML, иерархические диаграммы состояний и т.п. Понравилось меньше, хотя к ним есть CASE-средства, тот же IAR VisualState, например. Также есть SWITCH-технология ШАлыто, HSM Самека и др.
Большинство из них требует реализации среды исполнения, поскольку ориентированы на события.
Как раз контроль за изменением переменных очень удобно отслеживать по диаграмме.
Особенно если они обозначены разными цветами и расположены на одном уровне по горизонтали.
Использование ДРАКОНа значительно сокращает время на отладку, основное время затрачивается на этапе рисования и обдумывания алгоритма.
Особенно полезно, когда заказчик вносит (несущественные по его мнению) изменения в первоначальные требования в алгоритм, реализованный на десятке влияющих друг на друга автоматов с десятками состояний каждый.
В примерах использования редактора Тышова заметил, что присвоения делаются с помощью значка ДЕЙСТВИЕ. Для этого есть ПОЛКА - по внешнему виду сразу ясно, что переменная изменила значение, собственно, поэтому не тот флаг на этапе проектирования взвести трудно. А на этапе верификации - пишешь лог состояний и легко и просто отслеживаешь.

Автор:  Илья Ермаков [ Четверг, 10 Апрель, 2008 16:25 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

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

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

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

Автор:  Alexey_Donskoy [ Четверг, 10 Апрель, 2008 20:39 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

TMX писал(а):
Мы используем ДРАКОН около трех лет в проектах для встроенных систем на микроконтроллерах. Пишем на С.
Замечательно! А вот самое первое, что прямо напрашивается при программировании контроллеров - CoDeSys - Вы не рассматривали? Там, конечно, из 5 МЭКовских языков визуальных средств только два - FBD и потоковые диаграммы, но всё же?

TMX писал(а):
Также есть SWITCH-технология ШАлыто
А это реально пробовали? Ведь тоже интересная штука!

Автор:  Илья Ермаков [ Четверг, 10 Апрель, 2008 21:17 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

Да-да, вот про Шалыто очень интересно было бы услышать мнение!

Автор:  TMX [ Четверг, 10 Апрель, 2008 21:38 ]
Заголовок сообщения:  Re: Визуальный язык программирования "Дракон"

FBD мало приспособлено к автоматам, а они нужны.
Релейную логику использовать вообще тяжело.
Для CoDeSys нужно на контроллер среду исполнения портировать, преимуществ не вижу, если нет необходимости ПЛК делать. Опять же денег стоит.
И вообще эти языки МЭК ориентированы на задачи АСУ - достаточно типовые. Да и языки не самые лучшие.
Можно использовать IL для организации ВМ, но зачем использовать не очень удачную архитектуру процессора, когда для ВМ стековый гораздо удобнее?
Можно использовать ST, но С его победит.
Да и Forth еще жив.

Насчет SWITCH-технологии:
Изучил книжку, написанную Шалыто и сайты Softcraft и ЛИТМО. Много думал.
И понял: Шалыто - профессор, убеленный сединами.
А я - нет.
Мне вот тяжело ориентироваться в логических выражениях - условиях переходов. Хотя, может, они и позволяют минимизировать автомат впоследствии.
Да и выражение автомата через switch - не лучший способ в С.
В общем, не нашел в себе сил овладеть инструментом, предлагаемым Шалыто.

Страница 10 из 19 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/