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

V>И никто не пишет компиляторы прямо по ТЗ.
Я пишу.

V>А где же стадия анализа? А где стадия преобразования эквивалентных синтаксических граф-схем? А как же регуляризация грамматики? ))
Этот бред нужен только твоей секте.

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

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

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

Вы совершенно правы. НПЦАП — ведущее предприятие Роскосмоса по автономным СУ ракетно-космической техники.

Сам Пилюгин (1908 — 1982) видел цели так:

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

Я работаю в Пилюгинском центре всю жизнь (с 1961 года).
Участвовал в разработке СУ как баллистических ракет, так и космических проектов.

В разработке Бурана участвовал с первого до последнего дня. В тот период я был начальником лаборатории комплексной разработки вычислительной системы Бурана.

В 1986 года мой начальник Ю.В. Трунов (впоследствии Генеральный конструктор ФГУП "НПЦАП") поручил мне создать единый язык программирования вместо трех (Прол2, Диполь, ЛАКС), использоваавшихся при проектировании СУ Бурана.

Работа длилась примерно 11 лет, в ней участвовало около десяти человек, в частности из ИПМ РАН, и закончилась только в 1996 году.
______________________________

P> ... складывается ощущение что Дракон используется исключительно для документирования ТЗ.

Это не так. Инженеры фактически пишут программы (хотя они не знают об этом).
Посмотрите внимательнее на структуру технологии. Слева написано
«Программирование без программистов». Это не пустые слова.
http://drakon.su/_media/biblioteka/grafit_a4.pdf

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

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

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

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




Ну а у Владимира Даниловича Дракон "взлетел". Сначала в "детском" варианте на Буране. А затем, как я в курсе, в самые голодные годы работа не прекращалась. И сейчас пользуется у Пилюгина.

Так многие здесь, вместо того, что бы хотя бы проявить уважение, что не все пошло в корзину, что благодаря и вопреки, не зная, когда это начиналось, не зная, что эта разработка ровесник с LabView, обсирают со всей дури и задают дурацкие вопросы, "почему я labview знаю, а Дракона — нет".

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

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

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

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

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

здесь

Автор: Владимир Паронджанов
Дата: 29.05.12

Или опять будешь брызгать слюной про вранье?

Кстати, а по поводу LabView (здесь уже высказывалось мнение, что это очень похожие разработки), побрызгать не хочешь? Что это отстой ну и т.п. А заодно побрызгать в сторону Apple, ведь первая версия LabView как раз для яблока была зарелийзена?

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

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

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

N>Я о нем узнал вчера, но мы не в политике и меня слабо интересуют вопросы исторического первенства.

Вот так и появляются "Иваны, не помниющие родства". Конкретно, в данном случае, в IT.

N>Какие преимущества дает Дракон по сравнению с LabView сегодня?

Тем, что используется у Пилюгина. В чем и как — здесь уже перечисляли.

И потом, на кой хер, я должен, даже сейчас пусть и умозрительно, поддерживать ЧУЖУЮ разработку, если есть НАША?

Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Язык Дракон значительно облегчает алгоритмизацию и программирование...
ИМХО, как средство визуализации, это классная вещь. Как инструмент разработки, не очень, т.к. большинство людей мыслят словами, соответственно выражать мысли словами им проще и удобней.

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


B>>Во.. Может даже и встречались Ну, а про слухи это дело такое. Наши тоже щеки надували на свои разработки..А было все тупо как двери. Но работало.

kig>


kig>Ну а у Владимира Даниловича Дракон "взлетел". Сначала в "детском" варианте на Буране. А затем, как я в курсе, в самые голодные годы работа не прекращалась. И сейчас пользуется у Пилюгина.

kig>Так многие здесь, вместо того, что бы хотя бы проявить уважение, что не все пошло в корзину, что благодаря и вопреки, не зная, когда это начиналось, не зная, что эта разработка ровесник с LabView, обсирают со всей дури и задают дурацкие вопросы, "почему я labview знаю, а Дракона — нет".
Я сказал что тупо, но работало. Для инженера это и есть уважуха. Наше тоже запустило.. И тоже уважуха.. Но надо же смотреть вперед.. В наше время это уже вчерашний день..Я не задаю дурацкие вопросы у меня уже есть сравнительно умные ответы..
Алгоритмов самих по себе не бывает. Он состоит из шагов. Определяя эти шаги можно сделать из не разрешимого аглоритма разрешимый.. Но это теория.. А практически отсюда следует что алгоритм без определения этих шангов вообще ничто. Заниматься этим "ничто" глупо. Но можно. Можно даже получить практический результат, но я этим заниматься не хочу по вышеуказанным причинам. Занимающимся этим моя не уважуха!
Перевожу на бытовой язык. Когда ребенок произносит слово "мама" это вызывает гордость.. Но если он в 25 лет кроме этого ничего не произносит это дебилизм.

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

N>>Я о нем узнал вчера, но мы не в политике и меня слабо интересуют вопросы исторического первенства.
kig>Вот так и появляются "Иваны, не помниющие родства". Конкретно, в данном случае, в IT.
ТС вроде апеллировал к техническим преимуществам языка, а не к патриотизму. Впрочем скорее всего в вопросе первенства ты тоже не прав.

kig>И потом, на кой хер, я должен, даже сейчас пусть и умозрительно, поддерживать ЧУЖУЮ разработку, если есть НАША?
Может тогда заодно и "Наше Усе" Эльбрус откопаем? Судя по ролику Дракон отстает от LabView на сравнимое число человеко-лет. И это даже не касаясь высказанной здесь многократно точке зрения о полной ненужности визуального программирования, как такового.

Выскажусь и я.

Возьмём обычную книгу. Вся книга — текст. Запомнится ли по прочтении весь текст книги дословно? Конечно, нет. Если в книге будет несколько рисунков (или схем, графиков, диаграмм), то как раз они запомнятся.

Возьмём книгу комиксов (или мангу). Вся книгу — рисунки. Запомнятся ли по просмотру все рисунки? Опять же, нет. А вот немногочисленный текст в данном случае запомнится лучше.

Думаю, вывод очевиден: бессмысленно сравнивать небольшую блок-схему, UML-схему, схему Дракона с текстом большой программы.
Следует пояснять код (в текстовом виде) небольшим количеством диаграмм/схем/рисунков — это будет способствовать пониманию. Но абсолютно всё в виде рисунков/схем — затруднит понимание.


P.S.
Хотелось бы задать вопрос апологетам Дракона: если язык так хорош, то где написанный вами софт? Покажите реальные примеры, которые можно запустить и поиметь профит. Ведь по вашим утверждениям процесс программирования упрощается на порядки, значит софт должен клепаться как горячие пирожки на конвейере. Так где он, написанный лично вами?

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

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

Автор: Владимир Паронджанов
Дата: 29.05.12

kig>Или опять будешь брызгать слюной про вранье?
Не верю. Я так и не дождался ссылок на авторитетные источники.

Тем более, что если работа была закончена в 96-м году.

kig>Кстати, а по поводу LabView (здесь уже высказывалось мнение, что это очень похожие разработки), побрызгать не хочешь? Что это отстой ну и т.п. А заодно побрызгать в сторону Apple, ведь первая версия LabView как раз для яблока была зарелийзена?
Мне на него пофиг — его не пихают как панацею для всего. В своих нишах графические редакторы даже могут быть удобны — с этим никто и не спорит.

Но вот когда устаревшую на 50 лет идеологию пихают как панацею против всего, да ещё и напрямую студентам — нет уж.

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

kig>обсирают со всей дури и задают дурацкие вопросы, "почему я labview знаю, а Дракона — нет".

Вопрос был другой и без всяких обсираний.

В чем отличие этой программы от LabView?

Просто большинство не знающих Дракон, включая меня, испытывает трудности с пониманием терминологии автора, поэтому я привел широкоизвестный пакет для понимания ниши. Ты вроде подтвердил, что у LabView с Драконом разницы особой нет. Однако некоторые утверждения автора говорят о другом, например:

Существующие способы записи алгоритмов и программ (принятые во всем мире) слишком трудны для понимания и требуют неоправданно больших трудозатрат.

Поэтому очень хотелось бы услышать его комментарии. Если Дракон лицензирован под ОSS и имеет нормальную IDE и кодогенератор, возможно он был бы интересен.

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

V>>И никто не пишет компиляторы прямо по ТЗ.
WH>Я пишу.

Значит, такое ТЗ.


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

Приоритеты операторов задают семантику не влияя на синтаксис. EBNF не предназначен для задания семантики.

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

V>Приоритеты операторов задают семантику не влияя на синтаксис. EBNF не предназначен для задания семантики.
И этот человек говорит про кашу в голове.
Если брать полный синтаксический анализ. Включая то, что твоя секта записала в семантический, ибо не смогла формализовать. То станет ясно, что в общем случае (a + b) * c и a + (b * c) могут иметь разные типы. И как следствие одна строка может принадлежать языку, а вторая нет.
Таким образом, приоритеты операторов часть синтаксиса.

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

ВП>Я работаю в Пилюгинском центре всю жизнь (с 1961 года).
ВП>Участвовал в разработке СУ как баллистических ракет, так и космических проектов.

Вызывает совершенно искренний интерес и уважение.

Но вернемся к Дракону.
ВП>Это не так. Инженеры фактически пишут программы (хотя они не знают об этом).
Вы им об этом так и не сказали?

ВП>Посмотрите внимательнее на структуру технологии. Слева написано
ВП>«Программирование без программистов». Это не пустые слова.
ВП>http://drakon.su/_media/biblioteka/grafit_a4.pdf

Первый вопрос из тех что вызвала картинка — программист в процессе отладки может исправлять ошибки, что логично иначе его роль совсем непонятна — транслятор, кодогенератор и компановщик могут быть вызваны без участия человека. И что, после исправления этих ошибок ГРАФИТ и ФЛОКС-данные нужно сгенерировать вновь для их исправления? Тогда в схеме не показаны обратные связи делающие её совсем не такой красивой и простой. То, что не показаны совсем не простые (не поймёшь когда с программистом, а когда с остальными инженерами) обратные связи с этапом отработки программ очевидно.

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

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

V>>Приоритеты операторов задают семантику не влияя на синтаксис. EBNF не предназначен для задания семантики.
WH> И этот человек говорит про кашу в голове.
WH>Если брать полный синтаксический анализ. Включая то, что твоя секта записала в семантический, ибо не смогла формализовать.

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

WH>То станет ясно, что в общем случае (a + b) * c и a + (b * c) могут иметь разные типы. И как следствие одна строка может принадлежать языку, а вторая нет.

Детсад, сорри. В рамках техники парсинга текста даже на КЗ-парсере это невозможо разрулить в общем случае. Например, имеем некий файл-исходник в C#. Включая его в разные проекты, с разными определениями одних и тех же идентификаторов-типов для упомянутых переменных a, b и c, как в соседних файлах-исходниках проекта, так и через зависимые сборки, мы можем получать разную семантику и как следствие — принадлежность к языку или нет.

(В этом плане С++ более последователен, т.к. должен описывать через #include зависимости конкретной единицы компиляции явно.)


WH>Таким образом, приоритеты операторов часть синтаксиса.

Для C# это не так ввиду того, что типы оперируемых переменных могут быть объявлены "где-то еще" — в зависимых сборках. Т.е. даже фокус с "тупой" склейкой всех файлов проекта, чтобы рассуждать о чисто текстовой стадии разбора — не поможет. В итоге это "где-то еще", этот контекст, не может быть обработан самим парсером ни в одной из техник, весь этот контекст дается "свыше" и называется общим словом "семантика".

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


P>Первый вопрос из тех что вызвала картинка — программист в процессе отладки может исправлять ошибки, что логично иначе его роль совсем непонятна — транслятор, кодогенератор и компановщик могут быть вызваны без участия человека. И что, после исправления этих ошибок ГРАФИТ и ФЛОКС-данные нужно сгенерировать вновь для их исправления? Тогда в схеме не показаны обратные связи делающие её совсем не такой красивой и простой.

Итеративность может быть процессом более высокого уровня. Но для каждого этапа разработки, т.е. для каждой итерации, схема может быть именно такой — однонаправленной. Сравни с RUP.


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

Наоборот, к этому во многих отраслях и идет. И чем больше IT будет покрывать областей знаний, тем больше будет идти разделение на специалиста-прикладника и программиста. Ты прав только касательно небольших проектов, которые выполняются маленьким кол-вом разработчиков — порядка 5+-, где о выделенном аналитике не может быть и речи.

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

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

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

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

V>Это реальный язык, на котором программируют люди, далекие от профессионального программирования. На нем Буран сделали и он полетел. А современные "профессиональные программисты" наверняка бы уронили, к бабке не ходи.

Обращаюсь к vdimas-у, а не к автору топика Владимиру, потому как терминология vdimas-а мне ближе и понятнее, возможно vdimas и меня поймет скорее.

На сколько я понял из топика (а специально не интересовался), в ДРАКОН-е не очень гладко с функциональным программированием. Собственно, оно и понятно, т.к. ФП записывает алгоритмы в терминах преобразования данных, а ДРАКОН записывает шаги/активности и их ветвление, то есть в крайней степени императивен.

Вопрос в том, а где же в ДРАКОН-е хранятся и ходят данные под капотом? Взять тот же факториал. Шаги — оно понятно, из каких шагов состоит вычисление. Как записывается передача данных от шага к шагу? Или это записывается "под" схемой во вставках на языке генерируемых исходников? Если это так, то боюсь, что глядя на схему, может возникнуть непонимание алгоритма. В случае факториала — фиг с ним, т.к. алгоритм тривиален. А в более сложных случаях? Ну например, depth-first-search, или генератор перестановок?

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

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

P>Первый вопрос из тех что вызвала картинка — программист в процессе отладки может исправлять ошибки, что логично иначе его роль совсем непонятна — транслятор, кодогенератор и компановщик могут быть вызваны без участия человека. И что, после исправления этих ошибок ГРАФИТ и ФЛОКС-данные нужно сгенерировать вновь для их исправления? Тогда в схеме не показаны обратные связи делающие её совсем не такой красивой и простой. То, что не показаны совсем не простые (не поймёшь когда с программистом, а когда с остальными инженерами) обратные связи с этапом отработки программ очевидно.

Вы правы — картинка неполная.
Это реально работающая технология, имеющая сложную структуру. Объяснить ее в рамках форума невозможно.
Сделаю лишь главные пояснения.

1. Технология предназначена для разработки программ для компьютера Бисер, разработанном во ФГУП «НПЦАП».
Бисер — трехкратно резервированный компьютер, сохраняющий работоспособность при любом одном отказе аппаратуры.

2. Компьютер Бисер устанавливается на борту ракеты в качестве бортовой ЦВМ (БЦВМ). А также на земле в составе НКСУ (наземный комплекс системы управления).
Наземный Бисер называется НЦВМ.

3. Справа на картинке есть квадратик «Программа формирования модели памяти». На нашем жаргоне «модель памяти» — это то, что до начала работы (до начала режима) загружается в компьютер Бисер.

4. В НЦВМ и БЦВМ загружаются совершенно разные программы (разные модели памяти). Кроме того, они отличаются для РАЗНЫХ РЕЖИМОВ работы.

5. Что такое режим работы?
Для простоты дам пояснения на примере наземного комплекса системы управления.

6. Наземный комплекс СУ обеспечивает проведение режимов работы, необходимых для испытаний, подготовки и пуска ракеты:

• режим регламентных испытаний;

• режим защитных операций;

• режим проверочных включений;

• режим комплексных испытаний;

• режим предстартовой подготовки.

7. Режимы осуществляются в соответствии с принятой технологией на всех рабочих местах: КИС, ТК и СК.

• КИС — контрольно-испытательная станция космодрома

• ТК — технический комплекс космодрома

• СК — стартовый комплекс космодрома

8. Все режимы работы выполняются автоматически с помощью НЦВМ Бисер и БЦВМ Бисер.

Чтобы запустить режим, оператор выполняет ограниченное число ручных операций:

• включает наземный комплекс СУ;

• в диалоговом режиме выбирает нужный режим;

• выдает команду на начало автоматического выполнения режима;

• после этого процессы проверок и подготовки выполняются наземным комплексом СУ и бортовой СУ автоматически.

9. Вернемся к картинке. Все исправления ошибок идут только через инженеров. Программист не может сам тайком от инженера исправить ошибку. Это может быть только по договоренности с инженером.

10. Инженеры делают только прикладные программы, но не системные.

11. Системные программы делают только программисты.

12. Инженер не может вызвать транслятор, анализатор, кодогенератор и т.д. самостоятельно — это непосильный для него труд. Он и слов таких не знает. И он не в состоянии понять листинги результатов. Здесь без программистов не обойтись.

13. Распределение работ между инженерами и программистами — это тонкая материя. Если угодно, это наука. (Пока еще не созданная и никем не описанная). Я владею азами этой науки только на основании опыта.

14. Приведу пример. ФЛОКС — это описание структур данных. Эти структуры создают инженеры на понятном для них языке. Программисты заносят флокс-описания в реляционную базу данных ФЛОКС.

Однажды возник вопрос: Кто должен выпускать документацию на базу данных ФЛОКС?

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

Я решительно воспротивился. Потому что все идентификаторы, вся начинка базы создается инженерами.
Кроме того, я не очень доверяю программистам, когда речь идет о выпуске документации.

Чем дело кончилось?

Я придумал новый документ под названием «Флокс-формуляр», попросил отдел нормализации и стандартизации узаконить его.

Документ был узаконен в Головном институте нашей отрасли ЦНИИмаш. И вступил в законную силу.

Теперь инженеры при выпуске полного комплекта документации для каждой новой проектируемой ракеты обязательно выпускают и комплект флокс-формуляров, описывающих содержание базы данных ФЛОКС .

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

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

ВП>13. Распределение работ между инженерами и программистами — это тонкая материя. Если угодно, это наука. (Пока еще не созданная и никем не описанная). Я владею азами этой науки только на основании опыта.
Как всё запущено...

Т.е. как и предполагалось — ДРАКОН не используется для написания кода как такового, а только для рисования документации, по которой программисты с матом потом пишут код.