DRAKON.SU

А ещё не нужно забывать, что из таких языков идёт генерация для платформ с таким объёмом ОЗУ и возможностей, где вообще только на ассемблере удавалось иногда писать... Например, у той платформы, для которой идёт генерация из ГРАФИТа, нет аппаратной поддержки стека (!).
Сейчас в стране, конечно, уже есть отличные современные процессоры (Элвисовские Мультикоры, например, из класса DSP, или Эльбрус-3М из серии универсальных), но менять проверенные временем устройства на новые - лишний риск... Особенно с учётом того, что ту же БЦВМ "Бисер" НПЦАП собирает сам.
Не говоря про то, что в условиях жёстких излучений меньшая степень интеграции и меньшая плотность размещения ячеек памяти только на пользу.

dmitriid
Еще рекомендую посмотреть блоги, указанные в сообщении http://forum.easyelectronics.ru/viewtopic.php?p=157840#p157840

Только в отличие от UML, ДРАКОН-схема используется компилятором при компиляции. Программист не переписывает алгоритм, написанный другим инженером.

Собака может быть зарыта, а может и не быть. Вполне допускаю, что этот момент предсказуем, и алгоритмисты следят за их отсутствием. Но гарантировать не могу, поскольку ДРАКОНом не пользуюсь.

Сначала Вы поделитесь своими соображениями. Касательно реального времени, не затрагивая параллелизма. Я поделюсь своим мнением позже.

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

Затрудняюсь ответить. Ни тем, ни другим не пользуюсь.

Спасибо, посмотрю (вечером или завтра)



Есть такие инструменты и для UML (например, Rational Rose). Только вот при наличии схемы «открой замок, закрой замок» автоматической компиляции не получится ни в UML ни в Драконе



Возможно, просто используются разные термины с одинаковым названием. Для меня реальное время — все, что связано с [url=http://ru.wikipedia.org/wiki/Реальное_время]реальным временем[/url]. Таймеры и паузы — это таймеры.



«деский сад» это было про «неявный параллелизм». Если мы говорим только о асинхронных командах, которые не зависят друг от друга и не влияют друг на друга, то простого «запустили, пусть выполняется» достаточно. Но далеко не всегда. В Erlang'е, например, есть такие вещи, как деревья контроля, которые следят за выполнением процессов. Просто в многопоточном программировании есть процессы/потоки, обменивающиеся сообщениями и т.п. Поэтому я и говорю, что «неявный параллелизм» — это мало



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



Как вы описываете взаимодействие слабо связанных (loosely coupled) компонентов? Хотя, возможно, это выходит за рамки сферы применимости Дракона (нельзя иметь один инструмент на все )

Да, я в курсе. Но в этом заслуга не Дракона/Графита, а целевого языка, в который идет компиляция, и программистов, которые программируют реализацию блоков для связывания в Драконе

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

Нет, Валерий неправильно описал процесс.
ГРАФИТ - не "связующий слой". У него есть текстовый синтаксис, т.е. содержание "квадратиков": операции присваивания, арифметики, ввода-вывода. Декларации хранятся в табличном виде в БД. В НПЦ АП программисты вообще не участвуют в написании управляющих программ, они занимаются только системными вещами - диспетчер реального времени, библиотека системных процедур, ПО для отработки на стенде и проч.

Это язык для представления алгоритмов. В программировании используются алгоритмы, следовательно, ДРАКОН можно с пользой использовать в программировании. Но не на любых задачах.

Уважаемый Валерий,

Давайте рассмотрим несколько положений и вопросов.
1. Что значит термин "любая задача" в программировании? Вероятно, для создания баз знаний и экспертных систем лучше подойдет Пролог или другой язык логического программирования, чем Фортран или ассемблер. Можно ли написать на Фортране или ассемблере базу знаний? Думаю, большинство согласится, что в принципе можно.
2. Стандартные блок-схемы алгоритмов позволяют описывать в принципе любые императивные алгоритмы? Думаю, большинство согласится, что да.
3. Предложенная Паронджановым методика уж не хуже стандартизированных блок-схем, без сомнения. Он внес в нее целый ряд эргономических улучшений.
4. В связи с вышесказанным - можно ли использовать методику Паронджанова для описания любых императивных алгоритмов?
5. Является ли применение визуального подхода Паронджанова оптимальным по сравнению с использованием других языков и методик, для любых видов программ?
6. Уместно ли и полезно визуальное программирование при создании систем логического управления? Вероятно, широкое применение графических языков Grafcet, SFC, LD, FBD в мире при создании подобных систем в достаточной степени обосновывает это положение. Дает ли в определенной мере подобный подход возможность приблизиться к "программированию без программистов"? Безусловно, да - и мы имеем ряд успешных примеров в отечественной космической отрасли. Даже больше - в некоторых организациях, создающих критические приложения, блок-схема может входить в состав обязательно требуемой части программной документации.
7. В отличие от визуальных языков, используемых в основном на этапах анализа бизнес-процессов организаций, постановки задачи по созданию автоматизированных систем, проектирования информационных систем (IDEF0, IDEF1X, UML, DFD, ER), ГРАФИТ/ФЛОКС - именно вместе - позволяют получать на выходе готовую к прошивке в память бортовой ЭВМ исполнимую программу в машинном коде. Являясь именно истинной системой графического программирования. Что касается интегрированных систем разработки, основанных на методике Паронджанова и публично доступных, совсем недавних и активно развивающихся в настоящее время - среды Тышова и среды Митькина (за их бескорыстный труд мы можем лишь сказать им огромное спасибо), можно отметить, что и в них предусматривается автоматическая генерация программы. Причем на самых разных языках - алгоритм остается одинаковым, и всего лишь несколькими нажатиями клавиш можно получить программу на другом языке! Это и ассемблеры, и Си, и С++, и С#, и Оберон, и 1С, и Erlang! Практически на всех активно используемых в промышленном программировании. Некоторые известные среды, позволяющие генерировать программы по диаграмме классов и иногда по диаграмме состояний UML, далеки от подобного богатства возможностей.

Это что касается программирования.

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

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

Я к тому, что описания, тексты — это хорошо, но все равно есть момент, когда это надо связывать с реальным миром.


Если не на любых задачах, но в программировании, то мои комментарии остаются в силе:
- Мы или очерчиваем сферу применимости сразу, или перестаем выдвигать заявления о Драконе, как о панацее (см. это обсуждение на RSDN. Ну хотя бы например)
- Если Дракон применими в программировании, то у программистов будут возникать вопросы, которые есть в самом первом сообщении этого топика (кстати, совсем забыл про вот такой вопрос про параллелизм и глобальное состояние. Естественно, без ответа).

Вау. А люди делали Rational Rose, Visual Studio, Altova UModel (и так далее, их десятки) для генерации кода из UML, и не знали, что их не существует

Вот моё мнение.
Да, на ДРАКОНе возможно написать любую программу.
Лично мне не кажется, что оптимально будет для любой программы. ДРАКОН делает явным понятие перехода между командами. Например, обе ветки IF находятся через одинаковое количество переходов от условия. Это сильно помогает в местах, где этих переходов много(и ветки не из одного-двух операторов состоят). Наверно, ещё можно придумать кучу других примеров... Но если переход и так подразумевается и виден в тексте обычной программы, то ДРАКОН-схема как минимум не лучше, а возможно и хуже, поскольку излишне разрежает текст программы.
Из тех абстрактных примеров, которые у меня появляются в голове, кажется, что полезно.
Согласен. Я тоже это хотел сказать парой постов выше.

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

На любом Тьюринг-полном языке можно написать любую программу. Единственный вопрос — целесообразность.

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

Но при этом он вполне может использоваться для описания конечных автоматов.

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

Так что, если не зацикливаться только на кодинге, то пользы от него прибавится. Например, получать от заказчика алгоритм не в письменном виде, а в виде схемы. Во-первых, исчезнет неточность формулировок. А во-вторых, проще будет понять, по чьей вине что-то там не работает.

Насколько я помню, после генерации из UML работа не заканчивается, а только начинается.

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

С этим не спорю, но неизбежно появятся вопросы про сравнение с другими визуальными средствами (тем же UML)


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


Нет, не должны



Нет, важно. В том же Erlang'е очередь сообщений у каждого процесса(потока) своя. И вообще, в параллельном программировании стремятся вообще не иметь разделяемых данных (та же модель акторов и т.п.). Но это я повторяюсь. Если Дракон не может предоставить такую модель, то в дизайне параллельных вычислений он неприменим.

Процитирую также отсюда:

dmitriid
http://rsdn.ru/forum/philosophy/4781586.1.aspx - "К чему бы это?"

Dmitriid, к чему бы это Вам Дракон понадобился?
Когда и откуда Вы узнали о существования языка Дракон?
Что Вы знаете о Драконе? Кроме ракетно-космических технологий.
Какие книги В.Д. Паронджанова Вы прочитали?
Собираетесь ли Вы прочитать все книги В.Д. Паронджанова?

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

Простая констатация фактов. Или вы считаете, что разговор, который ведете вы и TAU, конструктивен и предметен? Что хамство, менторский тон, попытка перевести разговор на обсуждение моей личности, игнорирование любых моих вопросов — это корректный и предметный разговор?


Если бы ваш нимб позволял бы вам читать и понимать, что я пишу, вы бы увидели это:

И вообще, все это сообщение: viewtopic.php?f=78&t=3992&start=20#p73144


Только то, что доступно в интернете. В интернете доступно мало, а на мои вопросы, например, вы и TAU упорно отказываетесь отвечать.
Как там TAU сказал? «У меня нет соответсвующего уровня доступа, чтобы знать про реальные алгоритмы на Драконе».
На данный момент я прочитал все ответы Паронджанова, перечисленные тут: viewtopic.php?f=62&t=1276#p22068 и два с половиной сообщения, на которые вы меня отправили читать тут: http://forum.easyelectronics.ru/viewtop ... 40#p157840 (и прочитал всю тему по ссылке).
Вопросы все равно остались. Но вы же не собираетесь отвечать хоть на один из них, так ведь?

Не бывает глупых вопросов, бывают глупые ответы. К несчастью, от вас я даже таких не увидел.

Давайте с вами проведем один простой эксперимент. Я задам ровно один вопрос, а вы на него ответите, так, разнообразия ради.

Итак. Дракон позиционируется, как язык для представления любой сложности. Более того, его достаточно активно пиарили для решения задач, связанных с «обыкновенным программированием». Почему вы считаете заданные мной в первом сообщении некорректными и отказываетесь на них отвечать?

Еще раз. Такая схема работает только если:
1. у нас уже есть запрограммированная база объектов
2. у нас уже есть реализация этих объектов
3. у нас система, способная сгенерировать на основе описания этих объектов код для этих объектов

Пункт 2 и 3 должен был быть выполнен хотя бы до того, как инженеры начали двигать квадратики. Код из воздуха не появляется.

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

Теперь возьмем «обычное программирование». Откуда возьмется база объектов ФЛОКС? Откуда возьмется реализация этих объектов? Откуда возьмется знание, как генерировать код из «квадратиков» Дракона в целевой язык?

В качестве примера можно привести Drakon Editor (огромное спасибо Степану Митькину). Вместо того, чтобы манипулировать квадратиками в стиле «открыть окно, нажать кнопку, поместить квадрат в координатах XY» приходится писать полупсевдокод. «Полу» потому что призодится писать именно что код на целевом языке программирования, только заменяя условные переходы и циклы Драконом. База объектов «окно, диалог, рисунок, квадрат» магическим образом же не появится

Вот я о чем говорю.

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