DRAKON.SU

Вы абсолютно правы! Текст в ACTIVE OBERON получаемый из ДРОНа должен быть гарантированно безошибочным, т.е. все необходимые правки должны заключаться лишь в правках содержимого икон. Другое дело, некоторые топологические конструкции может быть проблематично представить в ACTIVE OBERON.

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

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

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

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

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

На Дракон-схеме не может быть отражена структура модуля. Причину я пытался объяснить в ответе на первое Ваше сообщение.

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

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

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

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

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

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

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

Илья, спасибо за совет! Мною двигало естественное желание использовать то, что уже придумано и есть. В этом дань уважения к автору Дракона, Владимиру Д. Паронджанову. Но раз Дракон в чистом виде для моих задач не подходит, то придётся придумывать что-то своё. Это, конечно, не означает, что Дракон плох, просто задачи у меня другие.
Кстати, просто дерево сущностей модуля, как в дельфийском инспекторе объектов, меня тоже не устраивает, так что придётся заняться изобретательством. Но не сейчас, всему своё время.

Все эти вопросы решены в полнофункциональном дракон редакторе трансляторе для конкретных языков: 1Cv77, 1Cv81, Delphi, КП. Для языков с Goto хорошо получается. Для КП возникают ограничения, излишняя сложность в сгенерированном коде.

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

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

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

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

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

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

Большое спасибо

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

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

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

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

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

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

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

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

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

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