Хочется не слов, не примеров, а математики, грубой и однозначной.
Поясню аксиоматический метод ДРАКОНа за 2 шага. Шаг 1. Теоретическое введение из книги Ершова и Палютина.
Ершов Ю.Л., Палютин Е.А. Математическая логика. —
М.: Наука, 1079. — 320 с. — С.12, 13.
Основным итогом деятельности в области оснований математики можно считать становление математической логики как самостоятельной математической дисциплины, а принципиальным достижением математической логики — разработку современного аксиоматического метода, который может быть охарактеризован следующими тремя чертами:
1. Явная формулировка исходных положений (аксиом) той или иной теории.
2. Явная формулировка логических средств (правил вывода), которые допускаются для последовательного построения (развертывания) этой теории.
3. Использование искусственно построенных формальных языков для изложения всех положений (теорем) рассматриваемой теории…
Введение и использование подходящих обозначений было на протяжении всей истории математики весьма важной и продуктвной процедурой…
Основным объектом изучения в математической логике являются различные исчисления.
В понятие исчисления входят такие основные компоненты, как:
а) язык (формальный) исчисления;
б) аксиомы исчисления;
в) правила вывода…
Еще одним замечательным достижением математической логики является нахождение математического определения понятию алгоритма…
Изучение исчислений составляет синтаксическую часть математической логики…
Наряду с синтаксическим изучением исчислений проводится также семантическое изучение формальных языков математической логики.
Основным понятием семантики является понятие истинности для выражений (формул, секвенций и т. п.) формального языка.
Шаг 2. Ссылка на мою книгу. См. Глава 32. ИСЧИСЛЕНИЕ ИКОН — НОВЫЙ МЕТОД ПРЕДОТВРАЩЕНИЯ ОШИБОК Стр. 303 и далее.
Нет. Я вижу ваш «адрес», и его надо читать как «перейди на ветку с названием таким-то».
Это правильно. Вы совершенно правы. Другого объяснения нет.
Это goto.
А это неправильно.
Объясняю. Вы как опытный специалист по программированию совершенно естественно (даже рефлекторно) трактуете эту конструкцию как goto.
Но. Слова goto там нет. Вы его добавили.
Тонкость вот в чем. Хотя эта графическая конструкция играет роль goto, но она безопасна (в отличие от опасного goto, написанного ручками).
Выходом из ветки служит икона «адрес», в которой записывается имя следующей по порядку исполнения ветки. Икона «адрес» — это замаскированный оператор перехода (gоtо).
Никуда оператор goto не делся.
Это не так. Очень даже делся. Он полностью исчез из поля зрения человека.
Что означает фраза:
Икона «адрес» — это замаскированный оператор перехода (gоtо).
Это всего лишь метафора для науч-попа, чтобы быстренько объяснить, что к чему.
В данной дискуссии она совершенно неуместна.
Сожалею, что она ввела вас в заблуждение.
Приношу свои извинения.
Дейкстра не только указал, что goto запрещен, но и указал — почему. Неужели вы весь труд Дейкстры поняли только как «запрет goto»?
(впрочем, Тышовская версия ДУРАКОНа вполне себе генерила эти goto, на которые вы призывали «не смотреть»).
Вы допускаете ошибку насчет Тышова. Серьезную ошибку.
Пользователь программы Геннадия Тышова (ДРАКОН-конструктор под названием ИС Дракон ) работает с дракон-схемой (дракон-алгоритмом), которая для него является исходником. В этой схеме вы даже под микроскопом не увидите goto. Их там нет.
Да, вы правы, я призывал не смотреть на goto, но что означает эта фраза? Этого вы, к сожалению, не поняли. А это очень важно.
Объясняю. эта фраза означает следующее:
1. Операторы goto никуда не исчезают. они как были, так и остались.
2. Работая с ДРАКОНом, человек никогда не пишет goto ручками. Он их не видит и не должен видеть.
Для человека они исчезли, стали невидимыми, сквозь землю провалились, кошка съела.
3. ДРАКОН-конструктор Тышова ИС Дракон физически исключил для человека возможность писать goto ручками и видеть их на экране.
Идем дальше. Программа ИС Дракон транслирует дракон-алгоритм (в котором нет goto) в исходный код целевого языка, например, языка Си. В этот момент (но не ранее!) на сцене впервые появляются goto.
Страшно ли это? Нет! — совсем не страшно. Почему не страшно? Потому, что эти операторы не нарисованы ручками, а получены автоматически. А это совсем другое дело!
Эти операторы уже безопасны, потому что они получены автоматически. Это значит, что они кастрированы и не способны рожать ошибки.
Но человек по-прежнему их не видит и не смотрит на них!
Почему? Потому что для пользователя ДРАКОНа исходником является дракон-схема, и только она.
Пользователь не смотрит на goto в исходном тексте целевого языка, как мы не смотрим на код после компиляции.
_________________________
Выше я описал идеальный случай, как должно быть.
На практике могут возникать вопросы реализации и некоторые отступления от идеала.
Но со временем рано или поздно все наладится.
И огрехи, если они есть, будут устранены.
Это вы сказали, а не я.
В гиперболу можно превратить все что угодно, но я против преувеличений и гипербол.
Я ограничился точным цитированием. Кому интересно, могу указать источники с номерами страниц.
Моя цель — показать, что идеи ДРАКОНа не взяты с потолка, а опираются на существующие тенденции и учитывают опыт выдающихся ученых.
то, что вы называете «опасными операторами» — это то, чем вы не научились пользоваться… Это всего лишь означает, что либо я еще маленький и глупый, и не умею переносить кружки с кипятком, либо что я уже взрослый, но криворукий.
Отлично! Не в бровь, а в глаз!
В 1968 году Эдсгер Дейкстра в журнале «Communications of the ACM» указал, что оператор goto, используемый во многих языках программирования высокого уровня, является основным источником ошибок и потому должен быть запрещен.
Это означает, что Эдсгер Дейстра, основоположник структурного програмирования, призвал исключить оператор goto не потому, что тот опасный и является источником ошибок, а потому что бедный Дейкстра, подобно маленькому и глупому ребенку, не научился пользоваться этим оператором!
Поздравляю вас!
Затем Бертран Мейер выявил еще два опасных элемента — операторы break и continue, которые также следует запретить как замаскированные goto. По словам Мейера, это те же старые «goto в овечьей шкуре».
Это означает, что Бертран Мейер, основатель контрактного програмирования и создатель языка Eiffel, книга которого Object Oriented Software Construction в свое время считалась библией ОО-программирования, призвал исключить операторы break и continue не потому что они опасные и являются источником ошибок, а потому что бедный Бертран Мейер, подобно маленькому и глупому ребенку, не научился пользоваться этими замечательными оператороми! Поздравляю вас!
Еще дальше идет доктор физико-математических наук профессор Игорь Вячеславович Вельбицкий, который считает, что из программирования следует исключить:
«ключевые слова-паразиты и соответствующие им конструкции языков типа: goto, if, for, while, break, begin-end, {-} и т.д… Эти конструкции являются основным источником ошибок и проблем в современном программировании».
Оказывается, и здесь незадача!
Бедный профессор Вельбицкий забил в набат, не поглядевши в святцы, потому что он тоже обмишурился — не научился пользоваться оператороми!
Это не так. Вы предположили, что ДРАКОН удаляет, вычеркивает, выбрасывает некоторые возможности целевого языка программирования (target language).
Но это совсем не так. Целевой язык (и все его коды) остаются в целости и сохранности.
Что же делает ДРАКОН? Он на время удаляет с глаз человека несколько опасных операторов и подсовывает вместо них безопасные.
Так что все возможности языка бережно сохраняются и никуда не деваются.
Кроме одной, а именно: возможности совершить ошибку в операторах управления. С оговоркой: ДРАКОН не гарантирует полную защиту от ошибок.
Вы правы. Не станут. Потому что они уже высокоуровненвые.
И для этого совсем не нужно их хвалить.
Но они могут быть и низкоуровневыми.
Насчет уровня. Уровень дракон-алгоритмов выбирает разработчик.
Если разработчику нужен высокий уровень, он нарисует высокоуровневые дракон-алгоритмы.
Если разработчику нужен низкий уровень, он нарисует низкоуровневые .
Уровень — это не показатель качества, а степень абстракции, которая нужна разработчику.
Я рад, что вы попробовали читать. Спасибо.
Вы, по-видимому, заметили, что ДРАКОН является развитием идей Эдсгера Дейкстры (структурное программирование) на случай визуального программирования.
Или нет?
В обсуждении появились замечания о сопоставлении ДРАКОНа и верификации.
Хочу объяснить принциальную разницу.
Верификация, без сомнения, замечательная вещь, и я обеими руками за верификацию.
Но. Верификация требует затраты дополнительного времени и дополнительных усилий.
Если таких возможностей нет (нет времени или жаль усилий) верификацию, естественно, не проводят.
Если кто-то желает привинтить к ДРАКОНу верификацию, — ради Бога! Нет никаких возражений. Флаг вам в руки.
Сегодня в ДРАКОНе нет верификации. А что есть? Есть автоматическое частичное доказательство правильности создаваемых дракон-алгоритмов с помощью аксиоматического метода.
Чем это отличается от верификации? Тем, что частичное доказательство правильности проводится полностью автоматически и не требует никаких дополнительных ресурсов. Иными словами, затраты дополнительного времени и дополнительных усилий НЕ ТРЕБУЮТСЯ.
Как говорится, солдат спит, а служба идет.
Причем пользователь (разработчик алгоритма), грубо говоря, не имеет никакого понятия о том, что где-то внутри программы ДРАКОН-конструктор каким-то чудом происходит самое настоящее математическое доказательство.
Здесь некоторые мои уважаемые оппоненты говорили о том, что читали мои книги и иронически при этом покрякивали по поводу моей дремучести.
Что тут скажешь?
«Этого-то товарищ Попандопуло и не учел, слона-то он и не приметил».
Так это ЯП или религия?
Очередная вещь, решающая всё с точки зрения её адептов
Это некорректное утверждение.
Я никогда не говорил (и не мог сказать), что ДРАКОН решает все.
Такие преувеличения можно встретить только у некоторых уважаемых оппонентов, участников нашей дискуссии, которые в отдельных случаях сплошь и рядом приписывают мне якобы сказанные мной различные несообразности.
Хотите графический язык? Это называется FBD. На нем программируют промышленные контроллеры. Хотите сложнее? Есть LabView, которому ваша Дракон и в пометки не годится.
Вы правы.
1. Промышленные контроллеры — это важно.
2. Function Block Diagram — графический язык программирования стандарта МЭК 61131-3 для программирования программируемых логических контроллеров (ПЛК).
3. Для LabView имеются профессиональные инструменты, а для ДРАКОНа — всего лишь экспериментальные.
Но вы, к сожалению, отстали от жизни: «Дракон и в пометки не годится». При сравнении ДРАКОНа и FBD дело обстоит иначе — ровно наоборот.
Поясню.
Предприниматель Алексей Муравицкий, системный интегратор фирмы ОВЕН использует ДРАКОН-технологию в нефтегазовой промышленности, пищевой промышленности, теплоэнергетике для программирования ПЛК при разработке шкафов управления установками и насосами
1. На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании «Сургутнефтегаз» и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.
Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
2. На видео показан шкаф управления насосами объемного действия частотно-регулируемого электропривода на кустовой насосной станции Азнакаевского нефтегазодобывающего управления компании «Татнефть», где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН. Программа загружается в энергонезависимую память сенсорного программируемого контроллера СПК 107 фирмы ОВЕН.
По результатам обсуждения внес изменение в статью.
В раздел 9. «Семейство ДРАКОН-языков» добавлен параграф ДРАКОН — это новый способ работать с существующими языками программирования
Поясню аксиоматический метод ДРАКОНа за 2 шага.
Шаг 1. Теоретическое введение из книги Ершова и Палютина.
Ершов Ю.Л., Палютин Е.А. Математическая логика. —
М.: Наука, 1079. — 320 с. — С.12, 13.
Шаг 2. Ссылка на мою книгу. См. Глава 32. ИСЧИСЛЕНИЕ ИКОН — НОВЫЙ МЕТОД ПРЕДОТВРАЩЕНИЯ ОШИБОК Стр. 303 и далее.
А это неправильно.
Объясняю. Вы как опытный специалист по программированию совершенно естественно (даже рефлекторно) трактуете эту конструкцию как goto.
Но. Слова goto там нет. Вы его добавили.
Тонкость вот в чем.
Хотя эта графическая конструкция играет роль goto, но она безопасна (в отличие от опасного goto, написанного ручками).
Это не так. Очень даже делся. Он полностью исчез из поля зрения человека.
Что означает фраза: Это всего лишь метафора для науч-попа, чтобы быстренько объяснить, что к чему.
В данной дискуссии она совершенно неуместна.
Сожалею, что она ввела вас в заблуждение.
Приношу свои извинения.
Пользователь программы Геннадия Тышова (ДРАКОН-конструктор под названием ИС Дракон ) работает с дракон-схемой (дракон-алгоритмом), которая для него является исходником. В этой схеме вы даже под микроскопом не увидите goto. Их там нет.
Да, вы правы, я призывал не смотреть на goto, но что означает эта фраза? Этого вы, к сожалению, не поняли. А это очень важно.
Объясняю. эта фраза означает следующее:
1. Операторы goto никуда не исчезают. они как были, так и остались.
2. Работая с ДРАКОНом, человек никогда не пишет goto ручками. Он их не видит и не должен видеть.
Для человека они исчезли, стали невидимыми, сквозь землю провалились, кошка съела.
3. ДРАКОН-конструктор Тышова ИС Дракон физически исключил для человека возможность писать goto ручками и видеть их на экране.
Идем дальше. Программа ИС Дракон транслирует дракон-алгоритм (в котором нет goto) в исходный код целевого языка, например, языка Си. В этот момент (но не ранее!) на сцене впервые появляются goto.
Страшно ли это? Нет! — совсем не страшно. Почему не страшно? Потому, что эти операторы не нарисованы ручками, а получены автоматически. А это совсем другое дело!
Эти операторы уже безопасны, потому что они получены автоматически. Это значит, что они кастрированы и не способны рожать ошибки.
Но человек по-прежнему их не видит и не смотрит на них!
Почему? Потому что для пользователя ДРАКОНа исходником является дракон-схема, и только она.
Пользователь не смотрит на goto в исходном тексте целевого языка, как мы не смотрим на код после компиляции.
_________________________
Выше я описал идеальный случай, как должно быть.
На практике могут возникать вопросы реализации и некоторые отступления от идеала.
Но со временем рано или поздно все наладится.
И огрехи, если они есть, будут устранены.
В гиперболу можно превратить все что угодно, но я против преувеличений и гипербол.
Я ограничился точным цитированием. Кому интересно, могу указать источники с номерами страниц.
Моя цель — показать, что идеи ДРАКОНа не взяты с потолка, а опираются на существующие тенденции и учитывают опыт выдающихся ученых.
Пожалуйста, скиньте мне на почту, что есть по ПРОЛ2 vdp2007@bk.ru
В 1968 году Эдсгер Дейкстра в журнале «Communications of the ACM» указал, что оператор goto, используемый во многих языках программирования высокого уровня, является основным источником ошибок и потому должен быть запрещен.
Это означает, что Эдсгер Дейстра, основоположник структурного програмирования, призвал исключить оператор goto не потому, что тот опасный и является источником ошибок, а потому что бедный Дейкстра, подобно маленькому и глупому ребенку, не научился пользоваться этим оператором!
Поздравляю вас!
Затем Бертран Мейер выявил еще два опасных элемента — операторы break и continue, которые также следует запретить как замаскированные goto. По словам Мейера, это те же старые «goto в овечьей шкуре».
Это означает, что Бертран Мейер, основатель контрактного програмирования и создатель языка Eiffel, книга которого Object Oriented Software Construction в свое время считалась библией ОО-программирования, призвал исключить операторы break и continue не потому что они опасные и являются источником ошибок, а потому что бедный Бертран Мейер, подобно маленькому и глупому ребенку, не научился пользоваться этими замечательными оператороми! Поздравляю вас!
Еще дальше идет доктор физико-математических наук профессор Игорь Вячеславович Вельбицкий, который считает, что из программирования следует исключить:
Оказывается, и здесь незадача!
Бедный профессор Вельбицкий забил в набат, не поглядевши в святцы, потому что он тоже обмишурился — не научился пользоваться оператороми!
Но это совсем не так. Целевой язык (и все его коды) остаются в целости и сохранности.
Что же делает ДРАКОН?
Он на время удаляет с глаз человека несколько опасных операторов и подсовывает вместо них безопасные.
Так что все возможности языка бережно сохраняются и никуда не деваются.
Кроме одной, а именно: возможности совершить ошибку в операторах управления. С оговоркой: ДРАКОН не гарантирует полную защиту от ошибок.
И для этого совсем не нужно их хвалить.
Но они могут быть и низкоуровневыми.
Насчет уровня. Уровень дракон-алгоритмов выбирает разработчик.
Если разработчику нужен высокий уровень, он нарисует высокоуровневые дракон-алгоритмы.
Если разработчику нужен низкий уровень, он нарисует низкоуровневые .
Уровень — это не показатель качества, а степень абстракции, которая нужна разработчику.
Никогда не было сказано, что ДРАКОН дает 100%-ю гарантию. Такой гарантии он, конечно, не дает, и не может дать.
Вы, по-видимому, заметили, что ДРАКОН является развитием идей Эдсгера Дейкстры (структурное программирование) на случай визуального программирования.
Или нет?
В обсуждении появились замечания о сопоставлении ДРАКОНа и верификации.
Хочу объяснить принциальную разницу.
Верификация, без сомнения, замечательная вещь, и я обеими руками за верификацию.
Но. Верификация требует затраты дополнительного времени и дополнительных усилий.
Если таких возможностей нет (нет времени или жаль усилий) верификацию, естественно, не проводят.
Если кто-то желает привинтить к ДРАКОНу верификацию, — ради Бога! Нет никаких возражений. Флаг вам в руки.
Сегодня в ДРАКОНе нет верификации. А что есть? Есть автоматическое частичное доказательство правильности создаваемых дракон-алгоритмов с помощью аксиоматического метода.
Чем это отличается от верификации? Тем, что частичное доказательство правильности проводится полностью автоматически и не требует никаких дополнительных ресурсов. Иными словами, затраты дополнительного времени и дополнительных усилий НЕ ТРЕБУЮТСЯ.
Как говорится, солдат спит, а служба идет.
Причем пользователь (разработчик алгоритма), грубо говоря, не имеет никакого понятия о том, что где-то внутри программы ДРАКОН-конструктор каким-то чудом происходит самое настоящее математическое доказательство.
Здесь некоторые мои уважаемые оппоненты говорили о том, что читали мои книги и иронически при этом покрякивали по поводу моей дремучести.
Что тут скажешь?
«Этого-то товарищ Попандопуло и не учел, слона-то он и не приметил».
Но, скорее всего, получится с ошибкой. А на ДРАКОНе — без ошибок (почти без ошибок).
Я никогда не говорил (и не мог сказать), что ДРАКОН решает все.
Такие преувеличения можно встретить только у некоторых уважаемых оппонентов, участников нашей дискуссии, которые в отдельных случаях сплошь и рядом приписывают мне якобы сказанные мной различные несообразности.
1. Промышленные контроллеры — это важно.
2. Function Block Diagram — графический язык программирования стандарта МЭК 61131-3 для программирования программируемых логических контроллеров (ПЛК).
3. Для LabView имеются профессиональные инструменты, а для ДРАКОНа — всего лишь экспериментальные.
Но вы, к сожалению, отстали от жизни: «Дракон и в пометки не годится». При сравнении ДРАКОНа и FBD дело обстоит иначе — ровно наоборот.
Поясню.
Предприниматель Алексей Муравицкий, системный интегратор фирмы ОВЕН
использует ДРАКОН-технологию в нефтегазовой промышленности, пищевой промышленности, теплоэнергетике
для программирования ПЛК при разработке шкафов управления установками и насосами
1. На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании «Сургутнефтегаз» и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.
Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
2. На видео показан шкаф управления насосами объемного действия частотно-регулируемого электропривода на кустовой насосной станции Азнакаевского нефтегазодобывающего управления компании «Татнефть», где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН. Программа загружается в энергонезависимую память сенсорного программируемого контроллера СПК 107 фирмы ОВЕН.
В раздел 9. «Семейство ДРАКОН-языков» добавлен параграф
ДРАКОН — это новый способ работать с существующими языками программирования