Комментарии 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, если бы он возвращал управление в точку вызова.
Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН