DRAKON.SU

Отладил простейший алгоритм подавления дребезга контактов.

Хочу поделиться как это выглядит на ИС ДРАКОН и как в традиционном представлении (код в Arduino IDE написан по общепринятым правилам с комментариями).

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

Суть алгоритма в том, что при появлении на цифровом выводе Arduino сигнала (на важно переход от 0 к 1 или обратно), делаем повторную проверку через 20 миллисекунд (достаточное время даже для плохой кнопки). И если через 20 мс подтвердится переход (от 0 к 1 или обратно), то выполняем какое-либо действие (в моем случае это выдача на терминал 0 или 1 для визуального контроля).
По сути это алгоритм, который отслеживает момент изменения фронта импульса. Алгоритм не использует прерывания. Так же не тормозит выполнение другого полезного кода и позволяет легко подключать от 1-й до любого количества кнопок (сколько памяти хватит). Руками надо только прописать количество кнопок и номера выводов микроконтроллера.

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


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

Андрей, как получен код на Си?
Вы его руками написали?
Или он получен автоматически из дракон-схемы на выходе ИС Дракон?

Comdiv, относятся ли эти слова к дракон-схеме?

Сначала поправлюсь, что речь была о логике предикатов, а не высказываний.

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

Comdiv, прежде всего, я хочу поблагодарить вас за участие в обсуждении.

Теперь по сути. Я не знаю, как был получен код на Си. Предположу, что он был получен автоматически из дракон-схемы.

В этом случае качество Си-кода не играет роли. Исходным кодом считается дракон-схема, и только она. На Си-код можно не смотреть, точно так же, как мы не смотрим на машинный код после компиляции.

Данная дракон-схема нарисована правильно, ибо она не содержит знаков И, ИЛИ, НЕ (которые являются потенциальным источником ошибок), реализуя принцип "конъюнкция без знака конъюнкции" и "дизъюнкция без знака дизъюнкции".

Цель языка ДРАКОН — облегчить понимание алгоритмов и программ ЧЕЛОВЕКОМ. Вторая цель — сократить число ошибок.

ДРАКОН не может конкурировать с другими языками по таким критериям как быстродействие, экономия памяти, скорость написания программы. Возможно, ДРАКОН может уменьшить время на отладку программы.

Comdiv, что вы об этом думаете?

Думаю, что в ряде случаев ДРАКОН может облегчить понимание. Во многом, это зависит от конкретного человека и от конкретного языка программирования, который служит наполнением для схемы.
Но в этом примере я увидел обратное. Посмотрев на схему, я понял, что мне легче понять код на C. Увидев недостатки в коде и уже поняв суть, я посмотрел на схему и увидел, что именно ДРАКОН спровоцировал появление этих недостатков. То есть, недостатки есть не только в сгенерированном коде, но и в исходной схеме.

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

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

Тем не менее, я уверен, что ДРАКОН был бы полезен для понимания программы, как минимум, при выполнении обратной задачи - визуализации кода в виде схемы.

Можно ли подкрепить это утверждение ссылками на литературу?

Мне известны ссылки на опасность ошибок именно в логических выражениях.
====================

Как известно, логическое отрицание представляет определенную трудность для понимания. В связи с этим Эдвард Йодан советует:

Опасность ошибочного понимания провоцируют не только знаки отрицания, но и другие связки. Поэтому Йодан расширяет и усиливает свою мысль:

Сходные предостережения делает не только Йодан. Его поддерживает Гленфорд Майерс:

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


Не смог сходу найти оригиналы цитат. Без этого неясно ни контекста, ни на что указывают ссылки. На результаты корректных исследований, некорректных исследований или на высказывание мнений?

Это просто "вода". Поэтому что является подмножеством обобщённого совета:

Избегайте без нужды использования сложного ЧЕГО УГОДНО. Такое сложное ЧТО УГОДНО многие понимают с трудом.Переусложнённый поток выполнения, являющийся результатом недопонимания логики тоже подпадает под это правило.

[10] Йодан Э. Структурное проектирование и конструирование программ. / Пер. с англ. / Под ред. Л.Н. Королева. — М.: Мир, 1979. – 415 с. — С. 252.

[11] Майерс Г. Надежность программного обеспечения / Пер с англ. / Под ред. В.Ф. Кауфмана. — М.: Мир, 1980. — 360 с. — С. 292.

Мое собственное изучение этого вопроса см.

стр. 124 – 183 https://drakon.su/_media/24_zhizneritm20.pdf

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

Извиняюсь что раньше не написал (был очень занят).

Код на Си написан руками уже после того как Дракон-схема была завершена (т. е. первоисточник схема). Я не пытался оптимизировать код на Си, а набросал его так, как делают большинство неопытных программистов (к числу которых я тоже отношусь).

Полностью с Вами согласен.
Более того я не знаю что такое: логика высказываний и неструктурные переходы.

Это сильно простой пример, давайте на минуту представим что код будет сложнее, например 5 принципиально разных алгоритмов подавления дребезга контактов которые перебираются покуда гарантировано не подавят этот самый дребезг.
Вы (профи) написали 80% кода и по какой-то причине ушли с фирмы или предприятия. Программиста вашего уровня нет и не предвидится. Мне (любителю) надо закончить и отладить.
Если алгоритм в виде ДРАКОН схемы, то разобраться как это работает любителю под силу. А значит можно закончить работу. Да пусть не так быстро.
Если же код на Си и писал опытный человек, то ищи минимум такого же по уровню знаний. Тут мне кажется без вариантов. А нет профи то и работа станет. Как сказал один умный человек: "Кадры решают все".

Это исключительно мое мнение и пишу это я больше для себя, чтобы лучше понять.

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

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

Хорошая мысль. Об этом же говорил и Уильям Оккам:
„Нельзя применять многочисленности без необходимости.“
„Не следует привлекать новые сущности без крайней на то необходимости.“

Ответ на это давно написан. Но к сожалению не все его читали.
https://drakon.su/_media/biblioteka/dra ... iption.pdf
Страница 111.
Собственно сам ответ.
ВЫВОДЫ
1. В алгоритмах со сложной логикой часто используются условные операторы с логическими выражениями. Опыт показывает, что такие операторы во
многих случаях трудны для понимания, что нередко приводит к ошибкам.
2. В языке ДРАКОН используются визуальные логические выражения, позволяющие при желании полностью исключить логические связки И,
ИЛИ, НЕ из условных операторов.
3. Визуализация логических формул во многих практически важных случаях
заметно облегчает их понимание и уменьшает вероятность ошибок.

Это не ответ. Вы используете ту же тактику, что и Владимир Даниелович - приводите цитаты, не относящиеся к делу под прикрытием близости темы.

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

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

Их этого следует несколько важных выводов.

Человеку лучше и привычней воспринимать информацию визуально. Конечно. Есть уникумы. Короые лучше воспринимают текстовую информацию, а не визуальную.

Но дело тут вот в чем. Те люди. Которые сейчас начинают работать на Драконе. Как правило, уже имеют какую либо подготовку в других языках. СИ, Бейсик, Ассемблер и тд и тп.

И им сложно перестроить мышление. Отсюда и идут требования дайте нам подсветку синтаксиса и все такое. То есть, они пытаются работать с Драконом. Но на ТЕКСТОВОМ языке... А переучиваться сложно...

С другой стороны. Те, кто воспринимает Дракон. Ничего не понимают в программировании.

Смычка, связка этих понятий приходит тогда. Когда появляется некто. Кто дает реальный пример работы именно в связке Дракона, и конкретного языка. Как например здесь.
viewtopic.php?f=233&t=6833

Прорыв будет тогда. Когда появятся уроки. Которые от простого к сложному. Проведут эту цепочку. И вот именно тогда это станет легко и просто. И будет непонятно. А как же можно по другому... Столько мучились.

А вот автор выше приведенного кода. Может лично убедиться в эквивалентности текстового и графического представления кода. Если переведет его на язык Дракон. Ибо никто лучше автора не знает суть данного конкретного алгоритма. Но имея предварительную подготовку именно на СИ. Ему сложно представить это в графическом виде...

И что интересно. Я не говорю о том что нужно или СИ, или Дракон. Нужно знать и то и то. И умело применять в связке. А вот преимущества Дракона. Проявятся очень быстро. С ростом сложности проекта. Так как удержать в голове и манипулировать большими объёмами текста. Несопоставимо сложнее. Чем графическими Образами. При том же мыслительных способностях того. Кто решает эту задачу.

Я бы и сам сделал это преобразование. Но у меня все еще впереди. Я только начал изучать СИ. Хотя с Драконом работаю давно и плотно. Применяя его везде по жизни.

Спорить в подобных случаях сложно. Так как во многом, это субъективные моменты. И у каждого свои источники ошибок. Как и свои способы их избежать.

Соответственно. С тем, что бы был предмет для спора. Должна быть статистика. Как, и по чему, и сколько ошибок возникает. Я такой статистики не встречал.

Но опираясь на собственный опыт использования Дракона. Могу уверенно утверждать. При обьеме кода если скажем в попупаях. Или с строках на СИ где-то порядка ста тысяч. Вычитывать текст и выискивать эти И ИЛИ НЕ. Сложно.

Особенно когда не только сроки горят (а горит то, что гореть не должно), и не только кофе не помогает. Но и то, что раньше не помогало, уже не мешает. Сложно. Гораздо проще не употреблять то, что раньше помогало. Но идти царской дорогой, а не с точностью до наоборот. Спотыкаясь об эти И ИЛИ НЕ. Отвечая на вопросы. Которые ты сам себе и задал. Гораздо проще, легче, и быстрее. И в таком разе, труднее ошибиться.

А если по сути. То я думаю заметно. Что используя И ИЛИ НЕ. Можно как прояснить суть дела. Так и затруднить понимание вопроса. Как выше приведенный текст. А вот в случае визуального представления выполненного по правилам Дракона. Сразу бросаются в глаза логические противоречия, невязки, и абсурдность того, что написано абзацем выше.