Re[17]: Язык ДРАКОН — новая идея в программировании - Философия программирования

Здравствуйте, WolfHound, Вы писали:

V>>Смогла, просто отнесла полную грамматику языка к КЗ,
WH>Не смогла придумать, как их разбирать.

Никто не смог пока. Это нерешенная на сегодня проблема. В твоем TDOP обрабатывается лишь узкий подкласс, фактически частный случай. Потому что используется не обобщенный парсер, а вполне конкретный алгоритм разбора. Пусть даже настраиваемый и тебя эта настраиваемость маленько торкнула. Ради бога. Компиляторы С++ тоже имеют некий конкретный алгоритм разбора конкретных сценариев КЗ, как компиляторы любых КЗ-языков.

V>>но обязательно даже помимо грамматики есть семантика.
WH>Только к разбору текста она не относится.

Угу, аргумент про парсинг в условиях уже определенного "свыше" контекста и зависимостей ты проигнорировал.

WH>Ты даже не понимаешь на что способны КЗ грамматики.

Во-первых понимаю. Во-вторых — а толку, если их невозможно парсить в общем виде?

> V>Смогла, просто отнесла полную грамматику языка к КЗ,
> Не смогла придумать, как их разбирать.
>
> V>но обязательно даже помимо грамматики есть семантика.
> Только к разбору текста она не относится.
>
> V>Детсад, сорри.
> Детский сад.
> Ты даже не понимаешь на что способны КЗ грамматики.

Угу. Типичное пиписькомеряние. И не понятно, это разборки двух маленьких детей или двух толстых бородатых мужиков. Закинуть этот диалог на башорг?

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

V>Никто не смог пока. Это нерешенная на сегодня проблема. В твоем TDOP обрабатывается лишь узкий подкласс, фактически частный случай. Потому что используется не обобщенный парсер, а вполне конкретный алгоритм разбора. Пусть даже настраиваемый и тебя эта настраиваемость маленько торкнула. Ради бога. Компиляторы С++ тоже имеют некий конкретный алгоритм разбора конкретных сценариев КЗ, как компиляторы любых КЗ-языков.
А общий вид нахрен никому кроме теоретиков не нужен.
Ну и не забывай что если в языке есть требование объявления до использования то этот язык КЗ.

V>Угу, аргумент про парсинг в условиях уже определенного "свыше" контекста и зависимостей ты проигнорировал.
Нет там никаких аргументов. Одни заблуждения.

WH>>Ты даже не понимаешь на что способны КЗ грамматики.
V>Во-первых понимаю. Во-вторых — а толку, если их невозможно парсить в общем виде?
Не понимаешь. Иначе ты бы не говорил что невозможно задать КЗ грамматику для кода на C#.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, elmal, Вы писали:

E> мне не очень понятно, как организована обработка ошибок на практике. Ибо отказать может в любой момент любой датчик, любое реле, в результате обработка ошибок должна пронизывать алгоритм.

Вы правы. Обработка ошибок пронизывает алгоритм.

E> Если же думать о возможных ситуациях каждый раз, получается очень и очень запутанно и неструктурировано.

Нет, это не так. Никакой путаницы нет. Все структурно.
Структуризация понимается по правилам Дракона (двумерное структурное программирование), которое намного удобнее чем классическое (одномерное)структурное программирование).

Обработка ошибок на драконе выглядит очень просто, даже элементарно.
Любая, сколь угодно сложная обработка ошибок.
Я в этом случае не использовал бы термин "состояние".

Добавлю, что речь идет также о проверке и выявлении ошибок в троекратно резервированной системе.

Грани резервирования называются так:

— грань резервирования А,

— грань резервирования В,

— грань резервирования С.

Поэтому при проверке проверяются все сочетания:

А
В
С
АВ
АС
ВС
АВС

В частности, при проверке грани А компьютера Бисер, отключаются грани В и С компьютера Бисер.

при проверке грани В компьютера Бисер, отключаются грани А и С компьютера Бисер.

при проверке грани С компьютера Бисер, отключаются грани А и В компьютера Бисер.

при проверке граней А и В компьютера Бисер, отключается грань С компьютера Бисер.

И так далее.

При проверке и выявлении ошибок важную роль играет понятие ГЛАВНЫЙ МАРШРУТ (когда все хорошо и ошибок нет).

И правило: ГЛАВНЫЙ МАРШРУТ ИДЕТ ПО ШАМПУРУ

Все ошибки располагаются на побочных маршрутах, которые располагаются справа от главного маршрута.

Правило ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ.

Посмотрите здесь http://drakon-practic.ru/drakon.pdf

Шампур стр 13

Главный маршрут стр 14

Чем правее, тем хуже стр 15-17

Главный маршрут силуэта стр 21, 22

См. также стр 47 рис 42

стр 50 рис 45

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Все ошибки располагаются на побочных маршрутах, которые располагаются справа от главного маршрута.
ВП>Правило ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ.
Это понял. Но. Я в примерах увидел, что проверка на наличие ошибок указывается явно. И переход на побочный маршрут идет явно. Каждый раз явно нужно инициировать проверки, что легко забыть. Смотрим рисунок 45 — история с кашей. Мы вызываем алгоритм "Свари кашу". А далее проверяем возможные ошибки — каша подгорела или каша пересолена. Во первых, мы какую то ошибку можем пропустить, например это ошибка, что нам вместо сливочного масла дали машинное. Что в этом случае делать — еще одну проверку на основном маршруте, названное "непредвиденная ошибка"? Причем это делать на практике нужно всегда, ибо всегда может случиться, что выкинется что то такое, что я изначально не предполагал. Алгоритм "Свари кашу" может писаться другим человеком параллельно, он потом может изменения какие внести, не уведомив меня, и т.д. Есть ли валидация на случаи, что все возможные ошибки обработаны и сделан переход на побочный маршрут? Возможно я даже соглашусь, что такая запись достаточно наглядна, и вполне возможно, что лучше и не придумать. Но вот будет громоздковато ИМХО.

И далее. Что то мне подсказывает, что автогенеренный код будет просто ужасен, и его будет крайне проблематично читать текстом. А читать текстом в любом случае придется, ибо детали реализации даже если на схеме и будут показаны, то будут разбросаны на практике по разным листам. Мне, например, весьма интересно, как на практике алгоритм "Свари кашу" будет уведомлять родительский алгоритм о том, что каша подгорела. Явный возврат контекста, содержащего результат выполнения и возможные проблемы? Если такое делать для всех, то получим весьма неслабый оверхед. Глобальные переменные какие? Или не глобальные, а алгоритм представляет собой объект, у которого можно выполнить метод execute, а потом вернуть проблемы и результаты? А если мы генерим Фортран код?

Здравствуйте, Владимир Паронджанов, Вы писали:

C>>Т.е. как и предполагалось — ДРАКОН не используется для написания кода как такового, а только для рисования документации, по которой программисты с матом потом пишут код.
ВП>Уважаемый Алексей!
ВП>Вы ошибаетесь
Замечательно. Тогда не составит труда привести примеры кода, надеюсь? Скажем строк так на 10000? Уж за 25 лет-то можно было написать его.

Нет? Тогда мне доказательства "мамой клянусь!" неинтересны.

Да, моего OpenSource-кода примерно на порядок больше. Проприетарного кода — на полтора порядка.

Здравствуйте, WolfHound, Вы писали:

V>>Никто не смог пока. Это нерешенная на сегодня проблема. В твоем TDOP обрабатывается лишь узкий подкласс, фактически частный случай. Потому что используется не обобщенный парсер, а вполне конкретный алгоритм разбора. Пусть даже настраиваемый и тебя эта настраиваемость маленько торкнула. Ради бога. Компиляторы С++ тоже имеют некий конкретный алгоритм разбора конкретных сценариев КЗ, как компиляторы любых КЗ-языков.
WH>А общий вид нахрен никому кроме теоретиков не нужен.

Да, теоретикам нужен общий. Для естественных языков или близких к ним, например.

WH>Ну и не забывай что если в языке есть требование объявления до использования то этот язык КЗ.

С чего ты решил, что кто-то забыл? И вообще причем тут?

V>>Угу, аргумент про парсинг в условиях уже определенного "свыше" контекста и зависимостей ты проигнорировал.
WH>Нет там никаких аргументов. Одни заблуждения.

Отличные ответные аргументы.

WH>>>Ты даже не понимаешь на что способны КЗ грамматики.
V>>Во-первых понимаю. Во-вторых — а толку, если их невозможно парсить в общем виде?
WH>Не понимаешь. Иначе ты бы не говорил что невозможно задать КЗ грамматику для кода на C#.

В условиях переопределения операторов где-то в зависимых сборках? Ес-но невозможно. Потому что надо начинать говорить об ABI платформы и ее семантике, а это уже мимо парсинга.

На самом деле особых проблем с однозначным парсингом современных языков программирования ес-но нет. Потому что никто не зацикливается на самом автомате-парсере, как ты, а использует его лишь как часть более общего алгоритма разбора. И тогда ABI платформы или объявление типов "где-то еще" сразу перестает быть проблемой формальных грамматик. Пример фильтрации типов токенов при передаче их от лексера к парсеру для случая С++ я уже приводил. Тривиальная же операция.

Здравствуйте, grosborn, Вы писали:

G>И не понятно, это разборки двух маленьких детей или двух толстых бородатых мужиков.

Двух ленивцев, скорее.

G>Закинуть этот диалог на башорг?

Дык, было бы смешно, можно было бы закинуть.

Здравствуйте, samius, Вы писали:

S>Где же все-таки лежат данные?
S>Я полагаю что схема в ДРАКОН-е является грубым аналогом объекта в том плане что она является экземпляром, который хранит поля, необходимые для работы. Наверное это не совсем верно, т.к. под капотом схемы данные могут лежать и в глобальных переменных. Возможно схема есть аналог статической функции, которая принимает необходимые данные через набор параметров? Как вообще принято в ДРАКОН-е? Может это остается на откуп подкапотным программистам?

Не про дракон, но там, где я видел квадратики (workflow foundation, bpel), оно (весьма условно) работало так. Схема — экземпляр некоего класса, у него есть набор входных свойств (заполняется при вызове схемы), выходных свойств (нужно заполнить перед выходом) и просто свойств, которые хранят какое-то промежуточное состояние. Время жизни экземпляра — по инстансу на вызов. Квадратики в целом двух видов.
— Методы класса. То есть при входе в квадрат просто выполняется код с полным доступом к свойствам схемы. Сюда же, пожалуй, можно отнести всякие циклы и ветвления, которые работают со свойствами схемы.
— Инстансы других классов (другие схемы, точки входа в какое-то внешнее АПИ и т.п.). Перед входом в такой квадрат ты должен заполнить его входные свойства, после выхода можно работать с выходными.

Думается, что в драконе сделано что-то подобное.

Вы, че ? Это же просто блок-схемы, или уже есть компилятор ?
Да и ценность блок-схем плюс простое правило выделения одной ветки исполнения, сильно сомнительна,
кроме как студентам мозги вправлять, чтобы думали "алгоритмически".

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, samius, Вы писали:

S>>Где же все-таки лежат данные?

MC>Не про дракон, но там, где я видел квадратики (workflow foundation, bpel), оно (весьма условно) работало так. Схема — экземпляр некоего класса, у него есть набор входных свойств (заполняется при вызове схемы), выходных свойств (нужно заполнить перед выходом) и просто свойств, которые хранят какое-то промежуточное состояние. Время жизни экземпляра — по инстансу на вызов. Квадратики в целом двух видов.
WWF я тоже видел. Для "замены" языков общего назначения он явно не годится. Т.е. идеи типа "а давайте поиск в графе напрограммируем в квадратиках WWF" — явно бредовые. Даже для своей ниши, а именно программирования воркфлоу, (имхо) в большинстве случаев он уступает специальным велосипедам. Преимущества в нем лишь те, что он уже написан и работает, + имеет визуальный дизайнер из коробки.

MC>- Методы класса. То есть при входе в квадрат просто выполняется код с полным доступом к свойствам схемы. Сюда же, пожалуй, можно отнести всякие циклы и ветвления, которые работают со свойствами схемы.
MC>- Инстансы других классов (другие схемы, точки входа в какое-то внешнее АПИ и т.п.). Перед входом в такой квадрат ты должен заполнить его входные свойства, после выхода можно работать с выходными.

MC>Думается, что в драконе сделано что-то подобное.
Что-то мне кажется что ДРАКОН лишь генерит скелет из goto и старательно запихивает между ними код, вставленный в схему.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, novitk, Вы писали:

N>>И это даже не касаясь высказанной здесь многократно точке зрения о полной ненужности визуального программирования, как такового.

V>Высказывались люди, которые обобщали свой субъективный опыт и характер решаемых задач на отрасль в целом. Без комментариев, как говорится.

Я не очень понимаю, какую позицию ты отстаиваешь в споре с Cyberax-ом. Он вроде всего лишь выступает против применения визуального подхода по сравнению с текстовыми для решения реальных задач из за неадекватного инструментария с которым он имел "счастье" работать. Если у тебя есть другой опыт, расскажи. Только не абстрактно, а конкретно про используемые тобой инструменты и задачи.

Здравствуйте, elmal, Вы писали:

E>Это понял. Но. Я в примерах увидел, что проверка на наличие ошибок указывается явно. И переход на побочный маршрут идет явно.

Да, Вы правы. Все надо задавать ЯВНО.

E>Каждый раз явно нужно инициировать проверки, что легко забыть.

Слова «легко забыть» говорят о серьезной опасности.
Можно ли принять меры против этой опасности?

Да, можно. Для этого надо решительно отобрать эту работу у постороннего человека (программиста, потому что он не в курсе дела) и передать ее компетентному человеку, то есть инженеру.

Почему? Потому что первоисточником знаний является инженер. Инженер стоит на высшей ступени знаний. Он знает данный вопрос (как обрабатывать ошибки) намного лучше, чем программист. Программист получает знания от инженера.

В основе технологии Графит-Флокс лежит принцип:

КТО ОБЛАДАЕТ ЗНАНИЯМИ, ТОТ И ДОЛЖЕН ИХ ФОРМАЛИЗОВАТЬ.

Это принцип позволяет создать наиболее надежную защиту от такого несчастья, как «легко забыть».

Инженеры первичны, программисты вторичны. Знаниями обладает инженер, а не программист. Инженер разработал прибор. Например, прибор, выдающий команды на подрыв пироэлементов, которые разделяют ступени ракеты. Инженер не только разработал прибор, он его тщательно проверил. Никто лучше автора-инженера не знает этот прибор. Он знает его вдоль и поперек.

Вероятность того, инженер, автор прибора, сможет «легко забыть» свой собственный прибор на порядок меньше, чем у программиста, который знает прибор с чужих слов.

E>Смотрим рисунок 45 — история с кашей. Мы вызываем алгоритм "Свари кашу". А далее проверяем возможные ошибки — каша подгорела или каша пересолена. Во первых, мы какую то ошибку можем пропустить, например это ошибка, что нам вместо сливочного масла дали машинное. Что в этом случае делать — еще одну проверку на основном маршруте, названное "непредвиденная ошибка"? Причем это делать на практике нужно всегда, ибо всегда может случиться, что выкинется что то такое, что я изначально не предполагал.

Это дело инженера. Как он решит, так и правильно. Учтем также, что у инженера есть начальник лаборатории. Последнее слово за начальником лаборатории. Программисты здесь ни при чем. Если начальник лаборатории посчитает нужным, он может сходить к программистам посоветоваться. Но решение принимают не программисты, а инженеры. Никто лучше их не знает, какие могут быть ошибки и что с ними делать.

E>Алгоритм "Свари кашу" может писаться другим человеком параллельно, он потом может изменения какие внести, не уведомив меня, и т.д.

Этого не может быть. Работа распределена между отделами, а внутри отдела между лабораториями. Невозможно представить, чтобы какой-то партизан без разрешения начал действовать в чужом огороде.

E>Есть ли валидация на случаи, что все возможные ошибки обработаны и сделан переход на побочный маршрут?

Система управления ракетой разделена на функциональные тракты. Тракты поделены между инженерными лабораториями. Внутри тракта хозяин инженер.

Если есть какой-то системный вопрос, относящийся к системному программированию, тут командуют программисты. (Это упрощенная схема, бывают исключения из правила).

E>Возможно я даже соглашусь, что такая запись достаточно наглядна, и вполне возможно, что лучше и не придумать. Но вот будет громоздковато ИМХО.

Нет, это невозможно. На Драконе громоздко не бывает в принципе. Если какая-то ветка получилась громоздкой, ее всегда можно разделить на две или три ветки меньшего размера.

Если силуэт кажется перегруженным, его всегда можно разделить. Причем сделать это разными способами.

Ответ на Ваш второй абзац я дам позже

Мои ответы относятся только и исключительно к организации работ в НПЦАП при разработке системы управления ракет.

Здравствуйте, novitk, Вы писали:

V>>Высказывались люди, которые обобщали свой субъективный опыт и характер решаемых задач на отрасль в целом. Без комментариев, как говорится.

N>Я не очень понимаю, какую позицию ты отстаиваешь в споре с Cyberax-ом.

Как и он, делюсь субъективным опытом.

N>Он вроде всего лишь выступает против применения визуального подхода по сравнению с текстовыми для решения реальных задач из за неадекватного инструментария с которым он имел "счастье" работать.

Дык, это не так просто объяснить человеку.

N>Если у тебя есть другой опыт, расскажи. Только не абстрактно, а конкретно про используемые тобой инструменты и задачи.

PCAD, ORCAD, CIRCAD, LabView, Mathcad, Matlab+Simulink.
Проектирование, расчеты, симуляция, разработка налоговых и аналогово-цифровых устройств. Без графики эта работа невозможна принципиально. До этих тулзов всю графику чертили ручками.

Ну и берем тот же решарпер, вижуал-студию, графы профайлеров и VCS. В общем, здесь подробней:
http://www.rsdn.ru/forum/philosophy/4754685.1.aspx
http://www.rsdn.ru/forum/philosophy/4755042.1.aspx

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Ответ на Ваш второй абзац я дам позже
ВП>Мои ответы относятся только и исключительно к организации работ в НПЦАП при разработке системы управления ракет.
Хорошо, ок. Заодно еще один вопрос. Даже 2.
1) Итак — весьма много обязанностей возложено на инженеров. Прекрасно. Это мечта многих контор, если они с этими обязанностями наконец справляются благодаря Дракону — замечательно. Только как обстоят дела с тестированием? Ошибиться может любой. И особенно инженер, особенно тот, кто сам все проектирует. Ибо у него глаз может намылиться. Потому работу проектировщика в индустрии проверяет специальный человек — тестер, который всеми силами пытается найти ошибки. Дополнительно пишутся тесты, где моделируются все возможные крайние случаи, и пытаются таким образом обнаружить ошибки. Это делать должен не инженер — у него намылен глаз, ему эту работу поручать нельзя (вернее он конечно сам то проверит 10 раз перед сдачей, но он вполне может ошибиться и что то пропустить, человеческий фактор!). Тестировать должен совершенно посторонний человек — только так можно уменьшить вероятность ошибки. И тестировать и проверять не только визуально, но и автоматизированно — написав программу, которая будет прогонять все тесты.
Так вот — а как поставлено тестирование? Как проверяется корректность работы алгоритма в целом и отдельных мелких частей в частности? Это крайне важно в этой предметной области, здесь нужно многократно все проверять и перепроверять! Неужели просто методом пристального взгляда? Если нет, то как пишут тесты и тестируют — тоже на Драконе?
2) Итого, нужны инженеры высокой квалификации. Этим инженерам дали удобный для их работы инструмент. Прекрасно. Но есть у этого оборотная сторона, для программистов инструмент будет однозначно неудобен. Ибо программист работает не с алгоритмом, а с конкретным кодом, ему придется лазить в автогенеренный код, который, как мне представляется, оставляет желать лучшего. Более того, работа программистов весьма второстепенна. Как результат, программисты высокой квалификации не захотят этим заниматься, ибо очень большая рутина, очень неудобно работать, теряется квалификация из за очень многих ограничений, да и не могут они использовать на практике многие свои знания и умения. Соответственно тем, кто долго работает, в случае каких либо проблем сменить работу крайне проблематично, ибо они обладают крайне специфичными навыками. И в случае любых проблем, им урежут зарплату не задумываясь — так как один черт им проблематично сменить работу. Соответственно это очень многие понимают, многие этого опасаются, в результате согласятся программировать далеко не самые лучшие. А те, у кого квалификация низкая (недавние студенты, или те, кто просто долго был в стороне от современного течения индустрии, в результате обладают очень ограниченным кругозором) — те вполне могут допустить ошибку, тем более в случае, когда у них значительное недовольство работой.
Так вот, что то мне подсказывают, что инженерам Дракон нравится, а вот программисты, имеющие современный опыт хотя бы в минимальном объеме, весьма и весьма на это все матерятся.

> Только как обстоят дела с тестированием? Ошибиться может любой. И особенно инженер, особенно тот, кто сам все проектирует.

Вот кстати хорошее замечание. Могу указать на слабое место, которое и приводит к падению спутников. Есть условно говоря два вида тестирования этих комплексов, главная часть — тесты которые пишет инженер. Он тестирует функциональность, поведение и ряд параметров, по которым и определятся работоспособность блоков и системы в целом. Эти тесты это даже не одна, а ряд совершенно отдельных задач, которые выполняются еще и другими людьми. Инженер написал тесты, а другой может проектировать для него стенды и в свою очередь давать задание другим программистам для написания программы для испытаний.
И вторая часть — тестирование самой программы которую пишет программист. Вот тут косяк, программиста в этом деле обычно или не контролируют достаточно, или контролируют внутри отдела. А тесты реализаций алгоритмов не в комплексе с программой испытаний инженера. Инженер не может создать программу испытаний для программиста, программист в свою очередь не владеет темой в комплексе. И даже по ТЗ написав безошибочную программу, в работающем комплексе возникают ошибки и сбои.
И это косяк декомпозиции.

Posted via RSDN NNTP Server 2.1 beta

	От:	WolfHound
	Дата:	30.05.12 10:27
	Оценка:

От:	Владимир Паронджанов	http://drakon.su/ Форумы сайта http://forum.drakon.su
Дата:	30.05.12 11:50
Оценка:

	От:	elmal
	Дата:	30.05.12 12:06
	Оценка:

	От:	vdimas
	Дата:	30.05.12 12:36
	Оценка:

	От:	grosborn
	Дата:	30.05.12 12:58
	Оценка:

От:	lseder	lseder.livejournal.com
Дата:	30.05.12 15:05
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	30.05.12 16:05
Оценка: