Проблема была с алгоритмами, которые делятся на компьютерные алгоритмы и жизнеритмы, исполняемые людьми.
Алгоритмы находятся внутри компьютеров и выполняются автоматически.
Жизнеритмы описывают поведение людей в разнообразных бизнес-процессах. Нужно иметь и то, и другое. Необходимо тщательно сопрягать алгоритмы и жизнеритмы.
При создании и эксплуатации самолета 737 МАХ понятие «жизнеритмы» охватывает следующую группу процессов:
— внутренние бизнес-процессы фирмы Боинг, описывающие взаимодействие работников различных отделов и подразделений фирмы друг с другом;
— бизнес-процессы, регламентирующие взаимодействие сотрудников фирмы Боинг и Федеральной авиационной администрации FAA;
— бизнес-процессы, описывающие взаимодействие сотрудников Боинга с авиакомпаниями и другими контрагентами;
— бизнес-процессы, регламентирующие обучение и сертификацию пилотов самолета 737 МАХ, в том числе, в критических и нештатных ситуациях полета.
Жесткое требование
Анализ алгоритмов и жизнеритмов должен показывать реальное состояние дел и демонстрировать упущения, ошибки и слабые места.
Это очень жесткое требование. Двойная авария лайнера 737 МАХ показала, что данное требование не выполняется. Алгоритмы и жизнеритмы не позволили заблаговременно выявить и устранить недостатки, допущенные при разработке и эксплуатации самолета 737 МАХ.
ДРАКОН позволяет улучшить обе составляющие: и алгоритмы, и жизнеритмы с помощью единой нотации и (почти) единой математики.
Заведена переменная A, которая только сравнивается с 3 минутами. Где она изменяется?
Есть икона (желтая трапеция с двойной линией по бокам), в которой надпись А = 0.
Это таймер (секундомер). Икона Таймер создает, обнуляет и запускает счетчик времени А, который начинает отсчет времени от 0. Когда выполнется условие А > 3мин, запускается фотонный двигатель.
И что по поводу остальных блоков типа «2м48с» — они тоже какую-то переменную меняют?
Нет, они переменную не меняют. Это икона Пауза (задержка). Она задерживает следующую команду «Снять признак Авария тарелки» на 2м48с (2 минуты 48 секунд).
Есть еще икона Синхронизатор (слева от иконы-хозяина), в которой написано В = 5мин. Она (синхронизирует) осуществляет проверку условия.
Когда счетчик В достигнет значения В = 5мин, запускается икона-хозяин (справа от Синхронизатора) — команда «Отключить гравитацию».
пожалуйста, перестаньте передергивать — это Вам очков не добавляет
Прошу прощения, но я не понял, в чем заключается передергивание.
Боинг погиб из-за ошибки в алгоритмах.
Кто в этом виноват?
Может быть, вы хотите сказать, что в этой ошибке виноват кто угодно, но только не профессиональные программисты, так как последние не ошибаются? Или у вас другая мысль?
Но это редкий случай для профессиональных программистов.
Почему же редкий? Сплошь и рядом.
Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования, погубили 346 человек.
У меня создалось впечатление, что некоторые участники дикуссии рассматривают ДРАКОН как еще один язык. Дескать, сейчас есть N языков программирования, например 9000 языков, а появился ДРАКОН, их стало на единицу больше N + 1 (9001). Это не совсем так.
ДРАКОН — это ИНОЙ способ работать с уже существующими языками программирования.
ДРАКОН работает не в одиночку, а в паре с кем-то (Мы с Тамарой ходим парой).
Что это значит?
Возьмем к примеру язык Си. Это значит, что в графических иконах ДРАКОНа вы пишете код на языке Си (без управляющих операторов, разумеется). Затем графический ДРАКОН-алгоритм (с сишным кодом) транслируется в исходный код языка Си, после чего компилируется в исполняемый код.
Это называется Гибридный язык Дракон-Си.
Вместо Си могут быть другие языки Java, JavaScript и т. д. Много вариантов.
И коли говорить о концепциях, то если уж переходить, то на концепции ФП и автоматного программирования.
Ради Бога. ДРАКОН поддерживает и ФП, и автоматное программирование.
Вот что сказано в статье (повторяю).
Автоматное программирование на языке ДРАКОН
Алгоритмическая макроконструкция силуэт представляет собой конечный автомат и способна работать в двух режимах:
— императивное программирование;
— автоматное программирование.
Дракон не выживет и по причине того, что он не умеет во чтобы то ни было, кроме императивной парадигмы. Где ООП? Где ФП?
Нет вопросов. Все учтено могучим ураганом. В статье описана концепция гибридных языков и Семейство ДРАКОН-языков.
Вот ссылка: Stepan Mitkin на конфереции Erlang User Conference в Швеции делает доклад по гибридному языку Дракон-Erlang. youtu.be/yZLedcnFA94
А при чём тут вообще Боинг? Софт на 737 Max делал ровно то, что должен был делать. Он определял, что угол атаки приближается к критическому и уводил стабилизатор на пикирование.
То, что в схему не было заложен взаимоконтроль датчиков, является проблемой не языка программирования, а архитектурного решения.
Не могу согласиться. Вы рассуждаете по принципу «моя хата с краю», а это не есть хорошо. Архитектурное решение тоже matter.
Тут дело более тонкое.
Могли ли летчики спасти и самолет, и пассажиров?
Да, безусловно могли. Алгоритм спасения существовал. для этого командиру надо было сделать обратное сальто, а затем правым пальцем левой ноги нажать нужную кнопку. И все бы остались живы-здоровы.
Но командир этого не знал. Мало кто знал. Но некоторые знали, и успешно сажали Боинг 737 МАХ.
И на вашем драконе можно нарисовать точно такую же кривую схему.
Да, собственно, ваша схема с летающей тарелкой. Пока первый двигатель в порядке второй и фотонный протестированы никогда не будут.
Вы правы, но легенда совсем не такая.
Легенда
Нас интересует: взорвется тарелка или нет. Для этого надо запустить хотя бы один из двух: либо плазменный реактор, либо фотонный двигатель, причем последний считается безотказным.
Текстовая репрезентация победила. Там где нужно — мы всегда по тексту можем сгенерировать визуализацию в виде диаграмм
Вы правы. Так все и делают.
И получают ошибки. Много ошибок.
Это увеличивает сроки тестирования и отладки. И иногда приводит к серьезным инцидентам, как с Боингом.
Такое положение является неприемлемым.
Взрослый же человек — неужели не понимаете, что это звучит как рекламный трэш?
Это цитата из статьи Сергея Ефанова "Программирование микроконтроллеров на ДРАКОНе", которая приведена в разделе литература. Там есть четыре видео, где все подробно показано с кодами.
Начиная с определенного количества блоков, которое достигается достаточно быстро, отладка в таком визуальном конструкторе превращается в адский треш.
Это не так.
1. В ДРАКОНе есть мощные средства визуальой декомпозиции.
2. Я уже писал в статье, процитирую еще раз: Индивидуальный предприниматель Сергей Ефанов:
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу!
Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!
В тексте на Си ее было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!
Но ничего не говорит о возможностях и невозможностях текстового программирования.
Не могу согласиться. Современное программирование — это текстовое программирование. Ошибки характеризуют уровень современного текстового программирования.
Нехорошо.
В рамках комментария невозможно изложить аргументацию. Если Вам интересны мои обоснования, в конце статьи перечислены мои (и не только мои) книги и статьи.
Это громкое утверждение нуждается в формализации и доказательстве. Или хотя бы, внезапно, доказательстве возможности его доказательства или опровержения.
Сергей, формально вы правы. Вопрос дискуссионный.
Но. Погибли 346 человек. Они погибли в результате ошибок разработчиков фирмы Боинг.
На Боинге работают специалисты высочайшей квалификации, которые знакомы со всеми последними достижениями в области ИТ.
Эта ошибка говорит не только о частном случае — промахе Боинга. Она говорит об общем уровне ИТ-отрасли.
Непонятен принцип «Чем правее, тем хуже». Почему в примере case ветка 1 лучше, чем ветка 2, а ветка 2 лучше, чем default?
Хаос — источник ошибок.
Во избежание ошибок, алгоритм должен быть упорядоченным
Принцип «Чем правее, тем хуже» позволяет упорядочить:
— макроконструкцию примитив;
— ветку в макроконструкции силуэт.
ЧТО ДЕЛАТЬ, ЕСЛИ ПРИНЦИП
«ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ» НЕ РАБОТАЕТ
Что ж, бывает и такое. Ничего страшного. Надо придумать какой-нибудь другой принцип, подходящий к вашей задаче. Например: чем правее, тем ниже, или, наоборот, тем выше. Идея проста. Смещение вправо от главного маршрута должно быть не произвольным и хаотичным, а продуманным и логичным.
Годятся любые правила, позволяющие сделать схему упорядоченной. Для разных задач могут понадобиться разные правила. Но у всех правил есть общая черта. В схеме должен быть не хаос, а порядок.
В статье Ефанова и в комментариях к ней можно найти ответы на некоторые (конечно, не на все, а только на некоторые) вопросы и сомнения, которые прозвучали выше.
Алгоритмы находятся внутри компьютеров и выполняются автоматически.
Жизнеритмы описывают поведение людей в разнообразных бизнес-процессах. Нужно иметь и то, и другое. Необходимо тщательно сопрягать алгоритмы и жизнеритмы.
При создании и эксплуатации самолета 737 МАХ понятие «жизнеритмы» охватывает следующую группу процессов:
— внутренние бизнес-процессы фирмы Боинг, описывающие взаимодействие работников различных отделов и подразделений фирмы друг с другом;
— бизнес-процессы, регламентирующие взаимодействие сотрудников фирмы Боинг и Федеральной авиационной администрации FAA;
— бизнес-процессы, описывающие взаимодействие сотрудников Боинга с авиакомпаниями и другими контрагентами;
— бизнес-процессы, регламентирующие обучение и сертификацию пилотов самолета 737 МАХ, в том числе, в критических и нештатных ситуациях полета.
Жесткое требование
Анализ алгоритмов и жизнеритмов должен показывать реальное состояние дел и демонстрировать упущения, ошибки и слабые места.
Это очень жесткое требование. Двойная авария лайнера 737 МАХ показала, что данное требование не выполняется. Алгоритмы и жизнеритмы не позволили заблаговременно выявить и устранить недостатки, допущенные при разработке и эксплуатации самолета 737 МАХ.
ДРАКОН позволяет улучшить обе составляющие: и алгоритмы, и жизнеритмы с помощью единой нотации и (почти) единой математики.
Это таймер (секундомер). Икона Таймер создает, обнуляет и запускает счетчик времени А, который начинает отсчет времени от 0. Когда выполнется условие А > 3мин, запускается фотонный двигатель.
Нет, они переменную не меняют. Это икона Пауза (задержка). Она задерживает следующую команду «Снять признак Авария тарелки» на 2м48с (2 минуты 48 секунд).
Есть еще икона Синхронизатор (слева от иконы-хозяина), в которой написано В = 5мин. Она (синхронизирует) осуществляет проверку условия.
Когда счетчик В достигнет значения В = 5мин, запускается икона-хозяин (справа от Синхронизатора) — команда «Отключить гравитацию».
Боинг погиб из-за ошибки в алгоритмах.
Кто в этом виноват?
Может быть, вы хотите сказать, что в этой ошибке виноват кто угодно, но только не профессиональные программисты, так как последние не ошибаются? Или у вас другая мысль?
Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования, погубили 346 человек.
ДРАКОН — это ИНОЙ способ работать с уже существующими языками программирования.
ДРАКОН работает не в одиночку, а в паре с кем-то (Мы с Тамарой ходим парой).
Что это значит?
Возьмем к примеру язык Си. Это значит, что в графических иконах ДРАКОНа вы пишете код на языке Си (без управляющих операторов, разумеется). Затем графический ДРАКОН-алгоритм (с сишным кодом) транслируется в исходный код языка Си, после чего компилируется в исполняемый код.
Это называется Гибридный язык Дракон-Си.
Вместо Си могут быть другие языки Java, JavaScript и т. д. Много вариантов.
Вот что сказано в статье (повторяю).
Нет вопросов. Все учтено могучим ураганом. В статье описана концепция гибридных языков и Семейство ДРАКОН-языков.
Вот ссылка: Stepan Mitkin на конфереции Erlang User Conference в Швеции делает доклад по гибридному языку Дракон-Erlang.
youtu.be/yZLedcnFA94
Тут дело более тонкое.
Могли ли летчики спасти и самолет, и пассажиров?
Да, безусловно могли. Алгоритм спасения существовал. для этого командиру надо было сделать обратное сальто, а затем правым пальцем левой ноги нажать нужную кнопку. И все бы остались живы-здоровы.
Но командир этого не знал. Мало кто знал. Но некоторые знали, и успешно сажали Боинг 737 МАХ.
Нельзя (кроме нескольких нелепых случайностей).
Вы правы, но легенда совсем не такая.
Легенда
Нас интересует: взорвется тарелка или нет. Для этого надо запустить хотя бы один из двух: либо плазменный реактор, либо фотонный двигатель, причем последний считается безотказным.
И получают ошибки. Много ошибок.
Это увеличивает сроки тестирования и отладки. И иногда приводит к серьезным инцидентам, как с Боингом.
Такое положение является неприемлемым.
1. В ДРАКОНе есть мощные средства визуальой декомпозиции.
2. Я уже писал в статье, процитирую еще раз:
Индивидуальный предприниматель Сергей Ефанов:
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу!
Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!
В тексте на Си ее было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!
В рамках комментария невозможно изложить аргументацию. Если Вам интересны мои обоснования, в конце статьи перечислены мои (и не только мои) книги и статьи.
Сергей, формально вы правы. Вопрос дискуссионный.
Но. Погибли 346 человек. Они погибли в результате ошибок разработчиков фирмы Боинг.
На Боинге работают специалисты высочайшей квалификации, которые знакомы со всеми последними достижениями в области ИТ.
Эта ошибка говорит не только о частном случае — промахе Боинга. Она говорит об общем уровне ИТ-отрасли.
Это не так. Они исключены в том смысле, что человек их не видит, не работает с ними и не смотрит на них. Как мы не смотрим на код после компиляции.
Хаос — источник ошибок.
Во избежание ошибок, алгоритм должен быть упорядоченным
Принцип «Чем правее, тем хуже» позволяет упорядочить:
— макроконструкцию примитив;
— ветку в макроконструкции силуэт.
ЧТО ДЕЛАТЬ, ЕСЛИ ПРИНЦИП
«ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ» НЕ РАБОТАЕТ
Что ж, бывает и такое. Ничего страшного. Надо придумать какой-нибудь другой принцип, подходящий к вашей задаче. Например: чем правее, тем ниже, или, наоборот, тем выше. Идея проста. Смещение вправо от главного маршрута должно быть не произвольным и хаотичным, а продуманным и логичным.
Годятся любые правила, позволяющие сделать схему упорядоченной. Для разных задач могут понадобиться разные правила. Но у всех правил есть общая черта. В схеме должен быть не хаос, а порядок.
Здесь действует правило хорошей хозяйки:
Ваше замечание учтено.
В книгу добавлено работающее (по закладкам) краткое содержание — см. страницы 3, 4.
drakon.su/_media/24_zhizneritm20.pdf
«Программирование микроконтроллеров на ДРАКОНе».
После статьи 4 видео и 279 комментариев.
we.easyelectronics.ru/drakon/programmirovanie-mikrokontrollerov-na-drakone.html
В статье Ефанова и в комментариях к ней можно найти ответы на некоторые (конечно, не на все, а только на некоторые) вопросы и сомнения, которые прозвучали выше.
С уважением В. Паронджанов
Не обязательно.
Это вопрос уже не к языку, а к компилятору.
Вы можете сами ответить, если посмотрите стр. 178 рис. 108 в книге drakon.su/_media/24_zhizneritm20.pdf