DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 01:09

Часовой пояс: UTC + 3 часа




Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 79 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 18:19 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Цитата:
Для программистов, конечно, такие языки кажутся слишком упрощенными и не катят, но для инженеров они подходят — не слишком их перегружая новыми знаниями и требованиями.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 18:22 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 18:25 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
dmitriid писал(а):
Valery Solovey писал(а):
Предметник составляет алгоритм и передаёт его программисту, а программист для конкретных блоков пишет подпрограммы и в специальном редакторе соединяет конкретный блок схемы с написанной подпрограммой (или берёт из библиотеки, если она есть готовая).

То есть, по сути, как я тут уже где-то говорил, Дракон может использоваться для высокоуровневой записи алгоритмов по принципу диаграмм UML interaction/bahavior — это понятно.

Существует, правда, маааленькая проблема :) Заключается в «программист для конкретных блоков пишет подпрограммы». Вот тут вооот тааааакая собака может быть зарыта ;)
Только в отличие от UML, ДРАКОН-схема используется компилятором при компиляции. Программист не переписывает алгоритм, написанный другим инженером.

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

dmitriid писал(а):
Valery Solovey писал(а):
dmitriid писал(а):
Только вот операторы реального времени в драконе не имеют никакого отношения ни к реальному времени ни к параллельным вычислениям. Пауза, ждать, таймер к «реальному времени» не имеют отношения
А почему Вы так решили?

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

dmitriid писал(а):
Valery Solovey писал(а):
В реальных проектах, где используется ДРАКОН, просто обязаны иметься возможности выполнять действия асинхронно. Поэтому, с определённой долей уверенности можно говорить, что ДРАКОНа для этих целей хватает.
Параллельность там где-то неявно.

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

dmitriid писал(а):
Как, например, будет выглядеть аналог sequence diagram( диаграммы последовательности ) на Драконе?
Затрудняюсь ответить. Ни тем, ни другим не пользуюсь.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 18:47 

Зарегистрирован: Четверг, 14 Июнь, 2012 14:48
Сообщения: 36
Геннадий Тышов писал(а):
Еще рекомендую посмотреть блоги, указанные в сообщении

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

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


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

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


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

Valery Solovey писал(а):
Отнюдь не детский сад. Параллельная работа подразумевает (хотя бы в концепции, на логическом уровне) одновременную работу независимых цепочек команд. Асинхронность же этого не требует, достаточно только породить независимую цепочку команд.


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

Valery Solovey писал(а):
Что касается общения цепочек в асинхронном режиме, то здесь никаких абстракций на уровне языка не требуется, достаточно лишь общедоступного ресурса для обеих цепочек команд. Например, глобальной переменной.


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 18:50 

Зарегистрирован: Четверг, 14 Июнь, 2012 14:48
Сообщения: 36
Илья Ермаков писал(а):
А ещё не нужно забывать, что из таких языков идёт генерация для платформ с таким объёмом ОЗУ и возможностей, где вообще только на ассемблере удавалось иногда писать... Например, у той платформы, для которой идёт генерация из ГРАФИТа, нет аппаратной поддержки стека (!).


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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 19:05 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
dmitriid писал(а):
Да, я в курсе. Но в этом заслуга не Дракона/Графита, а целевого языка, в который идет компиляция, и программистов, которые программируют реализацию блоков для связывания в Драконе ;)


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 19:09 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
dmitriid писал(а):
Здесь я не совсем согласен. Мы или очерчиваем сферу применимости сразу, или перестаем выдвигать заявления
Это язык для представления алгоритмов. В программировании используются алгоритмы, следовательно, ДРАКОН можно с пользой использовать в программировании. Но не на любых задачах.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 23:02 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Valery Solovey писал(а):
язык для представления алгоритмов. В программировании используются алгоритмы, следовательно, ДРАКОН можно с пользой использовать в программировании. Но не на любых задачах

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 23:22 

Зарегистрирован: Четверг, 14 Июнь, 2012 14:48
Сообщения: 36
Илья Ермаков писал(а):
ГРАФИТ - не "связующий слой". У него есть текстовый синтаксис, т.е. содержание "квадратиков": операции присваивания, арифметики, ввода-вывода. Декларации хранятся в табличном виде в БД.


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

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

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

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


Последний раз редактировалось dmitriid Суббота, 16 Июнь, 2012 23:27, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Суббота, 16 Июнь, 2012 23:26 

Зарегистрирован: Четверг, 14 Июнь, 2012 14:48
Сообщения: 36
TAU писал(а):
7. В отличие от визуальных языков, используемых в основном на этапах анализа бизнес-процессов организаций, постановки задачи по созданию автоматизированных систем, проектирования информационных систем (IDEF0, IDEF1X, UML, DFD, ER), ГРАФИТ/ФЛОКС - именно вместе - позволяют получать на выходе готовую к прошивке в память бортовой ЭВМ исполнимую программу в машинном коде.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 00:28 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
TAU писал(а):
Давайте рассмотрим несколько положений и вопросов.
Вот моё мнение.
TAU писал(а):
1. 2. 3. 4.
Да, на ДРАКОНе возможно написать любую программу.
TAU писал(а):
5. Является ли применение визуального подхода Паронджанова оптимальным по сравнению с использованием других языков и методик, для любых видов программ?
Лично мне не кажется, что оптимально будет для любой программы. ДРАКОН делает явным понятие перехода между командами. Например, обе ветки IF находятся через одинаковое количество переходов от условия. Это сильно помогает в местах, где этих переходов много(и ветки не из одного-двух операторов состоят). Наверно, ещё можно придумать кучу других примеров... Но если переход и так подразумевается и виден в тексте обычной программы, то ДРАКОН-схема как минимум не лучше, а возможно и хуже, поскольку излишне разрежает текст программы.
TAU писал(а):
6. Уместно ли и полезно визуальное программирование при создании систем логического управления?
Из тех абстрактных примеров, которые у меня появляются в голове, кажется, что полезно.
TAU писал(а):
7. В отличие от визуальных языков, используемых в основном на этапах анализа бизнес-процессов организаций, постановки задачи по созданию автоматизированных систем, проектирования информационных систем (IDEF0, IDEF1X, UML, DFD, ER), ГРАФИТ/ФЛОКС - именно вместе - позволяют получать на выходе готовую к прошивке в память бортовой ЭВМ исполнимую программу в машинном коде.
Согласен. Я тоже это хотел сказать парой постов выше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 00:35 

Зарегистрирован: Четверг, 14 Июнь, 2012 14:48
Сообщения: 36
Valery Solovey писал(а):
Да, на ДРАКОНе возможно написать любую программу.

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 00:49 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
dmitriid писал(а):
Если не на любых задачах, но в программировании, то мои комментарии остаются в силе:
- Мы или очерчиваем сферу применимости сразу, или перестаем выдвигать заявления о Драконе, как о панацее
В программировании (чаще в кодировании) его тяжело назвать панацеей. А в алгоритмике он как минимум не хуже других средств (особенно, если наделять блоки смыслом не в виде математических понятий, а простыми словами).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 00:53 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
dmitriid писал(а):
Rational Rose, Visual Studio, Altova UModel (и так далее, их десятки) для генерации кода из UML
Насколько я помню, после генерации из UML работа не заканчивается, а только начинается.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 00:56 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
dmitriid писал(а):
единственный способ синхронизации, который он предоставляет (из того, что мне удалось увидеть), — через глобальные переменные.
Чтобы два потока могли связаться друг с другом, они должны иметь общий ресурс. Он глобален для этих двух потоков. Переменная это или очередь сообщений - не важно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 01:15 

Зарегистрирован: Четверг, 14 Июнь, 2012 14:48
Сообщения: 36
Valery Solovey писал(а):
Так что, если не зацикливаться только на кодинге, то пользы от него прибавится. Например, получать от заказчика алгоритм не в письменном виде, а в виде схемы.

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

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

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

Valery Solovey писал(а):
Чтобы два потока могли связаться друг с другом, они должны иметь общий ресурс.

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

Valery Solovey писал(а):
Он глобален для этих двух потоков. Переменная это или очередь сообщений - не важно.


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

Процитирую также отсюда:
elmal писал(а):
Паронджанов писал(а):
Ответ такой. Уведомлять родительский алгоритм о том, что каша подгорела, НЕ НУЖНО. Поскольку все идентификаторы глобальные. Путаница не возникает. Потому что префикс наводит строгий порядок и задает четкое распределение ответственности.

Вот что то подобное я и предполагал. Дело не в путанице. Дело не в разделении ответственности. Глобальные идентификаторы — это крайне ужасно. Про параллелизм можно забыть сразу. А современная тенденция в программировании, и задача, которую не могут пока достаточно эффективно решить — это как максимально делать алгоритмы параллельными. В случае с глобальными идентификаторами хотя бы состояний — без шансов. Как мне сварить параллельно N каш? Да и даже если без параллелизма — тоже будут весьма интересные эффекты при многократном вызове какого либо алгоритма из разных мест.
И это даже мелочь. По сравнению с тем, что любой может случайно по невнимательности изменить значение. Или, я надеюсь, не может, и эти идентификаторы только на чтение, и устанавливать их можно только в том месте, где они определены? Хотя бы есть правило на ограничения доступа? Что родитель имеет доступ только к идентификаторам только непосредственно тех алгоритмов, который он только что вызвал? Если так, небольшое облегчение конечно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 05:03 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
dmitriid
Цитата:
...
и пусть устанут руки, и глазами
я не смогу ни строчки боле прочитать,
узнайте, други, флудер – с вами
и до скончанья дней он будет здесь писать!
http://rsdn.ru/forum/philosophy/4781586.1.aspx - "К чему бы это?"

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 12:18 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
dmitriid писал(а):
Илья Ермаков писал(а):
ГРАФИТ - не "связующий слой". У него есть текстовый синтаксис, т.е. содержание "квадратиков": операции присваивания, арифметики, ввода-вывода. Декларации хранятся в табличном виде в БД.


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 12:18 

Зарегистрирован: Четверг, 14 Июнь, 2012 14:48
Сообщения: 36
Геннадий Тышов писал(а):
http://rsdn.ru/forum/philosophy/4781586.1.aspx - "К чему бы это?"

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

Геннадий Тышов писал(а):
Dmitriid, к чему бы это Вам Дракон понадобился?

Если бы ваш нимб позволял бы вам читать и понимать, что я пишу, вы бы увидели это:
dmitriid писал(а):
И вот я здесь. Потому что меня интересует все новое (или хорошо забытое старое), что связано с программированием.

И вообще, все это сообщение: 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 (и прочитал всю тему по ссылке).
Вопросы все равно остались. Но вы же не собираетесь отвечать хоть на один из них, так ведь?

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Про сложные задачи в Драконе
СообщениеДобавлено: Воскресенье, 17 Июнь, 2012 12:32 

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


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

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

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

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

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

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 79 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB