Comments 130
Одни бегают туда-сюда через верхний Ларс в Грузию и обратно, вторые сейчас в мексиканском заливе на АПЛ Казань (июнь 2024), показывают «кузькину мать» супостату.
Приплёт не засчитан - Верхний Ларс брали в 2022-м, обновите методичку.
справа входы, слева выходы,
А не наоборот? (Рисунок 4)
Обратимся к МЭК 61131-3. Там описано два чисто графических языка программирования:
Там описано четыре языка, лишь два из которых графические.
ну дав то графических описано? Половина получается, сейчас поправлю
Уважаемые, в МЭК 61131-3 пять языков, три графических, один Паскале-подобный, и один однорегистровый псевдоассемблер. Среди графических: 1. LD -- это метафоризация релейных шкафов (а ля 60-е годы), язык релейно-контактных схем, 2. SFC -- это сети Петри, язык, придуманный Карлом Петри в 14-ти летнем возрасте для описания химических реакций, 1939 год (ходят слухи, он в это время в гитлер-югенде состоял и препаратами увлекался), и 3. расхваливаемый вами FBD -- это язык потоков данных, построенный на метафоре электрических схем. Языки понятно, устаревшие, и на смену им уже выпущена заплатка-надстройка МЭК 61499, проблем не решившая, и промышленностью игнорируемая. Разбор темы этих языков можно найти у Трамбулидиса, Кена Кратера и др.
Проблемы промышленность решает просто. Каждый производитель контроллеров делает свою рисовалку алгоритмов, либо берут CoDeSys и рисуют алгоритмы.
Для систем повышенной опасности есть ANSYS Esterel и SimInTech из SimInTech сразу генерируют код для управления АЭС.
Я бы FBD на с электрической схемой сравнивал, а с кибернетикой. Электрика это все таки единопобразный поток. Электроток в объект входит и электроток выходит. А в кибернетеке, есть любой вход в объект и любой выход из объекта, а внутри что то происходит. Например подается электро-ток, а на входе получаем алюмний. Так легче FBD воспринимать.
Зачем вы CODESYS поминаете? Нет CODESYS для нас. А сравнивать можно с чем угодно, хоть с "кибернетекой", но с научной точки зрения FBD это data flow язык. Я бы и SimInTech сравнил с Колотыркиным, очень сильная ассоциация с этим хорошим человеком, дай Бог ему здоровья... И декларировать можно многое, в частности, про повышенную опасность, но как это с реальностью согласуется вопрос открытый. Вы, РД NEREG листали? Что-то не обнаруживается там там ничего, ни про Estrel, ни по SimInTech. А про верификацию и верифицируемость есть. А если заглянуть в ГОСТ Р МЭК 60880-2010, то обнаруживается, что блок "функциональная валидация" обведен тонкими пунктирными линиями. И согласно Примечанию это означает, что эта "деятельность в отношении системы", не освещается в настоящем стандарте.
Кстати, вы или ваши коллеги не принимали ли случайно участие в создании текста ГОСТ Р МЭК 60880-2010?
так это же прямой первод с англйского аналога или нет?
если это перевод, то перевод кривой и безграмотный, по крайней мере с точки зрения русского языка, поэтому и вопрос, не ваши ли коллеги к этому руку приложили?
У меня сейчас сложилось впечатление, что у нас стандартами занимаются, те у кого мозгово или трудолюбие не хватает на реальную работу. Инженеров грамотных реально нигде не хватает. Мы занимаемся моделированием от косома до акеанских глубин, примерно везде видим систуации, людей просто нет. Поэтому любой грамотный специалист разрывается на реальных работах. Стандартами заниматся некогда от слова совсем, поэтому на выходе шлак. А стандрат цифровых двойников? Когда в самом определении логическая нестыковка. "Цифровой двойник это математическя модель связнаная информационно с объектом, если объек есть." Понятно цифровой двойник натягивали на модели на стадии проектирования. Потому что кому то понравилось западаное "Цифровые двойники", а мозгов и знания английского не хватило понять что двойник требует первака, иначет это не двойник а просто математическая модель.
В упомянутом вами случае "цифровой двойник" натягивали на конкретный программный продукт. Стандарт, понятно, и вышел корявый. Но зато можно тыкать всем в нос и говорить о соответствии собственного продукта стандартам. Что, кстати, и вы делаете. : )
Стандарты сейчас пишут в основном для создания преференций на рынке, для конкурентной борьбы. Пишут стейкхолдеры, а должны писать специалисты. Независимые профессионалы. И вопрос этот требует очень много мозгов, гораздо больше, чем требуется для разработки SimInTech.
Про data flow конечно абсолютно верно, я только против электрической метафоры возразил.
NERG это Nuclear Energe Regulation? Тогда смело можете выкинуть это байду в помойку. Беда в том что во всем мире Атомка в загоне, и все регуляторные акты устаревшие как дерьмо динозавра. А наши разарботчик увелеченно строят блоки по всему миру и тольковых людей там не хватает, поэтому и разработкой новых стандартов практически некому. Да и стандраты от наших разрабов, в мире хрен кто будет смотреть.
К тому же у атомки свой путь, у них на стадии проектирования есть обязательная модель, и если следовать буке стандарта, то атомка единственная отрасль в мире, где без цифрового двойника (в понимании нашего стандарта без первака) нельзя выпустить проектную документацию. Проблема в том, что в атомке цифровой двойник требуемый правилами, это оценка безопасности, то есть моделируются проектные и запроектные аварии, когда все плавится взрывается и радиоктивно загрязняется. ИБРАЭ этим занимается. Это конечно хорошо, но для реальной эксплуатации уровень загрязнения при расплавлении зоны, вообще не интересен.
Поэтому моделирование на стадиях проектирования вводят по факту, не заявляя об этом нигде. Превые генерацию кода из SimInTech для систему безопасности использовали в НИКИЭТ как раз для реакторов РБМК который в чернобыле взорвался. И использовали именно потому, что страшно было руками кодировать, те кто реально для реактора чернобыльского типа систему управления писал, они ложил болт на стандарты, потому что им понятно было где безопасней. По стандрату без SimInTech с мутными требованиями про верифицируемость и валидируемость. Или из диаграммы SimInTech автоматом, где код получатеся 100%, и ссаться по ночам не надо не забыл ли где кол-во датчиков в опросе увеличить. При этом, для увеличения безопасности системы управления они свой язык изобрели (чего не зделаешь если твоя программа управляет реактором Чернобыльского типа):
Вершиной обрезания Си в моей практике был язык FIL, для систем управления реакторами РБМК. В нем функции заранее писались на Си, компилировались, а потом вызывались на основе текстового файла, где они были описаны на языке FIL. В итоге, можно было вызвать только ограниченный, но тщательно проверенный и отлаженный набор функций. И все это – во имя безопасности и надежности.
Но для создания программ на я этом языке использовали SimInTech проблемно ориентированый язык. И ложили они болт на все древник как дерьмо мамонта стадарты атомного регулирования. После Чернобыля на первом месте безопасоть на втором ипучие регламенты. Хотя тогда они официально говорили что руками писали код. И только гда через два сертифицировали генератор кода, когда генерируемый код уже двумя блоками Чернобыльского типа управлял.
Жизнь идет всегда впереди стандартов.
Да и стандраты от наших разрабов, в мире хрен кто будет смотреть.
Будет, будет. Никуда не денется. Кого технология - того и стандарты. Иначе это просто не работает.
После Чернобыля на первом месте безопасоть на втором ипучие регламенты.
Т.е. безопасность достигается забиванием на регламенты, а не их заменой? Вы правда в атомке работаете?
Т.е. безопасность достигается забиванием на регламенты, а не их заменой? Вы правда в атомке работаете?
Дак любой регламент, это посмертный документ который от жизни отсал в момент написания. И те кто реально пишут программы для АЭС, они давно по технологиями обогнали регламенты. Например язык FIL который для РБМК изобрели в НИКИЭТ, более безопасный, но он не регламентами, не стандартами не предусмотрен. Я не заню официально но воообще зарегестировани? Но система безопасности РБМК не нем работает, нарушили регламент. Для того что бы регламент изменить надо лет 5.
Я не в атомке, поэтому могу говорить, правду. Я рядом с атомкой. И могу говорить то, про что атомщики, не расскажут. Я же привел пример, когда 2 два блока уже управлялись кодом генерированным из SimInTech, а на просьбу сделать справку для военных, разрабы говорили:
- На это я пойти не могу! Нет SimInTech в регламентах, не имеем право мы его использовать, мы все руками писали если, нас спросят.
Однажды на совещения в министерсве обороны, где мы первый раз толкали SimInTech военным, атомщик встал и сказал про меня буквально следующее:
Мы конечно для АПЛ SimInTech внедрили, но опять не через регламенты, а снизу через инженеров, которым реально нужен результат, не следование регламентам написанным в 50-го прошлого столетия.
Для того что бы регламент изменить надо лет 5.
Тогда понял, в чём дело. По-хорошему, регламенты должны писать те же самые люди, которые разрабатывают технологии и думают об их безопасности.
Именно, а грамотных людей не хватает на текущих стройках и разработках, поэтому ргеламенты и отстают. Если лет 10 - 15 темры строек сохранятся, то возможно опытные разработчики пойдут в эксперты писать регламенты. Но пока там сильный дефицит.
"Про data flow конечно абсолютно верно, я только против электрической метафоры возразил."
вы можете возражать, но в основе FBD лежит метафора электрических схем.
"NERG это Nuclear Energe Regulation? Тогда смело можете выкинуть это байду в помойку."
Вы бы лучше почитали документы. Понятно, что DSL повышают качество кода, поскольку исключают дополнительные ментальные операции, но без инженерии требований и верификации (а их у вас нет, и, судя по вашим комментариям, вы даже представления об этом не имеете) утверждения о качестве создаваемого кода, мягко говоря, дискуссионны.
И про графические языки вы зря холивар разводите. Объективно, нет у них явных преимуществ перед текстовыми. Это уже годов с 90-х прошлого века известно. Почитайте статьи по Software psychology.
Ну, вот например: Green, Thomas RG, and Marian Petre. "When visual programs are harder to read than textual programs." Human-Computer Interaction: Tasks and Organisation, Proceedings ECCE-6 (6th European Conference Cognitive Ergonomics). Vol. 57. 1992. Ссылка через гугл-сколар мигом ищется. Вот, даже нашел https://d1wqtxts1xzle7.cloudfront.net/30981063/10.1.1.57.1633-libre.pdf?1392058637=&response-content-disposition=inline%3B+filename%3DWhen_visual_programs_are_harder_to_read.pdf&Expires=1719983337&Signature=VMiHImX~rcERF4dTX1Y2Jr1ay9DXBvfAnBSGjqPtfpnAk6q8-fVGNFedlDheKOY6j1jX9wk-AgrVTJhQGPVrUizkgpC-ur6vv0B6N5v1t5ORLEGokQEHvJsBcNELXfNRJUtfl5UjGQL0bCqdl-9hEHX6anbvE6d32iNlEoHfr~Jo2irYVTwCJBi72G9X1JqoDq2J~bLuQJghQHTea4tgCI0Rbha4wmaghGMvdQWWOE6a8~Wpx2cnrnIrFpoowVXwolfGjGc4AsENBS7RwQCK2ZKQJSAfMobFXmLAld0nuZP5djSfGJOQcXE2rY0F6bMyGoCuucrK0UoejGmweF0nxA__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA
Сравнение в статье кривое, сравнивать нужно не кратинку с текстом, динамическую модель в SimInTech с текстом в дебагере. И в качестве тестового языка брали LabView в нем создается программа, которую можно записать текстом короче и понятней. Диграмму FBD собирать сложнее и дольше. Выигрыш начинается с момента отладки. Как только система становится сложной для отладки, и проверки, вот тут собака и порылась.
Вот например я уже тут это видео выкладывал, расскажите как вы это текстом изобразите?
Тут фишка не в повышении качества кода как такового. В SimInTech фишка, в том что мы верифицируем код уже с моделью объекта. Грубо говоря нас и продвинутых атомщиков код, как код вообще не интересует. Ну вот вообще. Нам наплевать на верификацию типа подали вход - проверили выход. В SimInTech мы провреяем комплекс модель + код, и смотрим на температуры, давления, обороты и наладчик на АЭС не рассматривают код, их код вообще не парит, они заливают его в стойки и подключнаю к модели и смотрят на работу в комплексе. Так же налаживают систему управлени АПЛ и ледоколов.
Не в одном стандарте до сих пор нет модели объекта при верификации кода.
Наприме те же Матлаб в своих документах пишет вектор входных воздействий (а откуда он берется, их вообще не ипет) Если говорить про АЭС где нет проблем с размером массой и электричество датчиков можно лепить миллионами и вектор входных воздействий для верификации собрать для класической процедуры верификации вообще не возможно, даже теоретически. Поэтому все с умным видом смотрят в книгу стандатов и держат фигу в кармане.
Я уже писал про это в статье Модельно-ориентированное проектирование там есть пример требований которые мы верифицируем
«При повышении давления выше предельного значения время закрытия (открытия) предохранительного клапана должно составлять не более 5 секунд.»
И как проверить это требования, если время закрытия зависти от давления в гидрсистеме, которое само является предметом регулирования системой управления?
Главное периумущестов графического языка, для сложных и критических в плане безопасности систем, в том что, им могут пользоватся технологи. А значит из цикла разработки исчезает программист, который выучил Си но ничего не понимает в технологических процессах, для которых он програмирует.
В SimInTech фишка, в том что мы верифицируем код уже с моделью объекта.
Верификация -- это формальный процесс, связанный с инженерией требований. У вас ни требований, ни верификации... Виртуальный объект управления -- это хорошо. Но не вы это придумали, и не вы единственные это используете.
мы провреяем комплекс модель + код, и смотрим на температуры, давления, обороты
ну, и смотрите, кто ж запретит... или не смотрите... :) вам-то понятно, по барабану, если в результате ошибки возникнет авария на атомной станций... у вас фига в кармане, куча людей погибнет, а в тюрьму пойдет технолог, которого "код вообще не парит". Молодцы! Хорошо устроились.
ну, и смотрите, кто ж запретит... или не смотрите... :) вам-то понятно, по барабану, если в результате ошибки возникнет авария на атомной станций... у вас фига в кармане, куча людей погибнет, а в тюрьму пойдет технолог, которого "код вообще не парит". Молодцы! Хорошо устроились.
Как раз у нас с SimInTech проверка более правильная и боле строгая, чем формальная проверка, связанная с инженерией требований. Поскольку формальные требования, всегда не полные, просто по опредлению и Чернобыль это легко доказал. Верификация описанная в стандартах, устаревших еще на стадии написания, совсем не панацея. Именно у нас технологи, которые боятся аварии и понимают куда нужно смотреть при моделирования процессов, что бы свести ее вероятность к минимум и повышают безопасность объектов за счет модели объекта SimInTech. И начали это делать когда было реально страшно менять аналоговую систему управления на цифровую на РБМК. Причем делали это как раз те кто в ликвидации участвовал аварии участвовал и косяки традиционной формальной верификации кода на себе ощущали.
И потом вот такие слайды для нас рисовали, когда модель в SimInTech совпадала с реальной АЭС.
Верификация -- это формальный процесс, связанный с инженерией требований. У вас ни требований, ни верификации... Виртуальный объект управления -- это хорошо. Но не вы это придумали, и не вы единственные это используете.
Проблема в том, что в формальном процессе нет модели объекта, просто нет. И стнадартов требований к модели тоже нет. На входе требования ТЗ (которые всегда не полные по определению). На выходе формльная проверка кода на соответствие. В итоге на объекте при пуске ставят кучу промежуточных уставок, дополнительных ограничений и отлаживают долго и мучительно, потому, что если в требованиях ошибка и давление 15 атм, не обеспечит нужную скорость срабатывания, будет больно и неприятно. Отсюда длительные пуско-наладочные работы.
В SimInTech появляется модель объекта, на которой верфицируют требования. Модель позволяет проверить требования, на их физическую выполнимость (когда 5 страница требований противоречит 105 странице, поскольку физически невозможно их реализовать) и полноту самих требований. Когда в требованиях указано время закрытия задвижки, а модель позволяет получить требуемое давления в гидросистеме. И уже эта модель используется для верификации алгоритмов управления. В итоге общее качество системы управления повышается, и технологи спит более спокойно после пуска объекта.
Но если подойти формально, мы должные еще доказать, что давление рассчитанное моделью соовтесвует заданному времени открытия, и тут мы заходим на новый цикл верификации уже математической модели. Для атестованых кодов и запроетных аварий проблема снимается атестацией кода в атоме, в паспорте пишут код, и оргнаизацию котаря это код может использовать для заданных параметров устанвоки. А у технолога работающая АЭС с реактором РБМК он атестацию не проходил, да и модель на атестацию не сдавал. И два варианта, писать по дествующим стандартам, и писаться ночью при пуске, либо взять SimInTech создать модель на ней проверить алгоримты и сгенерировать код. Ну а проверяющим можно сказать что писал руками по текстовым требованиям.
Проблема в том, что в формальном процессе нет модели объекта, просто нет.
Есть. Если вы не можете формально верифицировать свойства, так и скажите. Если не можете формально задать требования, то тоже не надо фантазировать и наводить тень на плетень.
Чернобыль если что и показал, то как раз то, что инженерам и технологам не стоит доверять.
Ну а проверяющим можно сказать что писал руками по текстовым требованиям.
Ох, как интересно вы работаете...
Ох, как интересно вы работаете...
Так не мы работае так все работают Боинг не даст соврать.
Есть. Если вы не можете формально верифицировать свойства, так и скажите. Если не можете формально задать требования, то тоже не надо фантазировать и наводить тень на плетень.
Ну и как формально верифицировать требования например такое: "Время открытия задвижки должно составлять не более 5 сек". Если само время открытия завист от давления в гидроаккомуляторе, которе так же управленияетя этим же кодом?
Требования к коду управляющих систем, для сложных технических объектов являются частью требований к процессами, и отдельно от процесса достаточно бессмысленно рассматривать, а все стандарты заточены именно на это. Есть вектор входа давайте сравним его с вектором выхода и будет нам счастье. Не будет.
Счастье возможно только с SimInTech :))))
Так не мы работае так все работают Боинг не даст соврать.
Это тот Боинг, у которого сейчас Старлайнер завис у МКС? Хорошие у вас ориентиры для подражания... :)))
Ну и как формально верифицировать требования например такое: "Время открытия задвижки должно составлять не более 5 сек"
Вот так и верифицировать. Если сможете требование формально записать. А потом преобразовать его, скажем, в верифицирующий автомат, если динамически верифицировать планируете... или в ltl, если статически верифицировать умеете.
Счастье возможно только с SimInTech :))))
:) Колотыркина цитируете... Старлайнер с орбиты снимите сначала...
Это тот Боинг, у которого сейчас Старлайнер завис у МКС? Хорошие у вас ориентиры для подражания... :)))
Боинг, это как раз ваш пример, там все просто отлично и формальной верификацией и с соблюдением стандартов, которые американцы всей авиации и навязывали. И на любой чих у Боинга, есть бумажка в строгом соотвесвии и верификацией и валиацией и прочей байдой. А все наша авиационная отрасль на эти стандарты надрачивала и нас с SimInTech посылала в Боинге внедрится сначала. Потом что Боинг на Matlab Simulink и Simieпs Amesim работает, это лучшие стандарты в мировом Авиастроении.
Если сможете требование формально записать. А потом преобразовать его, скажем, в верифицирующий автомат, если динамически верифицировать планируете... или в ltl, если статически верифицировать умеете.
В какой автомат? Время открытия зависти от давления в гидро-аккумуляторе и никак без модели процесса это требования верифицировать невозможно. Только запустив процесс в модели, можно убедится что во всех возможных режимах просадка давления в аккумуляторе обеспечивает нужный перепад давления для максимального времени открытия. И можно что угодно делать, но верифицировать это требование к алгоритмам без модели гидросистемы невозможно. Никакая темпоральная логика тут не поможет от слова совсем. Потому что алгоритмы здесь только часть гидравлической системы.
Старлайнер с орбиты снимите сначала...
В Боинге все хорошо и с формальной верификацией и автоматы верифицирующие и ltl.
Только SimInTech у них нет. Вот и сидят астронавты кукуют.
В какой автомат?
в тот самый, который SimInTech только планирует ввести в свой пакет.
В Боинге все хорошо и с формальной верификацией
Вот я и говорю, прежде, чем Боинг в пример ставить, и заниматься агрессивной рекламой своего пакета, хорошо было бы разобраться в вопросе.
Расскажите-ка лучше, как вы отказы отрабатываете со своим дата-флоу подходом.
Расскажите-ка лучше, как вы отказы отрабатываете со своим дата-флоу подходом.
Да легко, отказы это вобще часть любой модели АЭС. Мы эти занимаемся постоянно, с самого рождения лет та 30 наверное.
Во первых конечные автоматы уже давно существуют как отделная библиотека блоков. Бери пользуйся на здоровье лет 5 уже как.
Во вторых, примеры автоматов для тестов любой грамотный программист на блоках логики собирает за 3 секунды. Причем с абсолютно любой логикой. Вот кусок боевой программы тестирования из авиации, из обычных FBD блоков с помощю тригеров собирается вполне себе конечно автоматная программа, готовя к генерации в борт на Си. Из дата флов лекго и непренужденно переходим в state machin. И обратно.
Пакетная оргнаизация в модели позволяет подключить и отклюичить любую тестирующую логику и делать там вообще все что душа пожелает, не меняя общую модель системы и модель алгоритмов управления.
SimInTech есть все!
отказы это вобще часть любой модели АЭС
Ну, это понятно и ребенку. Вопрос, о стратегиях обработки отказов в дата-флоу языках Siminteck... Есть что сказать?
STATE = 3
Это вы называете автоматом?! Рассмешили. Это же самый нижайший уровень спецификации модели. Уровень реализации. Даже у Мили с Муром уровень выше.
Конечно есть и не только сказать, но и покажем, раскажем и дадим попробовать:
Пожалуйста вот вам пример стратегии обработки отказов на простой демонстрационной модели.
Покажите что нибудь подобное в автоматах миля или мура. Мне кажется, могу ошибаться. Теория конечных автоматов это интеллектуальный анонизьм не имеющий никакого практического применения. В практике используют простейшие реализации. Кде то у меня был текст от Esterl, где они объясняли, что все эти навороченые автоматы нихрена не годятся для реальных систем.
Возможно только если у Боинга, но они поэтому вернутся не могут, стратегия отработки отказов Мили с Муром как то не сработало.
А был бы у Боинга SimInTech были бы дома.
Так где обработка-то ошибок? Вы их имитируете на уровне модели. Вещь банальная. А где обработка этих отказов в управляющей программе? :) Так что, пока "интеллектуальный анонизьм" демонстрируете вы со своей агрессивной рекламой Симинтека.
То есть показать у вас нечего? Чистая теория из статей англиский ученых 50 летней давности. Ладно объясню теоретику, что ему только что показали.
Так где обработка-то ошибок? Вы их имитируете на уровне модели. Вещь банальная. А где обработка этих отказов в управляющей программе? :)
А ничего, что все что вы видете на экране это и есть программа? Может вам очки поменять? В видео демонстрация работы программы, SimInTech она называется. Вся программа созданана языком FBD и принципиальных схем, + скрипты SimInTech. Там нет ничего, кроме управляющией прогнраммы SimInTech. По вашим утвержедениям получается обработать отказы без автоматов мура милия и какого другого хера.
Я слышал про людей которые смотрят в книгу и видят фигу. Но фига в видео, это новое.
Расскажите-ка лучше, как вы отказы отрабатываете со своим дата-флоу подходом.
Я же вам именно это только что это и показал. Я на ваших глазах в программе перевел объект в состояние отказа нажатием кнопки. У меня в программе на ваших глаза изменилось состояние объекта.
1) В дилоговом окне изменилась индикация, начала моргать иконка.
2) На схеме гидравлической растет гидросопротивление, умееншается расход, расете перепад давления индикация закртытя.
3) В схеме локальной управляющией программы автоматики подключилась модель двигателя, отключились команды управления.
4) В схеме общих алгоритмов управления, включился в работу регулятор для компенсации снижения расхода.
И все это произошло на ваших глазах в управляющей программе SimInTech,
И я могу в этой модели обработать около 2000 таких отказов, только для одного типа оборудования, а там еще и насосы, клапана, датчики и у каждого до десятка вида отказов. И почему то у меня они все прекрасно обрабатываются в с нашим DataFlow подходом, без милей мулов и прочих херов. Хотя автоматы у нас тоже есть.
Ваша очередь, покажите что нибуть тольковое уже, интересно же.
Так что, пока "интеллектуальный анонизьм" демонстрируете вы со своей агрессивной рекламой Симинтека.
Просто в отличие от теориетиков у нас есть что демонстрировать - SimInTech почувствуй нашу 25 сантиметровость!
То есть показать у вас нечего?
Захочу показать, заведу отдельный пост. Тут вы вознамерились что-то продемонстрировать. И на вопрос об обработке ошибок алгоритмом управления пытаетесь показать имитацию отказов в модели объекта управления. Вы похоже, даже вопрос не понимаете. :))) "включился регулятор, у которого ничего не получится"... регулятор пыжится что-то сделать -- это глупо, у вас отказ никак не отрабатывается и система идет к краху (с мигающей лампочкой)
И да, еще в 90е годы прошлого века было экспериментально показано, что графические дата-флоу языки, типа Simintech, проигрывают по читаемости текстовым. Вы этого не знали? А кому до этого какое дело?
автоматы у нас тоже есть.
Увы, должен вас разочаровать, ваши STATE = 3, это не автоматы, а чушь собачья.
И на вопрос об обработке ошибок алгоритмом управления пытаетесь показать имитацию отказов в модели объекта управления. Вы похоже, даже вопрос не понимаете. :)))
Похоже это вы не догоняете, что модель объекта управления показаная в видео, представляет собой самый настоящий набор алгоритмов созданный в виде FBD диаграмм. Вы реальное не понимаете, что схемы это не реальный трубы, моторы, задвижки? Не догоняете? Открою вам тайну это просто алгоритмы! Еще раз крупно на видео показаны АЛГОРИТМЫ :)))))
Сложность этих алгоритмов на один или два порядка превышает сложность алгоритмов систем управления, в модели видно, что вычислительная нагрузка от модели турбины (каторая тоже просто алгоритм) в 10 раз больше чем нагрузка от алгоритмов защиты.
И то что я показал в видео, это есть комплексаня обработка отказов, в виде перключения состояний в различных частях модели.
регулятор пыжится что-то сделать -- это глупо, у вас отказ никак не отрабатывается
У вас как в голове с приченно - следсвенныем связями? Регулятор начал работу, при возникновени отказа. Это повашему "отказ никак не отрабатвается"? Вы серьезно? Или это рлоф такой, который я не догоняю? Алгоритм включился при отказе. Событие произошо! Состояние изменилось! В этом примере, регулятор это просто еще один алгоритм который обрататывает отказ, и меняет свое состояние. Это очевидная, даже ребенку демонстрация переключения состояний алгоритмов при возникновении отказа. Это наглядный пример обработки отказа, в программе написаной на языке FBD диаграмм. В дата-флоу подходе. Все как вы просили
Расскажите-ка лучше, как вы отказы отрабатываете со своим дата-флоу подходом.
Если вы хотите конккртено обсудить защиты турбины, вот вам пример алогоритма на языке DataFlow. Но смысла обсуждать его я не вижу, тут нужны турбинисты, а не как не специалисты по автоматам Мили Мала и прочих Хоров.
И да, еще в 90е годы прошлого века было экспериментально показано, что графические дата-флоу языки, типа Simintech, проигрывают по читаемости текстовым.
Если вы опять пытаетесь протолкнуть окаменело дерьм динозавров от английских ученых, так я уже прочитал статью и вижу что это просто наукообразная бессмыслица, где сранвиается текст программы с диаграммой. И показано что прочитать можно быстрее текст. Это и без английских ученых ясно. И написать программу так же быстрее чем нарисовать диаграмму. Это и без английских ученых ясно. Но это вообще мимо темы. Поскольку никто диаграмму статично никогда не смотрит. Диаграмма FBD в SimInTech это живая модель которую можно исполнять и видять процесс исполнения на схеме. И в этом случает диаграмма дает информацию которую в тексет просто нельяз прочитать, ее там нет по определению. Поэтому SimInTech рулит.
Сложность этих алгоритмов на один или два порядка превышает сложность алгоритмов систем управления,
у вас, да, ваши алгоритмы управления примитивны, зажечь лампочку и пыжится... :) и ждать команд от оператора.
Открою вам тайну это просто алгоритмы!
Убеждаюсь, что вы просто не понимаете, о чем я говорю.
Если вы хотите конккртено обсудить защиты турбины, вот вам пример алогоритма на языке DataFlow. Но смысла обсуждать его я не вижу,
И я не вижу, глупо обсуждать представленный низкоуровневый код. Посчитайте для него меру Маккейба... это же нечитаемая муть.
И показано что прочитать можно быстрее текст.
Да, сто лет назад было показано, что даже для относительно простых случаев текст и читается быстрее, и понимается быстрее. В графических языках уровень вхождения ниже за счет метафоризации. Но чуть влево-вправо начинаются метафорические артефакты. Вы бы почитали что-нибудь по теме. Графика хороша, чтобы фронтенд сделать для оператора, HMI. Тут и WYSIWYG эффективен и анимация. А насчет программирования надежных алгоритмов -- это путь в никуда.
Убеждаюсь, что вы просто не понимаете, о чем я говорю.
Согласен понять это сложно, я бы сказал даже невозможно. Когда в одном предложение, у вы говорите что алогоритм включается при отказе, (явное событие в нотации Sate Mashine) и утверждаете что отказ никак не обрабатывается. Тут проблемы с обычной логикой.
Убеждаюсь, что вы похоже вы сами не понимаете о чем говорите, просто набор букв сложенных в буквы, но смысла в них нет никакого. Вы просто не можете понятно объяснить, что вы спрашиваете. Как правило, это происходит когда человек сам толком не понимает что он срашивает и о чем говорит.
у вас, да, ваши алгоритмы управления примитивны, зажечь лампочку и пыжится... :) и ждать команд от оператора.
Примитивыны ваши представления о жизни. 3000 МВт тепловых в реакторе, с уцепной реакцией деления, с контрами охлаждения, регулирования, и управления 1000 МВТ электрических. Циркуляция первого контура что бы отвевести 3000 мегават тепловых, паргненраторы что бы тепло это тепло превартить в пар. Турбина где это тепло прверащается в обороты генератора и электросеть. И все это управляется примитивыными алгоритмами, которые зажигают лампочеку и ждук команды оператора, что бы он в ручную кажду из тысячи одновремнно работающих задвижке приведел в нужное положение.
Если для вас алгоритмы управления ядреным реактором, турбиной в составе АЭС, ядерной паротурбинной устанвокой ледокола, там где работает SimInTech примитивные, то ли бо вы занимаете космической баллистикой для расчета таректорий межзведных траекторий, либо вы просто зведун-теоретик, либо одно из двух.
В графических языках уровень вхождения ниже за счет метафоризации. Но чуть влево-вправо начинаются метафорические артефакты. Вы бы почитали что-нибудь по теме.
Я же уже почитал окаменелое говно динозавров которое вы тут вытащили. И уже объяснил почему английский ученые сравнивают жопу с пальцем. FBD диаграмма в SimInTech не является картинкой, на которую нужно тупить, как в эксперементах английский ученых из вашей статьи. FBD диаграммы в SimInTech это исполняемые модели, которые используюте при отладке комплексных моделей сложных тезнических объектов, и программы управления это только части общего объекта. И для того что бы сравнивать текст программы с FBD программы SimInTech вы сначала попробуйте в тексте описать модель с 220 объектами у которых есть по 9 состояний только отказова. Я вам это показал за 3 минуты. Вы в ответ опять что то невразмутельное мычите. И еще предлагете мне читать это дерьмо. Спасибо кушайте сами. Я вам лучше про примитивную систему управления видео покажу.
Одни читают окаменелое достижение английский ученых столетней давности, другие делают ледоклы.
SimInTech для тех кто делает!
в 90е годы прошлого века было экспериментально показано, что графические дата-флоу языки, типа Simintech, проигрывают по читаемости текстовым
Реально? Поделитесь ссылочкой, если не трудно.
Реально. Ссылку вам дал. Вы, похоже, не понимаете, что там написано.
Ладно, общаться с вами только время терять. Не хворайте.
Реально не сразу врубился о которой ссылке речь. Уже нашёл. Спасибо.
UPD:
Меня туда не пускает
<Error>
<Code>AccessDenied</Code>
<Message>Access denied</Message>
</Error>Вот эта сатья английских ученых от 92 года.
https://disk.yandex.ru/i/p1VxY1SplaCfEA
Там главный косяк в том, что они сравнивают текст и картинку и измеряют время нужно для считывания информации глазами. И решают что более понятно, схема или текст.
Но это абсолютно бессмысленное занятие! Никто сейча FBD диаграммы как картинку нигде не использует FBD диаграмма это средство для проигрывания моделей, а в процессе проигрывания FBD диаграмм уже отображает результа вычислений непосредственно на схеме, и пользователь оценивает динамический по времени процесс, чего ни текст ни картинка статическая не содержат в принципе.
90% времени пользователь FBD диаграммы в SimInTech, Simulink, Esterl смотрит на процесс моделируования в диаграмме. А не на статическую картинку, как у английских ученых эксперементе прошлого века.
Если что и доказывает это статья, так только то что уважаемый @mosk_onне разу с реально сложными системами дела не имел, чистый теоретик. И его представления о реальности это модель шарового коня в вакууме, из анекдота про теоретиков.
SimInTech это среда динамического моделирования технических систем
Т.е. на схеме показывается трассировка программы?
UPD:
В 92 году и текст был совсем не такой, как сейчас. Результаты исследований проведённых на тогдашних языках программирования вряд ли переносимы на современные языки. Или, по крайней мере, переносимость результатов нужно доказывать отдельными исследованиями.
На схеме FBD диаграммы в процессе динамичесеоо моделирование отражается текущие состояния всего процесса.
Например в гидравлической диаграмме у меня отражается моргнаинем процесс закрытия Z1 на 2.47 секунде процесса. Перейдя в алгоритм управления я вижу команду закрыть, и вижу что она возникла из-за того что давлени в узле больше уставки.
Через некоторое время давление снизистя и я увижку как команда закртить на FBD диаграмме будет 0. Можно видеть цифры, как на рисунке, можно их убрать оставть тольк цвет линии больше 0 розовый черынй меньше 0. А можно вообще построить график измения давления и графики команды задвижки, что бы убедится что закрытие и открыте соответсвует давлению определнным технологом.
Кстати, даже на это простом примере, ширина зоны нечусввительность определяется скорость движения задвижки и перепадом давления между узлами. Имеяя только алгоритмы управления верефицировать корректность задания зоны нечуствительности просто не возможно.
А уважаемый @mosk_on думает что автомат мура мула или хера ему поможет верифицировать программу управления.
Кстати, даже на это простом примере, ширина зоны нечусввительность определяется скорость движения задвижки и перепадом давления между узлами.
Это информация из предметной области, а не свойство среды разработки. Не имея этой информации, вы никак не верифицируете алгоритм управления, ни графически, ни автоматом. А при наличии такой информации - вы сможете самостоятельно разработать алгоритм верификации и описать его на любом доступном Вам языке.
Надо, как говорится, мух от котлет...
А можно вообще построить график измения давления и графики команды задвижки, что бы убедится что закрытие и открыте соответсвует давлению определнным технологом.
Это хорошая идея, если надо один раз посмотреть. А если нужно автоматически тестировать после внесённых изменений - нужно писать юнит-тест.
Это информация из предметной области, а не свойство среды разработки.
Проблема в том, что эта информации не сущестует, без диниамческого расчета, в предметной области. Поскольку процесс динамический и в системе все парвметры постоянно меняются. Например в выше приведенном примере, перепад давления может опредялятся регулятором температуры в программе управления. В этом случае мы получили обратную связь. Ширина зоны нечуствительности в программе зависит от перепада давления, а перпад давления зависит от настройки регулятора температуры в той же программе. В итоге без модели объекта верифицировать это программу невозможно. И если нет среды динамического моделирования настройку делают на живоме объекте на или на стенде.
Это хорошая идея, если надо один раз посмотреть. А если нужно автоматически тестировать после внесённых изменений - нужно писать юнит-тест.
Для тестирования то же есть инструменты и методы в SimInTech
Автоматическая проверка требований ТЗ в процессе динамического моделирования
Проблема в том, что эта информации не сущестует, без диниамческого расчета, в предметной области. Поскольку процесс динамический и в системе все парвметры постоянно меняются. Например в выше приведенном примере, перепад давления может опредялятся регулятором температуры в программе управления. В этом случае мы получили обратную связь
Это всё справедливо для живого железа. А в компьютерной модели поведение такое, какие уравнения написали разработчики. И эти уравнения поддаются анализу и без картинки.
В итоге без модели объекта верифицировать это программу невозможно.
Это правда. Но модель - это не картинка. Модель - это система уравнений.
А адекватность модели реальному железу - тоже нужно отдельно доказывать.
Это всё справедливо для живого железа. А в компьютерной модели поведение такое, какие уравнения написали разработчики. И эти уравнения поддаются анализу и без картинки.
Можно кнечно решения уравнение течения жидкости и газа на фортарне записывать, что бы отладить систему управления нагревателя. Но это не лучший и не самый быстрый вариант. Быстре использовать SimInTech, где уже в математичесок ядре зашито решение систем диференциальных уравнений.
Вот здесь мы как раз и переходим к "предметно ориентированому языку программирования" потому что на самом деле на рисунке с трубами и задвижками, не картинка на которую как бараны на ворота смотрят английские ученые из статьи 92 года, а система уравнений двухфазной сжимаемой жидкости, просто упакованная в принципиальную гидравлическую схема в среде SimInTech. Именно это я и пытался объяснить уважаемаемому @mosk_on
Например для канала решатеся система уравнений описаная в справке так Теплогидравлика/Канал
И когда пользователь SimInTech технолог отлаживает алгоритм управления например в таком виде:
Он как раз и занимается анализом системы уравнений, а не тупо смотрит на картинку. Можно конечно для каждой трубы в системе отдельно на фортране писать систему уравнений, а можно взять уже готовый среду моделирования динамических систем SimInTech и делать все то же самое в виде принципиальной гидравлической схемы. По сути SimInTech реализует трансфер системы математических уравнений описывающих физические процессы в технологические расчетные схемы, понятные технологу процесса.
А адекватность модели реальному железу - тоже нужно отдельно доказывать.
Конечно, если вы впервый раз реализуете решение системы уравнений механики жидкости газа на фортарне, а потом это подключате к программе, надо доказывать.
Но когда у вас альтернатива отлаживать систему управления на реакторе РБМК который взорвался в Чернобыле, то лучше всетакт отладить программу управления с моделью, даеж если ее впервый раз написали. Страшно, но отлаживать на реальном РБМК еще страшней.
Зато когда вы еще 20 лет назад получили совпадение процессов в модели МВТУ-4 (Дедушка SimInTech) и измерений с реальнокак на следующей картинке, то вопросы доказательства адекватности сами собой снимаются. Не каждая программа подтвержадется эксперементом на реакторе который взорвался в чернобыле.
SimInTech адеватные модели для адекватных инженеров!
На самом деле оказывается 5 языков и лишь дав из которы текстовые, прочем один из текстовых устарел и не входит в последнюю редакции:
FBD (Function Block Diagram) — графический язык программирования стандарта МЭК 61131-3. Предназначен для программирования программируемых логических контроллеров (ПЛК).
LD (Ladder diagram) — язык релейно-контактной логики.
SFC (Sequential Function Chart) - Последовательностные функциональные диаграммы.
В заголовке орфографическая ошибка
Ну тогда не "синтаксический сахар", а "графический сахар"
Хотя всплывающие по цепочке кликов окна параметров, загораживающие основную схему я бы сахаром не называл. В текстовых редакторах тоже можно накликать любую инфу, но сахаром там это не называют.
Графический сахар - это когда, например, сквозь блок немного видно что содержится внутри:
Не увидел семантического сахара. Это обычный инструментарий SCADA (в 90-х на трасе моде пилил) и Mindstorms EV3 (семикласснику помогал). Если говорить о языках программирования (коде), то можно вспомнить 90-е: код на основе UML (Rational) или EPC (колхоз на ARIS script).
Хотелось бы так: нарисовал схемку - и жмешь кнопку: "дай код js", а рядом с ней "дай код VBA". Как дальнейшее развитие BPMN, только с формированием "всего кода" из схемы.
Семантический сахар, - это когда один образ (та же схема), а на выходе - различные вариации созданной логики, т.е. разные синтаксические представления (языки программирования) одного образа из разных компонент, склеенных семантическим сахаром. Например, в части визуализации алгоритмов: разные обертки \ представления \ графические нотации Одного алгоритма, см.
Хотелось бы так: нарисовал схемку - и жмешь кнопку: "дай код js", а рядом с ней "дай код VBA". Как дальнейшее развитие BPMN, только с формированием "всего кода" из схемы.
Так оно и работает, только для кода Си. И железных платформ, выбираешь кодогенератор и говоришь дай код Си под Линукс на АРМ или кода dll под Windows 64. Или дай код для Ардуино. Там список сейчас такой: Milandr, TI, ST Schnaider Electric, Ardiunо, Gigadevice, STM32, MK17 и еще что то постоянно в доработке
Семантический сахар, - это когда один образ (та же схема), а на выходе - различные вариации созданной логики, т.е. разные синтаксические представления (языки программирования) одного образа из разных компонент, склеенных семантическим сахаром. Например, в части визуализации алгоритмов: разные обертки \ представления \ графические нотации Одного алгоритма, см.
Так пример на рисунках 12 и 16 это и есть разные графические нотации одной и той же логики ПИД регулятора. Если сгенерировать код Си там похоже разницы в коде не будет
Интуитивно, принципиальная модель, начерченная на плоскости это будто бы 2D модель. Почему 1D?
Потому что неважно где размещено, важна только очерёдность подключения, всего одна размерность получается.
Если говорить про гидравлику то в трубопроводе, расчетная сетка 1D уравнения сохраннения энергии, массы, и импульса считаются вдоль оси трубопровода. Изменения в сечении игнорируются. Уравнения 1D
В отличии от алфавитных языков улучшение графической программы требует не соблюдения от разработчика набора жестких рекомендаций и правил, а скорее наличия чувства прекрасного
Когда программу пишут сотни людей - и все разных возрастов, разных компетенций, разной культуры и уровня образования и даже разного языка - то невозможно гарантировать одинаковое чувство прекрасного у всех. Кроме того, то, что прекрасно для вас, будет уродливо и непонятно для других.
Именно для этого придумывают жёсткие правила и рекомендации. Потому что программу надо эффективно писать, а читать. Ине наслаждаться её красотой - а иметь возможность эффективно её модифицировать.
Графические схемы подходят для небольших линейных моделей, типа тех, которые вы показали. Попробуйте нарисовать на графической диаграмме, скажем, регулярное выражение. Или там - виртуальные конструкторы какие-нибудь. А после того, как нарисовали - попробуйте туда ещё правки вносить регулярно... Не уверен, что вы долго продержитесь 😁
Да, хорошие и удобно читаемые схемы нужны, это факт. Но они нужны там, где они подходят. Программисту проще прочитать страницу кода, чем карандашиком тыкать в блок-схемы. А вот директору по маркетингу, который хочет понимать логику работы CRM, вряд ли поможет её код - а вот схема всё объяснит.
Так что не красота спасет мир, а здравый смысл и использование правильных инструментов там, где они необходимы.
Графические схемы подходят для небольших линейных моделей, типа тех, которые вы показали. Попробуйте нарисовать на графической диаграмме, скажем, регулярное выражение. Или там - виртуальные конструкторы какие-нибудь. А после того, как нарисовали - попробуйте туда ещё правки вносить регулярно... Не уверен, что вы долго продержитесь 😁
Небольшие линейные модели в статье показаны, как пример модификации диаграмы для удобства читателя. Просто если взять натоящий ПИД регулятор, которые реально используется в ПО для управления АЭС, на него без подготовки, слабонервным, беременным женьщьнам и кормящим матерям лучше не смотреть. Например ПИД реальный с АЭС выглядит так:
Сравните с рисуноком 19 и почувствуйте разницу. А например регулятор на настощяий из статьи в реально проекте состит из двух листов каждый из которых содержит в себе по два типовых компонента.
Сравните с рисуноком 4 и почувствуйте разницу. И подобных листов в проекте ПО тысячи. Все это автоматической генерацией кода заливается в стойки управления АЭС и управляет ядерным реактором на Гигаваты мощности. После Чернобыля писать код руками и читать его стало как то стремена. А тут ничего работает модифицируется и поддерживается. Чернобыль вроде мы не повторяли. Вот например видео с простой модли системы управления ледоколом. Там одна система Шквал содержит 800 листов алгоритмов. И поддерживается и правки вносятся регулярно, поскольку это реально проектирующая организация и они постоянно дорабатывают проект. И ледоколы плавают.
Так что для меня вопрос како ПО более сложное, написаное на фремворках алфавитным язком СРМ или ПО для управления ядерным реактором с турбиной. Просто цена ошибки в СРМ, наверное меньше чем цена ошибки в САУ реакторного отделения. И тут графические языки выходят на первый план. Даже в стандарте МЭК 61131-3, половина языков - графическая
А как дела у графических языков с git-friendly? Есть лаконичный текстовый формат хранения схемы?
Так что для меня вопрос како ПО более сложное, написаное на фремворках алфавитным язком СРМ или ПО для управления ядерным реактором с турбиной.
Вы всё время аппелируете к абстрактным категориям, типа сложности или чувства прекрасного 😀 Но красота и сложнота - они исключительно в глазах смотрящего.
Вам вот, наверное, китайские иероглифы тоже кажутся жутко сложными - а меж тем ими прекрасно пользуются полтора миллиарда человек, которые, в основной массе, значительно моложе и глупее вас. Но для любого китайца будет пыткой попытка переложить его жуткие иероглифы на прекрасные и понятные буквы, которыми пользуется весь мир. И для всех это будет пыткой - просто потому, что китайский язык органически приспособлен к иероглифам, а не к буквами.
И потому никто до сих пор и не смог внятно записывать китайский язык латинскими буквами. Да, есть субституты, решающие узкой задачи - для облегчения быстрого взаимодействия с европейцами или компьютерами. То есть для локальной оптимизации. Но никто не пишет книги на таких субститутах. Вернее даже и пишут - но это, скорее, proof-of-concept или шедевр для тех, кто шарит - но не для всех.
Сложное - это то, чего ты не знаешь. Но для того, кто знает, оно будет простым.
Я вот не увидел ни грамма сложности в ваших схемах ПИДов. Они ОБЪЕКТИВНО НЕ СЛОЖНЫЕ - несколько однотипных блоков, простые операции да соединения. Пройтись по ним с карандашиком и прикинуть логику работы сможет и школьник. Но при этом я совершенно не могу найти в них потенциальные ошибки: например - бесконечные циклы без выхода или блоки, которые никогда не сработают. Такие вещи МНЕ ЛИЧНО гораздо быстрее и понятнее было бы искать в текстовом коде. Но вам, возможно, наоборот они виднее именно в таком виде - потому что вы привыкли читать такие диаграммы и анализировать их.
То есть каждому будет простым то, что он знает. Я на ассемблере могу читать быстрее, чем на родном языке. Но какой-нибудь там Лисп или Эрланг заставят мой глаз дергаться. Ваши картинки напугают беременную женщину или студента SkillFactory - но тот, кто хоть раз в жизни пробовал починить советский телевизор по схеме, будут надменнно над ними насмехаться.
И кстати - сложность схемы вовсе не говорит о её крутости, важности и применимости исключительно для АЭС и космических кораблей.
Наоборот - сложные схемы тяжело отлаживать и проверять на ошибки. Погуглите 10 принципов разработки mission-critical систем от NASA, которые они придумали ровно для того, чтобы строить и отлаживать максимально критичные и важные системы. Так вот эти принципы как раз про максимальное упрощение - никаких сложных потоковых конструкций, четкие границы блоков, один функциональный модуль на одну страницу и т.п.
Ровно для того, чтобы инженеры, с тонким чувством прекрасного и причастности к великому не нагромождали одним им понятную красоту, которая взорвется при первом же старте из-за того, что две стрелочки перепутались местами 😀
Я вот не увидел ни грамма сложности в ваших схемах ПИДов. Они ОБЪЕКТИВНО НЕ СЛОЖНЫЕ - несколько однотипных блоков, простые операции да соединения. Пройтись по ним с карандашиком и прикинуть логику работы сможет и школьник.
Правильно, именно для этого и создан язык FBD диаграмм, что бы даже школьник мог пройтись с карандашиком и понять логику работы. И сложное становится понятным даже школьнику. Напиши эту логку работы в коде и даже сам разработчик лет через 5 не сможет пнять, кто этот бред написал.
У меня есть личный пример из внедрения, когда в тренажере на объекте у заказчика, логика работы правится коде, поскольку там на месте не средства разработки (и происходит это в Индии). Возратившись обратно разработчик правит диаграммы из которых код генерится автоматически. Я когда увидел удивился:
- А зачем ты правишь эти диаграммы, ты же говорили, что вы уже там на месте в коде все поправили и режим уже работает?
- Да, просто через пол-года или год, опять поедем и я не вспомню что я там руками закодировал. А здесь наглядно и понятно.
Но при этом я совершенно не могу найти в них потенциальные ошибки: например - бесконечные циклы без выхода или блоки, которые никогда не сработают. Такие вещи МНЕ ЛИЧНО гораздо быстрее и понятнее было бы искать в текстовом коде.
Поскльку это FBD диаграмма, то она работает с заданным тактом постоянно по сути это изображение работы одного шага вход получили, прогнали по схеме - получили выход и так пока контроллер работает. Поэтому если на схеме замкнуть связь, то выйдет предупреждение об алгебраической петле. Блоков которые никода не сработают то же нет. Каждый блок выполняется на каждом шаге, (если это не автомат состояний но там даже нотация отличается). Возможна ситуация когда ключ всегда имеет один и тот же выход и логика обработки никогда не применится и мы будем иметь на каждом шаге одно и тоже состояние, но это не критическая ошибка, просто лишние вычисления. При этом такие ошибки логики могут обнаруживатся как канрандашом, так и путем моделирования.
Мне кажется тут проблема вот в чем, то что вам ЛИЧНО легче и быстрее найти ошибке в текстовом виде, как многим программистам (хотя я думаю, искать ошибки всем проще в диаграмме, другое дело писать в виде текста код гораздо быстрее). Для отладки сложных систем, нужен не только и не столько программист, а технолог процесса. Если у меня алгоритм управления ядреным, тепловым или химическим процессом, то абсолютно правильная без бескончных циклов, всегда работающим блоками программа, это не совсем не то что надо. В первую очередь мне надо, что бы программа поддерживала параметры рабочего процесса, и правильно реагировала на отклонения. А здесь нужны занания не кодов, циклов и регулярных выражения, а физики, химии, конструкции и процессов.
Из последнего смешного. АЭС отваливатся по аврийной защите. Гигаваты мощность, куча денег потеряно. Оказывается сработала защита по повышению температуры в подшибнике подпятника главного циркуляционного насоса. Программа сработала иделаьно из без ошибок. Если температура превышена занчит проблемы с подшипником, нужно его выключать. В тексте все правильно и в диаграмее тоже было все правильно. Просто при штатном отключении насоса вал замедляется и перед полной остановкой, пленка масла исчезает и подшипник греется выше температуры уставки. Без знания этого процесса, написать и проверть программу, что в тексте, что в диаграмме невозможно. А поскольку знаниям о процессах обладают технологи, а не программисты, то для них и сделали язык FBD диаграмм, что мы с карандашиком пройтись и проверит.
Просто при штатном отключении насоса вал замедляется и перед полной остановкой, пленка масла исчезает и подшипник греется выше температуры уставки.
Технолог должен был написать про это явление в ТЗ на программу управления.
Дак он и написал скорее всего, просто те, кто то реализовал программу, не понимали что им написал технолог про режим выбега насос. И решили, что пока насос не остановлен, он сичтатся в работе (расход же на выбеге есть) и соответвенно все защиты должны действовать до полной остановки.
Как правило на объект где используется такой софт для управления сложными объектами ездит Технолог и программист и они договариватся на месте.
У нас был реальный случай когдавнедерия SimInTech, программистов брать на объект перестали, потому что технолог сам правил диаграмму и заливал в стойки управления.
те, кто то реализовал программу, не понимали что им написал технолог
Слушайте, ну не настолько же программисты тупые! Или это были субподрядчики, которые сегодня пишут для "Подземгаза", а завтра для "Трамвайтреста"?
Просто если рально описывать процесс, как его видит технолог, то программисту нужно будет образование технолога. Именно отсюда растут заоблачные теребования к спецификации продукта в авиации. И отсюда рождаеся модель ориентированное проектирования когда отлаживается не программа, а алгоритмы вместе с моделью объекта. И мы сомотрим за температурами, давлением, силой тока или высотой полета. И тут уже точно нужен технолог, который понимает какие параметры нормальные какие не очень
Так нормальная подрядная организация так и должна работать, сегодня нефтезавод, завтра автоматизации серных ванн в санатории, после завтра очистные сооружения в городе. Там и там трубы задвижки контроллеры и шкафы управления и даже датчики температуры, давления и расхода. Только течет среда разная нефть, миниралка и моча. Какая разница?
искать ошибки всем проще в диаграмме, другое дело писать в виде текста код гораздо быстрее
Идеальная среда разработки должна позволять писать код и сразу видеть диаграмму.
Попробуйте нарисовать на графической диаграмме, скажем, регулярное выражение.
Это называется "синтаксическая диаграмма".
Плюсы: оригинальное начало статьи. Минусы: очень длинное и сложное повествование, сложно ухватить ключевые идеи.
PS "Рисунок 25. Реальный ПИД регулятор САУ реакторного отделения АЭС". Не знаю насколько уместно размещать такие примеры и раскрывать где/что/чем считают и куда бегают, тем более, в период так называемой "турбулентности" вокруг РФ. Всё-таки это АЭС/военка, и есть риск получить брешь в безопасности.
*
Наибольшая доля утечек данных компаний происходит через фото и скриншоты экрана.
Вы не поврите в 1998 году, я на практике в Смоленском учбно тренировочном центре АЭС в качестве работы написал учебное пособие “Реактор РБМК как чайник для чайников”. Вот же были времена, студент мог пойти и ознакомится с любыми чертежами АЭС, а потом еще выложит это все в интернет. До сих пор лежит, на народе https://reactors.narod.ru/rbmk/index.htm Сейчас приходя к заказчику, у которого стоит модель, созданная в нашем ПО, мене запрещают фотографировать, хотя она у меня на компьютере есть.
Но тут нет ничего секртетного это же просто регулятор ПИД, просто обвешаный дополнительной логикой и проверками.
У нас зачем-то добавили условия невлияния на поведения программы (с чего бы?). У русских всегда свой путь.
Попробую пояснить "с чего бы". В программе, что главное - ее алгоритм. Именно это и называют поведением.Поэтому в нашем варианте дано абсолютно необходимое дополнение. Это чтобы "не упариваться" потом с багами в программе.
Поэтому какой бы "сахар" не вводился он не должен влиять на поведение программы. Другое поведение - другая программа. В определении на английском об этом почему-то забыли. А, может, просто не понимают важности этого.
Алгоритм это последовательность инструкций или порядок действий. Вполне можно для упрощения чтения программы изменять последовательность а значит изменять алгоритм и поведение программы. Ну например самое простое, когда мы вводим дополнительную переменную, для промежуточных вычислений, без которой вполне можно обойтись, но ее ведение упрощает чтение кода. На рисунке 5 это введение новой перменной Esp. При расчетах процессов во времени, такое очень часто делают. Вводят перменную типа полный путь. Куда записывают результат интегрирования скорости. И в дальнешем коде используют уже эту переменную, хотя по сути это просто другое имя, той же переменной. Поэтому англйсское определение более верное, в русском лишнее условие.
Алгоритм это последовательность инструкций или порядок действий... Поэтому англйсское определение более верное, в русском лишнее условие
Итак, начнем снала... ;)
Вы привели по сути интуитивное определение понятия "алгоритм". Что интересно, оно у Вас включает в себя синтаксический сахар. Это понятия "инструкции" и "действия". К ним в легкую можно было бы добавить понятия "команда". С точки зрения семантики эти три понятия вполне допустимы в используемом Вами языке (язык программирования интуитивного уровня). Но с точки зрения семантики они должны быть эквивалентны или, по-другому, сводиться к чему-то одному. В любом языке программирования - это язык команд (ассемблер) процессора. Поэтому как бы мы не "сахарили", какую бы семантику не использовали, все в конечном счете сводится к порождению последовтельности инструкций/действий/команд процесса на языке ассемблера (до двоичного кода не будем опускаться ;). Набор подобных команд - одна компонента понятия алгоритма.
Команды работают с памятью. Так вдруг появилась вторая компонента понятия алгоритма - память. К чему бы это? Т.е. к чему бы это я это клоню? :) А к тому, что есть (должна быть) третья компонента понятия алгоритма - это понятие поведения, которое Вы также употребили. Как его формализовать? Математики всего мира долго бились со всем этим пока те же Тьюринг, Пост и другие не пришли к понятию "машины". В эти машины добавили еще одну компоненту - управление. Это управление и определяло поведение того или иного алгоритма, той или иной машины. Таким образом, понятие "машины" формализовало понятие !алгоритма". Таким образом, мы от интуитивного определения алгоритма перешли к его формальному определению. Так учат у нас, так, надеюсь, учат и у них. Может, правда, сейчас что-то поменялось ;)
Таким образом, понятия - память, команды, управление составляют "тройку", входящую в формальное определения алгоритма, реализуемого той или иной машиной. Разные компоненты - разные машины. Чтобы не закапываться дальше сразу задам вопрос/вопросы.
Где в машине, как в формальном определении понятия алгоритма, место синтпксическому сахару? Чему в формальном смысле соотвествует понятие "синтаксический сахар"? Зачем изобретать "синтаксический сахар"?
"Чтобы было лучше людям (чтобы человеку было хорошо)" - это не математически строгое определение ;). А програмирование - это, не будем забывать, все же в первую очередь - математика.
Синтаксический сахар, который изменяет поведение программы, делая при этом его не эквивалентным исходному поведению - вреден. Именно об этом говорит наше определение. Именно это забывает их определение. Именно поэтому оно не верно по своей сути.
Понятие ситаскический сахар относится исключительно к описанию алгоритма на языке программирования.
Вот например цикл в SimInTech:
for (i=1,10) s=s+i^2; - цикл от 1 до 10, поскольку шаг не указан внутри будет использоватся стандартное инкрементирования на 1,
for (i=1,10,1) s=s+i^2; - тот же цикл с указание шага, будет добавлено выражение сложение с шагом;
Один и тот же результат, но разная запись облегчающая четение или выражение, возможно разные алгоритмы и разный код. Под русское определение не попадает, хотя это ровно сахар как он определен.
Что касается кода ассемблера он получается разным даже при одинаковом тексте исходного кода, просто путем настройки опций компилятора. Например оптимизация по памяти, или оптимизация по скорости вы получите разный набор команд и разное поведение программы, для одного и того же исходного текста.
Один и тот же результат, но разная запись облегчающая четение или выражение, возможно разные алгоритмы и разный код. Под русское определение не попадает, хотя это ровно сахар как он определен.
Ни какой "сахар" не должен менять поведение программы.Вот к чему это приводит: засада номер 2 из моей крайней статьи.
Я против "сахарного цикла". Программист обязан указывать шаг цикла. Если он прибегает к "сахару" - его нужно бить по рукам. Как сладкоежку изолировать от сладостей (это я уже о себе ;)
for (i=1,10) s=s+i^2; - цикл от 1 до 10, поскольку шаг не указан внутри будет использоватся стандартное инкрементирования на 1,
for (i=1,10,1) s=s+i^2; - тот же цикл с указание шага, будет добавлено выражение сложение с шагом;
Но ваш алгоритм абстрагирован от алгоритма реализаций цикла в выходном коде: его суть - обойти числа от 1 до 10 и сложить их квадраты.
Говоря о синтаксическом сахаре нужно понимать, о КАКОМ алгоритме мы говорим.
Если у меня есть две формы записи цикла, одна из которых проще для понимания, другая проще для записи. То мне кажется это и есть пример синтаксического сахара для разработчика. Для него ничего не меняется кроме вида записи. Но алгоритмы при этом будут немного отличатся. Соответвенно под определение из русской википедии это не подходит. А под определение из английско вполне
Фотофакт. Провел генерацию кода СИ из скрипа для выражения for (i=1,10) u = u + i; результат:
/* Index=0
UID=0
GeneratorClassName=TLanguage
Name=LangBlock22
Type=Язык программирования */
l_start_dv0:;
state_vars->dv0i_=(1);
state_vars->dv0i_=(1);
dv0___2:
if(state_vars->dv0i_ > (10))
goto dv0___5;
state_vars->dv0u_=(state_vars->dv0u_+state_vars->dv0i_);
state_vars->dv0i_ = state_vars->dv0i_ + 1;
goto dv0___2;
dv0___5:
;Для выражения for (i=1,10, 1) u = u + i; результат
{
/* Index=0
UID=0
GeneratorClassName=TLanguage
Name=LangBlock22
Type=Язык программирования */
l_start_d1v0:;
state_vars->d1v0i_=(1);
state_vars->d1v0i_=(1);
d1v0___2:
if(((1) >= 0)&&(state_vars->d1v0i_ > (10))) {
goto d1v0___5;
} else {
if(((1) < 0)&&(state_vars->d1v0i_ < (10)))
goto d1v0___5;
};
state_vars->d1v0u_=(state_vars->d1v0u_+state_vars->d1v0i_);
if((1) != 0){
state_vars->d1v0i_ = state_vars->d1v0i_ + (1);
goto d1v0___2;
};
d1v0___5:
;
}Изменяя выражение с помощью синтаксического сахара мы меняем кода СИ который гененрируется из скрипта но для пользователя очевидно что
for (i=1, 10) u = u + i; - проще записать (меньше символов)
for (i=1, 10, 1) u = u + i; - иногда легче прочитать, если в тексте часто используются циклы не с целым инкрементом например если у меня по тексту for (i=1, 10, 0.5)..., for (i=1, 10, 0.1)...., for (i= 0, -10, -0.1).... потом вдуруг for (i = 1 , 5)... то глаз будет спотыкатся и мозг напрягаться, я в этом случае для едионобразия я запишу полную форму for (i=1, 5, 1)... И получу разный код для контроллера. И поведение программы изменится
Не царское это дело - програмисту на ЯВУ вникать в код генерации ;). Это входит в обязанности разработчика компилятора. Это он должен сделать так, что в подобном не было необходимости от слова совсем. Каждый должен заниматься своим делом. Прикладной программист - одним, системный программист - другим.
Вот поэтому американское определение синтасического сахра, писали те кто понимает что под капотом у языков, программирования. А русское написал ДЖВА программист, который не понимает, что у него в программе происходит.
Как раз понятие синтаксического сахара должно быть абстрагировано от того, что под капотом у языка программирования. А если не абстрагировано - то это уже не синтаксический сахар, а существенное изменение языка.
именно про это и говорится в американской версии сделать легче писать и читать, а как это реализовано это отношение к делу не имеет.
Вы по каким-то причинам отстаиваете американскую версию по отношению к русской... ;)
Проблема, ведь, не в том как это реализовано, а в том, какое поведение отражает любая реализация. А оно должно быть неизменным или, что точнее, любая реализация должна порождать эквивалентное поведение Только в этом случае результат не будет зависеть от реализации. Вот о чем идет речь при любом "сахаре".
Это теория, математика (теория алгоритмов, теория схем программ и т.п.). Цель не в том, чтобы красиво "припудрить" алгоритм, а в том, чтобы ни какая "приправа" - будь то сладкая, горька или кислая не влияла на определенные свойства алгоритма, которые гарантируют предсказуемый и верный результат. Именно это подчеркивает "русское" определения, настаивая на неизменности поведения.
Программы пишутся не для красоты, а для получения результата. По определению алгоритма он должен быть предсказуемым и повторяемым.
Ну, что мы тут уперлись в элементарные и достаточно очевидные вещи?
результат, это не поведение, если я изменил порядок вычислений для своего удобства, я его реально изменил и поведение программы явно изменилось, хотя результат остался тот же. Просто мне с математическим стилем мышления, это очевидно и америкнцы которые писали опредленеи на английском тоже это понимали. Теорему можно доказать разными способами, и каждый будет докзательством, верный результат вычислений можно получить разными алгоритмами, какой из разных но вреных вариантов выбрать, определяется удобством записи или четения для человка, имеено про это и есть американское определение синтксического сахара.
Поведение - это входно-выходная характеристика. То, чего мы не видим "под капотом" - к поведению не относится.
Если Вы можете изменить порядок вычисления, так, чтобы не изменилась входно-выходная характеристика, значит порядок вычислений не является значимой частью вашего алгоритма.
Мне это не очевидно, в американском определение все точно и однозначно, добавление непонятного условия не изменения "поведения" в русском варианте только путает.
правильно, для пользователя появление новых инструкций при применении синтасического сахара, не я является существенным, но изменяет поведение программы. Поэтому американское определение более простой и более правильное
Вы что-то своё называете поведением программы.
Почему? там же выше приямо живой пример синтаксического сахара для цикла от 1 до 10 for (i=1, 10) и for (i=1, 10, 1) выполняется одно и то же, но код реализации будет разный соотвевенно поведение программы будет разным. Во втором случае кода будеть больше, в программу добавляется проверка диапазона вниз, поскольку подразумевается что может быть и отрицательный шаг.
Что это как не изменение поведения программы, если бы больше вычислений делаем?
А пользователь в зависимости от ситуации может бырать что ему проще записать или проще понять. Это случай не попадает по определение из русской вики, но попадает под определение американской вики. А занчит американское более правильное.
Входно-выходная характеристика программы не изменилась. В ответ на тот же вход - тот же выход. А это - и есть поведение.
Что это как не изменение поведения программы, если бы больше вычислений делаем?
Я бы сказал, что это пример разного уровня оптимизации скомпилированного кода. Что можно поставить в минус компилятору.
википедию пишут на русском в основном украинцы вообще то, я считаю что это комплекс, есть американский термин, есть его перевоод на русские, зачем вместо прямого и точного перевода добавлять отсебятину мне не понятно.
...добавлять отсебятину мне не понятно.
Для Вас - отсебятина. А с точки зрения требования теории - необходимая вещь. Иначе фактически снимается отвественность с разработчика "сахара". Даже если он сделает ошибку, т.е. "сахар" будет порождать неэквивалентное поведение из-за чего и возникнет ошибка, то он может оправдаться, сказав, что такого требования - создание эквивалентного поведения не было. И будет, строго говоря, прав. Может, даже сошлется на Вашу поддержку ;)
Есть математические правила, например необходимые и достаточные условия. Есть определения. Есть правила написания определений. И маериканский вариант более правильный, поскольу содержит только необходимые признаки и достаточные признаки синтаксического сахара. В русском определении, лишние условия. Более, того я уже привел наглядный пример когда меняется алгоритм программы при использовании синтасического сахара. Он реально меняется, но от этого сахар не перестает быт сахаром. Никакой отвественности американское определение ни с кого не снимает. Там написано, что синтаксический сахар это все что упрощает чтение и выражение. Адекватность и отстутвие ошибок это требования более общие к любому языку программирования. Но требования более высокго уровния.
Вы противоречите даже не мне, а ... Никлаусу Вирту :) Хотя и он и Вы оцениваете именно с математической точки зрения понятие синтаксического сахара. Но я на стороне Вирта. А он против всяких "сахарных украшательств" (подробнее см. по ссылке).
Другая ссылка, где также достаточно доступно объясняется, что представляет собой "сахарное явление".
Изучив эти ссылки, узнав Ваш взгяд на эту тему, Я пришел к выводу, что "страшнее зверя нет", чем этот самый "сахар". А когда я еще узнал, что оказывается мой взгляд на сахар совпадает с мнением Вирта, то только еще больше утвердился в его вреде.
За любой сахар, кроме необходимого, нужно программисту "стучать по голове", приговаривая - пиши так, чтобы было понятно всем - от новичка, до самого крутого чела. Т.е. без сахара. :).
Вы можете быть за сахар, вы можете быть против сахара, вы можете даже быть диабетиком и колоть инслуин. Но определения сахара, и само понятие от этого никуда не исчезнет. Вот и все. И определение американское в википедии более правильное. Изменение поведение программы при применении синтасического сахара может быть вредным, может быть полезным, его может вообще не быть. Но ситаксических сахар не перстает быть ситаксическим сахаром при изменеии поведении программы, как это написано в амриканском определении.
И определение американское в википедии более правильное.
Кто Вам это сказал и почему Вы ему поверили?
Доказательство от обратного, я взяли пример синтаксического сахара, и посмотре на сгенерированый код, код получился разным - программа изменила поведение, занчит отпределени не верное. Применение синтаксического сахара может изменять поведение программы. Причем американсое определение даже синтасически построено более правильно.
In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express.
у американцев сахар это то что облегчате жизнь в первую очередь, в нашей версии, на первом месте условия не влияния на поведение программы, и только через но делает использование языка более удобным для человека.
Синтаксический сахар (англ. syntactic sugar) в языке программирования — это синтаксические возможности, применение которых не влияет на поведение программы, ...
К тому же если читать английскую верисю они где в конце абзаца пишут про сохранение функциональности, это более правильно, поскольку я могу релизовать одну и ту же функциональность разными вычислениями, изменяя поведение программы, но не меняю ее функциональность. Стандартный процесс оптимизации вычислений, меняет поведение программы но не меняет ее результат.
А почему Вы считаете, что разобранный Вами пример - является хорошим примером?
изменяя поведение программы, но не меняю ее функциональность.
Ну я и говорю: Вы что-то своё называете поведением.
Что значит хороший или плохой? Доказательство от обратного в математике именно так и строится, если частный пример опровергает общее утверждение, то общее утверждение является ложным. Сокращение записи цикла это типичный, явный и общепринятый пример ситасического сахара (плохой или хороший, какая разница?) и мы наглядно видим как происходит изменение поведения программы (там просто больше или меньше вычислений).
если частный пример опровергает общее утверждение
Но только в том случае, если частный пример имеет какое-то отношение к общему утверждению. Что тоже нужно предварительно доказать.
Сокращение записи цикла это типичный, явный и общепринятый пример ситасического сахара
Да, но только в том случае, если записи абсолютно взаимозаменяемы. А если нет - это камень в адрес компилятора.
Сокращение записи цикла это типичный, явный и общепринятый пример ситасического сахара
Вы просто вынуждаете... :) Вот полный код некорректного поведения "сахарной мечты" ;) :
void ThCounter::run() {
while (!pFThCounter->bIfLoad);
pFThCounter->DecrementActive();
}Здесь 2-я строка - Ваш случай. Ее можно записать и так (следите за ручками):
while(...) {}
А можно так
while(...)
И здесь не только разное поведение, но и разный результат. Программа вообще виснет и только в последнем случае работает, как задумано.
Но если мы запретим оптимизацию, пометив флаг bIfLoad как volatilе, то начнет работать.
Здесь все, как Вы "мечтаете" и сахар и оптимизация и ... разработчики компилятора, которые, видимо, работают по "американскому шаблону", не понимая, что поведение программы должно порождать один т тот же результат, они, блин, не понимают, если поведение ты изменяешь, то оно должно быть эквивалентно задуманному поведению и порождать один и тот же результат, а не отражать твои фантазии и т.д. и т.п.
Вас этот пример не убедил? Ведь, это именно и есть: " частный пример опровергает общее утверждение". Это Ваши же слова, которые нужно "отлить в граните" поскольку они, без шуток, абсолютно верные. Выше я все разложил "по полочкам". Есть и мой "частный пример" и Ваше "общее утверждение".
Ну как Вам такое, товарищ, Маск?
Вы доказываете, только то что, синтаксический сахар может в некоторых случаях вызывать ошибки. Как это противоречит американскому определению? Русскому определению ваш пример противоречит чуть больше чем полностью, в русском определении ситасический сахар не должен вызывать изменения поведения, и вас спрашиваю с каго препугу? Вы тут конкретным примером доказали что я прав и американское определение в вики верное, а в русской вики - нет.
Вы мы мне приводите пример, где синтасически сахар, не только изменяет поведение программы, но еще и приводит к ошибкам. Чем полностю подтверждате верность американского определения. "Синтаксический сахар", это то, что сделано для облегчения выражения и понимания. Те кто американскую вики писал, в отличие от авторов вики, хорошо понимают, что ситаксических сахар может и изменять поведения программы, и даже вызывать ошибки в некоторых случаях. Поэтому русский вариант определения некорректный.
По вашей логике если в языке програмирования есть ошибки, то это не язык программирования, потому что языком програмирования может называтся только язык которые обеспечивает корректное выполенние программ. А если не всегда корректно то это не язык программирования. Так?
А если не всегда корректно то это не язык программирования. Так?
Да, так! Это сырой продукт, которому еще предстоит быть языком программирования. В данном случае, чтобы называться языком, нужно или доработать оптимизацию, или отключить ее на фиг совсем, пока не устраните все ее ошибки.
Этот же пример показывает насколько сахар может быть вреден. Так, если не ставить (см. код) символ ';' . то вызов функции попадет в тело цикла, если поставить, то он будет за пределами цикла. Это разное поведение, это разные алгоритмы. Поэтому программисту, который "сокращает циклы" нужно отрывать не только руки, но и кое-что еще.
А когда в это еще вмешивается и кривая оптимизация, то вместе получается "ваще" крутой "американизм" ;)
Тут не согласен, язык программирования остается языком програмирования несмотря на существующие в нем ошибки. Можете назвать его сырым продуктом, но это все равно язык програмирования. Так же как и процессор Intel Pentiun в котором была ошибка деления, не перстал быть процессором. (Компилятор Delphi тогда предлагал опцию деления с обходом ошибки).
И Никлаус Вирт возражает против применения синтаксического сахара,как раз потому, что сахар может изменять повредение и является потенциальным источником ошибок.
Это вы и сами выше доказали примером американское определение синтаксического сахара в википедии, более верное, поскольку не гарантирует отсутсвий изменения поведения программы. Что показывают ваш примеры и сам Никлаус Вирт, об этом говорит.
А вот почитав русское определение вики, где сказано, что синтаксически сахар это синтаксические возможности, применение которых не влияет на поведение программы можно попасть в просак. Может это специально писали враги которые хотят русских программистов обмануть! ;)))))))
Поэтому изучайте оригнальные определения на англйском языке, это поможет лучше разобраться, ну и для допроса пленных опять же полезно.
Ржавая машина с убитым мотором не перестает быть машиной. Только пользы-то? Поэтому, если пошел троллинг, то как-то не хочется на него тратить время, т.к. точно есть заняться чем-то другим - более полезным;)
Если Вы все же продолжаете настаивать серьезно на своей трактовке "сахара", то тут надо не изучать неверные опреления и, тем более, руководствоваться ими, а, может, проштудировать теорию компиляторов. Наверное, в каждой книжке на эту тему есть разделы создания кода и особенно оптимизация. Вот там все и расписано... Особенно хороши книги Вирта.
По поводу пыток. Вас мне кажется пытать бесполезно. Если Вы на чем-то настаиваете, то не измените свою точку зрения даже под пытками. Проще припугнуть и - отпустить. Я против кардинальных мер. Нужно предоставить человеку шанс на исправление ;)
"Сахар", соответствующий русскому определению, априори не вреден (безразличен).
это и вводит в заблуждение неопытных пользователей. Тот кто прочитает амерканское определение в этом месте насторожится.
Может тогда просто не надо называть это "сахаром", чтобы не вводить людей в заблуждение? Или предупреждать, что сахар некачественный?
именно об это и английское определение, они говорят синтаксический сахар это для облегчения записи и понимания все. И опытный человек сразу понимает, тут могут быть засады, они всгеда бывают когда хочется сделать что то легче и быстрее. (именно по этому мне это определение кажется верным)
А в русском определение все хорошо, по русскому определению поведения программы не меняется. И я справедливо возмущен, кто такое сказал, откуда это следует, и кто вообще это придумал. В жизни все как раз по другому, о чем даже Никола Вирт говорит.
Вы не тому возмущаетесь. Проблема не в определении, а в реализации. Вы фактически предлагаете узаконить преступление.
А я как раз пишу про определение. Американское определение правильное, потому что описывает реальность данную нам в ощущениях. Русское опредление описывает несуществующую, но желанную как комунизьм к 1980 году, идеальную ситуацию. Для практического использвания лучше пользоваться определениями приближенными к реальности, а не фанатзийными предположниями, которые противочречат нам в ощущениях.
Программирование - это раздел математики. А в математике не руководствуются "ощущениями". Вам, как понимающему математику, это известно или должно быть известно... Или не так?
Потому-то Вирт и был против "сахара", который вводит понятия "приближенные к реальности". Их сложно формализовать или они просто не имеют особого смысла и только усложняют формальные преобразования.... В случае "сахара" - генерацию кода, его анализ, оптимизацию и т.п.
Именно математически определение в американскй вики верное поскольку говорит о сути явления, сахар сделан для облегчения записи и понимания. А в русской вики в определение добавлено условие, которое, на самом деле, противоречит реальности. И в этой ветки это с успехом доказали, на живом пример, "синтаксически сахар" вызывает изменение поведения. Мне это вообще очевидно исходя и американского определения. Более того Николас Вирт, возражал против применени синтаксического сахара именно потому что он может вызвать изменения в программе. Так устроена реальная жизнь, а в руской вики поисаны фантазии автора перевода с лишней отсебятиной, которая путает читателя. Поэтому всегда нужно читать первоисточника.
И в этой ветки это с успехом доказали, на живом пример, "синтаксически сахар" вызывает изменение поведения
С равным правом мы можем считать, что доказали, что данный пример не является синтаксическим сахаром.
Как это не явлется если он так определено авторами языка програмирования. Тогда мы можем сказать, что согласно русского определения в вики синтаксического сахара не существует. Потому что без подробного тестирования узнать, (меняется ли повредение программы) а значит является ли схаром сокращение или изменеия записи в языках програмирования невозможно. Поскольку я не знаю что под копотом у транслятора, компилятора и процессора, на любое изменение в синтаксисе можно сказать что он меняет поведение программы. И для того что бы убедится что сокращение записи цикла синтаксический сахра надо сравнить байтовый код, причем сравнить для разных процессоров. Intel, Amd и ARM могут давать разные результаты, изменяя поведение программы:
Как это не явлется если он так определено авторами языка програмирования.
А может они ошиблись?
Как это не явлется если он так определено авторами языка програмирования.
Только если это действительно так. Но это в общем случае не так. Простой аргумент: я могу сесть и написать простой язык, в котором будет синтаксический сахар. Причём, если надо, он будет перед компиляцией препроцессироваться в более длинный вариант на том же языке.
Поскольку я не знаю что под копотом у транслятора, компилятора и процессора, на любое изменение в синтаксисе можно сказать что он меняет поведение программы
Нельзя так сказать, именно по причине незнания, что под капотом у транслятора.
Ну, и, как я уже сказал, если Вы будете пользоваться своим собственным определением слова "поведение" - Вы докажете всё, что угодно, но с Вами никто не согласится.
Почём синтаксический сахар в графических языках программирования?