Справка

ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ

Язык ДРАКОН успешно используется во многих космических программах:

• разгонный блок космических аппаратов ДМ-SL (проект «Морской старт»);

• разгонный блок космических аппаратов «Фрегат» (включая Фрегат-СБ, Фрегат-МТ, Фрегат с модернизированной системой управления);

• модернизированная ракета-носитель тяжелого класса «Протон-М»;

• разгонный блок космических аппаратов ДМ-SL-Б (проект «Наземный старт»);

• разгонный блок космических аппаратов ДМ-03;

• первая ступень для южнокорейской ракеты-носителя легкого класса KSLV-1 (Korean Space Launch Vehicle);

• ракета-носитель легкого класса Ангара 1,2;

• ракета-носитель тяжелого класса Ангара-А5;

• разгонный блок космических аппаратов КВТК (кислородно-водородный тяжелого класса) и др.

Космодромы:

Плавучий космодром, производящий пуски с экватора в Тихом океане (экваториальная зона вблизи острова Рождества Республики Кирибати (с координатами 154 градуса западной долготы и 0 градусов широты)),

Байконур,

Плесецк,

Европейский космический центр во Французской Гвиане "Kuru" (Южная Америка),

Южнокорейский космодром "Naro".

Нет, ну совести совсем нет, зачем же так бессовестно вводить людей в заблуждение.

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

V>>Дык, сейчас всё хуже, насколько я вижу. Посади даже 15-тилетнего ребенка за комп и попроси написать аналогичную программу и засеки время. Ответ я знаю заранее.
C>В 15 лет я уже писал программы в тысячи строк кода (на С++). Первую программу я написал в 9 лет (на Бэйсике).

Охотно верю. Все-равно, ты бы не вложился в 20-30 мин, даже имея такой опыт на тот момент. Ответ я знаю заранее, потому что вижу "молодых и одаренных" в компьютерных кружках и вижу как они пишут программы: добавили несколько строк — запускают смотрят. Поправляют. Потом опять. Фактически процесс написания программы состоит из исправления багов в каждой 5-й строчке или даже чаще. Откровенная печаль.

А у меня опыт был — 2 раза урока информатики до этого.. И скорость печатанья, прямо скажем, отличается от нынешней. Просто потратил около 30 мин на диаграмму дома и чуть более 20 мин на ее набивку на уроке. И всё заработало сразу.


V>>Т.е. даже берем один графический язык — схем электрических принципиальных, и видим кучи редакторов разной степени удобства.
C>Электрические схемы — это по своей сути графическая вещь. Но вот сложные схемы всё как-то сейчас в виде текста описывают.

Тебя обманули. Описывают булевскую однородную логику, и больше ничего.

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

G>Нет, ну совести совсем нет, зачем же так бессовестно вводить людей в заблуждение.

У тебя есть информация, подтверждающая твои инсинуации? Поделись.

Здравствуйте, Cyberax, Вы писали:
C>Получается непонятная шизофрения — с одной стороны инжинеры должны описывать алгоритм на некотором почти-формальном языке, а с другой стороны программисты должны по этому намалёванному непотребию потом делать что-то работающее. Я прямо отсюда слышу их матюки.
А то. Ад как он есть. Тем не менее, подозрительно популярная тема: bpmn/bpel таки продаются за большие бабки, MS в своем шарепоинте тоже предписывает всем срочно садиться рисовать согласование документов в визио.

Что интересно, между собой программисты вроде как уже научились подобным образом делить работу. Взять тот же эрланг: внизу си и низкоуровневый мрак, а сверху довольно милый язык описания системы в виде процессов. Или драйвер каких-нибудь типичного устройства (я не большой спец по ним, но сложилось такое впечатление): сидит в фиксированном окружении, преобразует входящие запросы в вызовы АПИ. Их вроде еще не рисуют в виде квадратиков, зато сравнительно успешно верифицируют (на основе все тех же автоматов, т.е. фактически перегоняют в квадратики).

Ну и тут вот еще из геймдева примеры приводились.

Во всех этих примерах, правда, на верхнем уровне находится нечто более сложное, чем просто блок-схема, там получается набор точек входа, отвечающих за разные возможные внешние воздействия. Осталось понять, есть ли что-то подобное в драконе. Тут, я думаю, у нас ничего не выйдет, потому что автор темы — очевидный (зеленый) андроид, отвечает исключительно копипастой из книг.

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

ВП>Справка
ВП> ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ
Не верю. Попрошу ссылку, скажем, с сайта РКК "Энергия" о том, где конкретно используется ДРАКОН.

А то я тоже много чего написать могу.

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

ВП>Справка

ВП> ПРИМЕНЕНИЕ ЯЗЫКА ДРАКОН В РАКЕТНО-КОСМИЧЕСКОЙ ОТРАСЛИ

<skipped>

Приведите, пожалуйста, доказательства. Скажем, ссылки на официальные сайты упомянутых организаций, где будет написано, что ими применяется Дракон.

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

ВП>Вы совершенно правы, на простых алгоритмах дракон не дает выигрыша.
ВП>Но в сложных случаях дело обстоит иначе.
Кстати о сложных случаях. Со всей этой декомпозицией мы забыли спросить одну интересную вещь — а как делается обработка ошибок? Я не увидел обработки ошибок ни на одной из диаграмм. Итак, предположим мы пишем софт управления атомной станцией. И хотим следующее — чтобы в случае абсолютно любых ошибочных ситуаций заглушать реактор. Это настолько важно, что это все требуется на на диаграмме верхнего уровня! Что любая непредвиденная ситуация — заглушаем реактор. Эта любая непредвиденная ситуация может вылететь откуда угодно из нижестоящего сабалгоритма. То есть интересует в языке такая полезная вещь, как исключения. Итого — как это будет на Драконе? Я приблизительно догадываюсь, что на главной диаграмме сверху будет состояние ошибка, в которую мы можем переходить из других состояний. Но ... любой прямоугольничек может у нас выкинуть исключение. Даже функция проверки условия может выкинуть исключение (предположим, там датчик какой оказывается неисправным). Как будем поступать? Более того, обработчик ошибки очень интересуется деталями, в зависимости от того, что за ошибка, он захочет принять решение, стопать ли реактор или нет, или попытаться переключиться на резервный контур и проверить все еще раз. Как будет выглядить алгоритм в этом случае? Что то мне подсказывает, что будет очень неслабое усложнение схемы на ровном месте. И если исключения поддерживаются — очень интересует, как будет генерироваться программа на фортране, где на момент последнего с ним знакомства исключениями и не пахло?

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

V>>Эта "махинация" позволяет составлять запросы даже тем, кто плохо владеет языком SQL
WH>И где тут SQL?
WH>Может хватить прыгать по темам.
WH>Или сказать совсем нечего?

Ты спросил об SQL, я напомнил.

V>>или только начинает его изучать. Я наблюдал как девочки оперативно накидывали в MS Access полезные запросы в графике буквально на 2-3-й день его изучения, не зная языка SQL.
WH>А я видел девочек которые на С++ пишут лучше многих тут присутствующих.

Твоя фраза ничего не подтверждает, а моя подтверждает, что в 100% наблюдений за одним и тем же сценарием видно, что людям удобней было начать знакомиться с языком SQL через его графическое отображение в дизайнере запросов.

V>>И видел, как они постепенно изучали тем самым этот SQL до приемлимого уровня, видя во что именно преобразуется графическое представление.
WH>А с чего ты взял, что за те же 2-3 дня они бы SQL не осилили?

Потому что было показано как переключаться в SQL и как опльзоваться справкой, по SQL в т.ч. Не получается за 2-3 дня выдавать правильно работающие запросы. Зато переключают в MS Access из текста в режим дизайна и моментально находят ошибки.

Не боись, именно языку SQL и учил, бо возможности дизайнера в MS Access ограничены. С 0-ля — это месяцы, чтобы полноценно пользоваться SQL, и то только у двух получалось. Остальные дальше графики не прошли. Так что, я наблюдал тот самый "порог вхождения" воочию.

И ты вообще неправильно рассуждаешь изначально, меряя всех под одну гребенку. Я тоже пользовался дизайнером исключительно для того, чтобы без ошибок синтаксиса быстро накидать в запрос нужные таблицы и поля из них, потом переключался в текст и формулировал, что мне там надо. Это потому что до знакомства с Access я неплохо знал SQL и владел реляционной алгеброй. Т.е. всего рассказанного я бы так и не узнал, если бы не наблюдал затем лично за теми, кто не знал SQL. И вот тут эффект от дизайнера запросов был, я не побоюсь этого слова, потрясающий. Я аж проникся.


WH>>>Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.
V>>Это в любом случае надо понять, даже в виде БНФ или любой другой нотации.
WH>Сравнил блин.
WH>В нормальной нотации нужно запомнить всего один оператор.

Для этого надо уметь представлять в голове, как работает оператор повтора и что при этом происходит с выражением. Я наблюдал аналогичное для языка регулярных выражений (не перловских, а автоматных), там точно такие же примитивы повтора. Дык только на графах многие и понимали, что получается в итоге.


WH>Кстати как в твоей графике будет выглядеть запись того что правило нужно повторить от 5 до 10 раз?

А бывают такие правила?
В БНФ подобное делается через иерархическое выражение одних правил через другие. Т.е. Повторить8 может быть определено через Повторить7 и целевое тело.


V>>Ну и ок. Т.е. мы согласны обсуждать только Немерле, а на остальное плевать. На том и порешим.
WH>Причем тут немерле? Совсем аргументов нет?

На "мне плевать на IBM"? Ес-но нет и не будет. Не понравился пример — я не при чем.


V>>Да пообщался я с вами в той фейерической ветке про БНФ. Поржал, спасибо. Редкостная каша в голове.
WH>Сказал адепт секты, которая, не смотря на свою многочисленность, за 50 лет не смогла создать ни одного алгоритма годного для промышленного применения.

Алгоритмов море, бери любой. Странной была попытка взять один из алгоритмов и претендовать с ним на универсальность. Это же просто язык описания работы конкретного низлежащего автомата разбора. Пусть даже очень хорошего автомата, но конкретного. Какая тут нафик универсальность? Именно необходимость объяснять это и повеселила.

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

V>Твоя фраза ничего не подтверждает, а моя подтверждает, что в 100% наблюдений за одним и тем же сценарием видно, что людям удобней было начать знакомиться с языком SQL через его графическое отображение в дизайнере запросов.
А я изучил SQL за день по MSDN.
А от дизайнера запросов всегда плевался.

V>Для этого надо уметь представлять в голове, как работает оператор повтора и что при этом происходит с выражением. Я наблюдал аналогичное для языка регулярных выражений (не перловских, а автоматных), там точно такие же примитивы повтора. Дык только на графах многие и понимали, что получается в итоге.
Зачем тут граф? Не понимаю.

WH>>Кстати как в твоей графике будет выглядеть запись того что правило нужно повторить от 5 до 10 раз?
V>А бывают такие правила?
Любые.

V>В БНФ подобное делается через иерархическое выражение одних правил через другие. Т.е. Повторить8 может быть определено через Повторить7 и целевое тело.
И получаем 10 правил на ровном месте.
При однозначной трансляции в граф получи гору квадратиков.

V>>>Ну и ок. Т.е. мы согласны обсуждать только Немерле, а на остальное плевать. На том и порешим.
WH>>Причем тут немерле? Совсем аргументов нет?
V>На "мне плевать на IBM"? Ес-но нет и не будет. Не понравился пример — я не при чем.
А что мне должно вот в этом понравиться?

Создание задания без преобразования
 
>>-onpladm create job--задание--+-------------+-- -n------------>
                                '- -p--проект-'
 
>-- -d--устройство-- -D--база данных-- -t--таблица-------------->
 
   .---------------------------------------------------------------------------.
   V                                                                           |
>----+-----------------------------------------------------------------------+-+-><
     |                                                                  (1)  |
     '-+-------------+--+-----------------+--| Задание режима запуска |------'
       '- -S--сервер-'  '- -T--назначение-'

Это трудно читать.
Трудно писать.
И озвереешь при написании компилятора.

V>Алгоритмов море, бери любой.
Все говно.

V>Странной была попытка взять один из алгоритмов и претендовать с ним на универсальность. Это же просто язык описания работы конкретного низлежащего автомата разбора. Пусть даже очень хорошего автомата, но конкретного. Какая тут нафик универсальность? Именно необходимость объяснять это и повеселила.
Ни один из этих алгоритмов не используется в больших компиляторах и ИДЕ.
И это факт.

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

C>Не верю. Попрошу ссылку, скажем, с сайта РКК "Энергия" о том, где конкретно используется ДРАКОН.

Выше совершенно правильно перечислены проекты системы управления которых делал ФГУП «НПЦАП» (Центр Пилюгина). Все следы использования этого Дракона в ракетно-космической отрасли ведут туда. А вот в какой степени и с какой целью этот Дракон используется там действительно интересно было бы узнать. Пока складывается ощущение что исключительно для документирования ТЗ.

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

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

ВП>> ЧЕТЫРЕ ВИДЕОУРОКА НА YOUTUBE
ВП>>по 15 минут каждый

N>Посмотрел 10 минут ролика. В чем отличие этой программы от LabView?

Тем, что Вы о Драконе узнали только что. Или чуть раньше.
Однако, хотя за давностью лет их можно считать ровесниками, Дракон будет постарше. Годика этак на 3-4.

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

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


LVV>>ИМХО потому, что Владимир Даниэлович практически 25 лет с языком работает. На этом зыке проектировалась управляющая система Бурана.
LVV>>А в 90-х он, наконец, вышел из под секретности.
LVV>>Как препод могу сказать, что некоторым студентам и почти всем студенткам гораздо проще посмотреть на картинку алгоритма, чем на текст алгоритма. Для рисования сложных алгоритмов Дракон подходит как нельзя лучше.
B>Я работал разработчиком системы старта и технического обслуживания Бурана. (конкретно пульт управления моя разработка). Ни сном ни духом про Дракон. У нас был свой язык ЭЛИДО. Так это такое говно. Макросы обычные. Про существование синтаксиса и терии трансляторов наше техническое руководство тогда просто не доходило уровнем. Хотя были и в Подлипках и у Пилюгина по пол года не вылазили с полигонов..

А я как раз работал у Пилюгина. В аккурат с 80 по 89. И про Дракон, и про использование его в проектировании ИСУ слышал неоднократно. Хотя сам не пользовал, бо с другого конца был — автоматизация обработки ТМИ.
А отец у меня работал у Рязанского. Они для Бурана стряпали БИТЦ. Про Дракон если и слышали, то только в пол уха. Бо в каждой конторе в тем времена свои порядки и законы.

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

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

V>>>>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.
C>>>Бурановский программист в теме уже отметился и сказал, что они ничерта про ДРАКОН не знают.
V>>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
C>Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.

Ну и зря

Автор: kig
Дата: 28.05.12

C>Никаких независимых подтверждений его слов нет. Так же как и вообще известного софта или работающих реализаций самого языка.

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

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

V>>Почему многие сразу принимаются за критику, толком не разобравшись?
V>>Причина банальна — любая новая технология угрожает уже имеющимся специалистам, ведь им как минимум, надо понять что она из себя представляет, оценить насколько она может конкурировать с их собственной, какие задачи на ней возможно решаются лучше, и в конечном итоге — может быть даже заняться ее изучением.
C>У нормальных специалистов нет проблем с изучением очередной рвотной массы типа ДРАКОНа. В нём нового — ровно ноль. Обычный простой императивный язык, коих десятки тысяч.

C>До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?

Это ты думаешь, то ДО. А на самом деле — ПОСЛЕ.

V>>Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.
C>Имеет — в качестве посмешища.

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

V>>>Он сказал что он бурановский программист, он на обслуживающей инфраструктуре был — пульты делал.
C>>Я не верю, что на ДРАКОНе было что-то вообще работающее написано (в документации мог использоваться). Скорее всего, его автор просто врёт.
kig>Ну и зря

Автор: kig
Дата: 28.05.12

Так, а теперь для чего конкретно он использовался. Я всё ещё не верю, что на нём писали сколь-либо заметное количество (если вообще) работающего кода.

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

C>>У нормальных специалистов нет проблем с изучением очередной рвотной массы типа ДРАКОНа. В нём нового — ровно ноль. Обычный простой императивный язык, коих десятки тысяч.
C>>До ДРАКОНа были Together, Rational Rose и прочие гадости. Кто-то их помнит?
kig>Это ты думаешь, то ДО. А на самом деле — ПОСЛЕ.
Пофиг. Ключевое слово здесь — "были".

Они пиарились на всю индустрию, но люди быстро их выкинули, когда до всех дошло, что неправильные картинки неправильно работают.

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

WH>Это трудно читать.
WH>Трудно писать.
WH>И озвереешь при написании компилятора.

Это потому что в псевдографике. В чистой графике поприличнее. Смотрел ANTLRWorks?

И никто не пишет компиляторы прямо по ТЗ. А где же стадия анализа? А где стадия преобразования эквивалентных синтаксических граф-схем? А как же регуляризация грамматики? ))


V>>Алгоритмов море, бери любой.
WH>Все говно.

Есть разная степень подходящести алгоритма под класс грамматики. Просто ты всячески пытаешься отнекиваться от объективного фактора — разделения грамматик на классы. Пытаешь делать вид, что такого в природе не существует. А ведь LL(1) или LR(1) работают фактически со скоростью лексера. Т.е. там, где достаточно этих классов грамматики, нет смысла применять что-то другое. А GLR, помимо того, что полностью покрывает КС-грамматики, дык еще является "оперативным", выполняющим максимум работы на каждом символе и без откатов, что делает его очень удобным для грамматик огромных по размерам документов (на многие мегабайты). Парсеры с откатами на таких сценариях не взлетают.


V>>Странной была попытка взять один из алгоритмов и претендовать с ним на универсальность. Это же просто язык описания работы конкретного низлежащего автомата разбора. Пусть даже очень хорошего автомата, но конкретного. Какая тут нафик универсальность? Именно необходимость объяснять это и повеселила.
WH>Ни один из этих алгоритмов не используется в больших компиляторах и ИДЕ.
WH>И это факт.

Используется нейтральное БНФ для описания спецификаций независимо от подробностей реализации компилятора. А ты собрался эти подробности вытащить на уровень спецификаций. Тем самым ты собрался прибить гвоздями спецификацию к реализации... Это конфуз, коллега. Неужели история с ПЕГ тебя не научила, что всегда может найтись чуть лучшее решение, чем было использовано до этого?

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

kig>Тем, что Вы о Драконе узнали только что. Или чуть раньше.
kig>Однако, хотя за давностью лет их можно считать ровесниками, Дракон будет постарше. Годика этак на 3-4.

Я о нем узнал вчера, но мы не в политике и меня слабо интересуют вопросы исторического первенства. Какие преимущества дает Дракон по сравнению с LabView сегодня?

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

(конкретно пульт управления моя разработка). Ни сном ни духом про Дракон. У нас был свой язык ЭЛИДО. Так это такое говно. Макросы обычные. Про существование синтаксиса и терии трансляторов наше техническое руководство тогда просто не доходило уровнем. Хотя были и в Подлипках и у Пилюгина по пол года не вылазили с полигонов..

kig>А я как раз работал у Пилюгина. В аккурат с 80 по 89. И про Дракон, и про использование его в проектировании ИСУ слышал неоднократно. Хотя сам не пользовал, бо с другого конца был — автоматизация обработки ТМИ.
kig>А отец у меня работал у Рязанского. Они для Бурана стряпали БИТЦ. Про Дракон если и слышали, то только в пол уха. Бо в каждой конторе в тем времена свои порядки и законы.
Во.. Может даже и встречались Ну, а про слухи это дело такое. Наши тоже щеки надували на свои разработки..А было все тупо как двери. Но работало..