Comments 585
Не взлетит.
Визуальное программирование попросту неудобно по сравнению с текстом. Раньше (лет 25 назад) считалось, что удобнее, но опыт (и низкая распространённость сред визуального программирования) говорит об обратном.
Ни разу не встречал, чтобы при программировании текстом кто-то перепутал if и while, ну или else и for. Обычно труднонаходимые ошибки — это ошибки индексации (i вместо i-1), перепутанные переменные (i вместо j), перепутанные константы (PI вместо TWO_PI), перепутанные операции (* вместо **), перепутанный порядок операций (в сложных случаях). Визуальное программирование от этого не спасёт.
впрочем, один совет Паронджанова «использовать многосимвольные имена потому, что современные программы позволяют использовать для имен больше 8 символов, аж до 32» (источник не назову сходу, но один из его опусов) — уже показывает, на каком уровне дремучести оно находится. И да, «верификация дуракон-схемы осуществляется путем тщательного просматривания человеком»(это с изи-электроникс — там, правда, ветку после битв почистили изрядно, много перлов пропало)
Пользуюсь таким автоматизатором (Automagic) на телефоне: программируются разные задачи в визуальном стиле. Что-то простое делается на коленке на раз-два, а вот более сложные задачи создавать и отлаживать достаточно сложно.
Начиная с определенного количества блоков, которое достигается достаточно быстро, отладка в таком визуальном конструкторе превращается в адский треш.Это не так.
1. В ДРАКОНе есть мощные средства визуальой декомпозиции.
2. Я уже писал в статье, процитирую еще раз:
Индивидуальный предприниматель Сергей Ефанов:
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу!
Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!
В тексте на Си ее было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!
Я уже писал в статье, процитирую еще раз:
Без конкретного примера:
- задачи
- исходного кода
- получившегося кода
этот пример является всего лишь субъективным высказыванием одного человека.
Индивидуальный предприниматель Сергей Ефанов:
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу!
Взрослый же человек — неужели не понимаете, что это звучит как рекламный трэш?
"У меня были проблемы с финансами. Но после советов Дракона они немедленно пропали! Оказывается, у меня были проблемы с мотивацией, я не мог правильно организовать свою жизнь и не замечал своих ошибок, а теперь я их заметил и могу все организовывать!"
Фу.
UPD
Что всегда было забавно во фриках — это их способность к организации набегов и лайк-дизлайк-баттлов. Даже тогда, когда очевидно, что публика совершенно не впечатлена (и не будет) очередной «инновацией», «единой теорией всего», «универсальным средством» и т.п. А Министерство обороны, внезапно, денег не дало :-)
Взрослый же человек — неужели не понимаете, что это звучит как рекламный трэш?Это цитата из статьи Сергея Ефанова "Программирование микроконтроллеров на ДРАКОНе", которая приведена в разделе литература. Там есть четыре видео, где все подробно показано с кодами.
Ну вот пойдем в статью, нам не сложно.
Всё, что нужно — аккуратно запрограммировать ОДНУ икону. Только ОДНУ! Когда будем программировать другую — про предыдущую уже можно не вспоминать.
Это равносильно утвеждению "нужно аккуратно запрограммировать один модуль, когда будем программировать другой — про предыдущий можно не вспоминать". Работает в любом языке программирования.
Точнее, как — не работает, а "работает". Потому что, внезапно, в реальном мире модель оказывается слишком сложным, чтобы с ним можно было взаимодействовать только по его названию.
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу!
Это может означать, что автор кода не вполне осилил синтаксис языка. Такое возможно, если у человека основной род деятельности — не программирование. Но это редкий случай для профессиональных программистов.
Но это редкий случай для профессиональных программистов.Почему же редкий? Сплошь и рядом.
Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования, погубили 346 человек.
Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования, погубили 346 человек.
пожалуйста, перестаньте передергивать — это Вам очков не добавляет
пожалуйста, перестаньте передергивать — это Вам очков не добавляетПрошу прощения, но я не понял, в чем заключается передергивание.
Боинг погиб из-за ошибки в алгоритмах.
Кто в этом виноват?
Может быть, вы хотите сказать, что в этой ошибке виноват кто угодно, но только не профессиональные программисты, так как последние не ошибаются? Или у вас другая мысль?
Прошу прощения, но я не понял, в чем заключается передергивание.
Боинг погиб из-за ошибки в алгоритмах.
Кто в этом виноват?
никто не отрицает вины разработчика (= компании Боинг)
Речь о том, что пиариться на этом и продвигать свое решение — тупик, потому что ДРАКОН не решает проблему корректности алгоритма в целом. Garbage in — garbage out.
Может быть, вы хотите сказать, что в этой ошибке виноват кто угодно, но только не профессиональные программисты, так как последние не ошибаются? Или у вас другая мысль?
заканчивайте, пожалуйста. Ошибаются все, к сожалению.
Боинг погиб из-за ошибки в алгоритмах.
Насколько я помню, были организационные проблемы то ли с ТЗ, то ли с процессом тестирования. Что бы исправил ДРАКОН?
Алгоритмы находятся внутри компьютеров и выполняются автоматически.
Жизнеритмы описывают поведение людей в разнообразных бизнес-процессах. Нужно иметь и то, и другое. Необходимо тщательно сопрягать алгоритмы и жизнеритмы.
При создании и эксплуатации самолета 737 МАХ понятие «жизнеритмы» охватывает следующую группу процессов:
— внутренние бизнес-процессы фирмы Боинг, описывающие взаимодействие работников различных отделов и подразделений фирмы друг с другом;
— бизнес-процессы, регламентирующие взаимодействие сотрудников фирмы Боинг и Федеральной авиационной администрации FAA;
— бизнес-процессы, описывающие взаимодействие сотрудников Боинга с авиакомпаниями и другими контрагентами;
— бизнес-процессы, регламентирующие обучение и сертификацию пилотов самолета 737 МАХ, в том числе, в критических и нештатных ситуациях полета.
Жесткое требование
Анализ алгоритмов и жизнеритмов должен показывать реальное состояние дел и демонстрировать упущения, ошибки и слабые места.
Это очень жесткое требование. Двойная авария лайнера 737 МАХ показала, что данное требование не выполняется. Алгоритмы и жизнеритмы не позволили заблаговременно выявить и устранить недостатки, допущенные при разработке и эксплуатации самолета 737 МАХ.
ДРАКОН позволяет улучшить обе составляющие: и алгоритмы, и жизнеритмы с помощью единой нотации и (почти) единой математики.
ДРАКОН позволяет улучшить обе составляющие: и алгоритмы, и жизнеритмы.
нет, не может (фейспалм)
ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B4%D0%B0%D1%81%D1%82%D0%B5%D1%8F
тоже, кстати, декларировала «улучшение ума»:
Я разработала метод, с помощью которого можно брать дополнительное время и вводить это время себе в мозг и затем этот мозг начинает работать в более ускоренном режиме. Тем самым человек начинает видеть больше, помнить больше, успевать больше.(ц)
1. Бизнес-процессы (жизнеритмы). В отличие от должностных инструкций, диаграмм BPMN и прочего, ДРАКОН отвечает исполнителю на вопрос: Что конкретно мне делать сейчас?
2. ТЗ. ДРАКОН объясняет, как работает эта хрень.
Так это ЯП или религия?
Очередная вещь, решающая всё с точки зрения её адептов, но почему-то напрочь игнорирующая один важнейший аспект программирования, неочевидный для непрограммистов и изучаемый программистами на 2м курсе вуза… Фтопку.
мне кажется, что для начала автору ДРАКОНа надо избавиться от методов и привычек инфоцыган, но, видимо, это настолько спорное решение, что других вариантов популяризировать его нет
Это визуальный язык алгоритмов. Математика + эргономика.
Упомянутые в статье аксиомы-силуэты звучат как какое-то фричество, если честноСначала уточню. Не «аксиомы-силуэты». В статье говорится про две аксиомы языка ДРАКОН, из которых математически выводится графика любого дракон-алгоритма.
Они называются «аксиома силуэт» и «аксиома-примитив». Я рад, что вы на них обратили внимание. Спасибо.
Насчет фричества. Все привыкли, что аксиомы пишут текстом, а не картинками. Так что ваше недоумение понятно.
Вы заметили явное отступление от укоренившейся традиции. И обратили на это внимание. Это хорошо.
Тем не менее, это строгая математика. Самая настоящая математика, хотя, конечно, непривычная.
Если вы заинтересуетесь это новой областью математической логики, я готов вам всячески помогать.
Матлог — это хорошо. Где можно максимально сжато почитать про соответствующую логическую систему? Хочется что-то в стиле такого описания, если можно — по непонятным словам я потом дальше сам буду гуглить (или спрашивать вас).Мои данные Паронджанов Владимир Данилович
Почта vdp2007@bk.ru
Тел. +7-916-111-57
Звонить в любое время дня и ночи.
Поясню аксиоматический метод ДРАКОНа за 2 шага.
Шаг 1. Теоретическое введение из книги Ершова и Палютина.
Ершов Ю.Л., Палютин Е.А. Математическая логика. — М.: Наука, 1079. — 320 с. — С.12, 13.
Основным итогом деятельности в области оснований математики можно считать становление математической логики как самостоятельной математической дисциплины, а принципиальным достижением математической логики — разработку современного аксиоматического метода, который может быть охарактеризован следующими тремя чертами:
1. Явная формулировка исходных положений (аксиом) той или иной теории.
2. Явная формулировка логических средств (правил вывода), которые допускаются для последовательного построения (развертывания) этой теории.
3. Использование искусственно построенных формальных языков для изложения всех положений (теорем) рассматриваемой теории…
Введение и использование подходящих обозначений было на протяжении всей истории математики весьма важной и продуктвной процедурой…
Основным объектом изучения в математической логике являются различные исчисления.
В понятие исчисления входят такие основные компоненты, как:
а) язык (формальный) исчисления;
б) аксиомы исчисления;
в) правила вывода…
Еще одним замечательным достижением математической логики является нахождение математического определения понятию алгоритма…
Изучение исчислений составляет синтаксическую часть математической логики…
Наряду с синтаксическим изучением исчислений проводится также семантическое изучение формальных языков математической логики.
Основным понятием семантики является понятие истинности для выражений (формул, секвенций и т. п.) формального языка.
Шаг 2. Ссылка на мою книгу. См. Глава 32. ИСЧИСЛЕНИЕ ИКОН — НОВЫЙ МЕТОД ПРЕДОТВРАЩЕНИЯ ОШИБОК Стр. 303 и далее.
Просьба сориентировать меня. Собираетесь ли вы писать и защищать диссертацию на эту тему?
Но корректная схема (корректный синтаксис) не гарантирует корректного алгоритма, трансляции в корректную программу и соответствия схемы спецификации.
Аналогия в текстовом программировании — корректный синтаксис программы.Да, аналогия безусловно есть. Тем не менее, мне кажется, что графический синтаксис ДРАКОНа обеспечивает ( своих рамках, т.е. в рамках управляющих конструкций) более полные правила контроля, чем синтаксис текстового языка программирования. Каково ваше мнение?
Каково ваше мнение?
Нет, не обеспечивает.
Поэтому отказываться от более компактного и легко переносимого отображения кода, удобной отладки, системы управления версиями, возможности работать с текстом программы в любом текстовом редакторе только ради избегания мизерной доли процента синтаксических ошибок — это не самая лучшая идея.
Поэтому отказываться от более компактного и легко переносимого отображения кода, удобной отладки, системы управления версиями, возможности работать с текстом программы в любом текстовом редакторе только ради избегания мизерной доли процента синтаксических ошибок — это не самая лучшая идея.Я понял ваши слова так: да, графический синтаксис ДРАКОНа, действительно обеспечивает в своих рамках более полные правила контроля, но это составляет мизерную долю процента, так что овчинка выделки не стоит.
Я правильно понял вашу мысль?
действительно обеспечивает в своих рамках более полные правила контроля,
Не обеспечивает и это было доказано выше, но Вы аргументы не воспринимаете (
Но по сравнению с IDE с подключённым стайлгайдом он и это преимущество теряет напрочь.
При этом во всём, что не относится к синтаксису управляющих конструкций, у дракона нет никаких преимуществ, одни недостатки.
Да. Дракон может дать мизерное преимущество в контроле синтаксисаВы говорите о текущем состоянии дел.
Забудем на минутку о дне сегодняшнем. И поговорим о возможности развития.
Мизерное преимущество ДРАКОНа в дополнительном контроле — что это такое?
Я понимаю это так. Это значит, что удалось некоторую часть семантики (пусть мизерную) формализовать и перевести из области семантики в область синтаксиса.
Если это так, то это означает рождение новой области: преобразовать порцию семантических правил в синтаксические.
Может быть, на этом пути удастся найти еще одну или несколько порций и преобразовать их в синтаксические правила.
Каково ваше мнение?
Я говорю именно о синтаксических ошибках, например незакрытой фигурной скобке, которые устраняются за счёт автоматической генерации.
Ну и, полагаю, при текущей скорости развития раньше появится искусственный интеллект, создающий программы по техническому заданию произвольной формы, чем дракон дорастёт до коммерческого уровня.
Я понимаю это так. Это значит, что удалось некоторую часть семантики (пусть мизерную) формализовать и перевести из области семантики в область синтаксиса.
Это, вообще-то, основа любого языка программирования — выражение части семантики через синтаксические элементы.
Если это так, то это означает рождение новой области: преобразовать порцию семантических правил в синтаксические.
В том-то и дело, что не новой. Это существующая область, которая уже имеет выражение в существующих языках программирования.
Вот в логике есть такое понятие, как ложь.Да, истина и ложь (истинность или ложность) или 1 и 0. Это азы.
В ДРАКОНе эти понятия имеются и активно используются.
Но. ДРАКОН настроен на упрощение терминологии, там, где это возможно.
Поэтому в ДРАКОНе слово Истина заменяется на Да, а слово Ложь заменяется на Нет (в подавляющем большинстве случаев).
В связи с вашим вопросом (про ложь и истину). Про это написано в той же самой моей книге, но в другом месте — в части 3.
Это тоже математическая логика, но это новый раздел матлогики — визуальная математическая логика.
Часть 3. Алгоритмическая логика. Математическая логика в алгоритмах. Визуальная алгебра логики
Глава 12. Логические операции И, ИЛИ, НЕ
Глава 13. Логическая функция И
Глава 14. Логическая функция ИЛИ
Глава 15. Как удалить логические связки из логических выражений
Глава 16. Канонические логические схемы
Глава 17. Логическая функция «исключающее ИЛИ»
Глава 18. Сложные логические функции
Вы мне сделали прямо физически больно. Начать с того, что нельзя приравнивать истину или ложь к 1 или 0 по очевидным причинам. Или к «да» и «нет»
Далее идёт история, что должен быть способ описания отсутствия чего бы то ни было в языке (None, Null сюда).
Нам в целом мысль коллеги 0xd34df00d была намного глубже
нельзя приравнивать истину или ложь к 1 или 0 по очевидным причинам.Я вовсе не приравнивал Истину и Ложь к 1 и 0.
С чего вы взяли?
Имеется в виду, что в таблицах истинности иногда пишут 1 и 0, а иногда И и Л.
В ДРАКОНе в таблицах истинности можно писать Да и Нет. Посмотрите в моей книге Алгоритмы и жизнеритмы Часть 3. Алгоритмическая логика.
Там на 70 страницах все это подробно разжевано.
Если найдете хоть одну ошибку или неточность, сообщите. Буду благодарен.
Желаю вам физически не болеть и не переживать по пустякам.
Нет, у меня с диссерами не сложилось.Значит, вы думали об этом, но не сложилось.
Предлагаю вам тему диссертации:
«Визуальная математическая логика как теоретическая основа визуального алгоритмичческого языка ДРАКОН».
Это новое научное направление, диссертация в ученом совете пройдет на ура. Если вам это интересно, я составлю для вас план диссертации.
Защищаться вам можно, например:
— в Институте системного программирования Российской академии наук;
— или на кафедре системного программирования матмеха Санкт-Петербургского университета.
Если хотите, я переговорю с руководителями. Подумайте.
Где конкретно там математика?
Так это ЯП или религия?Это некорректное утверждение.
Очередная вещь, решающая всё с точки зрения её адептов
Я никогда не говорил (и не мог сказать), что ДРАКОН решает все.
Такие преувеличения можно встретить только у некоторых уважаемых оппонентов, участников нашей дискуссии, которые в отдельных случаях сплошь и рядом приписывают мне якобы сказанные мной различные несообразности.
впрочем, достаточно посмотреть на уровень тех, кто этим самым дураконом пользуется. Например, на того же упомянутого Ефанова — он же вываливал свой код? Араптанов, который еще смешнее?
Более того, вы сами надураконили в своей же собственной дуракон-схеме проверки летающей тарелки «полет навстречу взрыву».
Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программированияспециалистам по проектированию алгоритмов совсем не нужно знать синтаксис языка программирования.
Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования, погубили 346 человек.
Это не опровергает мой тезис о том, что визуальное программирование неудобно и не годится для серьёзного программирования. Конечно, если бы самолёт не был бы создан, то он бы не потерпел крушение!
Главный недостаток: разработчик сильно оторван от практики. Язык выходит оригинальный, местами интересный, но совершенно непрактичный.
Третий недостаток: отсутствует стандарт языка ДРАКОНБезошибочность без стандарта. Отлично.
Из тысячи? Я видел проекты на несколько миллионов строк. Пожалуй, мне даже не интересно увидеть такую блок-схему.
А вообще в универе очень бесило, когда к лабораторным надо было рисовать эти блок-схемы.
Кажется, в "Мифическом человеко-месяце" (ЕМНИП) было написано, что блок-схемы устарели ещё в 1960х. Так что, это бесило не только вас, но и несколько предшествующих поколений программистов!
Кажется блок-схемы изначально были придуманы чтобы всех бесить. Как и рамочки по ЕСКД и прочая дичь. Все это добро — на месте. ВУЗы — просто погибают. Видно изнутри очень четко, я все еще пытаюсь там "сеять разумное" и прямо вот беда в этой части. Государство — это ужас.
Очевидны и ясны ошибки проектирования системы образования вообще-то. И на уровне отбора кадров, и на уровне финансирования, и в плане целеполагания. Три толковых спеца легко и просто заменят кафедру на 30 человек, ну уж в IT — точно. Автотесты+видео+текст+лайвкодинг — и очень многое можно сделать.
Но кто-то из распорядителей финансовыми потоками должен
а) определить что эти трое вместо 30 — это реально спецы
б) отдать весь зарплатный фонд именно им, а не экономить на сокращениях.
Т.е. зп поднимать нужно в 10 раз, сокращая попутно море тётушек и дедушек. И вот тогда волшебство — если условный тимлид/синьор видит, что вот тут зп выше чем у него, легко понять куда он пойдет впахивать. В ВУЗ. И через пару лет — гарантия результата. Правда тётушкам и дедушкам кушать станет нечего.
Но… все как есть так есть. И скорее всего таковым оно и останется...
Тогда получается не так громоздко.
И кстати, FSA на С++ выглядит ужасно, тут на Хабре были статьи с примерами.
Высокоуровневые блок-схемы — это классно, и даже иногда работает. Только возникает вопрос причём тут ДРАКОН :-)
А что в данной реализации, мне неохота даже спецки смотреть. Есть там вообще вызовы ф-ций или обработки ошибок.
Эти правила не случайны. Они составлены так, чтобы выжать максимум из графического представления алгоритмов. Что дают эти правила?
1. Легкость восприятия (примеры: запрет на пересечение линий, только прямоугольные манхеттен-графы).
2. Единообразие и предсказуемость (примеры: следующий всегда внизу, ветвление всегда идёт вправо).
Высокоуровневые блок-схемы — это классно, и даже иногда работает. Только возникает вопрос причём тут ДРАКОНПри том, что действительно классные высокоуровневые блок-схемы вы сможете создать только на ДРАКОНе, и никак иначе.
При том, что действительно классные высокоуровневые блок-схемы вы сможете создать только на ДРАКОНе, и никак иначе.
Неа. Прекрасно можно нарисовать руками.
Неа. Прекрасно можно нарисовать руками.Вы правы. Руками, конечно, можно нарисовать.
Но, скорее всего, получится с ошибкой. А на ДРАКОНе — без ошибок (почти без ошибок).
Но, скорее всего, получится с ошибкой. А на ДРАКОНе — без ошибок (почти без ошибок).
Нет и нет. Нет в ДРАКОНе никакого волшебства, которое защищает от ошибок вида "забыли вариант в перечислении", "записали не в ту переменную" и так далее.
Нет в ДРАКОНе никакого волшебства, которое защищает от ошибок вида «забыли вариант в перечислении»Вы правы, в том смысле, что ДРАКОН не дает 100%-го устранения ошибок. Он устраняет многое, очень многое, но отнюдь не все.
Никогда не было сказано, что ДРАКОН дает 100%-ю гарантию. Такой гарантии он, конечно, не дает, и не может дать.
От того, что вы похвалите блок-схемы Дракона ещё пять раз, они высокоуровневыми не станут.
И для этого совсем не нужно их хвалить.
Но они могут быть и низкоуровневыми.
Насчет уровня. Уровень дракон-алгоритмов выбирает разработчик.
Если разработчику нужен высокий уровень, он нарисует высокоуровневые дракон-алгоритмы.
Если разработчику нужен низкий уровень, он нарисует низкоуровневые .
Уровень — это не показатель качества, а степень абстракции, которая нужна разработчику.
А потом выяснилось, что это универсальный язык, который понимают коллеги «южных гор, до северных морей».
Я тоже так думал. А потом выяснил, что универсально коллеги понимают только "коробочки и стрелочки", то есть "что за чем идет". А, скажем, о форме коробочек — какая что обозначает — у людей уже разные представления.
Но важнее, что все универсально понимают и принимают концепцию изображения алгоритма именно в таком виде. Ни у кого не возникает вопроса, что значит стрелочка, что за чем идёт, и что это вообще за фигня, почему не писать на Яве.
Всё-таки ромбики для ветвления от прямоугольничков для действия отличают, наверное?
Я сам не всегда отличаю. Если нарисовать прямоугольник вместо ромбика, и написать вопрос, все равно работает.
Но важнее, что все универсально понимают и принимают концепцию изображения алгоритма именно в таком виде.
В виде просто квадратиков и стрелочек? Ну да. Для алгоритмов определенного типа и определенной сложности.
А теперь попробуйте в таком виде описать взаимодействие двух систем, и становится весело. Прямо вот очень весело.
Но важнее, что все универсально понимают и принимают концепцию изображения алгоритма именно в таком виде.
Допускаю, что это так. Но зачем обсуждать алгоритмы с теми, кто не может читать код?
И если алгоритмы, которые приходится обсуждать, просты, почему бы в таком случае не обойтись русским языком, без блок-схем?
Потому что те, кто не может читать код, дают деньги на разработку.
«почему бы в таком случае не обойтись русским языком, без блок-схем?»
Просто русский (или английский) не потянет — слишком сложный сейчас софт. Текст приходится структурировать в виде юз-кейсов. Но с юз-кейсами возникает проблема — повторы. И тогда видишь: да, надо было брать ДРАКОН с самого начала.
То же самое и в сложных логических условиях. Когда вниз идёт то «Да», то «Нет» — это лишний повод запутаться.
Совершенно неясно, как комментарий после сложного условия страхует от ошибки? Он либо генерируется магическим образом, что маловероятно при написании условий свободным текстом, либо я могу изменить условия забыв изменить комментарий и он, в дальнейшем, будет служить дополнительной точкой генерации ошибок.
Непонятен принцип «Чем правее, тем хуже». Почему в примере case ветка 1 лучше, чем ветка 2, а ветка 2 лучше, чем default?
насчет «чем правее, тем хуже» — дуракон вырос из переноса систем управления с аналоговых систем на цифровые вычислители. поэтому «хуже» — это какие-то отклонения в идеальном линейном алгоритме, которые надо обрабатывать, реагировать на отклонения.
Просто не было в начале 70-х обучения программированию для инженеров, да и сами «эти эвээмы» были штуками страшными и непонятными. Инженеры самостоятельно написать программу для системы управления не могли, переучиваться не хотели, а программисты были редкостью. поэтому возникла вполне здравая на тот момент идея — рисовать нечто вроде блок-схемы, и по ней генерить программу. Правда, всего через 10 лет обучение программированию в профильных ВУЗах стало обязательным, а еще через 5 — и в школах тоже. Но Паронджанов уже уверовал в свою гениальность…
Джозеф Фокс, которого Паронджанов цитирует, работал, емнип, до 1977 года. Собственно, и представления о программировании у команды дуракона примерно этих же времен.
Непонятен принцип «Чем правее, тем хуже». Почему в примере case ветка 1 лучше, чем ветка 2, а ветка 2 лучше, чем default?
Хаос — источник ошибок.
Во избежание ошибок, алгоритм должен быть упорядоченным
Принцип «Чем правее, тем хуже» позволяет упорядочить:
— макроконструкцию примитив;
— ветку в макроконструкции силуэт.
ЧТО ДЕЛАТЬ, ЕСЛИ ПРИНЦИП
«ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ» НЕ РАБОТАЕТ
Что ж, бывает и такое. Ничего страшного. Надо придумать какой-нибудь другой принцип, подходящий к вашей задаче. Например: чем правее, тем ниже, или, наоборот, тем выше. Идея проста. Смещение вправо от главного маршрута должно быть не произвольным и хаотичным, а продуманным и логичным.
Годятся любые правила, позволяющие сделать схему упорядоченной. Для разных задач могут понадобиться разные правила. Но у всех правил есть общая черта. В схеме должен быть не хаос, а порядок.
Здесь действует правило хорошей хозяйки:
Если поcтараться, порядок всегда можно навести
Смещение вправо от главного маршрута должно быть не произвольным и хаотичным, а продуманным и логичным.
Вы не задумывались о том, что в программе, вообще-то, бывает больше одного "главного маршрута"? И они бывают вполне себе равноправными?
Правило «чем правее, тем хуже» позволяет выделять неприятные сценарии (например, обрабоку ошибок).
Позволяет, но не заставляет. Если сценарии равноправны, правило не применяем.
Если сценарии равноправны, правило не применяем.
А теперь попробуйте, глядя на диаграмму, понять: здесь два равноправных сценария, или справа тот, который хуже? Только именно по виду диаграммы понять, а не читать каждую ноду и вдумываться.
С другой стороны, ассимметрия довольно часто бывает.
Если есть throw или error — кидаешь их в правой части схемы и всё.
Это как написать. А я спрашиваю, как читать. Мы же о понятности, правда?
Но иногда уходить вправо заставляет топология схемы — иначе не сложишь. Тогда да, читатель ожидает проблем, а там всё хорошо. Правило тогда мешает.
Приведем список исключенных из языка ДРАКОН опасных элементов, обеспечивающих управление вычислительным процессом. Сюда относятся:
— служебные слова goto, break, continue, if, then, else, case, of, switch, while, do, repeat, until, for, foreach, loop, exit, when, last и их аналоги;
Никуда они не исключены. Вы просто заменили слова на стрелки, но делают они ровным счетом то же самое.
А на этой подмене и строится все последующее якобы доказательство.
Никуда они не исключены…Это не так. Они исключены в том смысле, что человек их не видит, не работает с ними и не смотрит на них. Как мы не смотрим на код после компиляции.
А на этой подмене и строится все последующее якобы доказательство.
Они исключены в том смысле, что человек их не видит, не работает с ними и не смотрит на них
Он работает со стрелочками, которые функционально выполняют то же самое. Вообще то же самое, как хорошо видно на примере с case.
Вы пытаетесь сделать вид, что "катализаторами ошибок" выступают ключевые слова:
С точки зрения языка ДРАКОН, дело обстоит принципиально по-другому. То, что важно и необходимо для Си, язык ДРАКОН рассматривает как лексический и синтаксический мусор, как слова-пустышки и знаки-паразиты, как бессмысленные, ненужные и вредные элементы, которые подлежат изъятию и удалению. Потому что они являются катализаторами ошибок.
Но это утверждение ничем не подтверждено. Катализатором ошибок, на самом деле, выступает управляющая конструкция (само ветвление, которое увеличивает цикломатическую сложность), а выражено оно ключевым словом switch или набором стрелок — не принципиально.
Кстати, вместо стрелок в ДРАКОНе прямые чистые линии. Стрелка в ДРАКОНе — это знак цикла.
Читать легче.
Это утверждение нуждается в формализации и доказательстве.
А вот с формальным обоснованием «лёгкости» всё в порядке. В основе ДРАКОНа лежат объективные правила эргономики. «Объективные» — значит не важно, нравятся они вам лично или нет, знаете вы о них или нет. Работают и всё. О них можно прочитать, всё гуглится. Примеры: запрет на пересечение линий, только прямоугольные двумерные графы, требования по выравниванию ширины и расстояний, предсказуемость (следующий элемент — внизу), единообразие (ветвление только вправо), правило «общая судьба», правило «чем правее, тем хуже», чёткое выделение циклов и прочее.
Строгих доказательств лёгкости восприятия у меня нет. Только личный опыт и опыт людей, с кем работал. Если вам интересно — собирайте доказательства сами.
Да нет, мне не интересно. Это ваше утверждение, вам его и доказывать.
А ваш "личный опыт" — это штука эфемерная. Вот в моем личном опыте читать текст легче, чем картинки смотреть.
А вот с формальным обоснованием «лёгкости» всё в порядке. В основе ДРАКОНа лежат объективные правила эргономики. «Объективные» — значит не важно, нравятся они вам лично или нет, знаете вы о них или нет. Работают и всё.
Пожалуйста, ссылку на конкретное исследование.
Примеры: запрет на пересечение линий, только прямоугольные двумерные графы, требования по выравниванию ширины и расстояний, предсказуемость (следующий элемент — внизу), единообразие (ветвление только вправо), правило «общая судьба», правило «чем правее, тем хуже», чёткое выделение циклов и прочее.
Муа-ха-ха. Все эти примеры (даже если они верны) говорят только о том, как сделать диаграмму, которая читается лучше другой диаграммы (при прочих равных). Но они ничего не говорят о том, что диаграмма читается лучше, чем не диаграмма.
Ну и да, вы вот говорите, что правило "чем правее, тем хуже" — объективное, а недавно говорили, что его можно не применять. Это, как бы, противоречие.
Если вкратце: на диаграмме можно пальцем (взглядом) проследить путь через алгоритм.
А в тексте есть проблема ёлочки из скобок (или ёлочки выравнивания, если питон): куда переходить, когда скобка закрыта?
«Пожалуйста, ссылку на конкретное исследование.»
Ищите сами. Автор статьи даёт знания. Нужны вам эти знания или нет — это ваше личное решение.
Если вкратце: на диаграмме можно пальцем (взглядом) проследить путь через алгоритм.
Нельзя. Потому что мы приходим к выбору, который надо помнить.
А в тексте есть проблема ёлочки из скобок (или ёлочки выравнивания, если питон): куда переходить, когда скобка закрыта?
У вас слева даже полосочка есть, которая отвечает на ваш вопрос.
Ищите сами. Автор статьи даёт знания.
Нет, он дает не знания. Он дает голословные утверждения, которым предлагается верить.
В алгоритме летающей тарелки ошибка: если левый двигатель готов, то правый даже не проверяется. Боинг на ДРАКОНе точно так же уткнулся носом в землю...
1. Боинг не имеет никакого отношения к Дракону. Используется прием из известной теоремы, что крокодил более длинный чем зеленый.
2. Дракон не более безопасный, а может даже и менее. Фактов и доказательств нет.
3. Графические языки давно известны и применяются в промышленности. Но, собственно, они удобны далеко не для всех задач. IEC 61131, Siemens SFC.
Текстовое программирование имеет принципиальный дефект. Оно не способно обеспечить безошибочность программных продуктов.
Для текстового программирования безошибочность — это непосильная задача и недостижимая цель.
Это громкое утверждение нуждается в формализации и доказательстве. Или хотя бы, внезапно, доказательстве возможности его доказательства или опровержения.
Это громкое утверждение нуждается в формализации и доказательстве. Или хотя бы, внезапно, доказательстве возможности его доказательства или опровержения.Сергей, формально вы правы. Вопрос дискуссионный.
Но. Погибли 346 человек. Они погибли в результате ошибок разработчиков фирмы Боинг.
На Боинге работают специалисты высочайшей квалификации, которые знакомы со всеми последними достижениями в области ИТ.
Эта ошибка говорит не только о частном случае — промахе Боинга. Она говорит об общем уровне ИТ-отрасли.
На Боинге работают специалисты высочайшей квалификации, которые знакомы со всеми последними достижениями в области ИТ.
Это утверждение нуждается в доказательстве.
Она говорит об общем уровне ИТ-отрасли.
Но ничего не говорит о возможностях и невозможностях текстового программирования.
Вы сейчас пытаетесь апеллировать к эмоциям ("погибли 346 человек") вместо того, чтобы хоть как-то попытаться обосновать свои утверждения. Нехорошо.
Но ничего не говорит о возможностях и невозможностях текстового программирования.Не могу согласиться. Современное программирование — это текстовое программирование. Ошибки характеризуют уровень современного текстового программирования.
Нехорошо.В рамках комментария невозможно изложить аргументацию. Если Вам интересны мои обоснования, в конце статьи перечислены мои (и не только мои) книги и статьи.
Ошибки характеризуют уровень современного текстового программирования.
Уровень — возможно. Принципиальные ограничения — нет.
Если Вам интересны мои обоснования, в конце статьи перечислены мои (и не только мои) книги и статьи.
Они не являются обоснованием вашего мнения. Почему? Обратитесь к Laurent Bossavit, "The Leprechauns of Software Engineering", 2015, там это подробно изложено.
Как всегда забыли, что алгоритм и реализация алгоритма это не одно и тоже. Боинги упали из-за ошибки алгоритмиста или программиста?
Плюс рекурсивные алгоритмы, плюс динамическое программирование. Кмк этот "дракон" уже не полетит.
Если конечно имелось в виду не это динамическое программирование?
Я тут посмотрел внимательнее на пример из статьи. Да, вот на этот:
И что я там вижу? Что для перехода снизу наверх надо запомнить название узла. Т.е. не пройти глазами по стрелочке, а именно запомнить.
Ну то есть вот смотрим, крайняя левая схема, последнее ветвление, "тарелка взорвалась?" Предположим, что да. Мы попадаем на узел "ремонт летающей тарелки". Ок. А теперь идем от него по стрелке… и попадаем к выбору из трех узлов ("проверка...", "ремонт...", "пробный полет..."). Хотя этот переход, казалось, бы, должен быть однозначен.
Или я фундаментально не понимаю, как читать эту схему (и ничего не надо запоминать), или это совсем не "гарантированное отсутствие ошибок", потому что человеку надо запомнить и сопоставить, а это процесс, в котором заведомо возможна ошибка.
(аналогичные замечания можно высказать и по поводу "установить/снять признак", потому что нет никакого визуального подтверждения, что признак один и тот же, исключительно через память читателя)
— Нет -> правый двигатель в норме?
— Да -> Включить плазменный реактор.
Отлично. То есть, если левый двигатель в норме, то правый двигатель никогда не проверяется! Да и зачем его проверять, ведь гораздо важнее взлететь, а там уж как пойдёт.
— Чеклист?
— Нет, не слышал!
А если левый двигатель не в норме, а с правым проблем нет, то мы в включаем плазменный реактор. Хотя мы и не знаем, как там устроена летающая тарелка, интересен вопрос, что же это за проверки такие, что работоспособность левого двигателя можно проигнорировать.
Хотелось бы комментариев, как язык помогает искать подобные логические ошибки. На данный момент это утверждение кажется абсолютно беспочвенным.
Ещё такие блок схемы ломают концепцию чек листов — Вы правы.
Я просто для СД делал такие блок схемы. Представляете себе?
Предположим, надо сделать три проверки (проверка левого, проверка правого, проверка фотонного двигателя). У нас один вход у алгоритма проверки и 2^3 промежуточных состояний, описывающих что может быть необходимо сделать для ремонта/диагностики. В результате блок-схема получается целиком состоящая из абсолютно однотипных кусков, сделанных копипастом. Для себя же сделал вывод, что если порядок проверки не важен — лучше выносить для исполнителей узлы такой таблицы состояний в подалгоритмы.
Хотелось бы комментариев, как язык помогает искать подобные логические ошибки
Я искренне думаю, что никак. Так же, как он не позволяет искать ошибки вида "присвоения не в ту переменную", "пропущенный вариант в switch" и так далее.
А для текстово-ориентированных языков верификация осуществляется путем тщательного просматривания текста программы.
Казалось бы, это должно намекать, что код надежнее, чем шампур-схема.
Это же касается и создания: современные текстовые IDE позволяют работать быстрее, с меньшим количеством ошибок.
На уровне 1960-х (и самого начала 70-х)- возможно, надежность была бы сравнимой.
Так же, как он не позволяет искать ошибки вида «присвоения не в ту переменную», «пропущенный вариант в switch» и так далее.Присвоение «не туда» и подобные ошибки копи-пасты, прекрасно видны в LAD Cross-Reference.
Пропущенный switch не ловится, как и прочие логические ошибки в любом представлении.
Тут скорее вопрос в области применения — к ряду задач графическое представление читается гораздо лучше, чем текстовое (да да, тщательный просмотр нагляднее, например в задачах автоматики), а к ряду задач практически неприменимо (тут веб и прочий энтерпрайз CRUD).
Да стоит подумать, зачем вообще изобрели UML?
Хотелось бы комментариев, как язык помогает искать подобные логические ошибки.
[...]
Пропущенный switch не ловится, как и прочие логические ошибки в любом представлении.
Done.
switch(c) {
case 'a': i = 1; break;
case 'b': i = 2; break;
default: i = 42;
}А при чем тут это? Я говорил, что представление Дракона не помогает найти такие ошибки, вот и все.
Или вот еще один вопрос к этой же диаграмме. А почему, собственно, в ней три "ветки", а не один "шампур"? Просто поместим "пробный полет" под крайним левым (он же основной), а ремонт — под соответствующим "адресом". Структура алгоритма таким образом будет виднее (в частности, будет видно, что пробный полет состоится всегда).
Так по какому же формальному критерию можно сказать, что так, как на диаграмме — лучше?
Тезис «неверный алгоритм — вовсе не алгоритм» не выдерживает критики. Аналогия с доказательством ложная. Действительно, неверное доказательство не является док-вом скорее всего вовсе. Но вот алгоритм как последовательность действий неверным быть в этом смысле не может. Неверный алгоритм — это ТОЖЕ алгоритм, только делающий вовсе не то, что от него ожидают. Подразумеваем, что мы не собрали синтаксически или логически неверный конструкт (в этом нас страхуют наши нынешние инструментальные средства).
Ну, и так далее. Вся статья — субъективщина, причём любая.
Рисование алгоритмов в виде блок-схем — это вообще пахнет 70-ми годами. Текстовая репрезентация победила. Там где нужно — мы всегда по тексту можем сгенерировать визуализацию в виде диаграмм
Текстовая репрезентация победила. Там где нужно — мы всегда по тексту можем сгенерировать визуализацию в виде диаграммВы правы. Так все и делают.
И получают ошибки. Много ошибок.
Это увеличивает сроки тестирования и отладки. И иногда приводит к серьезным инцидентам, как с Боингом.
Такое положение является неприемлемым.
Проблема не в тексте. Вы преувеличиваете масштаб проблемы. На базе текста можно писать корректные алгоритмы. Правда, зачастую это, действительно, сложно. И коли говорить о концепциях, то если уж переходить, то на концепции ФП и автоматного программирования.
Кстати, вообще надо отметить, что Дракон не выживет и по причине того, что он не умеет во чтобы то ни было, кроме императивной парадигмы. Где ООП? Где ФП?
И коли говорить о концепциях, то если уж переходить, то на концепции ФП и автоматного программирования.Ради Бога. ДРАКОН поддерживает и ФП, и автоматное программирование.
Вот что сказано в статье (повторяю).
Автоматное программирование на языке ДРАКОН
Алгоритмическая макроконструкция силуэт представляет собой конечный автомат и способна работать в двух режимах:
— императивное программирование;
— автоматное программирование.
Смотри статью Автоматное программирование на языке ДРАКОН.
Дракон не выживет и по причине того, что он не умеет во чтобы то ни было, кроме императивной парадигмы. Где ООП? Где ФП?Нет вопросов. Все учтено могучим ураганом. В статье описана концепция гибридных языков и Семейство ДРАКОН-языков.
Вот ссылка: Stepan Mitkin на конфереции Erlang User Conference в Швеции делает доклад по гибридному языку Дракон-Erlang.
youtu.be/yZLedcnFA94
Ради Бога. ДРАКОН поддерживает и ФП, и автоматное программирование.
Вы вообще знаете что такое ФП?
Вообще ФП имеет малую область применения, и там где подходит Дракон и подобные, ФП КМК не подходит.
То, что в схему не было заложен взаимоконтроль датчиков, является проблемой не языка программирования, а архитектурного решения. И на вашем драконе можно нарисовать точно такую же кривую схему.
Да, собственно, ваша схема с летающей тарелкой. Пока первый двигатель в порядке второй и фотонный протестированы никогда не будут. В результате где-нибудь в районе Альфы Центавра можно обнаружить, что первый двигатель вышел из строя, второй неисправен с момента постройки тарелки, а при включении фотонного тарелка взрывается. А до земной рембазы больше четырёх световых лет на вёслах. И как тут дракон помог составить безошибочный алгоритм проверки?
Рисование алгоритмов в виде блок-схем — это вообще пахнет 70-ми годами.70-ми годами пахнет не только это. Во всех реализациях дуракона- нет контроля области действия переменных. В реализации в «графит-флокс» — все «идентификаторы» (т.е переменные) глобальны.
Хот там вообще сказка: drakon.su/_media/biblioteka/grafit_a4.pdf
ну или drakon.su/_media/biblioteka_1/drakon_rakety_i_medicina_.pdf, почитайте со стр. 10. Как вам нравится глубокомысленный вывод: «Если два идентификатора отличаются хотя бы в одном символе, они считаются различными.»? Интересно, долго ли над этим думали? ну или «Чтобы быстро уяснить физический смысл идентификатора, надо пропустить префикс и читать только смысловую часть.».
Да, собственно, ваша схема с летающей тарелкой. Пока первый двигатель в порядке второй и фотонный протестированы никогда не будут.Вы правы, но легенда совсем не такая.
Легенда
Нас интересует: взорвется тарелка или нет. Для этого надо запустить хотя бы один из двух: либо плазменный реактор, либо фотонный двигатель, причем последний считается безотказным.
А при чём тут вообще Боинг? Софт на 737 Max делал ровно то, что должен был делать. Он определял, что угол атаки приближается к критическому и уводил стабилизатор на пикирование.Не могу согласиться. Вы рассуждаете по принципу «моя хата с краю», а это не есть хорошо. Архитектурное решение тоже matter.
То, что в схему не было заложен взаимоконтроль датчиков, является проблемой не языка программирования, а архитектурного решения.
Тут дело более тонкое.
Могли ли летчики спасти и самолет, и пассажиров?
Да, безусловно могли. Алгоритм спасения существовал. для этого командиру надо было сделать обратное сальто, а затем правым пальцем левой ноги нажать нужную кнопку. И все бы остались живы-здоровы.
Но командир этого не знал. Мало кто знал. Но некоторые знали, и успешно сажали Боинг 737 МАХ.
И на вашем драконе можно нарисовать точно такую же кривую схему.Нельзя (кроме нескольких нелепых случайностей).
Алгоритм спасения существовал. для этого командиру надо было сделать обратное сальто, а затем правым пальцем левой ноги нажать нужную кнопку.Для этого пилотирующему (Pilot Flying) надо было выполнить «по памяти» чек-лист «самопроизвольная перекладка стабилизатора». Причём причины такого поведения стабилизатора абсолютно неважны, будь это короткое замыкание, пробитый транзистор или сбрендивший автопилот.
«По памяти» — значит, что экипаж должен знать наизусть как действия по данному чек-листу, так и условия его применения. Сам чек-лист не новый, есть в руководстве с первых моделей 737.
Но командир этого не знал.Значит командир не должен был быть допущен к самостоятельным полётам.
Нельзя (кроме нескольких нелепых случайностей).Можно. И очень легко. Просто пропускаем в схеме блок сравнения показаний двух датчиков и прекрасно работаем только с одним, неисправным.
Как показывает жизнь, существует масса людей, которым НАДО разрабатывать алгоритмы, но они не являются программистами. Они хорошо видят картинку, но плохо читают текст.
Для таких людей ДРАКОН — то, что доктор прописал.
Вижу еще одну нишу для ДРАКОНА: построение ДРАКОН-схемы по коду.
Надо экспериментировать. Возможно, такой подход действительно снизит количество программмистских ошибок — на схеме будет сразу видно. Возможно, в некоторых случаях заменит отладку.
Для начинающих программеров жесткая дисциплина ДРАКОНА — то, что нужно для правильной «постановки руки».
В общем, серебряной пули нет, но в своих нишах ДРАКОН был бы весьма полезен.
ДРАКОН — это ИНОЙ способ работать с уже существующими языками программирования.
ДРАКОН работает не в одиночку, а в паре с кем-то (Мы с Тамарой ходим парой).
Что это значит?
Возьмем к примеру язык Си. Это значит, что в графических иконах ДРАКОНа вы пишете код на языке Си (без управляющих операторов, разумеется). Затем графический ДРАКОН-алгоритм (с сишным кодом) транслируется в исходный код языка Си, после чего компилируется в исполняемый код.
Это называется Гибридный язык Дракон-Си.
Вместо Си могут быть другие языки Java, JavaScript и т. д. Много вариантов.
Но «мыши плакали, кололись ...»
Народ голосует не за визуальное программирование, а за NoCode.
https://vas3k.ru/blog/nocode/
типа такого
Или https://n8n.io/
А ведь Microsoft Flow — это такой недоработанный ДРАКОН.
Неа, Microsoft Flow — это такой доработанный дракон.
Шутка удалась. :)
Если серьёзно: чем Flow хуже дракона? Почему Flow недоработан?
1. Из-за отсутствия шампура (центральной линии алгоритма) слишком много изгибов.
2. Нет силуэта. В результате схемы растут слишком далеко вниз. А в силуэте одна ветка на экране помещается.
3. Сам геймплей редактора муторный: трудно перекидывать ветки, копировать-вставлять и так далее.
Но несмотря на эти мелочи народу нравится Flow.
Из-за отсутствия шампура (центральной линии алгоритма) слишком много изгибов.
Это преимущество Flow.
Нет силуэта. В результате схемы растут слишком далеко вниз.
Это снова преимущество Flow.
Сам геймплей редактора муторный: трудно перекидывать ветки, копировать-вставлять и так далее.
Тут не могу ничего сказать, потому что со Flow я не работал. Однако, в других визуальных редакторах алгоритмов от Microsoft (например, в дизайнере Workflow Foundation) я никакой особой муторности не замечал.
1. Заведена переменная A, которая только сравнивается с 3 минутами. Где она изменяется? Если ответ в блоках «4c», то как догадаться, что «4с» изменяет именно переменную А? И что по поводу остальных блоков типа «2м48с» — они тоже какую-то переменную меняют? Как диаграммное программирование при таком раскладе(при условии, что имя изменяемой переменной скрыто) исключит изменение не той переменной?
Я уж молчу, что обычному человеку-непрограммисту, за которого тут много написано, было бы проще читать без загадочных «A := 0» и «А > 3 мин». Можно их обоих заменить на более понятное условие «Если с начала проверки двигателей прошло больше 3 минут».
2. Алгоритм небезопасный и с ним Боинг точно также бы и разбился. Вот почему я так думаю: мы 3 минуты тестируем двигатели. Если за 3 минуты ни один из двигателей не в норме, мы вместо того, чтобы отправится на ремонт/диагностику, просто врубаем фотонный двигатель(приговаривая «авось пронесёт»), и дальше — взрыв.
И мне так кажется, что подобный баг пропустить на развесистой диаграмме не сильно сложнее, чем в обычном «текстовом» описании алгоритма.
Заведена переменная A, которая только сравнивается с 3 минутами. Где она изменяется?Есть икона (желтая трапеция с двойной линией по бокам), в которой надпись А = 0.
Это таймер (секундомер). Икона Таймер создает, обнуляет и запускает счетчик времени А, который начинает отсчет времени от 0. Когда выполнется условие А > 3мин, запускается фотонный двигатель.
И что по поводу остальных блоков типа «2м48с» — они тоже какую-то переменную меняют?Нет, они переменную не меняют. Это икона Пауза (задержка). Она задерживает следующую команду «Снять признак Авария тарелки» на 2м48с (2 минуты 48 секунд).
Есть еще икона Синхронизатор (слева от иконы-хозяина), в которой написано В = 5мин. Она (синхронизирует) осуществляет проверку условия.
Когда счетчик В достигнет значения В = 5мин, запускается икона-хозяин (справа от Синхронизатора) — команда «Отключить гравитацию».
Это таймер (секундомер).
Где то написано?
Т.е. проблема не в языке программирования — проблема в мозгах.
Подождите, это же скрытое общее состояние. То самое, от которого программисты избавляются как раз ради увеличения надежности кода.
Кстати, разработчики "Бурана", которые использовали этот язык, столкнулись с проблемой отсутствия стандартных способов описания зависимостей между модулями, и по итогу реализовали все зависимости через глобальные переменные. Говорят, это был адский ад.
Я специально у него интересовался — какими методами, ввиду отсутствия до 2000-х хоть какого-то инструментария «ДУРАКОН применялся в». ведь столько красивых слов — «симультантность», «эргономичность» и т.п.
Ну и хотя я сразу осознал, что в нормальной работе это не применить — но надеялся, что получится некоторая замена BPMN. Зря надеялся.
Я тоже его читал. Одна реклама и никакой конкретики.
Я тоже подумал, что может выйти что-то вроде BPMN но автор играется в игрушки и не пытается написать ничего более-менее сложного. Впрочем, я порой применяю ДРАКОН на бумажке, чтобы посмотреть порядок ветвления: он компактнее обычных блок-схем.
Эта хрень очень напоминает то, на чем мы пытались писать в школе алгоритмы.
(Грустно) Россия страна изобретателей велосипедов.
Хотите графический язык? Это называется FBD. На нем программируют промышленные контроллеры. Хотите сложнее? Есть LabView, которому ваша Дракон и в пометки не годится.
Но принципиально ничего не меняется. Пока программист не в теме, и не обладает знаниями в предметной области, такие вещи будут повторяться. Ни одна система программирования не является экспертной системой, чтобы ловить алгоритмические ошибки
Хотите графический язык? Это называется FBD. На нем программируют промышленные контроллеры. Хотите сложнее? Есть LabView, которому ваша Дракон и в пометки не годится.Вы правы.
1. Промышленные контроллеры — это важно.
2. Function Block Diagram — графический язык программирования стандарта МЭК 61131-3 для программирования программируемых логических контроллеров (ПЛК).
3. Для LabView имеются профессиональные инструменты, а для ДРАКОНа — всего лишь экспериментальные.
Но вы, к сожалению, отстали от жизни: «Дракон и в пометки не годится». При сравнении ДРАКОНа и FBD дело обстоит иначе — ровно наоборот.
Поясню.
Предприниматель Алексей Муравицкий, системный интегратор фирмы ОВЕН
использует ДРАКОН-технологию в нефтегазовой промышленности, пищевой промышленности, теплоэнергетике
для программирования ПЛК при разработке шкафов управления установками и насосами
1. На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании «Сургутнефтегаз» и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.
Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
2. На видео показан шкаф управления насосами объемного действия частотно-регулируемого электропривода на кустовой насосной станции Азнакаевского нефтегазодобывающего управления компании «Татнефть», где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН. Программа загружается в энергонезависимую память сенсорного программируемого контроллера СПК 107 фирмы ОВЕН.
При сравнении ДРАКОНа и FBD дело обстоит иначе — ровно наоборот.Единичные примеры не могут служить подтверждением данного утверждения. Для корректного сравнения необходимо решить большое множество типовых задач на FBD и драконе, после чего оценить хотя бы время, затраченное на разработку в каждом из случаев.
Факт того, что кто-то что-то запрограммировал на драконе, говорит только о том, что это можно сделать, но ничего не говорит о скорости, удобстве и качестве результата при такой разработке.
Но это совсем не означает, что так следует делать. И тем более не означает, что 1с 7.7 дает какие-либо преимущества при написании ассемблеров. Это всего лишь показывает, что нашелся извращенец (я), который это написал.
В раздел 9. «Семейство ДРАКОН-языков» добавлен параграф
ДРАКОН — это новый способ работать с существующими языками программирования
ДРАКОН недостаточно выразителен, чтобы покрыть все возможности хотя бы одного из современных языков программирования.
Но это совсем не так. Целевой язык (и все его коды) остаются в целости и сохранности.
Что же делает ДРАКОН?
Он на время удаляет с глаз человека несколько опасных операторов и подсовывает вместо них безопасные.
Так что все возможности языка бережно сохраняются и никуда не деваются.
Кроме одной, а именно: возможности совершить ошибку в операторах управления. С оговоркой: ДРАКОН не гарантирует полную защиту от ошибок.
От ПРОЛ-2 жизнь ушло уже достаточно давно и очень далеко.
то, что вы называете «опасными операторами» — это то, чем вы не научились пользоваться.
В ваших аллегориях про варку каши: Понимаете, если я вылил на себя кружку горячего чая — это не означает, что кружки опасные, и кипяток опасный. Это всего лишь означает, что либо я еще маленький и глупый, и не умею переносить кружки с кипятком, либо что я уже взрослый, но криворукий. Т.е. мне надо либо учиться, либо лечиться. Ну, или как вариант — нанимать специалиста — квалифицированную сиделку, которая умеет аккуратно поить безнадежно тупого горячим чаем…
то, что вы называете «опасными операторами» — это то, чем вы не научились пользоваться… Это всего лишь означает, что либо я еще маленький и глупый, и не умею переносить кружки с кипятком, либо что я уже взрослый, но криворукий.Отлично! Не в бровь, а в глаз!
В 1968 году Эдсгер Дейкстра в журнале «Communications of the ACM» указал, что оператор goto, используемый во многих языках программирования высокого уровня, является основным источником ошибок и потому должен быть запрещен.
Это означает, что Эдсгер Дейстра, основоположник структурного програмирования, призвал исключить оператор goto не потому, что тот опасный и является источником ошибок, а потому что бедный Дейкстра, подобно маленькому и глупому ребенку, не научился пользоваться этим оператором!
Поздравляю вас!
Затем Бертран Мейер выявил еще два опасных элемента — операторы break и continue, которые также следует запретить как замаскированные goto. По словам Мейера, это те же старые «goto в овечьей шкуре».
Это означает, что Бертран Мейер, основатель контрактного програмирования и создатель языка Eiffel, книга которого Object Oriented Software Construction в свое время считалась библией ОО-программирования, призвал исключить операторы break и continue не потому что они опасные и являются источником ошибок, а потому что бедный Бертран Мейер, подобно маленькому и глупому ребенку, не научился пользоваться этими замечательными оператороми! Поздравляю вас!
Еще дальше идет доктор физико-математических наук профессор Игорь Вячеславович Вельбицкий, который считает, что из программирования следует исключить:
«ключевые слова-паразиты и соответствующие им конструкции языков типа: goto, if, for, while, break, begin-end, {-} и т.д… Эти конструкции являются основным источником ошибок и проблем в современном программировании».
Оказывается, и здесь незадача!
Бедный профессор Вельбицкий забил в набат, не поглядевши в святцы, потому что он тоже обмишурился — не научился пользоваться оператороми!
Затем Бертран Мейер выявил еще два опасных элемента — операторы break и continue, которые также следует запретить как замаскированные goto. По словам Мейера, это те же старые «goto в овечьей шкуре».
а чего мелочиться — давайте еще try except выкинем, а?
Они тоже являются замаскированными goto! Действительно — зачем нам SEH…
А еще запретим return в середине функции — это же тоже ломает понимание точек выхода из функции!
Во заживем!
Но нет, это так не работает!
Эти конструкции являются основным источником ошибок и проблем в современном программировании
о! Давайте пойдем еще дальше! Проблема ведь не в конструкциях, а в необходимости самого программирования! Может сразу на нейронные интерфейсы перейдем? Зачем вообще машине рассказывать как ей работать — лучше сразу ее срастить с человеком, пускай мозг всем управляет ) А программирование запретить вообще — как источник ошибок )))
В гиперболу можно превратить все что угодно, но я против преувеличений и гипербол.
Я ограничился точным цитированием. Кому интересно, могу указать источники с номерами страниц.
Моя цель — показать, что идеи ДРАКОНа не взяты с потолка, а опираются на существующие тенденции и учитывают опыт выдающихся ученых.
опираются на существующие тенденции и учитывают опыт выдающихся ученых.
Которые вы трактуете так, как вам удобно.
Которые вы трактуете так, как вам удобноНе согласен. Трактую Дейкстру и Мейера в соответствии с приведенными цитатами и не только.
Что касается Вельбицкого, то я полностью согласен с его тезисом. Но решение предлагаю существенно иное (по сравнению с Р-технологией Вельбицкого).
Трактую Дейкстру и Мейера в соответствии с приведенными цитатами.
Нельзя трактовать цитату в соответствии с ней же. Вы приводите цитату, а дальше делаете из нее какие-то выводы. Никакого подтверждения, что эти выводы совпадают с выводами, которые делал автор цитаты — нет (в случае с Дийкстрой даже веселее, тут уже приводили контрцитату).
Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!
DIJKSTRA, E. W. «Prospects for a better programming language,» in High level languages, C. Boon [Ed]. Infotech State of the Art Report 7, 1972, 217-232.
Когда нам, студентам, в руки попала книжка Дейкстры — мы на фортране, и на различных ассемблерах писали «без goto», хотя goto/jmp/br у нас вполне себе использовалось. просто делали конструкции, соотвествующие управляющим структурам.
Бертран Мейер — может иметь свое мнение, но судя по тому, что на его мнение (в отличия от доказательств Дейкстры) просто поклали — оно остается мнением. Собственно, Эйфель, несмотря на декларируемую надежность, практически не распространен — его недостатки перевешивают достоинства. Да, напомню, эйфель — вполне текстовый язык, без всякой графической мании.
Ну а Вельбицкий, один из адептов Р-технологий, насколько помню, тоже продвигал визуальную технологию, только пенпердикулярную Дуракону. Которая даже несколько удобнее, умнее, и даже реализована раньше и лучше. Но на нее плевали с высокой колокольни. И поэтому я, пожалуй, соглашусь с вами насчет Вельбицкого — он не научился.
Дейкстра не только указал, что goto запрещен, но и указал — почему. Неужели вы весь труд Дейкстры поняли только как «запрет goto»?Вы допускаете ошибку насчет Тышова. Серьезную ошибку.
(впрочем, Тышовская версия ДУРАКОНа вполне себе генерила эти goto, на которые вы призывали «не смотреть»).
Пользователь программы Геннадия Тышова (ДРАКОН-конструктор под названием ИС Дракон ) работает с дракон-схемой (дракон-алгоритмом), которая для него является исходником. В этой схеме вы даже под микроскопом не увидите goto. Их там нет.
Да, вы правы, я призывал не смотреть на goto, но что означает эта фраза? Этого вы, к сожалению, не поняли. А это очень важно.
Объясняю. эта фраза означает следующее:
1. Операторы goto никуда не исчезают. они как были, так и остались.
2. Работая с ДРАКОНом, человек никогда не пишет goto ручками. Он их не видит и не должен видеть.
Для человека они исчезли, стали невидимыми, сквозь землю провалились, кошка съела.
3. ДРАКОН-конструктор Тышова ИС Дракон физически исключил для человека возможность писать goto ручками и видеть их на экране.
Идем дальше. Программа ИС Дракон транслирует дракон-алгоритм (в котором нет goto) в исходный код целевого языка, например, языка Си. В этот момент (но не ранее!) на сцене впервые появляются goto.
Страшно ли это? Нет! — совсем не страшно. Почему не страшно? Потому, что эти операторы не нарисованы ручками, а получены автоматически. А это совсем другое дело!
Эти операторы уже безопасны, потому что они получены автоматически. Это значит, что они кастрированы и не способны рожать ошибки.
Но человек по-прежнему их не видит и не смотрит на них!
Почему? Потому что для пользователя ДРАКОНа исходником является дракон-схема, и только она.
Пользователь не смотрит на goto в исходном тексте целевого языка, как мы не смотрим на код после компиляции.
_________________________
Выше я описал идеальный случай, как должно быть.
На практике могут возникать вопросы реализации и некоторые отступления от идеала.
Но со временем рано или поздно все наладится.
И огрехи, если они есть, будут устранены.
ДРАКОН-конструктор Тышова ИС Дракон физически исключил для человека возможность писать goto ручками и видеть их на экране.
Мммм.
Выходом из ветки служит икона «адрес», в которой записывается имя следующей по порядку исполнения ветки. Икона «адрес» — это замаскированный оператор перехода (gоtо).
Никуда оператор goto не делся.
И это не говоря о том, что любой ваш соединитель, ведущий не строго вперед — это такое же goto.
Эти операторы уже безопасны, потому что они получены автоматически.
Нет, они безопасны только в том случае, если то ПО, которое их создавало, не содержит ошибок. А как это доказать?
На практике могут возникать вопросы реализации и некоторые отступления от идеала.
коллега выше пишет. С этим тезисом вынужден согласиться, но lair очень верно обращает внимание на проблему корректности транслятора. С другой стороны — если у нас есть графовое представление кода — мы вправе над ним производить эквивалентные замены. Заменять if + goto на условный цикл или назад. В зависимости от задачи. В этом отношении, конечно, очень помогла бы изоляции побочных эффектов. Что-то подобное в любом случае происходит как на уровне компиляторов (оптимизация кода и теория есть), так и на уровне железа.
Выходом из ветки служит икона «адрес», в которой записывается имя следующей по порядку исполнения ветки. Икона «адрес» — это замаскированный оператор перехода (gоtо).Никуда оператор goto не делся.
Это не так. Очень даже делся. Он полностью исчез из поля зрения человека.
Что означает фраза:
Икона «адрес» — это замаскированный оператор перехода (gоtо).Это всего лишь метафора для науч-попа, чтобы быстренько объяснить, что к чему.
В данной дискуссии она совершенно неуместна.
Сожалею, что она ввела вас в заблуждение.
Приношу свои извинения.
Он полностью исчез из поля зрения человека.
Нет. Я вижу ваш "адрес", и его надо читать как "перейди на ветку с названием таким-то". Это goto.
Или у вас есть какое-то другое объяснение, как надо читать "адрес"?
Нет. Я вижу ваш «адрес», и его надо читать как «перейди на ветку с названием таким-то».Это правильно. Вы совершенно правы. Другого объяснения нет.
Это goto.А это неправильно.
Объясняю. Вы как опытный специалист по программированию совершенно естественно (даже рефлекторно) трактуете эту конструкцию как goto.
Но. Слова goto там нет. Вы его добавили.
Тонкость вот в чем.
Хотя эта графическая конструкция играет роль goto, но она безопасна (в отличие от опасного goto, написанного ручками).
Это правильно. Вы совершенно правы. Другого объяснения нет.
Значит, это goto. И я легко могу вам создать пример плохого алгоритма, где эта конструкция будет использоваться именно так, как используется плохой goto.
Хотя эта конструкция играет роль goto, но она безопасна (в отличие от опасного goto, написанного ручками).
Это утверждение нуждается в доказательстве.
Пока что все, что вы делаете — это утверждаете, что вы заменили "опасные" операции на их "безопасные" аналоги, но никак не объясняете ни в чем опасность исходной операции, ни почему ваш аналог этой опасности не имеет.
Значит, это goto. И я легко могу вам создать пример плохого алгоритма, где эта конструкция будет использоваться именно так, как используется плохой goto.Ну раз легко, было бы интересно посмотреть на пример.
Мне кажется, вы с gecube и Mike_soft извратили утверждение вредности goto и вообще ищете проблемы не там, где они есть.
Ну раз легко, было бы интересно посмотреть на пример.
Переход на "ветку" из пяти-десяти других мест.
Мне кажется, вы с gecube и Mike_soft извратили утверждение вредности goto и вообще ищете проблемы не там, где они есть.
Я не могу говорить за других, я говорю только за себя. Я вообще не считаю goto вредным. Меня волнует утверждение "вон там вредный goto, а у нас он невредный" без объяснений, почему. И еще больше меня волнует, когда то же самое говорят про условные переходы.
Переход на «ветку» из пяти-десяти других мест.Не принято. Так будет выглядеть навскидку:
- Конец любой нетривиальной функции
- Концовка сложного условия или case
Так будет выглядеть навскидку:
Вот в том-то и дело, что я смотрю на диаграмму, и вижу там переход. И теперь мне надо подумать — а это конец, выход, goto, что-то еще? Я уже приводил этот пример, собственно:
(это из статьи картинка)
Я в нижней строке вижу три goto:
goto пробный полет...goto ремонт ...goto пробный полет...
Потому что это ровно то, что там написано: а теперь давайте перейдем в узел с таким-то названием и начнем выполнение с него.
if(tarelka_kirdyk) remont();
try_fly();Да и goto не наблюдается.
Так что этот пример тоже не принимается как «вредный»
Тогда и на схеме должно быть ветвление, где одна ветка ведет в полет, а вторая — в ремонт, а потом в полет. "Адреса" не нужны.
Важное отличие вызова подпрограммы (remont() в вашем случае) от "адреса" в диаграмме выше в том, что вызов подпрограмы либо вернет управление в точку вызова, либо завершит программу целиком (по крайней мере, таково мое ожидание от чтения кода), в то время как "адрес" вернет управление (если вернет) в точку выбора (сверху диаграммы), а не в то место, где он был задан (внизу диаграммы).
В каком-то очень общем смысле это выглядит так:
set branch=test
while (true)
switch (branch)
test:
...
if (success)
set branch=fly
else
set branch=repair
repair:
...
set branch=fly
fly:
...
exit(это вот прямо то, как я читаю диаграмму выше, один в один)
См еще этот коммент
… хотя, конечно, while(true) — это доброта. На самом деле, учитывая стрелки, вот так:
set branch=test
choice:
switch (branch)
test:
...
if (success)
set branch=fly
else
set branch=repair
goto choice
repair:
...
set branch=fly
goto choice
fly:
...
exitТам наверняка есть конвенция типа "по крайней левой", я решил не заострять на этом внимание.
Да, такая конвенция там есть. И, по хорошему, если не указано иного, ветви выполняются друг за другом слева направо.
Вообще, эта хрень была придумана как способ нарисовать на листе стандартного формата длинную блок-схему.
Непонятно, правда, зачем добавили странную, сбивающую с толку стрелочку.
Вообще, эта хрень была придумана как способ нарисовать на листе стандартного формата длинную блок-схему.
Меня иногда потрясает, как вещи, которые появились из попытки обойти ограничения (давно устаревшие. потому что есть увеличение/уменьшение, есть промотка, есть сворачивание/разворачивание), подаются как осознанные решения, которые сейчас улучшают процесс.
Ну, там есть определённая логика. Ветви — это как бы подпрограммы, которые имеют собственный смысл и вызываются последовательно. А если не последовательно — то предыдущая подпрограмма определяет, какая должна быть следующая. Как есть конечный автомат.
Я верю, что там есть логика. Я просто не верю, что эта логика "универсально безопаснее".
Я тоже не верю. По моему мнению, это инструмент с очень узкой областью применения. А безопасность тут вообще ни при чём.
А попытка натянуть сову на глобус, каковой занимается автор статьи, не идёт на пользу ни сове, ни глобусу. Если бы разработчики ДРАКОНа ставили перед собой выполнимые задачи — этот язык нашёл бы свою нишу. Но пока — увы.
Если ветви будут чистыми функциями (чего правда в драконе нет), то КА + это — весьма надежная техника программирования.
Безопаснее чем что?
Чем код, написанный квалифицированном разработчике на другом языке.
Про все языки нельзя утверждать определенно.
Тут скорее подход Раста — если в языке нет опасной функциональности или она запрещена, то выстрелить в ногу не получится (надо очень постараться).
В данном случае я вижу множество способов выстрелить себе в ногу, начиная с того, чтобы банально задать (семантически) неправильную метку в адресе.
Язык тут уже дело пятое.
В том-то и дело, что там нет никакого "топографизма". Там зачем-то есть адреса, которые надо глазами сопоставить с метками, вместо прямой стрелочки "мы идем сюда", которая бы как раз и помогала визуальному анализу алгоритма.
по какой из веток идти при запуске программы нигде не определено.Это не так. При запуске силуэта всегда работает крайняя левая ветка. Указывать на это нет необходимости.
Ну ок, привел ты типичный конечный автомат, который тоже никак не является плохим паттерном. Кстати, реализуется и без goto.
А вообще мы говорили про goto и его вред.
И пока утверждение не оправдано
Значит, это goto. И я легко могу вам создать пример плохого алгоритма, где эта конструкция будет использоваться именно так, как используется плохой goto.
И я легко могу вам создать пример плохого алгоритма, где эта конструкция будет использоваться именно так, как используется плохой goto.
Да нет, я как раз привел пример с goto. Для вас это не плохой goto? Окей, упираемся в вопрос, а что же такое "плохой".
Если вам мало иллюстраций, представьте себе такую блоксхему, где в ветке (как они там называются? шампуры?) инструкция вида "выведи переменную", а все остальные ветки на нее переходят, предварительно в эту переменную что-то записав.
Плохой — в данном случае будет переход в середину шампура (считай другой функции, т.к.даже скоупов тут нет). Такое здесь невозможно.
Достаточно побить шампур пополам, благо, ничто это не запрещает, и вы получите тот же самый эффект.
(это не говоря о том, что есть языки, в которых goto есть, а такой переход запрещен)
Достаточно побить шампур пополам, благо, ничто это не запрещает, и вы получите тот же самый эффект.Это называется рефакторинг =)
И опять нет, разбиение процедуры на подпроцедуры не ломает структурность программирования.
Это называется рефакторинг
Нет, это называется "я хочу переиспользовать код, но не знаю, как".
"я хочу переиспользовать код, но не знаю, как".
Разработчики ДРАКОНа предлагают выделять переиспользуемый код в отдельную ветку.
Возможность объявить полноценную подпрограмму там тоже вроде где-то была (хотя в этих книгах ориентироваться — застрелишься).
после фортрана goto мне не понадобился ни разу. совсем.
Полезность ДУРАКОНа Паронджанов обосновывает тем, что «нельзя перейти внутрь/наружу управляющей конструкции» (как оказалось — на дураконе это вполне возможно). Переход внутрь управляющей конструкции чреват сами знаете чем. Но прикол в том, что я текстом это сделать не смогу, если не напишу специально «goto» (а я не напишу — мне это просто не надо, хотя язык допускает), а дураконист — сможет не задумываясь. И дуракон это не запретит.
вообще ищете проблемы не там, где они естьа они там везде. Начиная от первичного объекта автоматизации (не самый удобный ПРОЛ-2, может, и стоило дураконить в 70-х годах — но он сдох лет 25 как, наверное), включая претензии на «серебряную пулю», и заканчивая, увы, личными проблемами автора («мудрецы — обезьяны, врачи калечат пациентов, программмисты вредители, лишь я умный, но меня не ценят»). Т.е. дуракон — это сам себе проблема, ибо:
1)автоматизирует то, чего уже нет (языки типа ПРОЛ-2 умерли четверть века назад).
2)для тех, кому эта автоматизация уже не нужна (нормальные инженеры уже научились программировать те же четверть века назад)
3)делает это с ошибками, как показано в этой ветке (т.е. несмотря на декларированное «улучшение работы ума» — оно не помогло за четверть века найти эти принципиальные ошибки)
4)для него до сих пор не решены задачи удобной работы, отладки, разграничения доступа — не говоря уж о версионировании и коллективной работе. Т.е. то, что существует уже лет 20.
5) он требует дополнительного изучения и дополнительного внимания — т.е. вместо того, чтобы правильно и логичино писать код — программист должен правильно рисовать И правильно писать. а после этого при отладке — ковыряться в сгенерированном. Т.е. вместо одной IDE — две «дыры в программу», концептуально разные (через одну дыру мы видим картинку, через вторую — что из этой картинки получилось в реальности). Т.е. опять отставание лет на 30
Другими словами, в декларируемых областях у ДУРАКОНа нет задач для решения. Программисту он не нужен. Врачу — ну, я б поопасался лечиться у такого. Преподавателю (нормальному, а не типа TAU) — тоже. Студенту — тем более.
Студенту — тем более.
его включили в общеобразовательную программу, по словам разраба. Видимо, зря
вон, апологет ДУРАКОНа с ником TAU — из какого-то сибирского говнометарного университета, вроде — там ДУРАКОН-схема «ввести число-посчитать логарифм(степень, корень) встроенной функцией — вывести на печать» является _семестровым_ заданием. И ведь не все сдают (он там буянил, требовал сдать, грозил отчислением)!
Это на изи-электроникс году в 2014 битвы были, и в них опрометчиво ссылку дали…
его включили в общеобразовательную программу, по словам разраба
Типичное "и вы говорите". Покажите мне ту программу.
О, я ее нашел. Долго смеялся.
(предмет смеха рекомендую каждому желающему искать в ней самостоятельно, это не очень сложно)
Но по сути могу заметить следующее. Документ называется "Примерная программа дисциплины «Информатика»", и он датирован 1996 годом. А где найти актуальную?
О, я ее нашел. Долго смеялся.
(предмет смеха рекомендую каждому желающему искать в ней самостоятельно, это не очень сложно)
Примерная программа дисциплины „Информатика“» одобрена Президиумом совета по информатике Госкомвуза. Председатель Президиума академик РАН Юрий Журавлев является руководителем Секции прикладной математики и информатики Отделения математических наук РАН, а также заместителем Академика-секретаря Отделения математических наук РАН.
В одобренной академиком Журавлевым «Примерной программе» содержится обоснование концепции и структуры учебного курса информатики; в частности, дается обоснование использования языка ДРАКОН.
Далее в Программе указываются требования к языку представления процедурных знаний нового типа: общедоступного, человечного, предельно лёгкого в изучении и удобного в работе, создающего наиболее комфортные условия для работы человеческого мозга, позволяющего решать проблемы ценою минимальных интеллектуальных усилий, удовлетворяющего самым строгим эргономическим и дидактическим требованиям. Отмечается, что этим требованиям соответствует язык ДРАКОН — «один из самых легких языков представления знаний и самый первый язык, с которого нужно начинать обучение алгоритмическому мышлению и программированию».
При коллективной интеллектуальной работе важную роль играет интеллектуальное взаимопонимание и интеллектуальное взаимодействие между специалистами.
Для улучшения взаимопонимания необходимо иметь общую языковую основу. Благодаря своей человечности (эргономичности) язык ДРАКОН относительно легко устраняет барьеры взаимного непонимания (в части процедурных знаний) между работниками различных специальностей: врачами и физиками, математиками и конструкторами, биологами и экономистами, программистами и технологами и т. д. Тем самым ДРАКОН создаёт универсальную языковую основу для процедурного интеллектуального взаимодействия между людьми, в частности, между участниками многопрофильных проектов. В результате этот «язык взаимопонимания» заметно упрощает междисциплинарное и иное общение между представителями разных организаций, ведомств, отделов, лабораторий, научных школ и профессий, отчасти играя роль «производственного эсперанто».
Бакалавр любой специальности должен уметь формализовать свои процедурные профессиональные знания самостоятельно, то есть без помощи профессиональных программистов или когнитологов (инженеров по знаниям). Программа предусматривает приобретение навыков автоформализации знаний на языке ДРАКОН.
Данные о распространенности языка в ВУЗах
В Сибирском государственном индустриальном университете студенты изучают язык ДРАКОН и осваивают интегрированную среду «ИС Дракон» на кафедре прикладной информатики для представления алгоритмов решения проблем управления при подготовке магистров, обучающихся по направлению: 140400.68 «Электроэнергетика и электротехника», профили подготовки «Электроприводы и системы управления электроприводов», «Автоматизированные электромеханические комплексы и системы».
В Новокузнецком филиале Кемеровского государственного университета студенты изучают язык ДРАКОН и осваивают интегрированную среду «ИС Дракон» на кафедре математики и математического моделирования согласно программе «М2.ДВ.4 Инструментальные средства визуального программирования», составленной в соответствии с требованиями федерального государственного образовательного стандарта высшего образования по направлению подготовки 010400.68 «Прикладная математика и информатика» для магистерской программы «Математическое моделирование» и утвержденной деканом факультета информационных технологий доктором технических наук профессором Валерием Калединым.
В Белоруссии в Минском высшем радиотехническом колледже отмечают:
«Как показал опыт применения языка ДРАКОН в лабораторном цикле „Изучение аналоговых и цифровых приборов“, студенты на порядок быстрее усваивают принципы работы операционных усилителей и регистрации их амплитудных и частотных характеристик».
Вы понимаете, что это всё было ОЧЕНЬ ДАВНО?
Несколько эпох назад.
Сложность программного обеспечения с тех пор возросла на пару порядков. Тогдашние средства разработки сейчас непригодны для использования.
Сложность программного обеспечения с тех пор возросла на пару порядков. Тогдашние средства разработки сейчас непригодны для использования.
Вы правы, и я с вами полностью согласен.
Но. Проблема в том, что современные средства разработки не справляются с возросшей сложностью программного обеспечения (которая, как вы правильно отмечаете, с тех пор возросла на пару порядков).
Не справляются в том смысле, что отсутствуют необходимые средства разработки, позволяющие обеспечить должный уровень безошибочности.
И авиаинцидент с самолетом Боинг 737 МАХ красноречиво подтверждает это.
Проблема в том, что современные средства разработки не справляются с возросшей сложностью программного обеспечения
Это утверждение нуждается в доказательстве.
отсутствуют необходимые средства разработки, позволяющие обеспечить должный уровень безошибочности.
Что такое "должный уровень безошибочности"? Как его измерить?
И авиаинцидент с самолетом Боинг 737 МАХ красноречиво подтверждает это.
Как ни странно, не подтверждает. А вот то, что остальные самолеты летают, подтверждает обратное.
Если конструкторы Боинга отказались от сравнения показаний датчиков и решили, что данных от одного из них достаточно для принятия решения, то никакой язык программирования и никакая среда разработки этого не обнаружат и не исправят.
Проблема в том, что современные средства разработки не справляются с возросшей сложностью программного обеспечения
Видите ли в чём дело: ДРАКОН даже не пытается справиться с возросшей сложностью.
В нём есть небольшие подвижки относительно ТОЙ ЭПОХИ, но современные средства разработки ушли далеко вперёд. Чтобы их догнать — их нужно хотя бы изучить, чем Вы пренебрегаете.
1. Несоответствие спецификации. По классике проверяется тестами. Чтобы понимание спеки было единообразно, заказчику стараются почаще выкатывать MVP, чтобы подтвердить, что написанное в спеке соответствует желаниям заказчика, а тесты пишет другой человек, а не тот. кто пишет код.
2. Опечатки. Например, копипастнули условие ветвления или адрес обращения. По классике проверяются статическими анализаторами, стараются таких ошибок избегать (с разной эффективностью) с помощью ФП.
3. Неоптимальное использование ресурсов. По классике надеемся на компилятор и вызываемые библиотеки, проверяем на код-ревью.
С какими из перечисленных (а может, иными) борется ДРАКОН?
Поставьте себя на место исполнителя. Заказчик (не всегда грамотный и не всегда понимающий, чего он хочет) принес вам толстый талмуд и просит согласовать и утвердить.
Это трудная работа. Адски трудная. Найти и удалить все ошибки в спецификации практически невозможно. возникает острейшая проблема взаимопонимания между заказчиком и исполнителем.
Достичь взаимопонимания между заказчико и испонителем очень трудно.
Почему? В частности. потому, что текст не может обеспечить то, что нужно.
Если в спецификации имеются части написанные на ДРАКОНе, достигается вау-эффект и положение коренным меняется.
По остальным вашим пунктам надо говорить отдельно по каждому.
Если в спецификации имеются части написанные на ДРАКОНе, достигается вау-эффект и положение коренным меняется.
это неверно. Вы так и не ДОКАЗАЛИ, что наличие ДРАКОНа в документации/спецификации устраняет противоречия.
Если в спецификации имеются части написанные на ДРАКОНе, достигается вау-эффект и положение коренным меняется.
Если спецификация написана опытным аналитиком, достигается вау-эффект и положение корреным образом меняется.
Хотя вы невольно выдали основную цель ДУРАКОНа — «произведение вау-эффекта на тупых заказчиков». Больше он ни на что не способен.
Удивительно, такой длинный комментарий, а ответа на вопрос "где же актуальная программа" так и нету. Впрочем, из "данных о распространенности" можно попробовать сделать неприятный вывод, да...
Ну и да, моя причина для смеха никуда не делась, а после вашей формулировки только еще смешнее стало.
Хотя эта графическая конструкция играет роль goto, но она безопасна (в отличие от опасного goto, написанного ручками).
она так же опасна. И компромиссом является введение специальных "безопасных" элементов вроде блоков "цикл", "выбор" и пр., но это в каком-то смысле насилие над разработчиком алгоритма, т.к. иногда алгоритм лаконичнее именно в варианте с "переходом" куда бы то ни было
Значит, это goto. И я легко могу вам создать пример плохого алгоритма, где эта конструкция будет использоваться именно так, как используется плохой goto.
согласен. Вне зависимости от того — как МЫ описали goto — текстом или графикой — он от этого не меняется.
gecubeЯ не согласен. Следует прежде всего различать КАК создан goto: вручную (тогда goto опасен) или автоматически (тогда безопасен).
согласен. Вне зависимости от того — как МЫ описали goto — текстом или графикой — он от этого не меняется.
В схеме "силуэт" безусловный переход создаётся в ручную.
Это было бы goto, если бы метка располагалась в середине шампура произвольным образом.
Неа. GOSUB прекрасно позволяет перейти куда угодно. Это был бы GOSUB, если бы он возвращал управление в точку вызова.
Следует прежде всего различать как создан goto: вручную (тогда goto опасен) или автоматически (тогда безопасен).
Дайте используемые вами определения понятий "опасен" и "безопасен".
Вы по прежнему считаете такой переход безопасным?
Большое спасибо за пример.
Если заменить «Середина цикла» на «Цикл А», а «Начало цикла» на «Цикл Б», будет видно, что это вложенные циклы.
И ошибка — неинициализированная i при старте.
Разбивая схему таким образом можно сделать переход внутрь любого контекста, например ветки if или switch. А можно и сделать выход из них в произвольное место.
Пока что написано это — зацикленная прога.
loop A
print i
i = i + 1
i = 0
if NOT i < 10 break loop
end loopПример кстати хороший, что сдуру можно и %@$ сломать.
Читаемость тоже плохая.
Получается, что наговнокодить в драконе ничуть не сложнее, чем в любом другом языке. И сам по себе дракон не является панацеей, магическим образом делающей алгоритм безошибочным.
Пример кстати хороший, что сдуру можно и %@$ сломать.
Так это ровно на то и пример, что ДРАКОН не защищает от таких ошибок.
Условие запрета вы сами можете сформулировать.
ДРАКОН-конструктор неправильно построен.
Почему неправильно?
Как только он заметит, как вы расставили метки, он должен сразу сбросить (удалить) ошибочную метку и сообщить, об ошибке.
ДРАКОН-конструктор неправильно построен.
Значит, ваш язык позволяет такую ошибку. Что, собственно, пример и призван продемонстрировать.
Но язык поддерживается ДРАКОН-конструктором, который (если он правильно построен) должен знать все правила языка и обеспечивать их выполнение.
В данном случае Конструктор не делает то, что обязан делать.
Значит, его нужно доработать.
Нет, не позволяет.
Когда язык что-то не позволяет, конструкция в нем не может быть выражена (не будет синтаксически корректной). Вы не можете написать на C# goto в произвольное место, это невозможно, это не будет синтаксически корректной программой на языке C#.
Какое правило синтаксиса ДРАКОНа нарушено в примере выше?
(кстати, где вообще можно ознакомиться с формальной спецификацией ДРАКОНа как языка?)
Так нельзя. Запрещено.Кем или чем?
Как только он заметит, как вы расставили метки, он должен сразу сбросить (удалить) ошибочную метку и сообщить, об ошибке.И каким же образом, по каким признакам дракон может определить, что здесь задан цикл, а не простое ветвление?
по каким признакам дракон может определить, что здесь задан цикл, а не простое ветвление?Посмотрите, в вашем примере (спасибо за пример) появились черные треугольники в иконах Адрес и Имя ветки.
Видите?
Они появились автоматически.
Значит, конструктор умеет распознать некоторую новую ситуацию.
Черные треугольники — это признак веточного цикла.
Значит, это не именно цикл, а не ветвление.
Простое ветвление может быть только внутри ветки, и больше нигде.
Веточный цикл должен строиться не от балды, не виде спагетти, а по строгим правилам. В данном случае эти правила нарушены, что недопустимо.
В конструкторе ошибка (спасибо вам); его надо поправить.
Черные треугольники — это признак веточного цикла.Нет, это всего лишь признак, что икона адреса находится левее иконы имени ветки. Это я сразу проверил, как только увидел тёмный треугольник.
Но сама по себе такая ситуация ничем особенным не является. Если нарисовать конечный автомат, где адресами будут состояния автомата, то относительное расположение текущей и следующей веток может быть каким угодно.
Нет, это всего лишь признак, что икона адреса находится левее иконы имени ветки.
1. Не совсем так. Веточный цикл — если икона Адрес указывает на свою, или более левую ветку.
2. Вложенные друг в друга веточные циклы возможны, но они громоздки.
Разрешать ли вложенные веточные циклы или запретить? Вопрос дикуссионный.
В рамках данной дискуссии лучше их запретить, чтобы не запутаться.
3. Процедурный и автоматный режим силуэта имеют РАЗНЫЕ правила.
Кто придумал эти правила для ДРАКОНа?
3.1. В программе Тышова ИС Дракон поначалу был только процедурный режим.
Сергей Ефанов для своих целей (он программирует микроконтроллеры) придумал два автоматных режима и уговорил Тышова реализовать их.
Сегодня в программе ИС Дракон три режима:
— процедурный;
— Автомат 1;
— Автомат 2.
3.2. У Степана Митькина силуэт может работать в процедурном и автоматном режиме.
Степан Митькин опубликовал статью. Автоматное программирование на языке ДРАКОН.
Черные треугольники — это признак веточного цикла. Значит, это не именно цикл, а не ветвление.
Правда?
Видите треугольник на "продолжение программы"? Там нет никакого цикла, "продолжение программы — завершение програмы — конец", это полностью линейное выполнение.
Так что, как вам верно пишут, это всего лишь признак того, что точка назначения — левее.
Веточный цикл должен строиться не от балды, не виде спагетти, а по строгим правилам.
Каким конкретно? Где они описаны? Как они формализованы?
Видите треугольник на «продолжение программы»? Там нет никакого цикла, «продолжение программы — завершение програмы — конец», это полностью линейное выполнение.Да, вы правы. Здесь нарушено правило пространственного расположения веток: Ветки должны располагаться слева направо не хаотично, а в том порядке, в каком они включаются в работу (кроме веточных циклов).
Ветку «продолжение программы» надо перенести вправо и сделать предпоследней.
Может ли конструктор автоматически распознать эту ситуацию и устранить погрешность?
Я думаю, может и должен.
Но, конечно, надо переговорить с разработчиком ДРАКОН-конструктора и узнать его мнение.
Ветки должны располагаться слева направо не хаотично, а в том порядке, в каком они включаются в работу (кроме веточных циклов).
"Должны", но не располагаются. А вот в этом примере (взято из ветки выше) располагаются, но там все равно "плохой" goto, который не виден никак.
И это все, что надо знать о "безошибочности" ДРАКОНа.
алгоритм лаконичнее именно в варианте с «переходом» куда бы то ни было.Такая философия стимулирует появление ошибок. Она очень опасна.
Вариант с «переходом» куда бы то ни было действительно позволяет создать лаконичный алгоритм. Но здесь-то и кроется подводный камень.
Центральной проблемой современного программирования является слишком большое количество ошибок и неумение сократить это число.
Стремиться надо не к лаконичности за счет использования опасных операторов, а к диаметральнопротивоположой цели — к надежности и безошибочности.
Центральной проблемой современного программирования является слишком большое количество ошибок и неумение сократить это число.
Вообще-то, в "современное программировании" есть множество способов сократить число ошибок, и программисты ими пользуются. Другое дело, что, судя по вашим заявлениям, вы о них можете быть не в курсе. Но это дело понятное...
Например, при выходе из цикла большой вложенности такой goto позволяет не создавать лишних переменных, лишних условных операторов и не усложнять условия завершения цикла.
Но, смотрите.
Вы человек очень высокой квалификации и обладаете большими знаниями и большими способностями.
Это обстоятельство позволяет Вам выполнять трудную работу — правильно использовать goto и делать программу не только лаконичнее, но и снизить вероятность ошибки. Я бы сказал, что вы разделяете позицию Дональда Эрвина Кнута в его известной дискуссии с Эдсгером Вибе Дейкстрой.
Но есть много разработчиков, которые не обладают такими возможностями.
Наконец, есть многомиллионная армия программистов-любителей (amateur programmers), которые тоже вносят важный вклад, в развитие ИТ.
Какой сигнал, какую рекомендацию насчет goto следует дать им?
Как вы считаете?
Какой сигнал, какую рекомендацию насчет goto следует дать им?
Начинающему программисту я бы посоветовал по возможности не использовать "goto". Или использовать, в некоторых особо оговорённых случаях.
И ровно ту же рекомендацию им следует дать относительно схемы "силуэт" в драконе, потому переходы между ветками обладают всеми теми же недостатками, что и "goto".
Можно было бы доработать нотацию ДРАКОН, чтобы этот недостаток убрать, но мне что-то подсказывает, что Вы этого делать не станете.
Можно было бы доработать нотацию ДРАКОН, чтобы этот недостаток убрать, но мне что-то подсказывает, что Вы этого делать не станете.Прошу вас поделиться вашими соображениями. Буду благодарен.
Самое первое: ввести соглашение, что если в нижней иконе адреса не указан адрес перехода, то переход должен переходить на следующую ветку по порядку слева направо.
Далее, рекомендовать именно такой способ завершения ветки.
Второе, в иконе конца цикла адрес не указывать: очевидно же, что она должна закрывать тот цикл, который открыт последним.
Возможность разбития циклов нужно сильно ограничить, но чтобы сказать что-то конкретное мне нужно пересмотреть вашу книгу.
И ещё, не по этому вопросу, но вопросу крайне важному: нужно стандартизовать текстовое представление дракон-схем.
Понимаете, язык мёртв, если у него есть git-friendly формата сохранения.
Если у вас еще возникнут предложения, просьба сообщить.
или здесь или мне на почту vdp2007@bk.ru
_______________________
Вы говорили о студентах. Возможно, вам будет интересно.
Сегодня я получил письмо из Испании:
Владимир Данилович, добрый день.
Я — студент PhD и программист-любитель, прочитал Вашу книгу «Алгоритмы и жизнеритмы на языке Дракон» и очень хотел бы начать использовать его для программирования микроконтроллерной системы сбора данных и управления экспериментом (я занимаюсь гетерогенным катализом).
Беда в том, что не могу даже установить систему ИС Дракон.
Я работаю в Испании, компьютер университетский, система Win 10, каталонская. Язык программ, не поддерживающих Юникод, поставил русский. Кодовую страницу в реестре поменял на русскую.
Дракон версии Dragon_2020-04-05 (по крайней мере, так называется архив с экзешником).
При попытке запуска этого самого экзешника получается вот что:
… крякозябры…
Active TCL версии 8.6.9 установлен.
В чем еще может быть дело?
С уважением,…
Возможность разбития циклов нужно сильно ограничить,Тут фокус в том, что цикл может быть неявным, то есть не while или for, а if goto. И вот как раз разбиение схемы на отдельные ветки позволяет как реализовать такой цикл, так и реализовать переход в середину этого неявного цикла.
Но и без таких циклов не обойтись, сам рисунок схемы подразумевает наличие бесконечного цикла, в самом начале которого выбирается ветка, а в самом конце каждой ветки задаётся следующая.
Но и без таких циклов не обойтись, сам рисунок схемы подразумевает наличие бесконечного цикла, в самом начале которого выбирается ветка, а в самом конце каждой ветки задаётся следующая.
по сути — навязанный автомат с неявной переменной STAGE, в которую кладется номер следующего "шампура".
Возможность разбития циклов нужно сильно ограничитьСпасибо. Мне кажется, можно построить алгоритм, который выявляет наличие неявного цикла if goto со входом в середину и поручить ДРАКОН-конструктору блокировать такие действия и выдавать сообщение об ошибке.
Или я ошибаюсь? Как вы считаете?
Да, такой алгоритм будет полезен, и написать его довольно просто. Но он помешает использовать Дракон для построения конечных автоматов.
Если это верно, тогда можно установить для этих режимов РАЗНЫЕ правила. То есть использовать указанный вами алгоритм ТОЛЬКО в процедурном режиме.
Тогда он не нанесет вреда автоматному режиму.
Как ваше мнение?
Или здесь есть скрытые ограничения?
Ну, в таком случае у вас в языке, который и без того довольно сложен, появляется ещё одна сущность — "режим работы". А так никаких других проблем данного решения я не вижу.
Режим работы (автоматный или процедурный) мы всегда знаем, не так ли?
их более, чем два ((((( Попробуйте ООП реализовать на своем ДРАКОНе… или ФП.....
Прошу вас поделиться вашими соображениями. Буду благодарен.
Отказаться от силуэтов. Вообще. Силуэты — наследие "бумажной" эпохи, когда требовалось экономить место. Вместо силуэтов нужно разрешить блок-схеме неограниченно расти вниз.
При необходимости напечатать блок-схему на бумаге все межстраничные переходы с адресами должен автоматически добавлять компьютер.
Для тех редких случаев, когда goto всё-таки нужен (скажем, те же конечные автоматы) — нужно разрешить позиционировать блоки вручную и рисовать стрелки к ним. Да-да, именно стрелки, потому что они человеку гораздо понятнее адресов.
Проблему пересекающихся стрелок нужно решать графически. Самое простое — автоматически раскрашивать их в разные цвета, благо мониторы в 21м веке цветные. А также можно "разрывать" одну из стрелок в точке пересечения, визуально такой способ читается очень легко.
Великим языком программирования от этих исправлений Дракон не станет — но будет хотя бы пригодным для рисования этих самых блок-схем с возможностью исполнения.
Полный отказ от силуэтов — это лишнее.
Они удобны для представления автоматов со сложной логикой выбора следующего состояния.
Великим языком программирования от этих исправлений Дракон не станетОн и невеликим языком не станет. Пока из всего необходимого набора в нём есть только урезанный набор управляющих конструкций, его максимум — надстройка для уже существующих языков.
Он и невеликим языком не станет. Пока из всего необходимого набора в нём есть только урезанный набор управляющих конструкцийЭто не так. Вы упустили из виду алгоритмичеескую логику (визуальную алгебру логики и пр.).
Вы упустили из виду алгоритмичеескую логику (визуальную алгебру логики и пр.).
Ее там не больше, чем в любом другом языке программирования (и меньше, чем в реально формализованных языках программирования).
Но она является важной частью и улучшает безошибочность
"Улучшает безошибочность" по сравнению с диаграммами, нарисованными на листке бумажки без инструментария? Возможно.
По сравнению с тем же алгоритмом, разработанным в современном языке программирования? Маловероятно. Докажите.
Но она является важной частью и улучшает безошибочностьНа мой взгляд, она добавляет дополнительный источник ошибки — расположение стрелок Да и Нет.
Если в тексте хватает проверки условия, то в драконе необходимо ещё и понять, куда надо перемещаться при выполнении условия — вниз или вправо.
????
Ээээ, что?
В Си это do while, выполнять, пока условие истинно.
В Паскале — repeat until, выполнять пока условие не станет истинным.
Но это разные языки, и разные ключевые слова.
У вас же в драконе на все условные операторы и циклы выделен один символ ромбика и для понимания, while это или until, какая ветка then, а какая else надо смотреть на подписи к стрелкам.
Уточню. смотреть надо не на подписи к стелкам, так как в ДРАКОНе стрелок нет (они используются только в цикле Стрелка (while, do while, loop with the test in the middle) и еще одна-единственная стрелка силуэта.
А куда смотреть?
ДРАКОН показывает все без исключения маршруты алгоритма от начала до конца.
ДРАКОН позволяет проследить их пальцем, не отрывая палец от экрана или бумаги. И даже продемонстрировать маршруты на анимации.
Метки Да и Нет у иконы Вопрос нужны для того, чтобы упорядочить алгоритм и соблюдать законы порядка:
1. Главный маршрут идет по шампуру
2. Все маршруты подчиняются правилу: чем правее, тем хуже (или иному правилу порядка).
3. Устраняют паразитные знаки инверсии, которые являются проклятием (неизлечимой проказой) текстового программирования.
Все маршруты подчиняются правилу: чем правее, тем хуже (или иному правилу порядка).
"или иному" означает, что единого правила нет. Это значит, что когда человек смотрит на диаграмму, у него нет мгновенного ответа "почему это справа".
Устраняют паразитные знаки инверсии, которые являются проклятием (неизлечимой проказой) текстового программирования.
Вы о чем?
- Устраняют паразитные знаки инверсии, которые являются проклятием (неизлечимой проказой) текстового программирования.
успокойтесь, нет такой проблемы.
Тогда попробуйте хотя бы сформулировать эту проблему, формализовать её.Это обычное логическое отрицание.
Текстовое программирование не может обойтись без логических отрицаний.
А ДРАКОН легко удаляет связку логического отрицания, переставляя знаки Да и Нет.
А в драконе вы не удалили логическое отрицание, а сделали два оператора, if и ifnot, различающиеся только направлением выходов, то есть перенесли отрицание на другой уровень обозначений. На мой взгляд, лучше от этого не стало.
А в чём проблема логического отрицания и зачем его нужно удалять? Вы никак не можете дать формулировку проблемы.Проблема такова (причем не я ее придумал, это сделали мэтры).
Как известно, логическое отрицание представляет определенную трудность для понимания.
В связи с этим Эдвард Йодан советует:
«Если это возможно, избегайте отрицаний в булевых [логических] выражениях. Представляется, что их понимание представляет трудность для многих программистов».Подчеркну: трудность вызывает не само отрицание, а именно знак (логическая связка) отрицания
При текстовом программировании избавиться от связки отрицания невозможно.
А в ДРАКОНе это делается элементарно: перестановкой Да и Нет.
При текстовом программировании избавиться от связки отрицания невозможно.
Это утверждение ложно.
Представляется, что их понимание представляет трудность для многих программистов
ну вот ему представляется, что для многих. ну а для многих — не представляет трудности.
в конце концов, что вам мешает поменять содержимое веток? оставить ветку истинности пустой, в конце концов?
Вам вопрос в теме задавали — когда вы последний раз принимали участие в разработке ПО? можете ответить? (когда/на чем/объем/размер команды?)
В связи с этим Эдвард Йодан советуетТо есть проблемы нет, есть только чьё-то мнение.
трудность вызывает не само отрицание, а именно знак (логическая связка) отрицанияЕсли вас так пугает сам знак отрицания, то что мешает избавиться от него, перенести его туда, где он не создаёт проблем?
#define ifNotRoot(user) (!ifRoot(user))Знак отрицания ! вы заменили на знак отрицания Not. Здесь против вас выступают уже не ИТ-гуру Эдвард Йодан, а лингвисты и филологи.
В обоих случаях плохо. Проблема как была, так и осталась.
Я уже не говорю, что у вас слитное написание Not в сложном слове без пробелов.
Простите, но так писали несколько тысяч лет назад, когда люди еще не изобрели пробел.
У вас, правда не палеогафия, а Camel case, но все-таки.
Мы ведь говорим не только о логике, но и об удобочитаемости и эргономике, верно?
#define ifRegularUser(user) (!ifRoot(user))Другое дело, что всё это не нужно. Отрицание свободно читается в логических выражениях и не создаёт проблем.
А тем, кому оно слишком сложно, стоит перейти в более простые профессии — в поэты, например, или в управдомы.
А тем, кому оно слишком сложно, стоит перейти в более простые профессии — в поэты, например, или в управдомыЭто предложение не реалистично. Программистов не хватает. В программисты идут не только после вузов, но и после средних учебных заведений и из других мест, например, врачи без ИТ-образования.
Кроме того, ваше предложение негуманно и нарушает права человека.
Если вы руководитель, вы вправе уволить слабого работника, но вы не вправе руководить его судьбой.
Я считаю, что нельзя проводить дискриминацию и упрекать людей за отсутствие знаний, способностей и т.д.
Отрицание свободно читается в логических выражениях и не создаёт проблем.У меня нет сомнений, что для вас действительно нет проблем. Но ведь вы сейчас высказываетесь от имени миллионов, предполагая, что у них нет проблем, точно так же, как и у вас, не так ли?
Человек по доброй воле пришел в профессию. Моя позиция: ему можно и нужно помочь.
Человек по доброй воле пришел в профессию. Моя позиция: ему можно и нужно помочь.
Правильно. Можно и нужно научить его свободно читать логические выражения, хоть с отрицанием, хоть без.
Это не сложнее, чем школьную алгебру решать.
Можно и нужно научить его свободно читать логические выражения, хоть с отрицанием, хоть без.
Это не сложнее, чем школьную алгебру решать.
Не могу согласиться.
Как известно, логическое отрицание представляет определенную трудность для понимания.
В связи с этим Эдвард Йодан советует:
«Если это возможно, избегайте отрицаний в булевых [логических] выражениях. Представляется, что их понимание представляет трудность для многих программистов».В похожие ловушки часто попадают не только программисты. Трудности испытывают и многие другие люди.
Опасность ошибочного понимания провоцируют не только знаки отрицания, но и другие связки.
Поэтому Йодан расширяет и усиливает свою мысль:
«Избегайте без нужды использования сложных булевых выражений… Даже если нет неоднозначностей, такие выражения обычно с трудом понимают все, за исключением их автора».
Сходные предостережения делает не только Йодан.
Его поддерживает Гленфорд Майерс:
«Распространенным источником ошибок является использование логических операций И и ИЛИ».
Возникает вопрос: можно ли устранить подобные источники ошибок? Существует ли радикальное средство, позволяющее ликвидировать опасные места, спрятанные в логических выражениях и провоцирующие появление ошибок?
К счастью, от этой неприятности можно избавиться.
Как известно, логическое отрицание представляет определенную трудность для понимания.
Программирование вообще представляет определенную трудность для понимания. Ему можно научиться.
Даже слова, вы не поверите, представляют определенную трудность для понимания, но их можно выучить.
В связи с этим Эдвард Йодан советует:
Он пишет "если возможно" и "избегайте без нужды". А вы это переносите на "всегда".
Возникает вопрос: можно ли устранить подобные источники ошибок?
Полностью — нельзя, потому что есть места, где логические операции необходимы. Но можно не использовать логические операции там, где они не необходимы.
есть места, где логические операции необходимыСогласен с вами. Работать без логических операций невозможно и немыслимо.
Но. Я говорю не об исключении логических операций.
Я говорю о том, что можно и нужно исключить логические связки.
При этом логические операции остаются в целости и сохранности, но они записываются без логических связок.
Появляются новые логические конструкции:
— конъюнкция без знака конъюнкции;
— дизъюнкция без знака дизъюнкции;
— отрицание без знака отрицания.
Я говорю о том, что можно и нужно исключить логические связки
Можно, но не нужно.
В качестве упражнения, запишите без оператора "ИЛИ" требование "выбрать из БД всех пользователей, которые работали в системе вчера, или хотя бы один раз открыли форму управления за последний месяц, или относятся к группе "менеджер"".
Нет ровным счетом никакого основания полагать, что полный отказ от логических операторов "И", "ИЛИ" и "НЕ" уменьшит количество ошибок в коде.
Нет ровным счетом никакого основания полагать, что полный отказ от логических операторов "И", "ИЛИ" и "НЕ" уменьшит количество ошибок в коде.
не уменьшит, т.к. сложность кода никуда не денется — она переместится на другой уровень, например, уровень условных конструкций
«выбрать из БД всех пользователей, которые работали в системе вчера, или хотя бы один раз открыли форму управления за последний месяц, или относятся к группе „менеджер“»
Все написано правильно.
Улучшить эту запись с помощью текста невозможно.
Улучшить эту запись и удалить две логические связки ИЛИ можно только с помощью дракон-схемы.
Нет ровным счетом никакого основания полагать, что полный отказ от логических операторов «И», «ИЛИ» и «НЕ» уменьшит количество ошибок в коде.Не могу согласиться. Отказ от связок с помощью дракон-алгоритма сделает логические выражения более прозрачными и понятными. И за счет этого сократит число ошибок.
Так зачем усложнять работу и разбивать нормальную запись логического выражения на множество отдельных элементов?
Единственное назначение, которое может быть у такой схемы — не написание программы, а визуализация алгоритма действий, при котором человек (не компьютер) ведя пальцем по линиям проговаривает «А вот это у меня выполняется? Да? Значит направо. А вот это? Нет? Значит направо. Почему направо? Только что направо было 'Да', а теперь 'Нет'. Непонятно.»
Улучшить эту запись и удалить две логические связки ИЛИ можно только с помощью дракон-схемы.
Продемонстрируйте, как можно улучшить эту запись с помощью дракон-схему. Только сразу с объективным критерием, почему это улучшение.
Отказ от связок с помощью дракон-алгоритма сделает логические выражения более прозрачными и понятными.
Это утверждение нуждается в доказательстве. Я ему не верю.
Я говорю о том, что можно и нужно исключить логические связки.
это не решает проблему, т.к. делает нагромождение операторов условий
В 90-92 годах мне довелось поучить школьников вновь появившемуся предмету — информатике. так вот, логические операции вполне осваивались ими за стандартный академический час. Причем класс хотя и числился «с уклоном в математику» — дети там были самыми разными. И из трех поступивших на наш факультет двое ушли («лихие 90-е»), да и в остальном сложилось по-разному: инженеры, торгаши, бандит, ЧОПовец, парикмахерша, швея (выросшая во владельца известного швейного предприятия), даже, говорят, Ю элитная путана… И _все_ они свободно осваивали и логические операции, и применение их в бэйсике. И никаких особых сложностей это для них не составляло. Где вы берете таких идиотов, которые хронически ошибаются?
Программирование вообще представляет определенную трудность для понимания. Ему можно научиться.я б, как говорится, «росширил и углУбил» — любая сложная деятельность, не только программирование, но и, например, инженерная деятельность, врачебная деятельность, даже правоохренительная — составляют «определенную трудность для понимания». Более того, даже первоначальные сведения об устройстве мира (арифметика, чтение и письмо, взаимосвязи в природе) тоже составляют определенную трудность. Даже прямохождение на своем начальном этапе…
Большинство эти трудности преодолевает в известном процессе, который называется «обучение». Не все, конечно. Но «не преодолевших», наверное, не стоит подпускать к деятельности, которая для них «представляет сложность»…
Я считаю, что нельзя проводить дискриминацию и упрекать людей за отсутствие знаний, способностей и т.д.
Упрекать, может быть, и нельзя. Но не брать на работу, если он не имеет нужных знаний — можно.
Я считаю, что нельзя проводить дискриминацию и упрекать людей за отсутствие знаний, способностей и т.д.Всё-таки у многих профессий есть свои ограничения. Ляжете ли вы под нож хирурга, у которого тремор рук? Доверите ли вести свою бухгалтерию человеку, путающемуся в таблице умножения? Будете ли слушать певца без голоса, которому аккомпанирует музыкант без слуха? Но ведь они тоже добровольно пришли в профессию, помогите им, дайте набраться на вас опыта.
Вот и с программированием так же. Человеку, не способному разобраться в одной простой операции булевой алгебры не стоит браться за создание сложных логических построений — программ.
Вы серьезно не видите, что это тот же самый "знак отрицания", который в ДРАКОНе выражается словом "нет" на основной ветке выполнения?
Проще говоря, ваш ДРАКОН тоже не избавился от знака отрицания (как не избавился он от циклов, goto, и всего остального).
А вот вам пример кода без "нет":
if user IsRegular:
...Прекрасно показывает, что текстовые языки умеют существовать без логического отрицания.
Я уже не говорю, что у вас слитное написание Not в сложном слове без пробелов.
Простите, но так писали несколько тысяч лет назад, когда люди еще не изобрели пробел.
Слово "непонимание" смотрит на вас с глубоким непониманием.
Не лезли бы вы в языкознание, честное слово...
Текстовое программирование не может обойтись без логических отрицаний.
Может.
А ДРАКОН легко удаляет связку логического отрицания, переставляя знаки Да и Нет.
Текстовое программирование легко удаляет связку логического отрицания, переставляя ветки then и else.
Но дело не в этом.
Вы, фактически, утверждаете, что если взять нотацию условия с выходами (1) и (2), то нотация, в которой значения "да" и "нет" присвоены выходам произвольно (т.е. (1) может быть как "да", так и "нет"), и при этом условие не может содержать отрицания, лучше, чем нотация, в которой выход (1) всегда соответствует значению "да", но условие может содержать отрицание.
Это громкое заявление. У вас есть ему обоснование?
Текстовое программирование не может обойтись без логических отрицаний.
А ДРАКОН легко удаляет связку логического отрицания, переставляя знаки Да и Нет.
А как в ДРАКОНе реализуется исключающее ИЛИ (xor)?
См. здесь Глава 17. Логическая функция
«Исключающее ИЛИ» Работающее содержание в начале книги
А зачем после ответа "нет" на вопрос "Том пошёл за кладом?" ещё раз задавать тот же вопрос, ожидая ответ "да"?
И код
if (a ^ b){
...
}понятнее будет.
А зачем после ответа «нет» на вопрос «Том пошёл за кладом?» ещё раз задавать тот же вопрос, ожидая ответ «да»Потому что этого требует (визуальная) математика.
Поясняю. Был проведен эксперимент, а именно: что будет, если удалить все логические связки в формуле «Исключающее ИЛИ»?
Ход эксперимента подробно описан в главе во всех деталях.
Результат показал, что после удаления связок получилось плохо (математически правильно, но громоздко и непонятно).
Поэтому вы совершенно справедливо, говорите, что с if лучше и понятнее.
В конце главы сделан вывод, что решение на вашей картинке плохое. Поэтому оно отброшено и сохранен обычный знак xor (в любом начертании).
в ДРАКОНе стрелок нетКак бы вы эти линии не называли, но раз движение по ним допускается только в одну сторону, то принципиальных отличий от стрелок у них нет.
циклы у вас не циклы, но циклы.
стрелки не стрелки, но стрелки.
адрес не goto, но goto.
Владимир Даниэлович, займитесь лучше делом — напишите воспоминания о разработке Бурана. Ну вот честное слово, пользы будет в разы больше.
Метки Да и Нет у иконы Вопрос нужны для того, чтобы упорядочить алгоритм и соблюдать законы порядка:
1. Главный маршрут идет по шампуру
главный — это всегда да? или главный — это всегда нет? :-)
если вы выбираете один любой из вариантов — значит, без инверсии («неизлечимой проказы») вам не обойтись.
а если выбираете «от контекста» (иногда главный «да», а иногда главный «нет»), то без подписей вам не обойтись, а это — потенциальный источник ошибок.
Не забываем, что в Си и в Паскале условия перевернутые, не так ли?
ДРАКОН позволяет проследить их пальцем, не отрывая палец от экрана или бумаги.
Т.е вы толком и этих языков не знаете?
Вы застряли на ПРОЛ-2, на goto, на вождении пальцем по экрану, на глобальных переменных (хорошо хоть уже поняли, что они не обязательно 8-символьные).
Паронджанов, сейчас не 1980-й. и даже не 1990-й. Очнитесь, сэр, это мертвая француженка… вы занимаетесь некрофилией…
Тем, кто умеет программировать (например, человек, способный окончить среднюю общеобразовательную школу, т.е. не совсем уж дурак) — ДУРАКОН не нужен.
Тому, кому дуракон нужен — тех, по-хорошему, к программированию нельзя подпускать. И к лечению тоже. Если человек неспособен понять написанную текстом инструкцию, если ему нужно водить пальцем по картинкам — значит, у него интеллектуальный уровень такой, что лучше бы ему работать дворником.
главный — это всегда да? или главный — это всегда нет?Ни то, ни другое. Главный маршрут — это наиболее благоприятный, самый лучший маршрут алгоритма (happy path).
Главный маршрут — это наиболее благоприятный, самый лучший маршрут алгоритма (happy path).
он необязательно один. Их может быть несколько одинаково равновероятных путей. Представьте себе алгоритм с rnd() и, например, 6 ветками, по каждому из выборов.
он необязательно один. Их может быть несколькоЭто неважно.
Главный маршрут назначает разработчик по своему усмотрению.
Главный маршрут обязательно идет по шампуру — жирная линия highlighted, happy path
Т.е. разработчик может назначить главный маршрут из подхода «чем правее, тем лучше»? а как же основное правило? Основной маршрут — это неудачный исход, издевательски называемый разработчиком ДУРАКОНа «happy path»?
Основной маршрут — это неудачный исход, издевательски называемый разработчиком ДУРАКОНа «happy path»?
Нет, не так. Я уже устал вас поправлять.
1. Не основной маршрут, а главный маршрут, или царский путь.
2. Главный маршрут — это наиболее благоприятный маршрут, наилучший из возможных маршрут (happy path).
Например, прогулка с броском кубика на каждом перекрёстке. Какой маршрут «главнее» — налево, направо или прямо, если нет цели попасть в какое-либо определённое место.
Или вот реальный пример из сервиса, который у меня тут в разработке: нам приходит документ одного из трех типов, для каждого типа — свой дальнейший маршрут обработки, они совершенно равноправны.
Мне, кстати, любопытно, как на ДРАКОНе вообще написать динамический вариант этой задачи, когда нам приходит документ из произвольного числа типов, мы по типу достаем обработчик из реестра обработчиков, и отправляем документ в него. Естественно, с верификацией, что отправляем куда надо, а не куда угодно.
что делать, если все маршруты равнозначны, равноправны и равноблагоприятныНазначаете любой.
Но. Наверно в вашем случае лучше упорядочить по привычной схеме слева направо.
Получится: налево, прямо, направо.
Хоть какой-то порядок будет.
Возможно, вы придумете что-нибудь поумнее.
Главное, чтоб был не хаос, а порядок.
Правило хорошей хозяйки гласит: если постараться, порядок всегда можно навести.
они все happy path. Ваш ход?
Главный маршрут назначает разработчик по своему усмотрению.
разработчик 1 назначил один маршрут, разработчик 2 — другой. Война правок? Как же однозначность, которую обещает ДРАКОН?
разработчик 1 назначил один маршрут, разработчик 2 — другой.это мелочь. Разработчики еще могут меж собой договориться. А вот как быть с «однозначностью восприятия»? со всеми этими симультантностями и эргономиками?
Здесь нет никаких проблем.
Главный маршрут назначает разработчик по своему усмотрению.
Если "по своему усмотрению", то любой выбор разработчика — верный. Возвращаемся к тому, что ДРАКОН ничего не улучшил.
Если «по своему усмотрению», то любой выбор разработчика — верный.ДРАКОН предоставил разработчику навести порядок. Этой возможности у разработчика раньше не было.
Этой возможности у разработчика раньше не было.
Раньше — это когда?
Сейчас у меня, как у разработчика, есть множество возможностей навести порядок в своем коде, и ни одна из них никак не связана с ДРАКОНом.
Все ваши возможности находятся в рамках мировой ИТ-отрасли, не так ли?
А возможности мировой ИТ-отрасли, увы, ограничены и приводят, как показал инцидент с Боингом, к гибели людей.
Вы считаете такое положение нормальным, а я нет.
А возможности мировой ИТ-отрасли, увы, ограничены и приводят, как показал инцидент с Боингом, к гибели людей.
Вы опять занимаетесь демагогией.
Раньше — значит до ДРАКОНа.
Вот только сейчас — сильно после ДРАКОНа.
А возможности мировой ИТ-отрасли, увы, ограничены и приводят, как показал инцидент с Боингом, к гибели людей.
Да, ограничены. Но достаточно широки для моих задач, и шире, чем мне может предоставить ДРАКОН.
Но вот ПО автопилота работало точно по тому алгоритму, который заложили конструкторы. А ошибки архитектуры, как мы уже выяснили, драконом не обнаруживаются и не исправляются.
Этой возможности у разработчика раньше не было.
Ой, да что Вы говорите? И как же это я поддерживаю порядок в коде, и даже не догадываюсь, что, оказывается, без ДРАКОНА это невозможно?
Вы точно в реальном мире живёте?
Но кроме вас существует большой мир — и в этом мире не все благополучно.
Все ваши возможности находятся в рамках мировой ИТ-отрасли, не так ли?
А возможности мировой ИТ-отрасли, увы, ограничены и приводят, как показал инцидент с Боингом, к гибели людей.
Вы считаете такое положение нормальным, а я нет.
ДРАКОН — это первый шаг к осознанию реальных проблем реального мира (мировой ИТ-отрасли) и указание пути, в котором следует двигаться к безошибочному будущему.
Это долгий путь, и ДРАКОН делает первый маленький шаг.
ДРАКОН — это первый шаг к осознанию реальных проблем реального мира (мировой ИТ-отрасли) и указание пути, в котором следует двигаться к безошибочному будущему.
Вы крайне сильно заблуждаетесь. Для того, чтобы сделать шаг вперёд — нужно изучить то, что сделано до Вас. С изучения существующего начинается любая разработка. А Вы — 20 лет топчетесь на месте.
И я благодарен вам за ваши предлоения по совершенствованию ДРАКОНа.
Можете не сомневаться, что они будут тщательно изучены и подвергнуты всесторонней экспертизе сообщества.
Повторяю, если возникнут еще мысли по совершенствованию, милости просим, я буду очень благодарен.
ДРАКОН — это первый шаг к осознанию реальных проблем реального мира (мировой ИТ-отрасли) и указание пути, в котором следует двигаться к безошибочному будущему.
В том-то и дело, что нет. Это вы думаете, что вы выбрали правильный путь, но даже в рамках комментариев к этому посту вам не удалось свою мысль никак обосновать.
Я вот искренне считаю, что ваш путь — неправильный.
Главный маршрут — это наиболее благоприятный, самый лучший маршрут алгоритма (happy path).
Вам неоднократно говорили, что бывают алгоритмы с равно благоприятными маршрутами. И что в этом случае делать?
бывают алгоритмы с равно благоприятными маршрутами.Вы правы. Бывают.
И что в этом случае делать?Главный маршрут разработчик назначает по своему усмотрению и помещает его на шампур ветки или шампур примитива.
Главный маршрут разработчик назначает по своему усмотрению
Там нет главного маршрута. Его нельзя назначить, потому что это исказит спецификацию.
Вы хотите сказать, что идеология ДРАКОНа не способна выразить такую простейшую задачу?
Там нет главного маршрута. Его нельзя назначить, потому что это исказит спецификацию.Чепуха.
Вы не видели спецификации, поэтому не можете этого говорить.
Вы не видели конкретной спецификации, по которой написан конкретный алгоритм, поэтому вы не можете говорить "чепуха" о моих требованиях к этому алгоритму.
Процитирую комментарий целиком.
Там нет главного маршрута. Его нельзя назначить, потому что это исказит спецификацию.
Чепуха.
Так к чему же относится слово "чепуха"?
Аргументируйте. Я, как автор спецификации, считаю, что назначение любого из равнозначных маршрутов главным искажает смысл спецификации.
А спецификация тут ни при чем. Пришей кобыле хвост. В огороде бузина, а в Киеве дядька.
Это как это "не искажает"?
В спецификации описаны равнозначные маршруты. Если в алгоритме/коде один из маршрутом будет главным (а остальные, следовательно, не главными), такой алгоритм/код искажает намерение спецификации.
Число маршрутов в алгоритме велико — это степенная функция от числа икон Вопрос.
Главный маршрут задается для каждой ветки силуэта независимо от остальных веток.
Вставлять дракон-алгоритм в спецификацию — это разумно. Описывать текстом каждый шампур в спецификации нецелесообразно.
Это не дает никаких преимуществ для спецификации
Спецификацию ни при чем
Как это не при чем? Она описывает желаемое поведение системы.
Число маршрутов в алгоритме велико — это степенная функция от числа икон вопрос. Главный маршрут задается для каждой ветки силуэта независимо от остальных веток.
И что? Даже в рамках одной "ветки силуэта" есть равнозначные маршруты. Я уже приводил пример с обработкой документов по типу (если надо, могу повторить), как его выразить на ДРАКОНе, не исказив ту информацию, что все документы равнозначны?
Вставлять дракон-алгоритм в спецификацию — это разумно, но описывать текстом каждый шампур в спецификации не нужно.
Вы, кажется, не поняли. Спецификация уже есть. ДРАКОН, как, типа, язык программирования, является способом реализации того, что написано в спецификации.
Вы, кажется, не поняли. Спецификация уже есть. ДРАКОН, как, типа, язык программирования, является способом реализации того, что написано в спецификации.Вы правы, я не понял. Я подумал, что разработка спецификаций — это ваш хлеб.
Поэтому я и сказал, что ДРАКОН как язык спецификаций — это золотое дно.
И что? Даже в рамках одной «ветки силуэта» есть равнозначные маршруты. Я уже приводил пример с обработкой документов по типу (если надо, могу повторить), как его выразить на ДРАКОНе, не исказив ту информацию, что все документы равнозначны?1. Вы правы, я внимательно прочитал ваш пример, и я конечно согласен, что бывают равнозначные маршруты и что в вашем примере маршруты равнозначны. Тут нет никакой причины для спора.
2. В этом случае вы как разработчик выбираете ЛЮБОЙ из этих маршрутов и помещаете его на шампур данной ветки (ветки А). Это ничего не искажает и не может исказить.
Если при этом задача полностью решена, то мы получаем малоинтересный частный случай, силуэт не нужен, а ветку А мы превращаем в примитив А.
3. Если же задача не решена, то алгоритм продолжаетс в следующих ветках.
Как именно они продолжаются?
Предположим, что ветка А трехадресная, имеющая три иконы Адрес с именами В, С, D.
А теперь внимание!
Чтобы был порядок, необходимо:
1. В ветке А три маршрута должны располагаться так:
1.1. Маршрут B на шампуре
1.2. Маршрут С справа от него
1.3. Маршрут D еще правее
2. Ветки А, В, С, D располагаются в силуэте слева направо:
— именно в таком порядке;
— включаются в работу последовательно друг за другом в том же самом порядке.
___________________________
Вы хотите все это записать в спецификации?
А зачем?
В этом случае вы как разработчик выбираете ЛЮБОЙ из этих маршрутов и помещаете его на шампур данной ветки (ветки А). Это ничего не искажает и не может исказить.
То есть шампур больше не означает главную ветку, он означает любую?
Ветки А, В, С, D располагаются в силуэте слева направо:
— именно в таком порядке;
— включаются в работу последовательно друг за другом в том же самом порядке.
С чего вы взяли, что они включаются в работу последовательно друг за другом? Они взаимоисключающие.
Вы хотите все это записать в спецификации?
А зачем?
Нет, не хочу. Я хочу, чтобы алгоритмы, выраженный диаграммой, отражал спецификацию. Спецификация первична.
То есть шампур больше не означает главную ветку, он означает любую?В вашем случае (случае равнозначных маршрутов) да.
В вашем случае (случае равнозначных маршрутов) да.
А вот теперь снова вопрос: как человеку, который видит эту диаграмму впервые, и прочитал в ваших книжках, что шампур означает главную ветку, понять, что в данном случае это не так?
Вы же вроде бы говорили, что задача ДРАКОНа — упрощать понимание, а тут сплошная путаница.
В чем вы видите путаницу для человека, который видит эту диаграмму впервые?
Он не знает, равнозначные маршруты, или самый левый — главный.
Он не знает, равнозначные маршруты, или самый левый — главный.Не совсем так. Он помнит, что самый левый главный. Но он помнит и о том, что принцип «чем правее, тем хуже» работает не всегда, бывают исключения.
Так что противоречий для него не будет.
Про наличие потиворечий — это надуманное утверждение.
Повторяю: здесь нет никаких противоречий.
Он помнит, что самый левый главный. Но он помнит и о том, что принцип «чем правее, тем хуже» работает не всегда, бывают исключения.
Вот это и есть путаница: глядя на диграмму, нельзя сразу однозначно сказать, что означает крайний левый маршрут.
Вот это и есть путаница: глядя на диграмму, нельзя сразу однозначно сказать, что означает крайний левый маршрут.Не могу согласиться. тут нет никакой путаницы.
Человек, который смотрит на дракон-схему, пытается понять смысл схемы, ее семантику. А что там слева на шампуре — дело десятое.
А что там слева на шампуре — дело десятое.
Ну то есть порядок расположения, на самом деле, не имеет значения. Так и запомним.
Ну то есть порядок расположения, на самом деле, не имеет значения. Так и запомним.Нет, имеет. Очен даже имеет.
Вы допустили преувеличение, а это не есть хорошо.
Чем ближе к крайностям, тем дальше от истины.
Вы ведь не хотите уклоняться от истины, не так ли?
Это просто замечательно.
А что там слева на шампуре — дело десятое.
[...]
Очен даже имеет [значение порядок].
Замечательно согласованные мысли.
Вы ведь не хотите уклоняться от истины, не так ли?
Чтобы не "уклоняться от истины", нужна терминологическая база. Я от вас сильно больше одного раза просил формальных определений используемых вами терминов, и формальной аргументации ваших построений, но каждый раз безуспешно.
ДРАКОН в спецификациях — это золотой дно. Подумайте. Для вас лично появился шанс — не упустите его.
Если вы будете использовать язык ДРАКОН при создании спецификаций, вы получите колоссальные преимущества. Все будут приходить к вам учиться.
Это утверждение нуждается в обосновании.
В моем опыте любой дополнительный язык при создании спецификаций представляет собой проблему, а не преимущество. Учитывая, что ДРАКОН не позволяет описывать ни бизнес-сущности, ни варианты использования, его ценность для написания спецификаций представляется мне завышенной.
Впрочем, все это никак не влияет на тот факт, что в моем примере спецификация уже есть, и она уже написана не на ДРАКОНе. Поскольку вы в вашем тексте и комментариях противопоставляете ДРАКОН традиционным языкам программирования, это корректная постановка примера.
Какой сигнал, какую рекомендацию насчет goto следует дать им? Как вы считаете?
Учиться.
В конце концов, сейчас достаточно языков, где goto либо нет вовсе, либо им нет необходимости пользоваться.
Не создавать себе кумира, не возводить чьи-либо слова в догму и учиться, учиться, учиться.
Я бы сказал, что вы разделяете позицию Дональда Эрвина Кнута в его известной дискуссии с Эдсгером Вибе Дейкстрой.
Вы прямо напоминаете персонажа из известного Азимовского цикла «Основание» с его подходом к археологии:
в себя гигантскую дозу табака, — увлекаюсь археологией.
— Вот как?
— Его светлость, — перебил Пирени, — великий знаток в этой области.
— Возможно, возможно, — скромно ответил его светлость. — Я проделал огромное количество работы в этой области и прочел массу научных книг. Всего Джадина, Обиджази, Кромвилла… О, всех их, знаете ли.
— Я, конечно, слышал об этих авторах, — ответил Хардин, — но никогда не читал.
— А стоило бы, мой дорогой друг. Знания не пропадают. Я был изумлен и счастлив, найдя здесь на периферии копию Ламета. Поверите ли, в моей
библиотеке эта копия отсутствует. Кстати, доктор Пирени, вы не забыли своего обещания сделать для меня эту копию?
— Буду только рад.
— Ламет, знаете ли, — продолжал канцлер торжественно, — Рассматривает новый и крайне интересный вопрос, который добавляет к моим предыдущим знаниям новое к «Вопросу о происхождении».
— Что это за вопрос, — переспросил Хардин.
— Вопрос происхождения. Место происхождения человеческой расы, знаете ли. Ведь конечно, вы знаете, что считают, что когда-то человеческая раса
занимала лишь одну планетную систему.
— Да.
— Бесспорно, никто уже точно не знает, что это была за система, затерянная в дымке времени, знаете ли. Однако, существуют разные теории. Сириус, как говорят некоторые. Другие настаивают на Альфа Центавра, понимаете ли.
— А что говорит Ламет?
— О, он идет по совершенно новому пути. Он старается доказать, что археологические ископаемые третей планеты Арктура доказывают, что человечество существовало там еще до того, как существовали космические перелеты.
— И это означает, что именно тогда эта планета была колыбелью человечества?
— Вероятно. Надо тщательно изучить и взвесить все обстоятельства, прежде чем я скажу с уверенностью. Надо же посмотреть, насколько
компетентны его утверждения.
Некоторое время Хардин молчал. Потом он спросил:
— Когда Ламет написал эту книгу?
— О, я думаю примерно восемьсот лет назад. Конечно, он в основном опирался на предыдущую работу Глина.
— Зачем же тогда доверять ему? Не проще ли полететь на Арктур и самому изучить раскопки?
Лорд Дорвин поднял брови и быстро втянул в себя табак.
— Да, но с какой стати, мой дорогой друг?
— Для, того чтобы получить информацию из первых рук.
— Но где необходимость? Это какой-то очень сложный и запутанный метод получения информации.
Смотрите сами, у меня собраны работы всех старых
мастеров, великих археологов прошлого. Я сравниваю их друг с другом, нахожу разногласия, анализирую противоречивые суждения, решаю, какое из
них наиболее правдивое и прихожу к заключению. Это и есть научный метод.
По крайней мере — так я его понимаю. Как неимоверно грубо будет отправляться на Арктур, или например, в Солнечную систему, и шататься по
планетам, когда великие ученые прошлого уже изучили все куда более эффективно, чем мы можем когда-либо надеяться."
Но, смотрите.
Вы человек очень высокой квалификации и обладаете большими знаниями и большими способностями.
Это обстоятельство позволяет Вам выполнять трудную работу — правильно использовать goto и делать программу не только лаконичнее, но и снизить вероятность ошибки.
Не подвергая сомнению квалификацию Rsa97, я лишь замечу — лучший способ использования goto — это его отсутствие. Никакие сверхспособности для этого не нужны — нужно лишь отсутствие врожденного идиотизма. Этому («программированию без использования goto») учат уже в средних общеобразовательных школах.
Понимаете? Нормальных людей (т.е. посещающих обычную среднюю школу, для детей без задержки интеллектуального развития) со школы учат нормально программировать.
Правда, есть одна запятая. То, что вы рассказываете про образование — святая правда.
Но. Все это не работает. Человечество по-прежнему не умеет писать безошибочные алгоритмы.
На руках разработчиков алгоритмов кровь сотен людей. И никакой Азимов не может опровергнуть эту истину.
1) за счет дополнительного слоя абстракции над используемым языком.
2) за счет генерируемого гомнокода (вы ж почему-то стесняетесь «выкласть» сгенерированное тышов-генератором?)
3) За счет того, что что ДУРАКОН позволяет генерировать алгоритм с ошибками, которые принципиально нельзя, невозможно допустить без дуракона. Т.е. ДУРАКОН сам становится генератором ошибок.
4) за счет того, что ДУРАКОН не работает с данными. За 10-15 лет после того, как в это вас ткнули носом — он не научился. Значит, и не научится.
5) я уже даже не хочу говорить про верификацию, средства коллективной работы — их просто невозможно нормально сделать.
На руках разработчиков алгоритмов кровь сотен людей— Используй разаработчики ДУРАКОН — счет шел бы на сотни тысяч.
а факты безусловно подтверждают, что ДУРАКОН не имеет самостоятельной сущности, а существует лишь как надстройка над языками. Подтверждают, что он умеет генерировать «запрещенные» алгоритмы (с переходом внутрь циклов, например).
Подтверждают, что автор сам делает ошибки в самых примитивных детских демонстрационных алгоритмах.
Вы экипаж своей летающей тарелки в алгоритме из пары десятков шагов угробили…
это примерно как вы покупаете книгу «как улучшить знания математики», и читаете там в предисловии: «С помощью этой книги вы научитесь в уме решать любые сложные тригонометрические задачи, например 2+3=7». Наверное, после такого предисловия у вас возникнет куча вопросов к автору, даже если книга издана 50 000 экземпляров? а если скажут, что автору 10 лет назад говорили, что это не тригонометрия, и 2+3 ну никак не 7?
автор сам делает ошибки в самых примитивных детских демонстрационных алгоритмах.Это не так. В алгоритме летающей тарелки нет никаких ошибок.
Вы экипаж своей летающей тарелки в алгоритме из пары десятков шагов угробили…
Она полностью соответствует легенде. А легенда такая:
Легенда
Нас интересует: взорвется тарелка или нет. Для этого надо запустить хотя бы один из двух: либо плазменный реактор, либо фотонный двигатель, причем последний считается безотказным.
Она полностью соответствует легенде. А легенда такая:
… и после этого вы что-то пафосно говорите о крови на руках разработчиков? Их код тоже "полностью соответствовал легенде".
Если фотонный двигатель безотказен — нет смысла проверять, взорвалась тарелка или нет. а проверка есть. Т.е. либо фотонный двигатель не безотказен, либо проверка излишняя.
ну и наконец — после ремонта исправность двигателей не проверяется, сразу «в полет».
три ошибки на такой алгоритм — это результат чтения книги «как улучшить работу ума»? а до чтения сколько ошибок было? 10? 100?
понимаете, ну любой начинающий эмбеддер знает — студент уже знает — после серьезного инцидента нужно проверять или переинициализировать периферию.
Вы придумываете новую легенду и говорите, что схема не соотствует вашей легенде.
Схема не обязана соответствовать вашей легенде. Она соответствует моей легенде. Так что там нет никаких ошибок.
Не фантазируйте.
Я не имею права упрекать программистов в этой беде, так как дело не только в программистах, а во всех специалистах и чиновниках, которых так или иначе причастны к созданию алгоритмов и жизнеритмов Боинга и не только.
Но даже их я не имею права упрекать, потому что получится, что Боинг, FAA и авикомпании плохие, а все остальные белые и пушистые. А это совсем не так.
Это не беда Боинга, это общая беда мирового ИТ-сообщества, если хотите, общая беда человечества.
Потому что человечество до сих пор так и не научилось, и не умеет писать безошибочные алгоритмы.
И об этом я ясно сказал в заголовке моей статьи.
Я считаю, что язык ДРАКОН делает первый шаг к безошибочному будущему. Но это всего лишь первый шаг, не более того.
Это не беда Боинга, это общая беда мирового ИТ-сообщества, если хотите, общая беда человечества. Потому что челоечество не умеет писать безошибочные алгоритмы.
не умеет. Абсолютно безошибочные не умеет. Но есть куча методик, которые позволяют уменьшить стоимость ошибки. К ДРАКОНУ это не относится — он вообще вне парадигмы того же тестирования ПО или верификации по системе типов (за нее 0xd34df00d расскажет)
Я считаю, что язык ДРАКОН делает первый шаг к безошибочному будущему. Но это всего лишь первый шаг, не более того.
не делает, это Ваше личное мнение, которое, к сожалению, слишком ангажировано и ошибочно.
Слово «обвиняете» здесь не подходит. Обвинять может только прокурор.
Да нет, обвинять может любой человек. Когда вы пишете "На руках разработчиков алгоритмов кровь сотен людей" — это и есть обвинение.
Я не имею права упрекать программистов в этой беде
Не имеете, но упрекаете. Цитата выше (и в тексте поста их предостаточно).
Я считаю, что язык ДРАКОН делает первый шаг к безошибочному будущему.
Ну делает, да. Первый для себя. Вот только индустрия уже продвинулась вперед.
Она соответствует моей легенде. Так что там нет никаких ошибок.
К сожалению, это утверждение невозможно проверить (или опровергнуть), потому что единственное хоть сколько-то формальное описание "вашей легенды" — это и есть ваша схема.
Ну и если ваша легенда не предусматривает проверку после ремонта — это ж еще печальнее, не правда ли? Т.е. вы даже не умеете проектировать сложные системы, не правда ли? Т.е. то, что в 1990-м году знал студент-пятикурсник кафедр САУ, АиТ или РТС — вы до сих пор не знаете?
На руках разработчиков алгоритмов кровь сотен людей. И никакой Азимов не может опровергнуть эту истину.
Это не "истина". Это ваше эмоциональное суждение.
Но дело даже не в этом. Дело в том, что, вопреки тому, что вы пишете в статье, вам нечего предложить для улучшения этой ситуации.
Вы про управление сложностью слыхали?
Видимо, нет, потому что сложные проекты вроде ядра линукса или браузера хром на драконе не написать. Скорее всего — принципиально. А вот опасные языки вроде с и с++ почему-то «тащат»?!
Более того — скажу — что в определенных случаях, но коллега ответил за меня ниже, лучше один goto, чем дополнительные 10 переменных и циклов. В общем случае — чем код короче, чем он нагляднее, тем он менее ошибкоопасен
И наша задача — не учить начинающих «дуракону», а учить актуальным средствам разработки, их ограничениям и их правильному применению.
Пользователь программы Геннадия Тышова (ДРАКОН-конструктор под названием ИС Дракон ) работает с дракон-схемой (дракон-алгоритмом), которая для него является исходником. В этой схеме вы даже под микроскопом не увидите goto. Их там нет.отлаживать я буду все равно в целевой системе. Потому, что ни Тышов, ни Паронджанов не смогли написать отладчик/эмулятор. Несмотря на все книги об улучшении работы ума. В отладчике я увижу сгенерированное этой поделкой код. Вы не постесняетесь вывалить его сюда? последний раз, который я видел — там была жуткая мешанина из goto.
1. Операторы goto никуда не исчезают. они как были, так и остались.а вот у меня goto нет. вообще. они мне не были нужны и не использовались с тех пор, как ушел с фортрана. И я ничуть не страдаю
2. Работая с ДРАКОНом, человек никогда не пишет goto ручками. Он их не видит и не должен видеть.я и без ДУРАКОНа не пишу goto. ни ручками, ни автоматом. а вот ДУРАКОН эти goto генерирует. почему?
3. ДРАКОН-конструктор Тышова ИС Дракон физически исключил для человека возможность писать goto ручками и видеть их на экране.поделка тышова неспособна сгенерировать результирующий код без goto. И поделка Тышова неспособна проэмулировать работу системы для отладки.
Выше я описал идеальный случай, как должно быть.
На практике могут возникать вопросы реализации и некоторые отступления от идеала.
Но со временем рано или поздно все наладится.
но в реалии, несмотря на книгу «как улучшить работу ума», тышов не смог выродить нормальной кодогенерации. за 30+ лет! Это, вообще-то, уровень всего лишь дипломной работы. (впрочем, не удивлюсь, если для каких-нибудь Физтеха или ИТМО это уровень курсача).
Вельбицкий, один из адептов Р-технологийВельбицкий не один из адептов Р-технологии. Он ее автор.
Он ее автор.
Ну, тем хуже. Он тоже не смог создать ничего работающего.
получается как-то странно: создаются гениальные методологии, позволяющие быстро и просто писать безошибочные программы. И авторы этих методологий неспособны за 30+ лет написать работающую систему, реализующую эти методологии.
Ибо ни на ДУРАКОНе, ни на Р-технологиях ничего достойного внимания не создано.
Я вам уже говорил, и еще раз повторюсь: этот ваш дуракон имел смысл в 70-х, когда спецвычислители появились, а школа инженеров была ПВУшная (а то и «релейная»). И, как писали Стругацкие, «нам позарез нужен программист. Программисты — народ дефицитный, избаловались»(ц)ПНВС
Сейчас (точнее, уже 35 лет) инженеров учат программированию в ВУЗах. С первого курса. И для расчетов, и для моделирования, а профильные специальности — и для проектирования систем управления. Любой инженер, выпущеный с 90-го года владеет этим инструментом — точно так же, как выпускник школы владеет арифметикой. поэтому переучивать или доучивать почти не нужно.
Поэтому никаких преимуществ ДУРАКОН уже не дает вообще. Ну не нужно никакому нормальному здоровому человеку бегать по стадиону с костылями (а создание систем — это бег за результатом, причем наперегонки с соперниками). а инвалид (уж извиняюсь за неполиткорректность) бегать не должен, ибо ног нет — он должен заниматься сидячей работой.
Вот только, как уже говорилось, вы никуда от этих операторов не делись, но продолжаете на них ссылаться, как на опасные.
Давайте вот на конкретном примере. У вас есть простенькая задачка: получить данные из источника X, а потом, в зависимости от признака в данных, отправить ее в получатель Y1. Y2 или Y3. Как на этапе рисования схемы в ДРАКОН понять, что получатель Y3 не умеет принимать данные, отдаваемые источником X?
(при этом когда я пишу этот же switch/case в языке программирования с достаточной типизацией, я получаю эту информацию ровно в тот момент, когда пытаюсь написать Y3(x))
Он на время удаляет с глаз человека несколько опасных операторов и подсовывает вместо них безопасные.
[...]
С оговоркой: ДРАКОН не гарантирует полную защиту от ошибок.
Ну, собственно, этого и достаточно. Оператор, который не гарантирует полную защиту от ошибок, нельзя называть безопасным.
Он на время удаляет с глаз человека несколько опасных операторов и подсовывает вместо них безопасные.
Это ложь. Он даёт иное визуальное представление тем же самым операторам, плюс добавляет один опасный оператор — нижняя икона силуета столь же опасна, как оператор goto.
Кроме того, он выбрасывает (вернее, изначально не поддерживает) такие необходимые для работы возможности языка как объявление функций и локальных переменных.
И, заодно, как будет выглядеть вложенная функция, возвращаемая из основной как замыкание.
Если требуется нестандартная лямбда, выносите алгоритм в отдельную функцию и вызывайте эту функцию в лямбде.
app.drakon.tech/ide/doc/drakon-tetris/89
app.drakon.tech/ide/doc/drakon-tetris/31
Обоснование: вложенные алгоритмы красивы и элегантны, но их не всегда удобно читать.
Целевой язык (и все его коды) остаются в целости и сохранности.Зачем применять для JavaScript идеологию Питона?
Ну и если лямбду ещё можно вынести в отдельную функцию, хотя и не всегда это удобно, то замыкание вам придётся иммитировать глобальными переменными, что совсем не комильфо.
Чтобы потом понимать написанный код. Но этот вопрос не относится к языку ДРАКОН. Как хотите, так и пишите. Другое дело, что текущие реализации ДРАКОНа не позволяют нарисовать алгоритм в алгоритме. Это да. Поэтому в замыканиях только текст, а не графические примитивы.
«замыкание вам придётся иммитировать глобальными переменными»
Не придётся. Замыкания работают, как обычно.
Если требуется нестандартная лямбда, выносите алгоритм в отдельную функцию и вызывайте эту функцию в лямбде.
Значит, утверждение "все возможности [целевого] языка бережно сохраняются и никуда не деваются" — ложь. Ну и да, дальше у вас начнется такой набор развлечений с замыканиями, что вам не понравится.
Обоснование: вложенные алгоритмы красивы и элегантны, но их не всегда удобно читать.
Вы хотели сказать: неудобно читать в ДРАКОНе. Ну да, это его недостаток.
Все сложное просто вписывается в квадратик =)
app.drakon.tech/ide/doc/drakon-tetris/118
Все сложное просто вписывается в квадратик
… в пределе получая ДРАКОН-программу из одного квадратика, содержащего полный код программы на языке имплементации?
В данном примере мы видим совмещение недостатков текстового и графического способов программирования, при утере достоинств каждого из них.
Кроме того, в файле buildGame, например, применение схемы "силуэт" делает программу менее читаемой, чем если бы это был один "шампур". Не надо так делать.
В общем, Дракон слишком примитивен. Нужен уровень хотя бы SFC.
Пояснение к картинке — Sx — это чистые по возможности функции (написанные на любом кстати, языке, не обязательно графическом), поперечные черты — условия перехода конечного автомата.
Да и компактность представления тут существенно выше.
В обсуждении появились замечания о сопоставлении ДРАКОНа и верификации.
Хочу объяснить принциальную разницу.
Верификация, без сомнения, замечательная вещь, и я обеими руками за верификацию.
Но. Верификация требует затраты дополнительного времени и дополнительных усилий.
Если таких возможностей нет (нет времени или жаль усилий) верификацию, естественно, не проводят.
Если кто-то желает привинтить к ДРАКОНу верификацию, — ради Бога! Нет никаких возражений. Флаг вам в руки.
Сегодня в ДРАКОНе нет верификации. А что есть? Есть автоматическое частичное доказательство правильности создаваемых дракон-алгоритмов с помощью аксиоматического метода.
Чем это отличается от верификации? Тем, что частичное доказательство правильности проводится полностью автоматически и не требует никаких дополнительных ресурсов. Иными словами, затраты дополнительного времени и дополнительных усилий НЕ ТРЕБУЮТСЯ.
Как говорится, солдат спит, а служба идет.
Причем пользователь (разработчик алгоритма), грубо говоря, не имеет никакого понятия о том, что где-то внутри программы ДРАКОН-конструктор каким-то чудом происходит самое настоящее математическое доказательство.
Здесь некоторые мои уважаемые оппоненты говорили о том, что читали мои книги и иронически при этом покрякивали по поводу моей дремучести.
Что тут скажешь?
«Этого-то товарищ Попандопуло и не учел, слона-то он и не приметил».
Есть автоматическое частичное доказательство правильности создаваемых дракон-алгоритмов с помощью аксиоматического метода.
Что такое "правильный алгоритм", и как именно автоматически доказывается его правильность?
некоторые мои уважаемые оппоненты говорили о том, что читали мои книги и иронически при этом покрякивали по поводу моей дремучести.
Я попробовал. Честно-честно. Мне г-н Кнут и г-н Дийкстра гораздо понятнее в плане текста, чем та вода, которая налита в Ваших книгах. И шутки прибаутки неудачные
Частичное доказательство правильности: «ваш алгоритм частично правильный».
МОДУЛЬ TST2;
ПРИЗНАКИ
ВРЕМЯ ВРМ ()();
ОЖИДАНИЕ ВРМ ()();
КОНЕЦ
КОМАНДЫ
KK1 K2H.КОЛЬЦВТЯН (TEST);
КОНЕЦ
СИГНАЛЫ
S1 SU2HKОЛВТЯН (TEST);
КОНЕЦ
КОНСТ
НУЛЬ=0;
НУЛЬ1=«12345678»;
НУЛЬ2=«ABCD»;
НУЛЬ3=1Д 2Ч 30М 10C;
КОНЕЦ
МОДУЛЬ TST1 МОДЕЛЬ;
ПРОЦЕСС TST1;
TEST :1T;
TEST2:1T;
КОНЕЦ
СОБЫТИЯ
C1 (TEST)(TEST);
КОНЕЦ
ПРИЗНАКИ
X1 ЛОГ (TEST)(TEST);
X2 ЦЕЛ (-1234..100000) (TEST)(TEST);
X3 ВРМ (TEST)(TEST);
X4 ПОЛУСЛОВО (TEST)(TEST);
X5 СЛОВО (TEST)(TEST);
X6 ВРМ (TEST)(TEST);
ОШИБКА ЦЕЛ(1000) (TEST)(TEST);
ТИП ЦЕЛ(1000) (TEST)(TEST);
Z1 ЛОГ (TEST)(TEST);
Z2 ЛОГ (TEST)(TEST);
Z3 ЛОГ (TEST)(TEST);
Z4 ЛОГ (TEST)(TEST);
Z5 ЛОГ (TEST)(TEST);
КОНЕЦ
ШАБЛОН Ш1;
Ф1: ВРМ,
Ф2: ЦЕЛ(1000)
КОНЕЦ
ТАБЛИЦА Т1: Ш1(10) (TEST)(TEST);
3T,100;
<>
ПОВТ 7 РАЗ
10T,55
КОНЕЦ
ШАБЛОН Ш2;
Ф1: СОБ,
Ф2: РЗР,
Ф3: БЛК,
Ф4: ЛОГ,
Ф5: ВРМ,
Ф6: ЦЕЛ(1000),
Ф7: СИГ,
Ф8: ШКЛ(100),
Ф9: ТАБ(Ш1,100),
Ф10: ИСП,
Ф11: УСТ,
Ф12: ВЫП,
Ф13: МТК,
Ф14: ПРЗ ЛОГ,
Ф15: ПРЗ ВРМ,
Ф16: ПРЗ ЦЕЛ(100)
КОНЕЦ
ТАБЛИЦА Т2: Ш2(12) (TEST)(TEST);
Z1,Z2,Z4,1,2M,100,S1,(1,2,3,4,5,6,7,8),T1,TEST2,X1:=1,TEST2,M2,X1,X3,X2;
<>
ПОВТ 7 РАЗ
Z1,Z2,Z3,0,1Ч,200,S1,(1,2,3,4,100), T1,TEST2,X2:=10,X1,M2,X1,X3,X2;
КОНЕЦ
ПРИЗНАКИ
X7 ТАБ(Ш2,12) (TEST)(TEST);
КОНЕЦ
ИСПОЛНИТЕЛЬ TEST2;
НАЧАЛО
<> ПАУЗА 0T;
НА М;
КОНЕЦ
ИСПОЛНИТЕЛЬ TEST;
X3: ЦЕЛ (-1..10000000);
Y1: ЛОГ;Y2: ЛОГ;Y3: ЛОГ;Y4: ЛОГ;
НАЧАЛО
%--------- ПРОВЕРКА АРИФМЕТИЧЕСКИХ ОПЕРАЦИЙ — ТИП:=1;
X3:=1234;
X2:=-X3;
X2:=-X2;
X3:=X2*X2;
X2:=X3/X2;
X3:=X3 MOД X2;
X3:=X2+X2+X3;
X2:=X3-X2;
%--------- ПРОВЕРКА ОПЕРАЦИЙ СРАВНЕНИЯ — X3:=0;
ЕСЛИ X2 =1234 ТО X3:=X3+0;
ЕСЛИ X2^=1234 ТО X3:=X3+1;
ЕСЛИ X2 >1234 ТО X3:=X3+10;
ЕСЛИ X2 <1234 ТО X3:=X3+100;
ЕСЛИ НУЛЬ>1234 ТО X3:=X3+1000;
ЕСЛИ X2>=1234 ТО X3:=X3+0;
ЕСЛИ X2<=1234 ТО X3:=X3+0;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА СТАНДАРТНЫХ ФУНКЦИЙ — %--------- ПРОВЕРКА ФУНКЦИИ ПРОВБИТ — ТИП:=2;
X4:=«0001»;
X5:=«00000001»;
ЕСЛИ ПРОВБИТ(X4,0) ^=0 TO X3:=X3+1;
ЕСЛИ ПРОВБИТ(X4,15)^=1 TO X3:=X3+1;
ЕСЛИ ПРОВБИТ(X5,0) ^=0 TO X3:=X3+10;
ЕСЛИ ПРОВБИТ(X5,31)^=1 TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ УСТБИТ — ТИП:=3;
X4:=УСТБИТ(X4,10,1);
ЕСЛИ X4^=«0021» TO X3:=X3+1;
X5:=УСТБИТ(X5,11,1);
ЕСЛИ X5^=«00100001» TO X3:=X3+1;
X4:=УСТБИТ(X4,0,1);
ЕСЛИ X4^=«8021» TO X3:=X3+10;
X5:=УСТБИТ(X5,1,1);
ЕСЛИ X5^=«40100001» TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ НОМБИТ — ТИП:=4;
ЕСЛИ НОМБИТ(X4)^=0 TO X3:=X3+1;
ЕСЛИ НОМБИТ(X5)^=1 TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ПСДВИГ — ТИП:=5;
ЕСЛИ ПСДВИГ(X4,4)^=«0802» TO X3:=X3+1;
ЕСЛИ ПСДВИГ(X5,4)^=«04010000» TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ЛСДВИГ — ТИП:=6;
ЕСЛИ ЛСДВИГ(X4,2)^=«0084» TO X3:=X3+1;
ЕСЛИ ЛСДВИГ(X5,1)^=«80200002» TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ОТРИЦАНИЯ — ТИП:=7;
ЕСЛИ ^X4^=«7FDE» TO X3:=X3+1;
ЕСЛИ ^X5^=«BFEFFFFE» TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ЛОГИЧЕСКОГО УМНОЖЕНИЯ — ТИП:=8;
ЕСЛИ (X4&«8007»)^=«8001» TO X3:=X3+1;
ЕСЛИ (X5&«00000001»)^=«00000001» TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ЛОГИЧЕСКОГО СЛОЖЕНИЯ — ТИП:=9;
ЕСЛИ (X4!«8007»)^=«8027» TO X3:=X3+1;
ЕСЛИ (X5!«10000001»)^=«50100001» TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ИСКЛЮЧАЮЩЕГО ИЛИ — ТИП:=10;
ЕСЛИ (X4#«FFFF»)^=«7FDE» TO X3:=X3+1;
ЕСЛИ (X5#«FFFFFFFF»)^=«BFEFFFFE» TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ И — ТИП:=11;
Y1:4:=1;
ЕСЛИ И(Y1:4)=0 TO X3:=X3+1;
Y1:4(2):=0;
ЕСЛИ И(Y1:4(1))= 1 TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ИЛИ — ТИП:=12;
Y1:4:=0;
ЕСЛИ ИЛИ(Y1:4)=1 TO X3:=X3+1;
Y1:4(5):=1;
ЕСЛИ ИЛИ(Y1:4(1))= 0 TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ СУМ — ТИП:=13;
Y1,Y2:4(1):=0;
Y1,Y2,Y3:=1;
ЕСЛИ СУМ(Y1:4)^=3 TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ АБС — ТИП:=14;
X2:=-100;
ЕСЛИ X2=АБС(X2) TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ПУСТО — ТИП:=15;
T1$Ф1(4):=0T;
T1$Ф2(5):=0;
ЕСЛИ ^ПУСТО(T1$Ф1(4)) TO X3:=X3+1;
ЕСЛИ ^ПУСТО(T1$Ф2(5)) TO X3:=X3+10;
ЕСЛИ ПУСТО(T1$Ф2(6)) TO X3:=X3+100;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ДЛТАБ — ТИП:=16;
ЕСЛИ ДЛТАБ(T1)^=8 TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ВХОДИТ — ТИП:=17;
ЕСЛИ ^ВХОДИТ(T2$Ф8(7),100) TO X3:=X3+1;
ЕСЛИ ВХОДИТ(T2$Ф8(1), ТИП) TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ ДАЙСОБ — ТИП:=18;
Z1:3:=1;
Z4:=0;
ЕСЛИ ДАЙСОБ(T2,2,6)^=0 TO X3:=X3+1;
ЕСЛИ ДАЙСОБ(T2,1)^=1 TO X3:=X3+10;
ЕСЛИ Z2=1 TO X3:=X3+100;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ФУНКЦИИ СЛУЧАЙ — ТИП:=19;
ЕСЛИ (СЛУЧАЙ()=СЛУЧАЙ())&(СЛУЧАЙ()=СЛУЧАЙ()) TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ОПЕРАТОРА УСТАНОВКИ — ТИП:=20;
X1:=0;
X2:=0;
УСТ T2$Ф11(1);
ЕСЛИ X1^=1 TO X3:=X3+1;
УСТ T2$Ф11(2);
ЕСЛИ X2^=10 TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ОПЕРАТОРА ВЫПОЛНЕНИЯ — ТИП:=21;
X1:=0;
X7:=T2;
ВЫП T2$Ф12(1);
ЕСЛИ ^TEST2 TO X3:=X3+1; ПРЕК TEST2;
ВЫП X7$Ф12(2);
ЕСЛИ X1^=1 TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ОПЕРАТОРА ПУСК — ТИП:=22;
ПУСК T2$Ф10(1);
ЕСЛИ ^TEST2 TO X3:=X3+1; ПРЕК TEST2;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ЦИКЛА — ТИП:=23;
X6:=0T;
ДЛЯ X2 OT 10 ДО 20 ПОВТ 5 РАЗ
X6:=X6+1T;
КОНЕЦ;
ЕСЛИ X6^=5T TO X3:=X3+1;
ЕСЛИ X2^=15 TO X3:=X3+10;
X6:=0T;
ДЛЯ X2 OT 10 ДО 20 ПОВТ
X6:=X6+1T;
КОНЕЦ;
ЕСЛИ X6^=11T TO X3:=X3+100;
ЕСЛИ X2^=21 TO X3:=X3+1000;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ВЫБОРА — ТИП:=24;
X2:=200;
ВЫБОР
КОГДА X2=1 TO X3:=X3+1;
КОГДА X2=2 TO X3:=X3+1;
ЛИБО X2:=100;
КОНЕЦ;
ЕСЛИ X2^=100 TO X3:=X3+10;
X2:=2;
ВЫБОР
КОГДА X2=1 TO X3:=X3+100;
КОГДА X2=2 TO X2:=300;
ЛИБО X3:=1000;
КОНЕЦ;
ЕСЛИ X2^=300 TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ПЕРЕКЛЮЧАТЕЛЯ — ТИП:=25;
X2:=200;
ПЕРЕКЛ X2
КОГДА 1 TO X3:=X3+1;
КОГДА 2 TO X3:=X3+1;
ЛИБО X2:=100;
КОНЕЦ;
ЕСЛИ X2^=100 TO X3:=X3+10;
X2:=2;
ПЕРЕКЛ X2
КОГДА 1 TO X3:=X3+100;
КОГДА 2 TO X2:=300;
ЛИБО X3:=1000;
КОНЕЦ;
ЕСЛИ X2^=300 TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ОЖИДАНИЯ — ТИП:=26;
X2:=200;
ЖДАТЬ
КОГДА X2=1 TO X2:=300;
КОНЕЦ;
ЕСЛИ X2^=300 TO X3:=X3+10;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ОЖИДАНИЯ СОБЫТИЯ — ТИП:=27;
X2:=0;
ЖДАТЬ СОБЫТИЯ 10T
КОГДА C1 TO X2:=300;
КОНЕЦ;
X2:=X2+1;
ЕСЛИ X2^=301 TO X3:=X3+1;
ТИП:=28;
ПАУЗА 0T;
X2:=0;
ЖДАТЬ СОБЫТИЯ 10T
КОГДА C1 TO X2:=300;
КОНЕЦ;
X2:=X2+1;
ЕСЛИ X2^=1 TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ОЖИДАНИЯ КОМАНДЫ — ТИП:=29;
X2:=0;
ЖДАТЬ КОМАНДЫ 10T
КОГДА K2H.КОЛЬЦВТЯН TO X2:=300;
КОНЕЦ;
X2:=X2+1;
ЕСЛИ X2^=301 TO X3:=X3+1;
ТИП:=30;
ПАУЗА 0T;
X2:=0;
ЖДАТЬ КОМАНДЫ 10T
КОГДА K2H.КОЛЬЦВТЯН TO X2:=300;
КОНЕЦ;
X2:=X2+1;
ЕСЛИ X2^=1 TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
%--------- ПРОВЕРКА ПРЕРЫВАНИЙ — ТИП:=31;
X2:=0;
БЛОК
ЖДАТЬ
КОГДА X2=400 TO X2:=300; КОНЕЦ;
X2:=500;
ПРЕРЫВАНИЯ
КОГДА S1 ПРОДОЛЖИТЬ X2:=100;Y2:=0;
КОГДА K2H.КОЛЬЦВТЯН ЗАВЕРШИТЬ ЕСЛИ X2=100 TO X2:=400;Y2:=1;
КОНЕЦ;
ЕСЛИ X2^=400 TO X3:=X3+1;
ОШИБКА:=X3; ПАУЗА 0T;
КОНЕЦ
%*****************************************************************
МОДУЛЬ TST0 TECT;
ПРОЦЕСС TST0;
A:1T;
КОНЕЦ
ИСПОЛНИТЕЛЬ A;
НАЧАЛО
ОШИБКА:=0;
ПУСК TEST;
<>
ЕСЛИ ^TEST TO
НАЧАЛО ПЕЧАТЬ(/,'ТЕСТ ОКОНЧЕН',/); ВЫЙТИ A; КОНЕЦ;
ЕСЛИ ТИП=26 TO X2:=1;
ЕСЛИ ТИП=27 TO C1:=1;
ЕСЛИ ТИП=28 TO C1:=0;
ЕСЛИ ТИП=29 TO ВЫДАТЬ(32T) KK1; %K2H.КОЛЬЦВТЯН;
ЕСЛИ ТИП=30 TO K2H.КОЛЬЦВТЯН:=0;
ЕСЛИ ВРЕМЯ> 90T TO S1:=1;
ЕСЛИ ВРЕМЯ>100T TO ВЫДАТЬ(32T) K2H.КОЛЬЦВТЯН;
ЕСЛИ ОШИБКА^=0 TO
НАЧАЛО ПЕЧАТЬ(/,'ОШИБКА ', ТИП,' ', ОШИБКА,/);
ПРЕК TEST;
ВЫЙТИ А; КОНЕЦ;
ПАУЗА 0T; НА М;
КОНЕЦ
размыты и магичны
дра-КОН(м)ичны :-)
Хочется не слов, не примеров, а математики, грубой и однозначной.Поясню аксиоматический метод ДРАКОНа за 2 шага.
Шаг 1. Теоретическое введение из книги Ершова и Палютина.
Ершов Ю.Л., Палютин Е.А. Математическая логика. —
М.: Наука, 1079. — 320 с. — С.12, 13.
Основным итогом деятельности в области оснований математики можно считать становление математической логики как самостоятельной математической дисциплины, а принципиальным достижением математической логики — разработку современного аксиоматического метода, который может быть охарактеризован следующими тремя чертами:Шаг 2. Ссылка на мою книгу. См. Глава 32. ИСЧИСЛЕНИЕ ИКОН — НОВЫЙ МЕТОД ПРЕДОТВРАЩЕНИЯ ОШИБОК Стр. 303 и далее.
1. Явная формулировка исходных положений (аксиом) той или иной теории.
2. Явная формулировка логических средств (правил вывода), которые допускаются для последовательного построения (развертывания) этой теории.
3. Использование искусственно построенных формальных языков для изложения всех положений (теорем) рассматриваемой теории…
Введение и использование подходящих обозначений было на протяжении всей истории математики весьма важной и продуктвной процедурой…
Основным объектом изучения в математической логике являются различные исчисления.
В понятие исчисления входят такие основные компоненты, как:
а) язык (формальный) исчисления;
б) аксиомы исчисления;
в) правила вывода…
Еще одним замечательным достижением математической логики является нахождение математического определения понятию алгоритма…
Изучение исчислений составляет синтаксическую часть математической логики…
Наряду с синтаксическим изучением исчислений проводится также семантическое изучение формальных языков математической логики.
Основным понятием семантики является понятие истинности для выражений (формул, секвенций и т. п.) формального языка.
Вы когда-нибудь научитесь делать оглавление с номерами страниц? ГОСТы не для Вас писались?
Шаг 2. Ссылка на мою книгу. См. Глава 32. ИСЧИСЛЕНИЕ ИКОН — НОВЫЙ МЕТОД ПРЕДОТВРАЩЕНИЯ ОШИБОК Стр. 303 и далее.
Я внимательно прочитал всю 32 главу, и не нашел там ничего о корректности. Там есть определение "истинности" и "ложности" "шампур-схемы", но нет никакого сопоставления этих схем с корректностью программы.
Процитирую:
ДРАКОН-конструктор осуществляет частичное автоматическое доказательство правильности шампур-схем
Шампур-схем. Не корректности программы.
возможности ДРАКОНа размыты и магичны. Хочется не слов, не примеров, а математики, грубой и однозначной.
Я уже указал и привел ссылки на мою книгу про два важных математических раздела, которые являются теоретической основой языка ДРАКОН.
1. Глава 32. Исчисление икон — новый метод предотвращения ошибокКроме того, нужно упомянуть еще один (третий) пункт, связанный с математическим обоснованием макроконструкции силуэт.
2. Часть 3. Алгоритмическая логика. Математическая логика в алгоритмах. Визуальная алгебра логики
Глава 12. Логические операции И, ИЛИ, НЕ
Глава 13. Логическая функция И
Глава 14. Логическая функция ИЛИ
Глава 15. Как удалить логические связки из логических выражений
Глава 16. Канонические логические схемы
Глава 17. Логическая функция «исключающее ИЛИ»
Глава 18. Сложные логические функции
Это модифицированный мною метод Ашкрофта-Манны, который в литературе называется по-разному.
Эдвард Йодан описывет его в разделе Метод введения переменной состояния на стр. 192 и далее (в книге Структурное проектирование и конструирование программ) и называет его методом Ашкрофта-Манны.
Ричард Лингер, Харлан Миллс и Бернард Уитт в книге Теория и практика структурного программирования описывают то же самое в разделе 4.4.4. Рекурсивные структурированные программы на стр. 129 и далее и не упоминают про метод Ашкрофта-Манны.
Это важный метод, позволяющий понять математическую предысторию макроконструкции силуэт. Я расскажу об этой математике чуть позже.
Участник Rsa97 сделал важную и полезную вещь: продемонстрировал парадоксальную дракон-схему.
Схема вызвала острую дискуссию и помогла понять некоторые особенности ДРАКОНа, которые оставались за кадром.
Был даже сделан вывод, что ДРАКОН не защищает от ошибок.
Все это очень хорошо и замечательно, и я благодарен коллеге Rsa97.
Но. Так делать в ДРАКОНе запрещено. Строго запрещено. И так никто не делает.
Подробно показано, какие в ДРАКОНе есть ГРАФИЧЕСКИЕ циклы, и как они работают. Ссылка на мою книгу все та же.
В начале книги работающее краткое содержание
Часть 2. Циклические алгоритмы
Глава 7. Простые циклические алгоритмы
Глава 8. Досрочный выход из цикла
Глава 9. Преобразование цикла со стрелкой в веточный цикл
Глава 10. Цикл со счетчиком
Глава 11. Цикл внутри другого цикла
Но. Так делать в ДРАКОНе запрещено. Строго запрещено. И так никто не делает.
Если язык нуждается во внешних по отношению к языку запретах, то говорить о безопасности языка уже бессмысленно.
Циклы — это неотъемлемая составная часть языка, его суть.
ДРАКОН — визуальный язык, и в нем строжайшим образом определены все визуальные циклы (полный набор циклов).
ДРАКОН — визуальный язык, и в нем строжайшим образом определены все визуальные циклы (полный набор циклов).
Пожалуйста, приведите формальное определение синтаксиса циклов в ДРАКОНе. Потому что, если верить вашей "части 2", то, что вы назваете "веточным циклом" — это набор нескольких условных и безусловных переходов, никакого синтаксического элемента для этого нет.
На всякий случай, покажу разницу в пседокоде. Вот синтаксический цикл:
until exit-condition:
workА вот код, который делает тот же самое, но на синтаксисе с условными и безусловными переходами:
start:
if exit-condition:
goto end
work
goto start
end:Вторая конструкция полностью идентична по синтаксическим элементам вашим примерам в "главе 2" (напомню, что ваше ветвление — это if, а ваш адрес — это goto).
поэтому «безопасность» ДУРАКОНа ничуть не лучше других языков.
Но. Так делать в ДРАКОНе запрещено. Строго запрещено. И так никто не делает.
В языках X, Y и Z cтрого запрещено неправильно использовать goto, поэтому они полностью лишены ошибок, связанных с goto.
В начале книги работающее краткое содержание [..] Часть 2. Циклические алгоритмы
Пожалуйста, приведите конкретную цитату из этой части, которая бы показала, что запрещено и при каких условиях.
Часть 2. Циклические алгоритмы
О да. Вот пример оттуда, из которого прекрасно видно, что "адрес" — это обычное goto, которое кидает в произвольным образом отделенный кусок кода:
"Доставка краски" кидает нас "вперед", а потом "Покраска" — обратно назад.
Вот пример оттуда, из которого прекрасно видно, что «адрес» — это обычное goto, которое кидает в произвольным образом отделенный кусок кодаЭто не так. Между оператором Адрес и goto есть принципиальное отличие.
goto — опасный оператор, а Адрес — безопасный.
Поясню.
1. goto позволяет перейти в любую точку, а Адрес не позволяет.
2. Адрес позволяет перейти только и исключительно в одну из икон «Имя ветки» и больше никуда. В примере «Покраска забора — это всего 4 точки (четыре иконы „Имя ветки“).
3. Макроконструкция Ветка вовсе не является произвольным образом отделенным куском кода. Ветка подчиняется строго определенным синтасическим правилам ДРАКОНа.
4. Ветки можно делить на части и объединять согласно синтаксическим правилам, которые строго описаны.
5. Во избежание ошибок надпись в иконе Адрес запрещено писать руками. Алгоритм такой. Надо щелкнуть по выбранной иконе „Имя ветки“, а затем по выбранной пустой иконе Адрес. Имя ветки будет скопировано в икону Адрес.
6. Если икона Адрес содержит адрес своей или более левой ветки, образуется веточный цикл. Именно цикл, а не ветвление. Ветвление всегда идет только вправо (и никогда влево).
7. Согласно картографическому принципу силуэта пространственное расположение веток по горизонтали следующее: ветки распоагаются в том порядке, в каком они включаются в работу по правилу чем правее, тем позже (за исключением веточного цикла).
goto — опасный оператор, а Адрес — безопасный.
Согласно вашему определению выше, Адрес не является безопасным оператором.
goto позволяет перейти в любую точку
Нет, не позволяет. Поэтому все ваши утверждения, что goto — опасный оператор, ошибочны.
Адрес позволяет перейти только и исключительно в одну из икон «Имя ветки» и больше никуда.
goto позволяет перейти только и исключительно в одну из определенных в коде меток, и больше никуда.
Макроконструкция Ветка вовсе не является произвольным образом отделенным куском кода. Ветка подчиняется строго определенным синтасическим правилам ДРАКОНа.
Каким конкретно? Где они описаны?
Во избежание ошибок надпись в иконе Адрес запрещено писать руками. Алгоритм такой. Надо щелкнуть по выбранной иконе „Имя ветки“, а затем по выбранной пустой иконе Адрес. Имя ветки будет скопировано в икону Адрес.
Во избежание ошибок, метку в операторе goto запрещено писать руками. Надо набрать goto, а потом выбрать в появившемся списке одну из определенных в коде меток. Название метки будет скопировано в оператор goto.
Если икона Адрес содержит адрес своей или более левой ветки, образуется веточный цикл. Именно цикл, а не ветвление.
Если оператор goto содержит метку, которая находится выше по порядку выполнения, образуется цикл.
Согласно картографическому принципу силуэта пространственное расположение веток по горизонтали следующее: ветки распоагаются в том порядке, в каком они включаются в работу по правилу чем правее, тем позже (за исключением веточного цикла).
Согласно правилам чтения текста, расположение кода по вертикали следующее: код располагается в том порядке, в котором он включается в работу (чем ниже — тем позже), за исключением циклов.
Адрес позволяет перейти только и исключительно в одну из икон «Имя ветки» и больше никуда.
Но я могу поставить икону "Имя ветки" в любом месте программы в результате нескольких простых манипуляций из пункта 4.
Во избежание ошибок надпись в иконе Адрес запрещено писать руками.
Это ни от чего не защищает. Вот ни разу за всю свою жизнь я не опечатывался в названии метки так, чтобы получилась другая корректная метка.
Для борьбы со сложностью в программировании применяют декомпозицию.
Если функция становится слишком длинной, её режут на куски и эти куски помещают в отдельные функции — подпрограммы.
При этом возникает проблема: для того, чтобы понять алгоритм, приходится переключаться между несколькими функциями.
Это сбивает внимание читателя алгоритма.
В языке ДРАКОН декомпозиция применяется точно так же, как и в текстовых языках программирования.
Большую дракон-схему превращают в несколько маленьких, доступных для восприятия.
При этом читателю тоже приходится переключаться между несколькими диаграммами, и при этом возникает та же проблема с вниманием.
Но. Чтобы уменьшить необходимость искусственного разделения алгоритмов на подпрограммы, в языке ДРАКОН имеется конструкция силуэт.
Силуэт разбивает сложный алгоритм на подпрограммы, при этом достигаются следующие преимущества:
1. Все подпрограммы присутствуют на одной визуальной сцене. Не нужно открывать другие диаграммы, чтобы понять алгоритм.
Силуэт не всегда полностью помещается на экране, но к этому и не надо стремиться. Для удобства восприятия достаточно, чтобы силуэт вмещался в экран по высоте (Правило Сергея Ефанова).
2. Отсутствуют затраты на связывание (binding). Не требуется определять аргументы подпрограмм, передавать значения в аргументы и принимать возвращаемые значения.
3. В отличие от оператора goto, переходы в силуэте упорядочены.
Во-первых, чётко оговорены места, откуда происходит переход к подпрограммам (низ диаграммы, выровненные по нижней горизонтали иконы Адрес),
Во-вторых, сами подпрограммы тоже находятся в ожидаемых местах (верх диаграммы, иконы Имя ветки).
4. Оператор goto может содержать в себе скрытые циклы. Силуэт тоже может реализовать циклы посредством перехода между ветками. Важное отличие силуэта — автоматическое выделение циклов при помощи так называемых меток цикла (темные треугольники). В отличие от скрытых циклов goto, веточные циклы в силуэте хорошо видны.
Если подпрограмма вызывается из нескольких алгоритмов, то она не может быть веткой силуэта.
В этом случае подпрограмму (функцию) помещают на отдельную диаграмму, которая вызывается с помощью иконы Вставка.
Но если подпрограмма нужна только в одном месте, есть возможность применить силуэт.
Силуэт представляет из себя удачный компромисс.
С одной стороны, силуэт разделяет большую задачу на малые части.
С другой — силуэт не заставляет читателя переключать внимание между несколькими диаграммами.
Дополнительный плюс силуэта — чёткая визуализация циклов.
Все подпрограммы присутствуют на одной визуальной сцене. Не нужно открывать другие диаграммы, чтобы понять алгоритм.
Это недостаток Дракона. В текстовых языках, знаете ли, тоже можно всё в одном файле написать — вот только так почему-то не делают, и модульность почему-то считается фичей.
Не требуется определять аргументы подпрограмм, передавать значения в аргументы и принимать возвращаемые значения.
И это тоже недостаток Дракона. Существует множество задач, в которых именно эта информация является самой важной.
В отличие от оператора goto, переходы в силуэте упорядочены.
Враньё.
И это тоже недостаток Дракона. Существует множество задач, в которых именно эта информация является самой важной.Это не так. Тут нет никакого недостатка ДРАКОНа даже близко.
именно эта информация является самой важнойВы говорите о функциях и ошибочно предполагаете, что в ДРАКОНе их нет.
Но они есть и реализуются иконой Вставка (прямоугольник с двойной линией по бокам).
Функции (Вставки) используются как элемент декомпозиции в обеих макроконструкциях (и в силуэте, и в примитиве).
Все подпрограммы присутствуют на одной визуальной сцене.
В силуэте отсутствуют подпрограммы.
Если в данном случае вам не нравится слово подпрограмма, его можно заменить на другое слово.
Какое другое слово вам больше нравится?
Вы не понимаете, что такое "подпрограмма" в терминах структурированного программирования. Пожалуйста, продолжайте использовать понятийный аппарат ДРАКОНа.
Не можете — не соглашайтесь, дело ваше. Но вам больше одного оппонента указало, что ваше употребление термина "подпрограмма" некорректно.
вам больше одного оппонента указало, что ваше употребление термина «подпрограмма» некорректно.
Ой, Боже мой! Опять за рыбу деньги. Да это же явное недоразумение. Я уже давно согласился и два раза написал об этом.
Чтобы полностью снять вопрос, пишу в третий раз: я согласен, что термин подпрограмма не следует употреблять по отношению к ветке. И благодарю уважаемых коллег, которые указали на это.
Забавно, конечно.
— Вы не понимаете, что такое "подпрограмма" в терминах структурированного программирования. Пожалуйста, продолжайте использовать понятийный аппарат ДРАКОНа.
— Не могу согласиться с этим замечанием
— Вам больше одного оппонента указало, что ваше употребление термина "подпрограмма" некорректно.
— Я уже давно согласился и два раза написал об этом.
При этом возникает проблема: для того, чтобы понять алгоритм, приходится переключаться между несколькими функциями.
Ошибка. Чтобы понять алгоритм в конкретной функции, не надо переключаться между несколькими функциями. Название (и тип) функции обычно достаточны для того, чтобы понимать ее использование и работу.
Силуэт разбивает сложный алгоритм на подпрограммы, при этом достигаются следующие преимущества:
- Все подпрограммы присутствуют на одной визуальной сцене. Не нужно открывать другие диаграммы, чтобы понять алгоритм.
Силуэт не всегда полностью помещается на экране, но к этому и не надо стремиться. Для удобства восприятия достаточно, чтобы силуэт вмещался в экран по высоте (Правило Сергея Ефанова).
Структурированное программирование разбивает сложный алгоритм на подпрограммы, при этом достигаются следующие преимущества:
- Все подпрограммы присутствуют на одной визуальной сцене. Не нужно открывать другие программы, чтобы понять алгоритм.
- Программа не всегда помещается на одном экране, но к этому и не надо стремиться. Для удобства восприятия достаточно, чтобы программа вмещалась в экран по ширине (правило Сергея Роговцева).
Отсутствуют затраты на связывание (binding). Не требуется определять аргументы подпрограмм, передавать значения в аргументы и принимать возвращаемые значения.
Это достоинство не "силуэта", а глобального разделенного состояния. Которое, если я не ошибаюсь, принято считать антипаттерном в современном программировании. Надо объяснять, почему?
В отличие от оператора goto, переходы в силуэте упорядочены.
Во-первых, чётко оговорены места, откуда происходит переход к подпрограммам (низ диаграммы, выровненные по нижней горизонтали иконы Адрес),
Во-вторых, сами подпрограммы тоже находятся в ожидаемых местах (верх диаграммы, иконы Имя ветки).
В структурированном программировании, в отличие от оператора goto, нет различия между оператором и вызовом подпрограммы, поэтому нет необходимости в упорядочивании "переходов".
Оператор goto может содержать в себе скрытые циклы. Силуэт тоже может реализовать циклы посредством перехода между ветками. Важное отличие силуэта — автоматическое выделение циклов при помощи так называемых меток цикла (темные треугольники). В отличие от скрытых циклов goto, веточные циклы в силуэте хорошо видны.
Важное отличие языка программирования, содержащего явную поддержку циклов — автоматическое выделение циклов при помоще ключевых слов цикла (ключевые слова for, foreach, while, until и им подобные). В отличие от скрытых циклов goto, явные циклы хорошо видны.
Силуэт представляет из себя удачный компромисс.
С одной стороны, силуэт разделяет большую задачу на малые части.
С другой — силуэт не заставляет читателя переключать внимание между несколькими диаграммами.
Дополнительный плюс силуэта — чёткая визуализация циклов.
Как показано выше, ни одно из описанных преимуществ не является уникальным для "силуэта".
Ну и, опять же, продемонстрирую. Сравните текстовый вариант записи и схему на драконе:
v = 5;
q = -10;
z = 15;
x = РешениеКвадратногоУравнения(z, v, q);
вывод x;
Теперь скажите, сможете ли вы, не изучая на схеме ветку «Решение квадратного уравнения» сказать, какие именно параметры использует эта «якобы подпрограмма», как она возвращает результат и куда будет передано управление после её завершения?
А в текстовом варианте это видно сразу. Вдобавок, в любом современном IDE при наведении на название подпрограммы будут показаны тип и название параметров, тип возвращаемого результата, а, при наличии, ещё и текстовое описание выполняемых действий.
Вдобавок, в любом современном IDE при наведении на название подпрограммы будут показаны тип и название параметров, тип возвращаемого результата, а, при наличии, ещё и текстовое описание выполняемых действий.
В некоторых современных IDE часть этой информации (в частности, названия параметров и, возможно, тип возвращаемого значения) будут показаны прямо на экране без дополнительных действий со стороны пользователя.
https://blog.jetbrains.com/dotnet/2018/11/27/inline-parameter-name-hints-c-vb-net-resharper-rider/
А в текстовом варианте это видно сразу. Вдобавок, в любом современном IDE при наведении на название подпрограммы будут показаны тип и название параметров, тип возвращаемого результата, а, при наличии, ещё и текстовое описание выполняемых действий
В ДРАКОН-конструкторе для иконы Вставка все это со временем появится.
Здесь нет разницы между текстовым и визуальным программированием.
В ДРАКОН-конструкторе для иконы Вставка все это со временем появится.
Чтобы оно появилось, нужна концепция типов данных (и, как следствие, типов/сигнатур подпрограмм). У вас (я специально поискал в вашей книге) такой концепции нет, а все объяснение входных данных алгоритма сводится к "Икона Пояснение играет роль правого комментария. Она присоединяется справа от иконы, которая нуждается в дополнительной информации или примечании. Если же ее прицепить к иконе Заголовок, она называется «Формальные параметры», как это принято в программировании."
Проще говоря, ваш язык вообще не оперирует данными как отдельной сущностью, в нем нет таких символов, поэтому для языка в его текущем состоянии это невозможно.
ваш язык вообще не оперирует данными как отдельной сущностью
Спасибо. Вы подняли очень интересный и очень важный вопрос.
Язык используется на рынке, в очень небольших (микроскопических) масштабах, но используется. Значит, проблема с данными каким-то образом решается.
Каким же образом?
1. За счет концепции гибридного языка: ДРАКОН работает не один, а в паре с существующим текстовым (целевым) языком. Данные описываются средствами целевого языка.
2. В моих книгах про данные почти ничего не говорится. Есть элементарные примеры в задаче про крольчатник, где показано, как описать массив, где для данных используется икона Полка.
3. В этих условиях разработчики ДРАКОН-конструктора по своей инициативе предлагают какие-то средства для описания данных.
4. Возникают новые идеи. Предприниматель Алексей Муравицкий выдвинул ортгтнальную идею и показал, как можно использовать конструкцию силуэт для описания данных. Сегодня это уже не идея, а реальное промышленное использование.
5. Интересное решение найдено в Роскосмосе. Данные удалены из ДРАКОН-алгоритма (из дракон-схемы), ибо их очень много и они в блок-схеме не помещаются, и хранятся в базе данных ФЛОКС.
На этапе компиляции данные извлекаются из базы данных, соединяются с дракон-алгоритмами и попадают в испоняемый код (я описал это в открытой статье (мой доклад в Минобороны), которая доступна в сети). Но в существующих ДРАКОН-конструкторах этого нет.
Язык используется на рынке, в очень небольших (микроскопических) масштабах, но используется. Значит, проблема с данными каким-то образом решается.
Каким же образом?
Очень простым: игнорированием. Вы делаете вид, что данные, и особенно их типы, для алгоритма не имеют принципиального значения.
За счет концепции гибридного языка: ДРАКОН работает не один, а в паре с существующим текстовым (целевым) языком. Данные описываются средствами целевого языка.
Это значит, что в ДРАКОНе их нет, и он не может их верифицировать. А поскольку данные представляют большое значение для корректности программы, из этого вытекает, что ДРАКОН не может верифицировать и саму программу.
Более того, усложняется и верификация данных средствами целевого языка, потому что на этапе работы с диаграммой этот язык не обладает информацией о взаимосвязях между данными в разных фрагментах.
В моих книгах про данные почти ничего не говорится.
Что подтверждает мой тезис о том, что у вас нет такой концепции, вы просто игнорируете данные, а язык ДРАКОН не предназначен и не имеет инструментов для их формального описания.
Что делает его, лично для меня, полностью непригодным для полномасштабного прикладного программирования.
ваш язык вообще не оперирует данными как отдельной сущностью
Спасибо. Вы подняли очень интересный и очень важный вопрос.
Этот вопрос поднимали в 2014 году на изиэлектроникс. и задолго до этого на oberon.su. Т.е. вопросу явно больше 10 лет. Десяти!!!
Интересное решение найдено в Роскосмосе.
Знаете, вчера некий Илон Маск запускал свой прототип, эпично взорвавшийся при попытке посадки… так вот, потом сотоялся некий диалог:
Elon Musk:
— В следующий раз мы попробуем тянуть «вверх»
¦
MadOverlord:
— Вопрос: Почему на посадку зажигают только 2 двигателя? Любой отказ двигателя означает потерю транспортного средства, поэтому у вас есть две отдельные точки отказа. Почему бы не зажечь все три, сделать переворот, затем выбрать два лучших и выключить другой?
¦
Elon Musk:
— Мы были слишком тупыми.
Т.е. он оперативно понял, что сделал ошибку, признал ее (несколько экспрессивно), и уже принял решение о том, как будет исправлять. А роскосмос все еще занимается некрофилией с вашим ДУРАКОНом.
Паронджанов, это не живая англичанка, это мертвая француженка! Пора уже закопать стюардессу!
Ветки — это никоим образом не подпрограммы, хотя бы потому, что их невозможно вызвать из середины другой ветки.
Во-первых, спасибо за картинку.
Во-вторых, здесь явное недоразумение. Я с вами вовсе не спорю. Я согласен с вами.
Вам не понравилось, что я назвал ветку подпрограммой.
Я тут же соглашаюсь и готов использовать для ветки любое другое слово, которое вы предложите.
Ветка результат декомпозиции программы силуэт. Как назвать этот результат декомпозиции? Или вы считаете, что здесь нет декомпозиции?
Функции, о которых вы говорите присутствуют в силуэте (и в примитиве тоже в виде иконы Вставка (прямоугольник с двойной линией по бокам.
Таrим образом, в данном случае нет никаких причин для спора. Надо лишь договориться о термине для ветки.
Ветка результат декомпозиции программы силуэт. Как назвать этот результат декомпозиции?
Веткой и назовите. Зачем вам дополнительное название?
И, опять же на мой взгляд, декомпозиции здесь немногим больше, чем при добавлении в текст программы пустой строки и комментария, описывающего назначение следующего фрагмента кода. Всё-таки при декомпозиции должны получаться независимые друг от друга модули кода, а у вас всё связано глобальным состоянием.
На мой взгляд, даже термин «ветка» здесь плохо подходит. Он подразумевает ветвление программы, а на приведённой схеме исполнение линейное. Может быть «фрагмент»?
Спасибо.
На английском языке я изменил термин и пишу не ветка, а tree (дерево).
Фрагмент — хороший термин, спасибо. Но тут возникают некоторые препятствия.
Что касается русского языка, то замена термина Ветка на «фрагмент» вряд ли возможна по чисто организационным причинам.
Судите сами, тираж печатных книг по ДРАКОНу почти 50 тысяч экземпляров, а скачиваний без счета.
В университетах студенты и другие читатели уже привыкли к термину ветка, а привычка — вторая натура; выходит учебное пособие по ДРАКОНу для вузов, а следом для техникумов и колледжей.
Люди свыклись со старой драконовской терминологией, и объяснить, почему привычная терминология устарела, будет очень трудно.
Еще раз, спасибо.
В университетах студенты
вряд ли вообще слышали про ДРАКОН. Больно уж маргинальный язык.
тираж печатных книг по ДРАКОНу почти 50 тысяч экземпляровТираж книг ДФМНПопова (80 000) или НовойХренологииАкадемикаФоменко (под миллион) еще больше. От этого напечатанный в них бред не перестал быть бредом.Как, собственно, и в ваших.
А все эти ваши «конференции» — они примерно такие: сидят в президиуме десяток восьмидесятилетних паронджановых, одиннадцатый несет бред с трибуны. потом меняются местами. а результат — нулевой. потому, что последние 30 лет занимались не реальной работой, а ерундой. Не, я понимаю, что вам обидно — 30-40 лет жизни псу под хвост. десяток, простигосподи, «монографий» по «улучшение работы ума» — а все вместе эти люди «с улучшенным умом» неспособны написать нормальный инструмент для работы в «ихнем улучшателе ума». И получается, что жизнь потрачена на непонятную и никому, кроме откровеных фриков, не нужную хрень.
Уж лучше бы книгу про историю создания софта Бурана написали (не на уровне Губанова — так хотя бы на уровне Каршенбойма) — это была бы польза. А то позорище получается — историю создания Шаттла люди в нашей стране знают лучше, чем историю создания Бурана.
Тема про логические операторы вызвала много вопросов и замечаний.
У меня предложение. Тема подробно описана в моей книге. Ссылка все та же. Посмотрите, скопируйте и выложите нужные рисунки. Тогда разговор будет наглядным и предметным. А то голыми словами очень трудно объяснять.
Часть 3. Алгоритмическая логика. Математическая логика
в алгоритмах. Визуальная алгебра логики
Глава 12. Логические операции И, ИЛИ, НЕ
Глава 13. Логическая функция И
Глава 14. Логическая функция ИЛИ
Глава 15. Как удалить логические связки из логических выражений
Глава 16. Канонические логические схемы
Глава 17. Логическая функция «исключающее ИЛИ»
Глава 18. Сложные логические функции
Кстати говоря, а почему было не применить для обозначения логических связок иконки логических элементов из схемотехники?
Это вы утверждаете, что графическая форма удобнее, чем текстовая, вам и копировать.
Попробуйте сделать то же самое со схемой дракона.
Вот я и говорю: если это так просто, у вас не должно быть проблем приводить дракон-схемы для иллюстрации своих комментариев.
Как сделать PDF-файл, из которого можно будет просто скопировать схему и вставить её в свой редактор?
Есть ли вообще единый формат хранения схем, чтобы я мог открыть одну и ту же схему в разных редакторах?
… более того, я регулярно пишу код прямо в поле ввода комментария/окне мессенджера, не открывая никакого редактора кода. Как это сделать в случае ДРАКОНа?
Я давно присматриваюсь к ДРАКОН-схемам, и есть своё видение в практическом применении их в разработке программ, в планах создать систему написания кода прямо в браузере, чтобы можно было кодить со смартфона, благодаря разделению кода на небольшие куски, вполне удобно это будет делать на небольшом экране.
Как минимум, вам нужен единый текстовый формат хранения схем, понимаемый всеми редакторами и позволяющий сохранять как полные схемы, так и отдельные фрагменты.
Как минимум, вам нужен единый текстовый формат хранения схем, понимаемый всеми редакторами и позволяющий сохранять как полные схемы, так и отдельные фрагменты.Согласен с вами. Спасибо.
А что вы думаете об этом предложении:
Я давно присматриваюсь к ДРАКОН-схемам, и есть своё видение в практическом применении их в разработке программ, в планах создать систему написания кода прямо в браузере, чтобы можно было кодить со смартфона, благодаря разделению кода на небольшие куски, вполне удобно это будет делать на небольшом экране.
Я тоже полагал, ДРАКОН не для маленьких экранов.
Это сообщение впервые появилось сегодня:
в планах создать систему написания кода прямо в браузере, чтобы можно было кодить со смартфона, благодаря разделению кода на небольшие куски, вполне удобно это будет делать на небольшом экране.Я, конечно, приветствую этот план.
Сегодня я получил на Хабре в разделе Диалоги письмо-комментарий к нашей дискуссии.
Выкладываю его. Я удалил из письма одно невежливое слово, заменив его точками по соображениям политкорректности.
Кроме того, я удалил фамилию, имя и отчество автора письма-комментария.
Здравствуйте, Владимир Даниелович!Прошу высказать ваше мнение по существу вопросов, заронутых в письме.
Поражаюсь вамему мужеству в общении с……………………… хабровчанами!
Перестал здесь публиковаться из-за токсичного сообщества, хотя мои статьи чаще всего набирали плюсы, но в других несколько человек полностью разрушают конструктруктивное общение.
Я давно присматриваюсь к ДРАКОН-схемам, и есть своё видение в практическом применении их в разработке программ, в планах создать систему написания кода прямо в браузере, чтобы можно было кодить со смартфона, благодаря разделению кода на небольшие куски, вполне удобно это будет делать на небольшом экране.
Схема будет строиться исходя их обычного исходного кода, при изменении схемы изменяется исходый код, при изменении исходного кода изменяется схема, то есть, не будет специального формата для хранения схемы, как и не будет возможности что-либо двигать на ней, отрисовка автоматически раздвигает узлы как требуется.
В данный момент разрабатываю новый язык разметки, навроде Markdown, но гораздо более мощный по возможностям, и проще в реализации, и в нём сразу заложу возможность создавать ДРАКОН-схемы в виде текстового описания. Это будет как раз стартовой площадкой для реализации редактора кода.
Благодарю Вас за ваш труд по развитию ДРАКОН-схем, это большой шаг в будущее, но большинство ещё этого не поняли, и держатся за старое привычное, так со всеми новшествами всегда было, новое пробивается в мир с трудом.
С уважением, ..................
Я что-то не вижу там вопросов, по какому поводу предлагается "высказаться"? "В планах создать систему"? "Разрабатываю новый язык разметки, навроде Х, но гораздо более мощный"? Без конкретики там нечего обсуждать.
Идея создавать алгоритм на маленьком экране мне нравиться. Только не телефон, а планшет 10" с пером. Такого добра сейчас как грязи, а достойной программы нет. WEB редактор Митькина хорош визуально, и достаточно удобен с позиции интерфейса, но не умеет генерить код. Мне например нужен такой же подход как в программе ИС ДРАКОН: в иконке пишу комментарий, а в квадратике в углу иконы спрятан код. И чтобы я мог сгенерировать код на языке Си (работаю с микроконтроллерами stm32). А идея с планшетом мне нравиться потому, что можно положить его на пузо и лежа не напрягаясь и не кому не мешая править или создавать алгоритм. Я например не могу уснуть пока в голове крутиться какая-то не решенная идея. А потом в голове срастается, но садиться за комп лень, а вот была бы на планшете программа то ту же и записал бы.
WEB редактор Митькина хорош визуально, и достаточно удобен с позиции интерфейса, но не умеет генерить код.Вы говорите про DrakonHub, он действитель не умеет создавать код.
Но ведь у Митькина есть еще два редактора, которые умеют генерировать код.
Drakon.Tech создает код на JavaScript.
DRAKON Editor генерирует код на 13 языках. Они вам не подходят?
Думаю этот редактор больше подходит для обучения. Хотя мне удалось запустить его на планшете, но там работать еще неудобнее чем на ПК.
Это ведь так просто — доказать, что мы все дураки, а дуракон — гениальная штука: надо всего лишь показать результат.
Переход на личности — это не очень хорошо.
Я могу не одобрять тон Mike_soft, но его желание увидеть реальные примеры проектов на "перспективном языке" мне вполне понятно. Особенно когда нам долго и упорно рекламируют этот язык, как превосходящий то, на чем мы сейчас пишем.
А я еще раз повторю — со времен споров на изи-электроникс, а это 2014-2015 год, на ДУРАКОНе ничего стоящего (т.е. чуть более того, что вменяемый школьник может написать на любом другом языке) не написано. Попытайтесь опровергнуть фактом…
В данный момент разрабатываю новый язык разметки, навроде Markdown, но гораздо более мощный по возможностям, и проще в реализации, и в нём сразу заложу возможность создавать ДРАКОН-схемы в виде текстового описания. Это будет как раз стартовой площадкой для реализации редактора кода.
Зачем чесать левой пяткой за правым ухом? Если так нужен ДРАКОН в документах, почему было просто не написать пакет для LaTeX?
Главная моя претензия к автору: вы занимаетесь не разработкой, а рекламой.
Язык сырой и в имеющемся виде не пригоден решительно ни для чего, однако Вы смеете его рекламировать.
В Ваших аргументах — одни лозунги и ни одной формулы. Неужели Вы думаете, что кто-то может поверить такой риторике?
Всё это вместе — не соответствует нормам человеческой честности.
Мне нравятся некоторые элементы ДРАКОНа, но я не хочу к Вам присоединяться именно из-за вышеописанного Вашего поведения. С такими как Вы — каши не сваришь.
Возможно, мне будет нечем заняться, и я форкну ДРАКОН… Но это не точно.
Выкладываю его. Я удалил из письма одно невежливое слово, заменив его точками по соображениям политкорректности.
Кроме того, я удалил фамилию, имя и отчество автора письма-комментария.
Здравствуйте, Владимир Даниелович!Прошу высказать ваше мнение по существу вопросов, заронутых в письме.
Поражаюсь вамему мужеству в общении с……………………… хабровчанами!
Перестал здесь публиковаться из-за токсичного сообщества, хотя мои статьи чаще всего набирали плюсы, но в других несколько человек полностью разрушают конструктруктивное общение.
Я давно присматриваюсь к ДРАКОН-схемам, и есть своё видение в практическом применении их в разработке программ, в планах создать систему написания кода прямо в браузере, чтобы можно было кодить со смартфона, благодаря разделению кода на небольшие куски, вполне удобно это будет делать на небольшом экране.
Схема будет строиться исходя их обычного исходного кода, при изменении схемы изменяется исходый код, при изменении исходного кода изменяется схема, то есть, не будет специального формата для хранения схемы, как и не будет возможности что-либо двигать на ней, отрисовка автоматически раздвигает узлы как требуется.
В данный момент разрабатываю новый язык разметки, навроде Markdown, но гораздо более мощный по возможностям, и проще в реализации, и в нём сразу заложу возможность создавать ДРАКОН-схемы в виде текстового описания. Это будет как раз стартовой площадкой для реализации редактора кода.
Благодарю Вас за ваш труд по развитию ДРАКОН-схем, это большой шаг в будущее, но большинство ещё этого не поняли, и держатся за старое привычное, так со всеми новшествами всегда было, новое пробивается в мир с трудом.
С уважением,…
Автор этого письма — фрик, изобретающий велосипед.
С таким как он — тоже каши не сваришь.
Я давно присматриваюсь к ДРАКОН-схемам, и есть своё видение в практическом применении их в разработке программ, в планах создать систему написания кода прямо в браузере, чтобы можно было кодить со смартфона, благодаря разделению кода на небольшие куски, вполне удобно это будет делать на небольшом экране.
Да, я тоже к нему присматривался в этом плане. Но в нынешнем виде ДРАКОН для этого не пригоден. И, судя по отсутствию развития за последние 20 лет, никогда не будет доработан.
получается в отличии от тех же диаграмм активности, тут появляется второе измерение (без введения «дорожек»), что большой плюс, двумерное размещение компонентов не только экономит зрительное пространство, но и позволяет более успешно отслеживать «завороты кишок» в алгоритмах (особенно если убрать из «икон» тексты), введен аналог оператора «switch» что тоже сильно упрощает и позволяет описывать и «автоматное программирование»
из доработок было бы неплохо увидеть более упрощенные-формализованные «иконы» пригодные к рисованию от руки на доске, поработать над наименованиями, так как «икона на шампуре», для русскоязычного звучит немного смешно и странно и самое главное было бы хорошо как то лучше документировать — как строить асинхронные системы и системы с временными задержками на базе ДРАКОНа и больше примеров из применения в реальных проектах
В моей статье в разделе Литература указано:
11. (2017) Митькин С.Б. Визуальное программирование на языке ДРАКОН. — Хабр, 2017 ( rykkinn )
Степан Митькин rykkinn — автор трех ДРАКОН-конструкторов (Норвегия) три с лишним года назад опубликовал на Хабре длинный пост Визуальное программирование на языке ДРАКОН, содержащий большое количество примеров на гибридном языке Дракон-JavaScript c кодами. Я исходил из того, что за прошедшие три года все желающие посмотрели статью Митькина и получили подробные ответы насчет кодов.
Если это не так, ничего страшного. Можно посмотреть статью Митькина и сейчас. Вот ссылка.
Хорошая статья. К сожалению, многие не понимают, что в областях, не имеющих непосредственного отношения к программированию, такой подход даёт очень положительные результаты. Известно же, что использование проверочных списков (checklists) радикально уменьшает ошибки у пилотов и хирургов (см например, https://www.hsph.harvard.edu/news/magazine/fall08checklist/). И это даже не алгоритмы, а линейные списки правил. Гораздо большего можно достичь, если формализовать такой подход. Развитие этого направление должно только приветствоваться.
Вот только проверочные списки-то — внезапно текстовые.
К сожалению, многие не понимают, что в областях, не имеющих непосредственного отношения к программированию
Я про области, которые к программировнаию отношения не имеют, даже и не заикался. Автор-то про программирование нынче пишет, и предлагает свой язык именно для этого:
язык ДРАКОН использует двумерное (2d) структурное программирование
На самом деле он не вполне «визуальный» (как тот же scratch или blueprints в UE). Это мост между кодом и «инфографикой». Проверка условий, циклы, блоки инструкций могут содержать довольно много кода на произвольном языке, что позволяет после определенных «танцев с бубном» генерировать рабочий код из читаемой неспециалистом блок-схемы. Т.е. уровень абстракции может быть весьма высок (именно это, как я понимаю, автор имеет ввиду под декомпозицией) и достаточно сложный проект на разных уровнях может все еще выглядеть читаемо и понятно даже тем, кто не владеет кодовой базой.
Но… Блин. Эта конкретно
Подобный продукт может быть актуален там, где убеленный сединами научрук согласует аспиранту проект на очередном навороченном фреймворке, вникать в который столпу академической науки абсолютно не с руки. ;) И ошибки отлавливать так же не его задача — пускай аспирант мучается, дело молодое. НО увидеть общую конву проекта, крупно, широкими мазками — это да. Это ДРАКОН позволяет очень хорошо!
Примерно то же можно сказать о презентациях продукта руководству. Понятно, что вы не будете показывать код — кому он нужен. Можно все накидать в Visio, но… Во-первых, по многим параметрам схемы ДРАКОНа просто визуально лучше (хотя это конечно дело вкуса), но главное не это. Все-таки в ДРАКОНЕ есть прямая корреляция между схемами и кодом. Т.е. еще раз: из схемы ДРАКОН можно получить компилируемый исходник и запустить его.
В общем везде, где вам нужно презентовать работу тем, кто не в теме — ДРАКОН норм. Это упрощение, визуализация кода. Но никак не средство написания «безошибочных алгоритмов»…
Но… Блин… Безошибочность кода достигается только покрытием тестами. Визуальная проверка общей логики может выявить только совсем уж грубые нарушения СМЫСЛА ТЗ, а не сложно выявляемые баги. Ну не предназначен ДРАКОН для этого. Совсем.
ДРАКОН… это упрощение, визуализация кода. Но никак не средство написания «безошибочных алгоритмов»…
Спасибо за очень интересный, содержательный комментарий. Меня особенно заинтересовали и удивили эти две цитаты.
Пожалуйста, скажите ваше мнение, что ДРАКОН не является средством для сокращения числа ошибок на чем основано? Это чисто теоретическое умозаключение? Или вы опираетесь на реальную практику использования ДРАКОНа? Если на практику, то нельзя ли рассказать подробнее? Спасибо.
Давайте определимся с тем, что вы понимаете под «ошибкой». Ошибка в логике верхнего уровня, то что может увидеть человек, глядя на схему — эти ошибки никогда или почти никогда не бывают проблемой. Это предсказуемые ошибки, видные «невооруженным» глазом!
Основную проблему представляют два других класса ошибок: непредсказуемые и неочевидные. Первые появляются в результате стечения обстоятельств, которые разработчики не предполагали, а вторые вообще не ошибки в рамках логики системы исполняющей код.
Например, языки со слабой типизацией пропустят ошибку там, где языки с сильной выдадут ошибку типов — это обычно считается плюсом языков с сильной типизацией с точки зрения сокращения числа ошибок.
Или поддержка юнит тестирования является сильной стороной в том случае, если система разрабатывается так, что каждый элемент выполняет совершенно конкретную функцию, работоспособность которой легко проверить автоматическим тестом. Это уже относится к паттернам проектирования, позволяет обновлять очень сложные системы с массой зависимостей.
Все это — серьезные шаги вперед к написанию кода с меньшим числом ошибок. ДРАКОН в этом смысле отстал примерно лет на 30 — вы говорите о проблемах, которые были актуальны для проектов с кодовой базой в пару сотен строк!
Поймите — у вас ХОРОШИЙ продукт. Я могу себе представить Дипломный проект, научную работу, презентацию расчета показателей себестоимости на совете директоров — все те вещи, где нужно доступно показать что собственно происходит без погружения в технические дебри кодовой базы…
Но не там, где речь идет о надежности кода и тем более — безопасности людей. Там проблема уже не в читаемости. Там нужны уже совсем другие вещи.
Немножко о моей практике в ДРАКОНе… Нет, я не использовал его в реальной разработке. я пробовал с помощью него сделать работающее алгоритмы для 1С(буквально пару обработок, которые УЖЕ работали до того без ДРАКОНа), луа (применительно к роботам в майнкрафте — для детей), некоторую автоматизацию на питоне.
Получилось красиво. ;) Не очень практично, но если бы мне нужно было бы показать семилетнему сыну, как робот рубит деревья или копает железо, или пожилому отцу, далекому от программирования, как работает камера с детектором движения на RaspberryZero, или бухгалтеру, как сейчас закрывается себестоимость по счетам — это было бы неплохо. И кстати — может быть бухгалтер указал бы мне на какую-то ошибку в этом закрытии… Так что да в случае, если автоматизацией занимается кто-то, кто не очень в теме предметной области — ДРАКОН тоже может помочь в плане ошибок. Но только одного очень специфичного класса…
Все известные человечеству средства не решают проблему ошибок, которая по-прежнему приводит к переделкам, потере времени и приносит человечеству большой экономический ущерб.
ДРАКОН — новое средство для предотвращения ошибок в алгоритмах. Он сокращает число ошибок, хотя и не уничтожает их полностью.
Для этого используется сложный комплекс мер (а не визуальная проверка как вы предположили). ДРАКОН подавляет ошибки в зародыше (хотя и не все).
Вот один из примеров из статьи Сергея Ефанова, написанной 10 лет назад.
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.Сергей Ефанов описывает случай, когда ДРАКОН не позволяет совершить ошибку. Физически не позволяет. Слова Ефанова
Функция заработала сразу! Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!
В тексте на Си её было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!
С тех пор прошло чуть больше года. Я программирую только на ДРАКОНе.
алгоритм в этом месте «не вырисовывался»означают, что алгоритм с ошибкой на ДРАКОНе невозможно нарисовать (в данном конкретном случае).
Удивительно, как вы раз за разом повторяете, что ДРАКОН "не позволяет" совершить ошибку, умалчивая при этом, что:
- ДРАКОН позволяет совершать ошибки (примеры ошибок приводились неоднократно)
- Другие языки тоже не позволяют совершать некоторые классы ошибок (в том числе те, которые ДРАКОН пропускает)
Так что нет никаких формальных оснований считать, что у ДРАКОНа есть хоть какое-то преимущество.
НО увидеть общую конву проекта, крупно, широкими мазками — это да. Это ДРАКОН позволяет очень хорошо!
Общую канву алгоритма, а не проекта, к сожалению. Современные проекты далеко не тривиальны и не ограничиваются алгоритмами, тем более, простыми алгоритмами. Алгоритм с цикломатической сложностью 100 на ДРАКОНе будет не менее нечитаем, чем в виде текста. А в крупном плане он может сводиться к "Получить сообщения", "Обработать сообщения", "Повторить", "PROFIT!!". Что толку от схем, если они показывают идею только в упрощённом до предела уровне, занимая при этом кучу места?.. Блок-схемы за это критиковали ещё в 1960-х.
В общем везде, где вам нужно презентовать работу тем, кто не в теме — ДРАКОН норм. Это упрощение, визуализация кода.
Зачем вообще презентовать алгоритмы тем, кто не в теме? Это одна из внутренних деталей реализации проекта, невидимая и неинтересная пользователю. Руководству тоже больше важны финансовый результат и сроки, чем алгоритмы в программе.
Предположим, что мы разрабатываем типичный интернет-магазин. Что именно из алгоритмов проекта можно реализовать на ДРАКОНе, чтобы потом вставлять в презентации? Будут ли эти схемы передавать суть?
Теоретически автор говорил про декомпозицию. ДРАКОН не язык в строгом понимании этого слова. Проект любой сложности вы можете представить в виде функциональной схемы из крупных блоков, каждый из которых может быть так же детализирован при необходимости. Каждый блок может быть как вложенной ДРАКОН-Схемой, так и, теоретически, кодом произвольной сложности (можно его рассматривать при этом, как библиотечную функцию). Другое дело, что такой подход не слишком способствует нахождению ошибок в том смысле, как это понимают программисты: это не отладка и не дебаг.
>>> Зачем вообще презентовать алгоритмы тем, кто не в теме?
Потому, что заказчик/постановщик задач/эксперт в предметной области это не то же самое, что разработчик! Я там выше привел примеры: расчет себестоимости, закрытие бухгалтерских счетов, например. Если Бухгалтер хочет сам убедится, что у вас все правильно, для понимания диаграммы ДРАКОН, ему будет достаточно здравого смысла. При этом эта диаграмма может быть конвертирована в рабочий код. Да там, где будет написано Закрытие счета ХХ на счет YY, будет подставлен реальный код 1С и проблема его правильности остается на программисте, но бухгалтер способен проконтролировать общую логику — порядок действий, правильность условий, сами счета. Он может увидеть не только и не столько ошибку программиста, но и косяк в исходном ТЗ, который для программиста уж точно не очевиден. То же самое актуально, если программист автоматизирует секвенирование генома, расчет баллистики и прочие вещи, где нужна внешняя экспертиза…
С типичным интернет магазином — ОЧЕНЬ хороший вопрос! Конечно можно! Можно построить на ДРАКОНЕ внешнюю логику связи страниц, общую компоновку интерфейса. При необходимости (если это почему-то важно) — логику работы с базой данных и другими внешними источниками. При этом все технические детали будут внутри блоков и в общем останутся на совести разработчика. Но заказчик — может увидеть, что предложение заказать сопутствующие товары не появляется или появляется не в том момент… В общем логику ПОВЕДЕНИЯ сайта, а не низкоуровневый код.
А если сравнить с текстовым псевдокодом, точно ли ДРАКОН лучше?
Я там выше привел примеры: расчет себестоимости, закрытие бухгалтерских счетов, например. Если Бухгалтер хочет сам убедится, что у вас все правильно, для понимания диаграммы ДРАКОН, ему будет достаточно здравого смысла.
Полагаю, расчёт себестоимости можно выразить и математической формулой, а для бухгалтеров есть тот же язык 1С, который, по идее, основан на русском и должен быть понятен бухгалтеру. Нужен ли ДРАКОН?
В общем логику ПОВЕДЕНИЯ сайта, а не низкоуровневый код.
То есть в данном случае ДРАКОНом лучше моделировать логику поведения, а не алгоритмы на уровне машины. Сомневаюсь, что высокоуровневое поведение можно напрямую скомпилировать в код, т.к. низкоуровневые детали важны, какая-нибудь предварительная подготовка данных типа кэширования испортит понятность схем, а её отсутствие - испортит скорость сайта. А не проще ли будет высокоуровневое поведение описать текстом/псевдокодом?
То же самое актуально, если программист автоматизирует секвенирование генома, расчет баллистики и прочие вещи, где нужна внешняя экспертиза…
По моему опыту, экспертам лучше писать формулы, а программистам оставить написание алгоритмов. Я видел странные, некорректные и очень медленные алгоритмы, написанные людьми без специальной (алгоритмической) подготовки. Наверно, код, написанный программистом, тоже выглядит странно для эксперта, но он хотя бы работает быстро и корректно (при условии корректности формул, естественно). Лучше грамотно разделить сферы экспертизы, чем учить экспертов программировать.
Конечно блок-схема лучше псевдокода! Причем для всех. Да — для разработчика свой, и в некотором роде даже чужой код на знаком языке высокого уровня иногда предпочтительней в силу компактности, но все равно — правильная блок-схема обычно нагляднее (просто потому, что выделяются только смыслообразующие элементы, а весь технический обвес остается за кадром). А уж для непрограммиста что псевдокод, что не псевдо — одинаково нечитаем.
Собственно проверено на бухгалтерах: тот же 1с почти псевдокод, но если там что-то большее чем «хелло ворлд» — тоска и уныние. ДРАКОН однозначно проще для восприятия.
>>> Сомневаюсь, что высокоуровневое поведение можно напрямую скомпилировать в код, т.к. низкоуровневые детали важны, какая-нибудь предварительная подготовка данных типа кэширования испортит понятность схем, а её отсутствие — испортит скорость сайта.
Вы не совсем поняли: ДРАКОН в данном случае, два в одном! ) Еще раз: у вас есть визуальный элемент, а есть его содержимое, которое может быть или вложенной схемой или непосредственно кодом. И нет в общем строгих ограничений, как компоновать код в эти визуальные элементы за исключением того, что логика высокоуровневых связей будет сохранена. Т.е. в блок-схеме у вас могут быть крупные блоки действий «подготовка данных» — «формирование элементов интерфейса» — «открытие страницы», а может быть один блок «подготовка и открытие страницы», но при этом каждый блок — это много кода (либо еще вложенные блок-схемы). Т.е. ДРАКОН тут по сути — верхний уровень абстракции над языком.
А код там получается по очень простым правилам же — не бином ньютона транслировать циклы/условия/действия в единый код (этот момент следовало бы больше проработать, а то некоторые вещи я смог реализовать фактически только через аналог goto, но это частности). Т.е. вы из листа ДРАКОН получаете исполняемый код на нужном вам языке…
>>> По моему опыту, экспертам лучше писать формулы, а программистам оставить написание алгоритмов.
Ну… Мой опыт говорит несколько иное. Блок-схемы, если они не излишне перегружены вполне доступны людям без ИТ-подготовки и однозначно лучше воспринимаются, чем псевдо-код. Применяются абсолютно независимо в самых разных презентациях/диаграммах опять-таки людьми от программирования далекими. Я вполне допускаю кейс разработки, когда логику некоего процесса в ДРАКОН накидает технолог/менеджер/эксперт предметной области, а код к блокам напишет уже программист — вполне годный пайп-лайн разработки.
Сейчас такое во всю используется, например, в геймдеве: нодовые редакторы есть для шейдеров, игровой логики, анимаций и тп. Просто надо понимать: это все хорошо работает зачастую не ВМЕСТО, а ВМЕСТЕ с кодом. Повышает читаемость и наглядность высокоуровневой логики.
ДРАКОН мог бы стать действительно великолепным проектом, будь он опенсорс, на современном движке, соберись вокруг него хорошее комьюнити (ну потому, что банально многие вещи, которые в нем есть требуют серьезного развития и проработки, которую автор в одно лицо по понятным причинам не вытягивает и вытягивать не может!). В существующем виде непрактичен конечно… Но любопытен!
Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН