DRAKON.SU https://forum.drakon.su/ |
|
Проект на Драконе https://forum.drakon.su/viewtopic.php?f=147&t=1493 |
Страница 1 из 3 |
Автор: | Рэйлвэй Каген [ Пятница, 24 Апрель, 2009 21:36 ] |
Заголовок сообщения: | Проект на Драконе |
Драфт здесь -> Вложение: Конечно, могут быть ошибки, но уже собирается само. Писишная часть на подходе.Вложение: hist 2009-04-28: добавлены Дракон-схемы в pdf-формате 2009-04-27: исправлены мелкие недочёты |
Автор: | Рэйлвэй Каген [ Суббота, 25 Апрель, 2009 12:32 ] |
Заголовок сообщения: | Re: Проект на Драконе |
некоторые итоги: "++" 1. набор соглашений по использованию икон (см. любой лист проекта ГНОМ-схема слева). Эти соглашения устанавливают соответствие между макроиконами Дракона и управляющими конструкциями целевого языка программирования. Очевидное решение может быть в виде набора словарей под различные целевые языки программирования. TAU на сахара.ru привёл в качестве примера систему ГРАФКОНТ с шаблонами программных текстов для каждого вида икон. В дальнейшем эти словари (или шаблоны) должны использоваться для автоматической трансляции Дракон-схем. В пределах листа вроде бы нерационально использовать несколько целевых языков, но, как назло, некоторые программы запросто обращаются, допустим, к SQL-серверу или скриптовому движку. Если с визуализацией запроса в Драконе пока никак, то многие скриптовые языки естественным образом могут быть отображены на Драконе. Поэтому я не стал бы навсегда отвергать возможность использования нескольких словарей на одном листе. Чтобы иметь возможность рисовать тот самый Data Execution, который в отдельных местах надо душить нещадно, а в других - без него никак. 2. возможны варианты при разметке линии сборки текста - оптимизация только лишь оценкой графики, без синтаксического анализа. Проиллюстрировано здесь(включить отображение линии сборки) -> Вложение: Вложение: Сборка по последнему варианту несколько короче, но имеет смысл при трансляции непосредственно в язык целевой платформы(маш.коды, ассемблер). При трансляции Дракон-схемы в языки высокого уровня такой метод оптимизации неработоспособен."--" 3. источник дополнительных ошибок - ручная расстановка управляющих конструкций в программных примечаниях. Это весьма затрудняет начало работы с первым проектом для данного целевого языка и без выработки системы соглашений (см.п.1) приводит к запутыванию проекта. 4. первый лист проекта (c которого запускается сборка) получился абсолютно неинформативным(технологическим). Это неправильно. По моему, первый лист должен давать представление о системе в целом. |
Автор: | ==== [ Вторник, 28 Апрель, 2009 20:08 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Решил показать вариант вашего документа с применением 1-й иконы "Проект" (ранее называлась "Лист"), в которой имеется несколько ссылок на иконы "Сборка текста" других документов, взамен нескольких икон с 1 ссылкой в каждой. Вложение: dozer.png Рэйлвэй Каген писал(а): некоторые итоги: ... 4. первый лист проекта (c которого запускается сборка) получился абсолютно неинформативным(технологическим). Это неправильно. По моему, первый лист должен давать представление о системе в целом. Может, на него следует поместить икону "Комментарий" схемы "Гном" с описанием назначения устройства. |
Автор: | Илья Ермаков [ Вторник, 28 Апрель, 2009 20:18 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Может, кто-нибудь потратит время и сделает pdf с примерами схем из проекта Рэйлвэй Кагена? Просто я думаю, что многим было бы так удобнее посмотреть. |
Автор: | Рэйлвэй Каген [ Вторник, 28 Апрель, 2009 22:16 ] |
Заголовок сообщения: | Re: Проект на Драконе |
2 Геннадий Тышов: Вариант с одной иконой "Проект" намного лучше. Спасибо. Насчёт текстового описания на первом листе - по-моему не очень хорошая идея. Тут лучше 100 раз подумать. 2 Илья Ермаков: Доки в pdf'е добавлены в первое сообщение темы. Более маниакального занятия, чем запихивание png в pdf с подгонкой форматов у меня ещё не было Видимо стоит рассмотреть варианты с djvu и автодокументированием. |
Автор: | Рэйлвэй Каген [ Среда, 29 Апрель, 2009 21:12 ] |
Заголовок сообщения: | Re: Проект на Драконе |
как собрать исходник и где искать структурность?
Подробнее:
Вложение:
Комментарий к файлу: Устранение пересечений для линейной модели. Метод - дублирование кода. 1.7z [825 байт] Скачиваний: 625
GOTO может сыграть положительную роль только при использовании его на автоматическом уровне(аналогично невидимому inc(PC)), когда нет прямой возможности "пошалить ручками". Автоматическая трансляция Дракон-схемы в язык с GOTO оказывается в выигрышном положении относительно ЯВУ, не имеющих такой конструкции |
Автор: | Владимир Паронджанов [ Среда, 29 Апрель, 2009 23:06 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Рэйлвэй Каген писал(а): Дракон дает шанс языкам с GOTO. GOTO может сыграть положительную роль только при использовании его на автоматическом уровне(аналогично невидимому inc(PC)), когда нет прямой возможности "пошалить ручками". Автоматическая трансляция Дракон-схемы в язык с GOTO оказывается в выигрышном положении относительно ЯВУ, не имеющих такой конструкции[/list][/list] Полностью согласен. Эта мысль меня давно и очень сильно волнует. Поскольку конструкции Дракона "не ложатся, точнее, не всегда ложатся" в конструкции текстовых языков, возникает вопрос, как быть? Есть два ответа. Ответ 1. Надо использовать только те конструкции дракона, которые успешно ложатся в имеющиеся текстовые кострукции. Недостаток этого варианта в том, что часть преимуществ Дракона пропадает. Это плохо, так как жалко добро терять. Ответ 2. При трансляции с выхода дракон-редактора в исходные коды целевого языка ПОВСЕМЕСТНО (ИЛИ ПОЧТИ ПОВСЕМЕСТНО) ИСПОЛЬЗОВАТЬ GOTO. В этом случае будут сохранены ВСЕ преимущества дракона. Но! это возможно (без выкрутас) лишь в том случае, ЕСЛИ ЦЕЛЕВОЙ ЯЗЫК ИМЕЕТ GOTO. Страшно ли это? По-моему нет. Так как в гибридном языке Дракон-целевой язык, последний отчасти играет роль ассемблера, в который GOTO вставляется автоматически (что безопасно), а не ручками. Уважаемый Рэйлвэй Каген! Большое спасибо, что Вы высказали эту мысль в явном виде. Но как же быть в итоге? Ведь в Обероне (если я не ошибаюсь) нет GOTO. Выходит, что союз дракон-Оберон не может быть ИДЕАЛЬНЫМ? Или я что-то напутал? |
Автор: | Madzi [ Среда, 29 Апрель, 2009 23:15 ] |
Заголовок сообщения: | Re: Проект на Драконе |
В подавляющем большинстве случаев схема с GOTO может быть преобразована к схеме без GOTO. Точно также схема на Драконе не всегда может быть записана одним единственным способом. Тут нужно строить изоморфные графы и смотреть теряется наглядность или нет. |
Автор: | Евгений Темиргалеев [ Среда, 29 Апрель, 2009 23:47 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Тут вопрос в том, будет ли правиться текстовый код. Если работать только с ДРАКОН схемами, то целевой код хоть с GOTO, хоть без. Как получится. А вот если работать по более мягкому принципу правки при разработке по выбору схема/текст с переключениями туда-сюда, тогда надо думать про структурность текста.... |
Автор: | Peter Almazov [ Четверг, 30 Апрель, 2009 04:43 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Смиялсо. Ну вот и пришли к закономерному итогу всей этой возни: оператору GOTO. |
Автор: | Димыч [ Четверг, 30 Апрель, 2009 06:55 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Peter Almazov писал(а): Смиялсо. Ну вот и пришли к закономерному итогу всей этой возни: оператору GOTO. Знаете, просто сказать, что «все плохо», это еще ничего не сказать. Появление GOTO не есть признак непрофессионализма, это признак знакомства с работами Дейкстры Возможно, что я сейчас выскажу мысль, которую уже здесь высказывали, но уж очень она к месту, как мне кажется. За всеми этими разговорами о GOTO как-то упускается тот факт, что вовсе не обязательно производить однозначное соответствие «икона — кусок кода». Можно же сделать соответствие «схема — конечный автомат». А вот последний смело может быть реализован без использования GOTO. Евгений Темиргалеев писал(а): Тут вопрос в том, будет ли правиться текстовый код. Если работать только с ДРАКОН схемами, то целевой код хоть с GOTO, хоть без. Как получится. А вот если работать по более мягкому принципу правки при разработке по выбору схема/текст с переключениями туда-сюда, тогда надо думать про структурность текста.... Верно. И если не лазить в код, то можно один раз для одного языка программирования создать шаблон конечного автомата, а потом встраивать иконы и соответствующий код в текст автомата.Далее, если порассуждать над этой схемой, можно прийти к тому, что Borland в свое время назвала two-way tools. Как в Дельфи можно назначить обработчики событий и из инспектора попадать в код в нужную процедуру, так и из Дракон-редактора в перспективе можно попадать сразу в точку реализации иконы в автомате (естественно, с соответствующим синтаксическим [косметическим] выделением точки реализации в коде). Кстати говоря, подобный подход очень сильно перекликается с «гнездами» Горбунова-Посадова в его «Расширяемых программах». Сам конечный автомат в основном неизменен в рамках одного языка. Изменяется лишь небольшой его блок (case-часть). В рамках же case-элемента меняется только внутренняя часть, сам же элемент («гнездо») неизменен. И в рамках этой модели можно получить большой выигрыш от взаимодействия «графической» части и «содержимого гнезда». Это все, конечно, требует проработки. Но в целом, при использовании Дракона представляется разумным в перспективе вообще уйти от редактирования кода схемы, не исключая, впрочем, редактирования деталей схемы. Материалы по теме: Психология автоматного программирования Расширяемые программы |
Автор: | Peter Almazov [ Четверг, 30 Апрель, 2009 08:19 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Так это всё понятно. Есть 4 решения, все они здесь перечислялись: 1. Использование теоремы Ашкрофта-Манна, или автоматов, я не вижу здесь разницы (switch внутри цикла). 2. Иногда можно использовать подходящие конструкции типа loop со многими exit, если они есть в языке. 3. Дублирование кода. 4. Оператор GOTO. Но я лично критикую Дракон совсем не за это. Можно писать абсолютно структуированные блок-схемы, или Дракон-схемы, это ничего не меняет. Просто блок-схемы - это тупик. Как инструмент, позволяющий вытянуть хоть что-то путное из людей, не занимающихся программированием (как здесь говорят, "нормальных людей, а не программистов") блок-схемы - это, пожалуй, подходящий инструмент. |
Автор: | Рэйлвэй Каген [ Четверг, 30 Апрель, 2009 09:29 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Владимир Даниелович, по поводу использования GOTO - это не моя мысль. Это факт, отмеченный во многих работах, так или иначе использующих диаграммную технику. Этот факт имеет простое и наглядное обоснование. Пусть на сторонах проволочной модели прямоугольника заданы направления обхода, соответствующие движению по диагонали от верхнего левого угла к нижнему правому(развилка в верхнем левом углу). Возьмём модель за эти углы по диагонали и попробуем растянуть её в линию с сохранением направления обхода. Не получается? Чтобы сделать это, потребуется сделать 2 разреза и поставить две метки и два GOTO. Владимир Паронджанов писал(а): ..союз дракон-Оберон не может быть ИДЕАЛЬНЫМ? Отсутствием GOTO в Обероне начинается и завершается список недостатков этого союза. А вот для Дракона и Си список достоинств их союза состоит лишь из наличия GOTO.
|
Автор: | igor [ Четверг, 30 Апрель, 2009 09:34 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Владимир Паронджанов писал(а): Поскольку конструкции Дракона "не ложатся, точнее, не всегда ложатся" в конструкции текстовых языков, возникает вопрос, как быть? Хочу высказать одну идею, которая уже давно витает у меня в голове. Над реализацией пока не думал. Но ведь мысль первична . Не будет идей -- не будет и реализации.... Выходит, что союз дракон-Оберон не может быть ИДЕАЛЬНЫМ? Или я что-то напутал? Работая с исходниками Блэкбокс (и другими), я обратил внимание, что требуется много усилий (если модуль большой, как Kernel, например) для того чтобы обрести ясность что делает та или иная процедура, и как она используется в самом модуле. Эти затруднения произростают из того, что модуль имеет линейную структуру (по форме). Те представления о структуре модуля, которые подразумевал программист на момент написания, оказываются безвозвратно потеряны. Просто просматривая длинную вереницу процедур, трудно понять какие из них являются ключевыми, а какие служат лишь для того, чтобы обеспечить реализацию этих ключевых процедур. Идея, собственно, состоит в том, чтобы создать такую IDE, в которой структура модуля разрабатывается на Драконе. Далее, двойной клик по иконке раскрывает окно с текстом процедуры, написанной в обычном традиционном стиле, например, на Обероне. То есть Дракон-схема выполнят в том числе роль своеобразного инспектора объектов. Идейка, конечно, пока сыровата. Как всегда обычно бывает, есть много нюансов. Вместе с тем открываются и новые не виданные доселе возможности. Например, условный вызов процедур. Хотя полезность от таких возможностей пока не очевидна и, наверное, спорна. Ещё хочу высказать своё предположение о том, что язык Дракон предлагает свой способ борьбы со стилем "спагетти", отличный от классических принципов структурного программирования. Здесь тоже спасение в структурах, но иная реализация. Может именно этим объясняется то, что некоторые драконовские схемы, которые трудно обвинить в неструктурности, "не ложатся" на тот же Оберон или КП. |
Автор: | Рэйлвэй Каген [ Четверг, 30 Апрель, 2009 09:41 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Madzi: "схема с GOTO может быть преобразована к схеме без GOTO.."
За предупреждение о тупике - спасибо. У меня есть КАСКО.
|
Автор: | Peter Almazov [ Четверг, 30 Апрель, 2009 09:49 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Рэйлвэй Каген писал(а): Peter Almazov: "Смиялсо." PS убрал.
За предупреждение о тупике - спасибо. У меня есть КАСКО. А зачем мне читать екзешник? Я с ним не имею дела ни на каком этапе. В отличии от. Вы еще посоветуйте почитать то, что наделает компилятор для RISC-машины. |
Автор: | Рэйлвэй Каген [ Четверг, 30 Апрель, 2009 10:01 ] |
Заголовок сообщения: | Re: Проект на Драконе |
igor писал(а): структура модуля разрабатывается на Драконе Вы вовремя подняли этот вопрос. Дракон применим там, где связи между декларативными сущностями(процедурами, значениями логических выражений, функциями и переменными..) существуют в виде порядка выполнения. Т.е. их можно изобразить в виде маршрута. Структура модуля - это связи несколько другого типа. Есть ещё структуры данных, структура программы и структура информации для её сборки. Размещая это "в лоб" в Драконе, получаем весьма мутный документ - см. первый лист в сборке проекта. Было бы весьма приятно иметь возможность плоского представления указанных связей, раз уж линейная запись для них существует. Но не в рамках Дракона, а рядом - в качестве равноправной компоненты IDE, взаимодействующей в Дракон-схемами. |
Автор: | Рэйлвэй Каген [ Четверг, 30 Апрель, 2009 10:14 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Peter Almazov писал(а): А зачем мне читать екзешник? Это первый шаг к пониманию, что наличие кода jmp в .exe(да и в .obj тогда уже) и GOTO в промежуточном результате сборки - это эквивалентные "изъяны природы". Нежелательно GOTO при работе человека с линейной текстовой моделью - так не используйте. Но здесь то работа с плоским представлением и в нём нет GOTO, а есть свои методы структуризации. |
Автор: | PGR [ Четверг, 30 Апрель, 2009 10:57 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Рэйлвэй Каген писал(а): Структура модуля - это связи несколько другого типа. Например в BlueJ для Java структура классов пакета представляется визуально. |
Автор: | Владимир Паронджанов [ Четверг, 30 Апрель, 2009 11:01 ] |
Заголовок сообщения: | Re: Проект на Драконе |
Рэйлвэй Каген писал(а): Евгений Темиргалеев: "..если работать по более мягкому принципу правки при разработке.."
Я склонен полностью принять точку зрения Рэйлвэя Кагена. Вопрос к Евгению Темиргалееву Если можно, поясните мне, зачем нужна работа "по более мягкому принципу"? Поясню вопрос. Программист, который работает на ЯВУ, очень редко лезет в ассемблерный текст. Он может просто не знать ассемблер. Сошлюсь также на Peter Almazov. Он пишет: "А зачем мне читать екзешник? Я с ним не имею дела ни на каком этапе". Суть моего вопроса: ЕСЛИ МЫ РАБОТАЕМ, НАПРИМЕР НА ДРОНе, ТО ЗАЧЕМ НАМ ЛЕЗТЬ С ПРАВКАМИ В ACTIVE OBERON? Может быть, в этом случае можно рассматривать ACTIVE OBERON как аналог ассемблерного текста, екзешника? Или я не прав? |
Страница 1 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |