DRAKON.SU

Текущее время: Пятница, 24 Март, 2017 20:55

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 375 ]  На страницу Пред.  1 ... 7, 8, 9, 10, 11, 12, 13 ... 19  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 07 Апрель, 2008 21:49 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 626
Откуда: Россия, Орёл
Сергей Губанов писал(а):
В данном случае, я был несогласен с выбором в качестве предусловия несуществующее значение позиции "минус один" когда ясно что должен быть ноль.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Апрель, 2008 22:04 
Аватара пользователя

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

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

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


Последний раз редактировалось Александр Ильин Понедельник, 07 Апрель, 2008 22:15, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Апрель, 2008 22:14 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Апрель, 2008 09:03 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Александр Ильин писал(а):
Аналогичное правило можно сформулировать для отрицания (в обсуждаемом алгоритме не нарушается): чем меньше отрицаний в условии, тем легче оно воспринимается. Что проще понять: "~(a # b)" или "(a = b)"? В первом случае опять мозг должен выполнять интерпретацию, сокращать выражение, чтобы уяснить позитивный смысл: а что же автор хотел сказать.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Апрель, 2008 11:54 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 189
Откуда: Россия, Санкт-Петербург
Info21 писал(а):
Ну, если (a # b) это условие поиска, то как раз в WHILE лучше оставить вариант с отрицанием, потому что именно (a # b) будет предикатом, выполняющимся после завершения цикла, и сразу ясно, к чему мы стремимся -- это же важно :-)
Да, я писал об изолированных, отдельно стоящих условиях.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re:
СообщениеДобавлено: Вторник, 08 Апрель, 2008 13:36 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 189
Откуда: Россия, Санкт-Петербург
Владимир Лось писал(а):
Ярослав Романченко писал(а):
Почем-бы не сделать гремучую смесь Дракон+Оберон?
О!бекон!
:о)

Дрон!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Апрель, 2008 13:57 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 863
Откуда: Россия, Чебоксары
Посмотрел Дракон-редактор. Пока только с эргономической стороны.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Апрель, 2008 19:24 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Alexey_Donskoy писал(а):
Посмотрел Дракон-редактор. Пока только с эргономической стороны.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Апрель, 2008 21:23 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 626
Откуда: Россия, Орёл
Геннадий Тышов писал(а):
2. Дракон-схема это алгоритм, т.е. определяет цели и действия для их достижения в конкретной области деятельности. Дракон-схема отображает знания и служит наглядным средством общения и взаимопонимания.
3. Если область деятельности виртуально переносится в компьютер, то приступать к программированию компьютера следует после завершения написания алгоритма в виде Дракон-схемы. Программировать следует в среде программирования.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 09 Апрель, 2008 22:05 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Илья Ермаков писал(а):
Да, но кто мешает делать "знания" непосредственно исполняемыми? Никто. Имеет смысл рассматривать это как цель.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 09:48 
Аватара пользователя

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 10:41 
Модератор
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 11:11 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 863
Откуда: Россия, Чебоксары
Илья Ермаков писал(а):
Ну, можно сказать, что имеем разделение алгоритма как системы на два уровня: структура связей и содержание в узлах этой структуры. Содержание может быть выброшено - останется чистая, предельно формальная структура. Соответственно (как и всё предельно формальное) - бессодержательная.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 11:33 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 626
Откуда: Россия, Орёл
В принципе, видны плюсы. Когда что-то видим явно и отдельно, то легче это запомнить, узнать, сравнить, провести ассоциации-аналогии (узнавание одинаковых алгоритмических схем), верифицировать и т.п.... Поэтому вопрос ещё уже: какие есть (если есть) отрицательные моменты?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 13:01 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 863
Откуда: Россия, Чебоксары
"Поэтому вопрос ещё уже: какие есть (если есть) отрицательные моменты?"

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 16:18 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 16:25 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 626
Откуда: Россия, Орёл
Alexey_Donskoy писал(а):
То есть подобные ошибки находятся в слое, ортогональном алгоритмическому. Но я скажу больше - намеренное выделение алгоритмического слоя задачи в "чистую форму" провоцирует подобные ошибки.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 20:39 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 21:17 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 626
Откуда: Россия, Орёл
Да-да, вот про Шалыто очень интересно было бы услышать мнение!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 10 Апрель, 2008 21:38 

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 375 ]  На страницу Пред.  1 ... 7, 8, 9, 10, 11, 12, 13 ... 19  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2016, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB