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/ |