DRAKON.SU

Текущее время: Воскресенье, 26 Июнь, 2022 21:03

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




Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Четверг, 30 Апрель, 2009 11:35 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 234
Откуда: Украина, Киев
Владимир Паронджанов писал(а):
ЕСЛИ МЫ РАБОТАЕМ, НАПРИМЕР НА ДРОНе,
ТО ЗАЧЕМ НАМ ЛЕЗТЬ С ПРАВКАМИ В ACTIVE OBERON?
Вы абсолютно правы! Текст в ACTIVE OBERON получаемый из ДРОНа должен быть гарантированно безошибочным, т.е. все необходимые правки должны заключаться лишь в правках содержимого икон. Другое дело, некоторые топологические конструкции может быть проблематично представить в ACTIVE OBERON.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Четверг, 30 Апрель, 2009 14:41 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Рэйлвэй Каген писал(а):
Евгений Темиргалеев: "..если работать по более мягкому принципу правки при разработке.."
-- В пределах иконы текст линейный. Все отступления от этого правила - как использование SYSTEM в Обероне. Можно, но небезопасно. И как только возникает потребность применить/изменить структурную конструкцию - лучше изменять двумерный исходник, а не править промежуточное представление.
Если я Вас правильно понял, то Вы говорите о записи в иконах операторов, относящихся к маршрутной части языка. Такого я не предлагал.
Владимир Паронджанов писал(а):
Вопрос к Евгению Темиргалееву
Если можно, поясните мне, зачем нужна работа "по более мягкому принципу"?
Поясню вопрос. Программист, который работает на ЯВУ, очень редко лезет в ассемблерный текст. Он может просто не знать ассемблер.
...
Суть моего вопроса: ЕСЛИ МЫ РАБОТАЕМ, НАПРИМЕР НА ДРОНе, ТО ЗАЧЕМ НАМ ЛЕЗТЬ С ПРАВКАМИ В ACTIVE OBERON?
Ассемблер большинство программистов скорее всего не знает. Но ЯВУ, на которых они пишут - знают. Они привыкли писать текстом (в т.ч. и я). Вот про этот контингент я говорю.

Сказать однозначно, что всё подряд, от начала и до конца, рисовать на ДРАКОНЕ мне будет удобнее, я сейчас не могу. Нужно опытное сравнение. Для такого сравнения, я полагаю, нужен редактор, который умеет отображать схемы в структурный текст и аналогичный текст обратно в схемы. Чтобы я мог править и так и так. При этом я знаю правила трансляции туда-сюда; на текст наложены ограничения (соотв-е правилам преобразования схема->текст, чтобы было возможно взаимнооднозначное преобразование).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Четверг, 30 Апрель, 2009 15:42 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Рэйлвэй Каген писал(а):
Было бы весьма приятно иметь возможность плоского представления указанных связей, раз уж линейная запись для них существует. Но не в рамках Дракона, а рядом - в качестве равноправной компоненты IDE, взаимодействующей в Дракон-схемами.
Именно так! То есть основная идея у меня состояла не в том, чтобы совсем заменить традиционный язык программирования Драконом, а в том, чтобы дополнить им средства разработки программ. Ну и в рамках этого подхода задача трансляции дракон-схем в объектный код уже не столь актуальна. Получается как бы два уровня проектирования: верхний -- определяет структуру будущего модуля, взаимосвязь сущностей модуля; и нижний -- собственно декларации и код процедур.
Работа в такой системе должна выглядеть примерно так. Программист открывает Дракон-схему и обозревает структуру модуля, читает информативные заголовки веток, написанные на естественном языке. Затем, если решает поработать с кодом (нижний уровень), получает к нему доступ путём активации нужной иконки на схеме.
А вот где проводить границу между Драконом и исходным кодом -- это вопрос. С одной стороны все ключевые моменты модуля должны быть отражены на схеме, с другой стороны схема не должна быть засорена утомительными подробностями.
Опять же подчеркну, что говорю всё это на уровне идеи. Пока не ясно нужна ли вложенность схем, или действовать по принципу "один модуль -- одна схема".
Можно пойти дальше, использовать схемы в IDE не только для представления модулей, но и всего проекта. Иконки, соответствующие модулям и сущностям модуля, снабдить ссылками на соответствующие разделы справки.
Вобщем, перспективы практического использования языка Дракон в программировании я вижу именно в симбиозе этого языка с традиционными языками программирования в рамках конретной IDE.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Четверг, 30 Апрель, 2009 17:24 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Евгений Темиргалеев писал(а):
..Такого я не предлагал.
Гм.. Это скорее я неправильно понял Ваше предложение в части, когда "надо думать про структурность текста" и принялся долонить про линейный текст в иконах и т.д..
Попробую исправить ответ - переключаться в линейную текстовую модель можно, но всё-таки лучше думать о структурности именно наверху - в двумерном исходнике и с более мощными средствами её обеспечения. Получается, что "мягкий принцип правки" теряет смысл: текст иконы мы и наверху видим, а править что-то, учитывая структурные конструкции сразу в промежуточном представлении - можно, но небезопасно. А при получении некорректной структуры на промежуточном уровне тоже тащить её в Дракон? Чтобы он лишний раз рявкнул? Тогда надо грузить верхний уровень задачами обнаружения ошибок промежуточного представления, но по-моему такая постановка процесса разработки ошибочна.

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


Последний раз редактировалось Рэйлвэй Каген Четверг, 30 Апрель, 2009 18:59, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Четверг, 30 Апрель, 2009 17:52 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
igor писал(а):
Программист открывает Дракон-схему и обозревает структуру модуля..
На Дракон-схеме не может быть отражена структура модуля. Причину я пытался объяснить в ответе на первое Ваше сообщение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Четверг, 30 Апрель, 2009 20:25 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Рэйлвэй Каген писал(а):
На Дракон-схеме не может быть отражена структура модуля.
Соглашусь с Вами только отчасти. По какому принципу мы обычно разбиваем весь исходный код проекта на модули? По функциональному! Приведу в качестве примера сканер из подсистемы Dev в Блэкбоксе. "Маршрут", о котором Вы говорили, здесь явно просматривается. Аналогично с другими модулями, которые выполняют какую-либо определённую функцию (или группу тесно взаимосвязанных функций). Если же модуль не выполняет чётко очерченной функции, то скорее всего этот модуль спроектирован неудачно.
Но соглашусь с Вами, что аналогично можно привести пример вполне удачно спроектированных модулей, для отображения которых Дракон не очень-то подходит. Например, модуль Math -- это просто библиотека почти не связанных друг с другом математических функций. Здесь, как говорится, шампуром и не пахнет :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Пятница, 01 Май, 2009 07:59 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Ещё поразмышлял :)
Сама возможность использовать язык Дракон для описания структуры модуля, является, пожалуй, скорее исключением, чем правилом. И в этом смысле Рэйлвэй Каген совершенно прав. Получается, что идея использовать для описания структуры любых модулей язык Дракон в чистом виде, является в целом несколько натянутой. Это разумеется не означает, что задача сохранения проектной метаинформации о модулях в IDE в хорошо структурированном виде перестала для меня быть актуальной. Взамен, так сказать, допотомным текстовым описаниям. Но, во-первых, это будет уже оффтоп. Во-второых, я сейчас подробно обсуждать эту тему не готов, так как занят в другом проекте, который отнимает почти всё свободное время.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Пятница, 01 Май, 2009 13:41 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Игорь, Вы оставьте в покое сам Дракон, а вот его топологию связей попробуйте... Может и заработать для выражения каких-то связей (даже обязано работать в нек. случаях, скажу Вам; но в других случаях за уши притягивать не надо :) ).
Я б и сам подумал на эту тему, но пока мысли в другом направлении заняты :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Пятница, 01 Май, 2009 22:55 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Ярослав Романченко писал(а):
Вы абсолютно правы! Текст в ACTIVE OBERON получаемый из ДРОНа должен быть гарантированно безошибочным

Ну конечно! В этом одно из главных преимуществ подобной технологии программирования.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Пятница, 01 Май, 2009 23:37 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Рэйлвэй Каген писал(а):
Владимир Даниелович, по поводу использования GOTO - это не моя мысль. Это факт, отмеченный во многих работах, так или иначе использующих диаграммную технику

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

Не очень здорово получится. У нас пока генерируется на ассемблере и Си - где с безусловным переходом все в порядке :) .


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Суббота, 02 Май, 2009 10:07 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Ярослав Романченко писал(а):
..некоторые топологические конструкции может быть проблематично представить в ACTIVE OBERON.

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

"При применении схем алгоритмов, в большинстве случаев переход от алгоритмизации к программированию для сложных задач логического управления представляет большую проблему. Это объясняется тем, что обычно процесс алгоритмизации почти никогда не завершается тем, чем положено – созданием алгоритма в математическом смысле, который, по определению, должен однозначно выполняться любым Вычислителем. Обычно этот процесс заканчивается лишь некоторой ″картинкой″, называемой алгоритмом, которую в той или иной степени приходится додумывать при программировании (например, структурировать схему алгоритма или вводить безусловные переходы в неструктурированную программу). В этой ситуации либо Разработчик должен сам программировать, либо Программист должен знать особенности технологического процесса, либо они вместе должны при испытаниях устранять неминуемые ошибки традиционного проектирования программ. " (Шалыто А.А. Алгоритмизация и программирование задач логического управления.)
- вроде как замолвил словечко за программистов.
Но "..структурировать схему алгоритма или вводить безусловные переходы в неструктурированную программу" отражает цену вопроса - оптимизировать "картинку" специально под семантику промежуточного языка, под линейную модель вычислителя(в обоих случаях - в ущерб понимаемости для разработчика-предметника) или отдать эту работу предсказателю переходов(в развитых архитектурах).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Суббота, 02 Май, 2009 10:33 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Илья Ермаков писал(а):
Игорь, Вы оставьте в покое сам Дракон, а вот его топологию связей попробуйте... Может и заработать для выражения каких-то связей (даже обязано работать в нек. случаях, скажу Вам; но в других случаях за уши притягивать не надо :) ).
Илья, спасибо за совет! Мною двигало естественное желание использовать то, что уже придумано и есть. В этом дань уважения к автору Дракона, Владимиру Д. Паронджанову. Но раз Дракон в чистом виде для моих задач не подходит, то придётся придумывать что-то своё. Это, конечно, не означает, что Дракон плох, просто задачи у меня другие.
Кстати, просто дерево сущностей модуля, как в дельфийском инспекторе объектов, меня тоже не устраивает, так что придётся заняться изобретательством. Но не сейчас, всему своё время.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Суббота, 02 Май, 2009 10:39 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Рэйлвэй Каген писал(а):
TAU писал(а):
Да, я, например, тоже задумывался над тем, как нам генерировать по диаграмме "структурный" текст программы. Не очень здорово получится.
"При применении схем алгоритмов, в большинстве случаев переход от алгоритмизации к программированию для сложных задач логического управления представляет большую проблему. ..." (Шалыто А.А. Алгоритмизация и программирование задач логического управления.)
Все эти вопросы решены в полнофункциональном дракон редакторе трансляторе для конкретных языков: 1Cv77, 1Cv81, Delphi, КП. Для языков с Goto хорошо получается. Для КП возникают ограничения, излишняя сложность в сгенерированном коде.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Суббота, 02 Май, 2009 11:11 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Геннадий Тышов писал(а):
Для языков с Goto хорошо получается. Для КП возникают ограничения, излишняя сложность в сгенерированном коде.

igor писал(а):
Ещё хочу высказать своё предположение о том, что язык Дракон предлагает свой способ борьбы со стилем "спагетти", отличный от классических принципов структурного программирования. Здесь тоже спасение в структурах, но иная реализация. Может именно этим объясняется то, что некоторые драконовские схемы, которые трудно обвинить в неструктурности, "не ложатся" на тот же Оберон или КП.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Вторник, 02 Июнь, 2009 09:11 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5434
Откуда: Москва
Рэйлвэй Каген писал(а):
как это ни странно, Дракон дает шанс языкам с GOTO.
GOTO может сыграть положительную роль только при использовании его на автоматическом уровне(аналогично невидимому inc(PC)), когда нет прямой возможности "пошалить ручками". Автоматическая трансляция Дракон-схемы в язык с GOTO оказывается в выигрышном положении относительно ЯВУ, не имеющих такой конструкции


Уважаемый Рэйлвэй Каген!

Еще раз большое спасибо за высказанную Вами мысль
(Дракон дает шанс языкам с GOTO).

Мне кажется, Ваша мысль может иметь далеко идущие последствия.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Среда, 03 Июнь, 2009 07:56 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
В плане последствий, на мой взгляд, всё зависит от выбора промежуточного представления кода. В какое представление транслировать Дракон-схему? Ежели в ассемблер или Си - это будет быстрое решение в лоб, способное доказать работоспособность подхода. Но на этом развитие системы проектирования заканчивается.
С другими языками могут быть и варианты.
Например, в Java нет goto, но переносимый байт-код Java является по сути линеаризованным объектным кодом стековой машины. И никто не ругает его(байт-код Java) за наличие команд табличных переходов и передачи управления.
Для Оберона тоже разработано промежуточное представление. Было бы интересно, если кто-нибудь из разбирающихся в вопросе, попробовал оценить возможности трансляции Дракон-схемы в подобие Slim binaries, минуя запись на Обероне. Речь не об использовании в лоб компилятора, а об отказе от определения и использования сннтаксиса управляющих конструкций языка высокого уровня в результатах трансляции Дракон-схемы.

Спросите, что же останется от языков высокого уровня? А останется система типов, некоторые определения и различная смысловая часть - семантика языка высокого уровня, позволяющая создавать четко структурированные(Oberon) или же хитро построенные(Си) программы. Вот тут-то и есть где развернуться - придумать пару для Дракона, позволяющую адекватно(визуально) поддерживать процесс проектирования.

P.s.: "система типов, некоторые определения".. они почти одинаковые для большинства императивных языков.


Последний раз редактировалось Рэйлвэй Каген Среда, 03 Июнь, 2009 10:45, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Среда, 03 Июнь, 2009 09:32 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5434
Откуда: Москва
Большое спасибо


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5434
Откуда: Москва
Геннадий Тышов писал(а):
Все эти вопросы решены в полнофункциональном дракон редакторе трансляторе для конкретных языков: 1Cv77, 1Cv81, Delphi, КП.

viewtopic.php?p=28890&sid=4cbcb1275a6fdcbe7ac201da115ebd06#p28890

Уважаемый Геннадий Николаевич!

1. Что означают слова "Все эти вопросы РЕШЕНЫ... для конкретных языков: 1Cv77, 1Cv81, Delphi, КП?"

2. Речь идет о Вашей закрытой разработке? Или же это Ваша открытая разработка?

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

4. Вы имеете в виду Вашу ПРАКТИЧЕСКУЮ разработку, или же только ТЕОРЕТИЧЕСКУЮ?

5. Если имеется в виду Ваша ПРАКТИЧЕСКАЯ разработка, является ли она каким-либо аналогом конвертора (компилятора) языка ДРОН, созданном Ярославом Романченко? Или же здесь имеются в виду совершенно разные вещи?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Среда, 17 Июнь, 2009 21:31 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
1. Да, "Все эти вопросы РЕШЕНЫ... для конкретных языков: 1Cv77, 1Cv81, Delphi, КП?"
2,3,4. Было сделано 2 выпуска "Полнофункциональный дракон-редактор, транслятор", все осталось не востребованным, без обсуждения. По требованию, сделана настраиваемая сборка текстов, в том числе из программных примечаний, транслятор удален. Оба выпуска имеются на форуме с исходными текстами.
5. Разработка транслятора полностью оригинальная.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект на Драконе
СообщениеДобавлено: Четверг, 18 Июнь, 2009 05:00 

Зарегистрирован: Среда, 27 Май, 2009 01:41
Сообщения: 33
Геннадий Николаевич, где можно получить(или как) вариант транслятора Дракон-схем в язык 1с v.7.7 ?? Давно и плотно занимаюсь разработкой прикладных решений разного уровня сложности в 1С, все никак не доходят руки формализовать начальный процесс проектирования. М.б. это как раз шанс привыкнуть к Дракону? Было бы интересно, а то надоедает этот 1с уже... ;-)


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

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


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

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


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

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