DRAKON.SU

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

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




Начать новую тему Ответить на тему  [ Сообщений: 12 ] 
Автор Сообщение
 Заголовок сообщения: Особенности языка ДРАКОН
СообщениеДобавлено: Воскресенье, 18 Декабрь, 2011 12:00 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Уважаемые коллеги!

Это текст для Википедии.
Прошу критиковать.
Ваши замечания представляют для меня огромную ценность
_____________________________________________________________________

Содержание

1 Особенности
1.1 Язык ДРАКОН значительно облегчает алгоритмизацию и программирование
1.2 Двумерное структурное программирование
1.3 Графический и текстовый синтаксис языка ДРАКОН
1.4 Семейство ДРАКОН-языков
1.5 Гибридные языки ДРАКОН-семейства
1.6 Достоинства гибридных языков
1.7 Гибридные языки ДРАКОН-семейства и оператор GOTO
1.8 План развития и частичной унификации языков программирования
1.9 Целесообразно создать международный стандарт на дракон-схемы


[править] Особенности

[править] Язык ДРАКОН значительно облегчает алгоритмизацию и программирование

Существующие способы записи алгоритмов и программ (принятые во всем мире) слишком трудны для понимания и требуют неоправданно больших трудозатрат.

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

Язык ДРАКОН использует новую эргономичную нотацию (дракон-схемы) и за счет этого существенно облегчает алгоритмизацию и программирование. Благодаря использованию дракон-схем алгоритмы и программы становятся более понятными, доходчивыми, ясными, прозрачными.

В итоге ТРУДНЫЕ для понимания способы записи алгоритмов и программ заменяются на более ЛЕГКИЕ. Вследствие этого работники быстро овладевают дракон-схемами и успешно создают алгоритмы и прикладные программы без программистов или с их минимальным участием. Об этом свидетельствует 15-летний опыт эксплуатации Технологии ГРАФИТ-ФЛОКС в НПЦ автоматики и приборостроения им. Н. А. Пилюгина. Приведем цитату.
Цитата:
«ДРАКОН — очень легкий язык. Настолько легкий, что разработку многих компьютерных программ для космических ракет на практике ведут не программисты, а инженеры — по принципу „программирование без программистов“.

Причина частичного отказа от программистов проста. При решении практических прикладных задач инженеры досконально владеют материалом и прекрасно знают постановку задачи. В отличие от них программисты не знают физику процесса и становятся „лишними людьми“, без которых в ряде случаев (хотя и не всегда) вполне можно обойтись.

Это позволяет значительно сократить издержки, улучшить показатель „затраты — результат“, ускорить ход работ. И полностью избавиться от ошибок „испорченного телефона“, вызванных взаимным непониманием между программистами и инженерами».[10]


[править] Двумерное структурное программирование

1.Процедурная часть языка ДРАКОН опирается на новый метод – двумерное структурное программирование.

2.Правила двумерного структурного программирования существенно отличаются от традиционного одномерного (текстового) структурного программирования.

3.Идеи структурного программирования разрабатывались, когда компьютерная графика фактически еще не существовала и основным инструментом алгоритмиста и программиста был одномерный (линейный или ступенчатый) текст.

4.До появления компьютерной графики методология текстового структурного программирования была наилучшим решением.

5.С появлением компьютерной графики ситуация изменилась. Появилась возможность заменить текстовые управляющие структуры на управляющую графику, то есть использовать двумерное структурное программирование.

6.Слабое место традиционного структурного программирования и текстового представления алгоритмов и программ заключается в недостатке выразительных средств. Следствием являются ограничения и запреты. Эти ограничения и запреты вытекают из природы текста, из природы текстового представления управляющих структур.

7.Недостаток выразительных средств, проявляющийся через ограничения и запреты, тормозит повышение производительности труда алгоритмистов и программистов.

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

9.Многие ограничения и запреты, неизбежные при текстовом структурном программировании, во многих случаях противоречат здравому смыслу, затрудняют понимание алгоритмов и программ, искажают нормальный ход человеческой мысли.

10.Недопустимо запрещать правильный процесс мышления. Его надо разрешить. Шампур-метод и язык ДРАКОН устраняют этот недостаток.

11.При использовании шампур-метода набор управляющих ключевых слов текстового структурного программирования становится ненужным.

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

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

14.ДРАКОН — это не просто новый язык (новое семейство языков). Это новый взгляд на процедурное программирование. Если угодно — новое мировоззрение.

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

16.Язык ДРАКОН позволил эффективно решить эту задачу.

17.Одновременно была решена задача эргономизации блок-схем, то есть задача приспособления блок-схем для наиболее удобного человеческого восприятия и понимания.[11]

[править] Графический и текстовый синтаксис языка ДРАКОН

ДРАКОН — графический (визуальный) язык, в котором используются два типа элементов:

        • графические фигуры (иконы),
        • текстовые надписи, расположенные внутри или снаружи икон (текстоэлементы).

Поэтому язык ДРАКОН имеет не один, а два синтаксиса: графический и текстовый.

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

Текстовый синтаксис задает алфавит символов, правила их комбинирования и привязку к иконам. (Привязка необходима потому, что внутри разных икон используются разные типы выражений).[12][13]

[править] Семейство ДРАКОН-языков

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

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

При этом единообразие правил графического синтаксиса семейства ДРАКОН-языков обеспечивает их концептуальное единство. А разнообразие текстовых правил (то есть возможность выбора любого текстового синтаксиса) определяет гибкость языка и легкую настройку на различные предметные и иные области.[14]

[править] Гибридные языки ДРАКОН-семейства

Процедурную часть языка Дракон можно присоединить к некоторым языкам программирования и получить так называемые гибридные языки:

язык Дракон + язык Бейсик = гибридный язык Дракон-Бейсик

язык Дракон + язык Си = гибридный язык Дракон-Си

язык Дракон + язык Java = гибридный язык Дракон-Java

язык Дракон + язык Си# = гибридный язык Дракон-Си#

язык Дракон + язык Питон = гибридный язык Дракон-Питон

язык Дракон + язык Perl = гибридный язык Дракон-Perl

язык Дракон + язык Ruby = гибридный язык Дракон-Ruby

язык Дракон + язык Ада = гибридный язык Дракон-Ада

язык Дракон + язык Оберон = гибридный язык Дракон-Оберон

язык Дракон + язык Tcl = гибридный язык Дракон-Tcl
и т.д.

Пример 1. При создании гибридного языка Дракон-Си необходимо, в частности, создать транслятор из дракон-схемы в исходный код языка Си. В этом случае Си является целевым языком.

Пример 2. При создании гибридного языка Дракон-Дельфи необходимо, в частности, создать транслятор из дракон-схемы в исходный код языка Дельфи. При этом Дельфи называется целевым языком.

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


Еще один пример. Предположим, пользователь работает в связке ИС Дракон - Транслятор Дракон-Си - Keil. Понятно, что исходником служит дракон-схема. При отладке программы не следует вносить исправления в промежуточные текстовые Си-файлы. Все исправления нужно вносить в исходный код, то есть в дракон-схему.
Цитата:
Я уже больше года работаю на связке ИС Дракон - DrakonToC - Keil. И ни в коем случае не позволяю себе править промежуточные текстовые Си-файлы. Исходник - это Дракон-схема![15]

Подробнее см. [16]

[править] Достоинства гибридных языков

С точки зрения человеческого фактора, в истории развития языков программирования условно можно выделить два этапа.

На первом этапе появились языки высокого уровня, которые по сравнению ассемблером сделали исходный текст программы более понятным и удобным для человека. И значительно увеличили производительность труда программистов.

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

Это позволит отказаться от текстовых управляющих структур, используемых в языках высокого уровня, и заменить их на управляющую графику ДРАКОНа.

Что это даст? Исходный код программы станет еще более понятным и удобным для человека. И, следовательно, еще больше увеличится производительность труда программистов.
Цитата:
Как и все прочие языки, ДРАКОН опирается на математику и логику. Однако сверх того, он самым тщательным образом учитывает когнитивные вопросы. Благодаря систематическому использованию когнитивно-эргономических методов ДРАКОН приобрел уникальные эргономические характеристики. Можно предположить, что в будущем ДРАКОН сможет претендовать на звание чемпиона по критерию «понимаемость алгоритмов и программ» (в классе императивных языков) .

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

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

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

В основе языка ДРАКОН лежит идея когнитивной формализации знаний, позволяющая сочетать строгость логико-математической формализации с точным учетом когнитивных (познавательных) характеристик человека.[17]


[править] Гибридные языки ДРАКОН-семейства и оператор GOTO

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

На первом этапе — после изобретения структурного программирования и призыва Эдсгера Дейкстры: «оператор go to должен быть отменен в языках программирования высокого уровня» [18] — начался процесс исключения GOTO из вновь создаваемых языков. Сегодня имеется целый ряд языков без GOTO: Java, Python, Tcl, Модула-2, Оберон и др.

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

При этом открылись два обстоятельства. Транслятор из ДРАКОНа в целевой язык лучше всего делать с использованием GOTO, имеющемся в целевом языке. Если же оператор GOTO в целевом языке отсутствует, этот оператор приходится эмулировать. Это можно сделать, например, так.[19]

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

Как отмечает Петр Приклонский:
Цитата:
Оператор GOTO нежелательно использовать именно в текстовых языках, так как контроль за соблюдением структурности программы остается за исполнителем (программистом). В языке ДРАКОН есть свои собственные правила, позволяющие сохранять структурность.[20]


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

При описанных условиях ввод оператора GOTO не представляет никакой опасности. Он не приведет к нарушению структурности и появлению «спагетти», так как GOTO будет вводиться в текст целевого языка только автоматически в результате работы транслятора, а не в результате действий человека. Человек будет иметь доступ только к дракон-схеме.

В свою очередь, дракон-схема имеет надежную защиту от подобных неприятностей благодаря использованию ДВУМЕРНОГО структурного программирования. Принципы двумерного структурного программирования подробно описаны в литературе.[21][22][22а]

[править] План развития и частичной унификации языков программирования

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

        1.Использовать графический синтаксис языка ДРАКОН в качестве стандарта, позволяющего осуществить частичную унификацию языков высокого уровня.

        2.Текстовый синтаксис следует заимствовать из целевого языка. При этом следует удалить все элементы текстового синтаксиса, которые заменяются управляющей графикой ДРАКОНа.

        3.Преобразовать языки высокого уровня в гибридные языки. Метод преобразования описан в источниках.[23][24]

Как показывают первые опыты подобной работы, переход от языков высокого уровня к гибридным языкам свидетельствует о заметном повышении производительности труда.


[править] Целесообразно создать международный стандарт на дракон-схемы

Обоснование необходимости нового стандарта поясняется ниже.
Цитата:
2. Текстовое структурное программирование решило стоявшие перед ним исторические задачи, исчерпало свои эвристические возможности и, выполнив свою миссию, потеряло актуальность. В настоящее время точкой роста научного знания является визуальное структурное программирование.

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

5. По эргономическим показателям визуальное структурное программирование существенно превосходит свой текстовый аналог...

7. Дальнейшее использование… блок-схем во всех случаях следует признать нецелесообразным.

8. Существующая литература по блок-схемам, включая международные и национальные стандарты, на 99% устарела.

9. Современные стандарты на блок-схемы объективно содействуют снижению качества соответствующей интеллектуальной продукции. Указанные стандарты игнорируют три важнейших принципа: структуризации, формализации и эргономизации.

10. Актуальной задачей является разработка новой системы международных и национальных стандартов…, свободных от перечисленных недостатков. В основу проекта новых стандартов целесообразно положить изложенные в этой книге правила визуального структурного программирования. Дракон-схемы наследуют… все достоинства блок-схем и устраняют их недостатки.[23]


Литература

10.↑ Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому (Как улучшить работу ума без лишних хлопот). М.: ДМК-пресс, 2010. С. 13, 14 ISBN 978-5-94074-606-5

11.↑ Паронджанов В.Д. Теоретические основы языка ДРАКОН. Глава 36. #22. Замечания

12.↑ Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов - это очень просто! М.: Дело, 2001. — С. 101.

13.↑ Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому (Как улучшить работу ума без лишних хлопот). М.: ДМК-пресс, 2010. С. 80 ISBN 978-5-94074-606-5

14.↑ Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому (Как улучшить работу ума без лишних хлопот). М.: ДМК-пресс, 2010. — C. 80, 81. ISBN 978-5-94074-606-5

15.↑ Практический вывод по результатам эксплуатации системы ИС Дракон — Транслятор Дракон-Си — Keil.

16.↑ Приклонский П. Транслятор файла *.drt ИС Дракон в текст Си-программ

17.↑ Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов - это очень просто! М.: Дело, 2001. — С. 31, 32.

18.↑ Dijkstra E. W. Go To Statement Considered Harmful. // Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148.

19.↑ Эмуляция GOTO в языках Python и Tcl.

20.↑ Структурность в текстовых языках и языке ДРАКОН

21.↑ Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов - это очень просто! М.: Дело, 2001. — С. 226-266.

22.↑ Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому. М.: ДМК-пресс, 2010. — С. 325-351, 357-379. ISBN 978-5-94074-606-5

22а. Ермаков И.Е., Жигуненко Н.А. Двумерное структурное программирование; класс устремлённых графов. (Теоретические изыскания из опыта языка «ДРАКОН») // Сборник трудов V Международной конференции "Инновационные информационно-педагогические технологии в системе ИТ-образования", Москва, 8-10 ноября 2010. М.:, Изд-во МГУ, 2010. — С. 452—461.]

23.↑ Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов - это очень просто! М.: Дело, 2001. — С. 265, 266.
_____________________________________________________________________

Это текст для Википедии.
Прошу критиковать.
Ваши замечания представляют для меня огромную ценность


Последний раз редактировалось Владимир Паронджанов Вторник, 20 Декабрь, 2011 14:09, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Воскресенье, 18 Декабрь, 2011 14:49 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Об общих направлениях высказался в этом посте. Навскидку некоторые частности (во многом следующие из общего :)):
Владимир Паронджанов писал(а):
Уважаемые коллеги!

Это текст для Википедии.
Прошу критиковать.
...
Литература

10.↑ Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому (Как улучшить работу ума без лишних хлопот). М.: ДМК-пресс, 2010. С. 13, 14 ISBN 978-5-94074-606-5

11.↑ Паронджанов В.Д. Теоретические основы языка ДРАКОН. Глава 36. #22. Замечания

12.↑ Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов - это очень просто! М.: Дело, 2001. — С. 101.

13.↑ Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому (Как улучшить работу ума без лишних хлопот). М.: ДМК-пресс, 2010. С. 80 ISBN 978-5-94074-606-5

14.↑ Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому (Как улучшить работу ума без лишних хлопот). М.: ДМК-пресс, 2010. — C. 80, 81. ISBN 978-5-94074-606-5

15.↑ Практический вывод по результатам эксплуатации системы ИС Дракон — Транслятор Дракон-Си — Keil.

16.↑ Приклонский П. Транслятор файла *.drt ИС Дракон в текст Си-программ

17.↑ Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов - это очень просто! М.: Дело, 2001. — С. 31, 32.

18.↑ Dijkstra E. W. Go To Statement Considered Harmful. // Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148.

19.↑ Эмуляция GOTO в языках Python и Tcl.

20.↑ Структурность в текстовых языках и языке ДРАКОН

21.↑ Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов - это очень просто! М.: Дело, 2001. — С. 226-266.

22.↑ Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому. М.: ДМК-пресс, 2010. — С. 325-351, 357-379. ISBN 978-5-94074-606-5

23.↑ Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов - это очень просто! М.: Дело, 2001. — С. 265, 266.

1. Может снова возникнуть претензия к авторитетности ("почему так много самоцитирования создателя ДРАКОНа?"). Тут пока ничего не поделаешь - будет "много ссылок, хороших и разных" (прежде всего - по авторам и представляемым организациям ;)) - и со временем вопрос отпадёт сам собой... :)

2. Считаю нужным прояснить здесь:
Владимир Паронджанов писал(а):
...
6.Слабое место традиционного структурного программирования и текстового представления алгоритмов и программ заключается в недостатке выразительных средств. Следствием являются ограничения и запреты. Эти ограничения и запреты вытекают из природы текста, из природы текстового представления управляющих структур.

7.Недостаток выразительных средств, проявляющийся через ограничения и запреты, тормозит повышение производительности труда алгоритмистов и программистов.

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

9.Многие ограничения и запреты, неизбежные при текстовом структурном программировании, во многих случаях противоречат здравому смыслу, затрудняют понимание алгоритмов и программ, искажают нормальный ход человеческой мысли.

10.Недопустимо запрещать правильный процесс мышления. Его надо разрешить. Шампур-метод и язык ДРАКОН устраняют этот недостаток.

...
- что конкретно за ограничения и запреты преодолеваются шампур-методом? Какие ещё, быть может, нужно преодолеть для "эргономичной формальности "- но пока это не сделано?

3. Считаю нужной правку:
Владимир Паронджанов писал(а):
...

[править] Графический и текстовый синтаксис языка ДРАКОН

ДРАКОН — графический (визуальный) язык, в котором используются два типа элементов:

        • графические фигуры (иконы),
        • текстовые надписи, расположенные внутри или снаружи икон (текстоэлементы).

Поэтому язык ДРАКОН имеет не один, а два синтаксиса: графический и текстовый.

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

Текстовый синтаксис задает алфавит символов, правила их комбинирования и привязку к иконам. (Привязка необходима потому, что внутри разных икон используются разные типы выражений).[12][13]

[править] Семейство ДРАКОН-языков

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

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

При этом единообразие правил графического синтаксиса семейства ДРАКОН-языков обеспечивает их концептуальное единство. А разнообразие текстовых правил (то есть возможность выбора любого текстового синтаксиса) определяет гибкость языка и легкую настройку на различные предметные и иные области.[14]

[править] Гибридные языки ДРАКОН-семейства

Процедурную часть языка Дракон можно присоединить к некоторым языкам программирования и получить так называемые гибридные языки:

язык Дракон + язык Бейсик = гибридный язык Дракон-Бейсик

язык Дракон + язык Си = гибридный язык Дракон-Си

язык Дракон + язык Java = гибридный язык Дракон-Java

язык Дракон + язык Си# = гибридный язык Дракон-Си#

язык Дракон + язык Питон = гибридный язык Дракон-Питон

язык Дракон + язык Perl = гибридный язык Дракон-Perl

язык Дракон + язык Ruby = гибридный язык Дракон-Ruby

язык Дракон + язык Ада = гибридный язык Дракон-Ада

язык Дракон + язык Оберон = гибридный язык Дракон-Оберон

язык Дракон + язык Tcl = гибридный язык Дракон-Tcl
и т.д.

Пример 1. При создании гибридного языка Дракон-Си необходимо, в частности, создать транслятор из дракон-схемы в исходный код языка Си. В этом случае Си является целевым языком.

Пример 2. При создании гибридного языка Дракон-Дельфи необходимо, в частности, создать транслятор из дракон-схемы в исходный код языка Дельфи. При этом Дельфи называется целевым языком.

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


Еще один пример. Предположим, пользователь работает в связке ИС Дракон - Транслятор Дракон-Си - Keil. Понятно, что исходником служит дракон-схема. При отладке программы не следует вносить исправления в промежуточные текстовые Си-файлы. Все исправления нужно вносить в исходный код, то есть в дракон-схему.
Цитата:
Я уже больше года работаю на связке ИС Дракон - DrakonToC - Keil. И ни в коем случае не позволяю себе править промежуточные текстовые Си-файлы. Исходник - это Дракон-схема![15]

Подробнее см. [16]

[править] Достоинства гибридных языков

С точки зрения человеческого фактора, в истории развития языков программирования условно можно выделить два этапа.

На первом этапе появились языки высокого уровня, которые по сравнению ассемблером сделали исходный текст программы более понятным и удобным для человека. И значительно увеличили производительность труда программистов.

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

Это позволит отказаться от текстовых управляющих структур, используемых в языках высокого уровня, и заменить их на управляющую графику ДРАКОНа.
...
В цитированных положениях есть скрытые противоречия. Не везде явно сфера приложения ДРАКОН-синтаксиса ограничивается структурой маршрутов (потоком управления программы/деятельности).
    ДРАКОН-схема НЕ м.б. сама по себе "исходным чертежом" программы; как показали реализации Романченко и других, в этом случае приходится "впихивать" декларации величин и определения исполнителей в дракон-комментарии или ещё куда. Это - НЕ визуализация программы (шире - информодели деятельности) в точном смысле. Представляемом, скажем, такой классификацией.
Необходимо везде излагать соответствующие положения единообразно в таком ключе:
Цитата:
Процедурной частью (визуальными [макро]операторами) языка ДРАКОН можно заместить маршрутные операторы некоторых (естественным образом - императивных/процедурных) чисто текстовых языков программирования, что называется гибридизацией их с ДРАКОНом. В результате получаются так называемые импер-граф-базированные языки программирования. При этом:
    а) Текст вершин должен содержать, по крайней мере, атрибутивную часть импер-составляющей смысла программы (командные операторы), а также ссылки на величины программы.
    б) Непроцедурные составляющие смысла программы (объявления величин и определение исполнителя, общее определение программы) таким образом не визуализируются; выбор графовой основы для их представления и увязка с импер-граф-языком, полученным при гибридизации с ДРАКОНом, есть самостоятельная задача комплексной гибридизации. Её результатом служит т.н. графит-прогязык, в котором структурная часть каждой составляющей смысла программы передаётся графом, а атрибутивная - текстом и таблицами (как разметкой рёбер и/или вершин графа).
    в) При отсутствии комплексной гибридизации текст дракон-вершин должен также включать описания непроцедурных составляющих программы (взамен ссылок на них); это снижает эргономичность и должно считаться временной мерой (до разработки комплексного графит-прогязыка).

Соответственно все "обычные" языки высокого уровня (как и Ассемблеры) нужно так и называть - "чисто текстовыми". И не забывать, что и машинные коды также м.б. визуализированы - и здесь естественная сфера приложения дракон-силуэта...

Переписывать весь проблемный текст самому - IMHO, как бэ неуважение к Владимиру Даниеловичу будет... при отсутствии явной просьбы... так что только обозначаю.

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

В общем, уточнять, что ДРАКОН - не "обёртка" для прогязыка, а форма записи для его процедурной части...
Пока всё - но это самое важное.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Понедельник, 19 Декабрь, 2011 14:46 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
В связке со сказанным здесь: viewtopic.php?f=62&t=3303&p=68763#p68763 - нуждается в правке и сказанное ниже.
Владимир Паронджанов писал(а):
...
[править] Гибридные языки ДРАКОН-семейства и оператор GOTO

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

На первом этапе — после изобретения структурного программирования и призыва Эдсгера Дейкстры: «оператор go to должен быть отменен в языках программирования высокого уровня» [18] — начался процесс исключения GOTO из вновь создаваемых языков. Сегодня имеется целый ряд языков без GOTO: Java, Python, Tcl, Модула-2, Оберон и др.

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

При этом открылись два обстоятельства. Транслятор из ДРАКОНа в целевой язык лучше всего делать с использованием GOTO, имеющемся в целевом языке. Если же оператор GOTO в целевом языке отсутствует, этот оператор приходится эмулировать. Это можно сделать, например, так.[19]

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

Как отмечает Петр Приклонский:
Цитата:
Оператор GOTO нежелательно использовать именно в текстовых языках, так как контроль за соблюдением структурности программы остается за исполнителем (программистом). В языке ДРАКОН есть свои собственные правила, позволяющие сохранять структурность.[20]


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

При описанных условиях ввод оператора GOTO не представляет никакой опасности. Он не приведет к нарушению структурности и появлению «спагетти», так как GOTO будет вводиться в текст целевого языка только автоматически в результате работы транслятора, а не в результате действий человека. Человек будет иметь доступ только к дракон-схеме.
...
Исходя из следующего:
    1) Из ДРАКОНа goto (явный БП) никуда не делся - он из чисто текстового стал "графитным" (как пара "Имя-Адрес"; туда же надо отнести и соединители разрывов линий схем).

    2) В отличие от goto - да, "силуэтно-разрешённый" явный БП уже не произвольный, а вводится по правилам "физического" аранжирования (укладки) маршрутного графа на плоскости.

    3) Это совершенно не означает, что для текстовой записи без явных БП нужно "эмулировать goto". Решение, использованное Дмитрием_ВБ, С. Митькиным (возможно, и П. Приклонским) - это как раз "эмуляция цикла Дейкстры" - т.е. структуры без goto. Уложенной уже не "физически", а "логически" - грамотно разделённой на аранж-блоки, в которые входим не по метке БП (имени ветки), а по условию выбора блока.

В общем и целом:
    а) Понятие "мерности" приложимо только к укладке структуры в заданном пространстве (без пересечений), оно не связано с формой записи структуры (текст/схема). Шампур-метод использует принцип двумерной укладки "через соединители" ("притыкая" условный выбор следующей ветки внутрь тела предшествующей - как условие выбора заземлённой лианы), метод Дейкстры - "через разветвители" (внося условие выбора следующей ветви в "шапку" конструкции).
      Эту мысль можно видеть, скажем, на этом рисунке: http://grafit-basis.narod.ru/L3/grafit- ... 2933cd.gif. Просто в позиции ветвления "шапки" маршрут-кросса (индексированы *Рш) на место "фиктивных разветвителей" шампур-силуэта встают реальные вершины Вопрос дейкстрала... :)

    б) Граф и текст являются просто разными формами записи одной и той же "структурированной мысли". Поэтому неправомерно и говорить о том, что граф даёт какие-то особые формальные средства задания/поддержания структурности. Граф-базированная запись столько же нуждается (или не нуждается ;)) в явных БП, сколь и текстобазированная.
      Вот удобство восприятия - да, граф даёт... А как только восстановим явные БП в графе - снова будет возможность "спагетти"... если редактор поддерживает... И никаких чудес по сравнению с текстом. ;)

    в) Можно сказать, что от мерности пространства (реального или абстрактного) зависит способ структуризации. Так, логически одномерное пространство, как-то "лента памяти" информашины, требует выкладки нелинейных структур через соединители (потому в системе команд нужны явные БП - сами по себе и как части команд условного перехода). Но и здесь непринципиально - чистый текст применён для исходной записи структуры или нет.
      А вот дракон-силуэту с его адресами веток как визуализациями команд БП здесь самое эргономичное применение. Как знать - возможно, машины будущего будут иметь "зашивку" лио-ДРАКОН-знакогенератора для визуализации кода в отладочном ("пультовом") режиме?.. ;)

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

Так что не будем "круто менять судьбу goto" для языков высокого уровня (чисто текстовых, нет ли - неважно)...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Вторник, 20 Декабрь, 2011 14:04 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В тексте "Особенности языка ДРАКОН" я пропустил подраздел. Сейчас я вставил пропущенное. Теперь текст "Особенности языка ДРАКОН" можно считать завершенным.
Для удобства чтения дублирую пропущенный подраздел ниже


План развития и частичной унификации языков программирования

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

        1.Использовать графический синтаксис языка ДРАКОН в качестве стандарта, позволяющего осуществить частичную унификацию языков высокого уровня.

        2.Текстовый синтаксис следует заимствовать из целевого языка. При этом следует удалить все элементы текстового синтаксиса, которые заменяются управляющей графикой ДРАКОНа.

        3.Преобразовать языки высокого уровня в гибридные языки. Метод преобразования описан в источниках.[23][24]


Как показывают первые опыты подобной работы, переход от языков высокого уровня к гибридным языкам свидетельствует о заметном повышении производительности труда.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Среда, 21 Декабрь, 2011 07:14 
Модератор
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Четверг, 22 Декабрь, 2011 14:18 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
А как Вы думаете по опыту (м.б. можете формально обосновать) - в принципе значимого повышения производительности не будет происходить от перехода к описанию структуры графово? или нужно просто по каким-то другим принципам строить графовый язык?..

И взаимосвязанно - корректно ли говорить, что в техноязыке есть правила сохранения структурности, а в текстовых (или нешампур-графовых) языках "контроль за соблюдением структурности программы остается за исполнителем (программистом)"?.. В частности - можем ли мы считать структурирование маршрутов в цикле Дейкстры за такое же "двумерное структурное программирование" - возможное что в чистом тексте, что с использованием графов?.. И вообще - надо ли сопрягать мерность со структурностью?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Четверг, 22 Декабрь, 2011 15:34 
Модератор
Аватара пользователя

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

2) Говорить "контроль за соблюдением структурности программы остается за исполнителем (программистом)" я думаю, некорретктно. Очень мутное высказывание.

3) Возможности выражения не-вложенно-блочных структур в программе в текстовом представлении, конечно, ограничены. И тут, опять же, сфера применения - оно бывает очень нужно в "поведенческих" алгоритмах (потому что сильно их проясняет), но совершенно не актуально в обычных.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 14:35 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Илья Ермаков писал(а):
1) Я думаю, что эффект от графового представления есть только тогда, когда оно делает явным что-то, что оказывается неявным в тексте.
Аналогично. :)
Илья Ермаков писал(а):
...
Для вычислительных программ в структуре поведения прояснять особо нечего. Зато там может быть полезным прояснять структуру зависимостей данных при вычислениях. Так что.... можно на эту тему поразмышлять.
В общем, не граф управления - а граф вычислений (потоков данных). Уже поразмышлял в своё время здесь в конце пункта (возникло прежде всего как результат объяснить "прямое" программирование табличных вычислений). Схема действий может строиться как упрощение ДПД-схемы (исключая указание исполнителей, если подразумевается единоличный вычислитель).
Возможно, у Вас схожие представления?..

Илья Ермаков писал(а):
...
2) Говорить "контроль за соблюдением структурности программы остается за исполнителем (программистом)" я думаю, некорретктно. Очень мутное высказывание.
Об чём и говорю... править надо... :wink: Как Вы полагаете, такая формулировка пойдёт:
Владислав Жаринов в viewtopic.php?f=62&t=3303&start=20#p68763 писал(а):
...
Смысл замечания - не нужно наделять ДРАКОН или вообще граф-базированные языки представления отчуждаемых знаний, как и реализации этих языков, некими уникальными свойствами структурности. На самом деле грамотное определение и реализация текстобазированного ЯПЗ (или граф-базированного - но не "по шампуру"), как мы видим, дают тот же эффект. Т.е. контроль за структурностью максимально перекладывается на редактор.
...


Илья Ермаков писал(а):
...
3) Возможности выражения не-вложенно-блочных структур в программе в текстовом представлении, конечно, ограничены. И тут, опять же, сфера применения - оно бывает очень нужно в "поведенческих" алгоритмах (потому что сильно их проясняет), но совершенно не актуально в обычных.
Наверное, и вложенно-блочные эргономичнее выражать специальными средствами... скажем, как здесь: viewtopic.php?f=79&t=3383&p=68848#p68848 (в левом нижнем окне интерфейса). :) А вообще лучше опять же графами - типа как тут: http://grafit-basis.narod.ru/L3/part_vi ... il3-n122?..

Кстати, ежели бы профессиональные читатели "Современного компьютера" тогда же в середине 1980-х взяли бы на заметку ПЕКАН-представления - м.б. у нас пораньше была бы графит-система приличная... и не только для Бисера... ;)

Не-вложенно-блочные - это типа схем взаимосвязи программных частей, о чём здесь: viewtopic.php?p=63138#p63138? Или что-то другое?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Пятница, 23 Декабрь, 2011 14:57 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Владимир Паронджанов писал(а):
...
План развития и частичной унификации языков программирования

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

        1.Использовать графический синтаксис языка ДРАКОН в качестве стандарта, позволяющего осуществить частичную унификацию языков высокого уровня.

...
Ну и опять - стандарт исходит из представления о составе простых и составных конструкций языка. Каковое успешно выражается и чистым текстом (формальным) - как здесь: https://sites.google.com/site/purebuilder/#TOC-10.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 25 Декабрь, 2011 08:44 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Тут надо, видимо, пояснить кое-что. Для начала снова используем предложенный текст:
Владимир Паронджанов в viewtopic.php?f=62&t=3722#p68728 писал(а):
...
9.Многие ограничения и запреты, неизбежные при текстовом структурном программировании, во многих случаях противоречат здравому смыслу, затрудняют понимание алгоритмов и программ, искажают нормальный ход человеческой мысли.

10.Недопустимо запрещать правильный процесс мышления. Его надо разрешить. Шампур-метод и язык ДРАКОН устраняют этот недостаток.
Ну, про 10) и сказать нечего - естественная эргономическая позиция. Вопрос в том, что считать правильным процессом... :) И тут настоятельное требование к 9) - вместо неопределённого "многие" написать "а именно" - и перечислить ограничения и запреты, наделяемые указанными в пункте свойствами.

Владимир Паронджанов в viewtopic.php?f=62&t=3722#p68728 писал(а):
...
1.Процедурная часть языка ДРАКОН опирается на новый метод – двумерное структурное программирование.

2.Правила двумерного структурного программирования существенно отличаются от традиционного одномерного (текстового) структурного программирования.

3.Идеи структурного программирования разрабатывались, когда компьютерная графика фактически еще не существовала и основным инструментом алгоритмиста и программиста был одномерный (линейный или ступенчатый) текст.
Текст - да, принципиально одномерен. Но значит ли это, что на нём не выражались многомерности? IMHO - нет, не значит. Так что традиционная (текстовая) запись структур (в частности, в программировании) не была (и не есть, и не будет) только одномерной.
    Что показывает и Ваш пример с силуэтом на текстовом языке: viewtopic.php?p=47472#p47471. Фактически Вы задали формат ШМ-текста для силуэта.
    Кстати, дракон-схема там ШМ-тексту не соответствует... ;)
Средства же выражения неодномерности в линейной записи различны. Отчасти это зависит от иерархии описаний - как в статье здесь: viewtopic.php?f=86&t=3317&p=61330&hilit=+%D0%9A%D0%B0%D0%B3%D0%B0%D0%BD#p61330. Но не только. Так, для описания тех же [микро]операций существовал "птичий язык" (называю так потому, что в основном употреблялся в ПТЦА - есть такая дисциплина :)). И там вообще всё писалось в строку (без интендаций). А для показа не-естественных (в этом смысле: viewtopic.php?p=52447#p52447) переходов применялись, разумеется, метки (эквивалент в ШМ-тексте - оператор 'ВЕТКА '<имя-ветки>). Только команды перехода (эквивалент в ШМ-тексте - оператор 'АДРЕС '<имя-ветки>) писались как знак "стрелка" - после которого шёл адрес (эквивалент в ШМ-тексте - параметр <имя-ветки>).
    И упомянутый ШМ-текст в ПТЦА-форме м.б. записан, как показано во вложении (взят фрагмент, соответствующий одной ветке):
    Вложение:

    Ну и скриншот того же (ибо стрелка - знак нестандартный):
    Вложение:
    Текст Силуэт Поездка на автобусе - фрагмент.png
    Текст Силуэт Поездка на автобусе - фрагмент.png [ 54.55 КБ | Просмотров: 11515 ]
Ясно, что эргономика этого текста не ахти какая. Кстати, поэтому в реальном ПТЦА-языке применялась литерация - операторы индексировались (как алфавитные знаки у Вас или у меня), и в ПТЦА-тексте писались индексы. Ну и обходились без "операторно-закрывающих" ключевых слов - все "открывающие" слова тоже трактуются как метки (или явно помечаются), а вместо "закрывающих" - тоже стрелки на эти метки... Эа счёт этого ПТЦА-текст становился короче, а его структура - более очевидной.
Но возможности двумерного представления (текстового) это никак не отменяет. Одномерным было бы представление, не допускающее никаких переходов. Но в этом случае в нём м.б. выражены только линейные структуры...

Итак, давайте отделять "логическую" мерность от "физической". Физически одномерный текст без формальных проблем представляет логически неодномерные структуры - при наличии адекватных выразительных средств. Вопрос лишь в эргономичности такого представления.
Отсюда - надо говорить просто о текстовом или графовом структурном программировании. И отдельно - о проблемах представления человеку неодномерных структур текстом или графикой. В частности, эргономических.
Как попытка решить их, сохраняя чисто текстовую запись, возникло двумерное (физически) текстовое программирование - с операторными скобками (и/или эмулирующими их ключевыми словами), интендациями, переносом строк.
У Вас (как и у Дейкстры на свой лад) - двумерное (опять же физически) графовое. А есть ли физически одномерное графовое? Да - это при ограничении лиоформой, т.е. при обязательной "выкладке" графов в линию. Что обсуждалось для логически одномерных структур здесь: http://drakonografika.narod.ru/L3/linsu ... html#n2211, а для неодномерных - здесь: http://drakonografika.narod.ru/L3/vetvs ... html#n2222 и здесь: http://drakonografika.narod.ru/L3/cikls ... html#n2231. Как видим, здесь снова нужны явные переходы - несмотря на иную форму записи...

Может возникнуть вопрос - если не в "мерности" новизна шампур-подхода, то в чём?.. Прежде всего - в "веточном" способе структурирования графа (как мы видели, имеющем изоморфное текстовое выражение). К этому мы сейчас и перейдём.
Владимир Паронджанов в viewtopic.php?f=62&t=3722#p68728 писал(а):
...
4.До появления компьютерной графики методология текстового структурного программирования была наилучшим решением.

5.С появлением компьютерной графики ситуация изменилась. Появилась возможность заменить текстовые управляющие структуры на управляющую графику, то есть использовать двумерное структурное программирование.

6.Слабое место традиционного структурного программирования и текстового представления алгоритмов и программ заключается в недостатке выразительных средств. Следствием являются ограничения и запреты. Эти ограничения и запреты вытекают из природы текста, из природы текстового представления управляющих структур.

7.Недостаток выразительных средств, проявляющийся через ограничения и запреты, тормозит повышение производительности труда алгоритмистов и программистов.

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

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

Прежде всего нужно снова снять связку мерности с формой записи, как сказано выше.

Далее, в 6)-8) снова не даны ограничения и запреты, от которых избавляет шампур-визуализация.

Наконец, как одно из новых выразительных средств, предлагаемых вместе с переходом к граф-импер-записи, выступали соединители: viewtopic.php?f=79&t=2689&p=61015&hilit=+%D1%81%D0%BE%D0%B5%D0%B4%D0%B8%D0%BD%D0%B8%D1%82%D0%B5%D0%BB%D0%B8#p61015.
При этом предлагалось и расширить их применение: viewtopic.php?f=78&t=3184&p=61769#p61769. Однако такое применение требует уточнения, обсуждавшегося здесь: viewtopic.php?f=78&t=2919&p=63601&hilit=%D1%81%D0%B8%D0%BB%D1%83%D1%8D%D1%82#p63751.
И главное - нужно уточнение, что соединители - это артефакты "нестрогой" визуализации. И не являются операторами целевого языка.

Владимир Паронджанов в viewtopic.php?f=62&t=3722#p68728 писал(а):
...
11.При использовании шампур-метода набор управляющих ключевых слов текстового структурного программирования становится ненужным.

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

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

14.ДРАКОН — это не просто новый язык (новое семейство языков). Это новый взгляд на процедурное программирование. Если угодно — новое мировоззрение.

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

16.Язык ДРАКОН позволил эффективно решить эту задачу.

17.Одновременно была решена задача эргономизации блок-схем, то есть задача приспособления блок-схем для наиболее удобного человеческого восприятия и понимания.[11]
...
По 11) - "и этот тезис не вызывает у меня возражений" (С) 12 стульев. :)

По 12) - так, да не совсем. Не выделены два случая - когда схема является "исходным чертежом" машинного кода (объектного модуля) напрямую, и когда "исходный чертёж" представляет ЯВУ-текст... из которого ещё предстоит получать код. Здесь уже требуется не обращаться и к ЯВУ-тексту... что и сформулировал П. Приклонский: viewtopic.php?f=62&t=3303&p=68763#p68763.

По 13) - да, но именно "заменив", а не "модифицировав". А при представлении ЯВУ-структур шампур-силуэтом возникает вопрос, обсуждавшийся ещё здесь: viewtopic.php?f=62&t=2618&p=47232&hilit=%D1%83%D1%89%D0%B5%D1%80%D0%B1%D0%BD%D1%8B%D0%BC#p47258 и здесь: viewtopic.php?f=62&t=2618&p=52403&hilit=%D1%83%D1%89%D0%B5%D1%80%D0%B1%D0%BD%D1%8B%D0%BC#p52403.
И именно из сказанного о 12) проистекает эта ситуация - ведь силуэт можно рассматривать именно как укладку машкода, где всегда есть чем явно представить ИМЯ и АДРЕС (ветки ли, просто марша, как "М1" в "Поездке на автобусе" - неважно). А ЯВУ-структура в общем случае требует и иного представления - о чём сказал здесь: viewtopic.php?f=62&t=3722#p68766 (прежде всего в а)).

В 14) стоит указать ключевую идею мировоззрения...

По 15) - вот тут мы наконец видим вполне чёткую формулировку цели, средством достижения которой стал шампур-силуэт. Имеется в виду "создать математически строгий метод формализации блок-схем, ... для ... трансляции в объектный модуль программы". Как можно видеть из описания ГРАФИТ-ФЛОКС здесь: viewtopic.php?f=100&t=1091, силуэт именно и визуализирует импер-часть программы в кодах БЦВМ. Т.е. представление на текстовом ЯВУ между ними отсутствует. В случае же визуализации ЯВУ-текста без явных БП как раз возникает необходимость в "логической укладке" маршрутов. Что и предложено ещё Дейкстрой и воплощено здесь: http://grafit-basis.narod.ru/L3/grafit- ... l#GR-n1414. И, кстати, без проблем выводится по ШМ - описано здесь: http://drakonografika.narod.ru/L3/cikls ... html#n2231.
Отсюда - нужно выделить два случая:
    * допускается явный БП (типичный машинный код, ЯВУ с goto);
    * не допускается явный БП (ЯВУ без goto, инженерное программирование на языке любого рода).
И показать, что во втором случае применяется метод Дейкстры (на основе ввода атомов). И привлекается текст развилок - для логически правильного структурирования.

И в общем - не забывать указывать, что всё это относится к структурированию маршрутов. А об остальных составляющих смысла информодели деятельности (программы, "бизнес-процесса") разговор отдельный...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Особенности языка ДРАКОН
СообщениеДобавлено: Воскресенье, 25 Декабрь, 2011 10:28 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Итак, из предыдущего видно, что без учёта различных возможностей представления маршрутов применимость шампур-метода для визуализации будет ограниченной. Хотя ясно, что это не внутренние ограничения метода. :)

А кроме того, есть ещё один аспект - зависимость от характера задачи. О чём говорил Илья:
Владислав Жаринов писал(а):
Илья Ермаков в viewtopic.php?f=62&t=3722#p68824 писал(а):
1) Я думаю, что эффект от графового представления есть только тогда, когда оно делает явным что-то, что оказывается неявным в тексте.
Аналогично. :)
Илья Ермаков писал(а):
...
Для вычислительных программ в структуре поведения прояснять особо нечего. Зато там может быть полезным прояснять структуру зависимостей данных при вычислениях. Так что.... можно на эту тему поразмышлять.
В общем, не граф управления - а граф вычислений (потоков данных). Уже поразмышлял в своё время здесь в конце пункта (возникло прежде всего как результат объяснить "прямое" программирование табличных вычислений). Схема действий может строиться как упрощение ДПД-схемы (исключая указание исполнителей, если подразумевается единоличный вычислитель).
...
И тут надо учесть, что схема действий ещё д.б. "развёрнута" в алгоритм - т.е. это доалгоритмическая информодель. С учётом рассмотренного здесь: viewtopic.php?f=6&t=1454&p=27265&hilit=+%D1%88%D1%83%D1%80%D1%83%D1%8E%D1%82#p27265
Илья Ермаков писал(а):
...
Суть в том, что мы имеем множество (взаимо)действующих объектов, но при этом они приводятся в движение только одним (или небольшим количеством) потоков выполнения. И эти потоки "шуруют" насквозь через граф из огромного числа обьектов.

Однако естественно ждать перехода к нормальной ситуации, когда "каждый объект сможет поиграть собственным мячом" (С) "Хоттабыч". Собственно, это уже и наблюдается. Параллельное ООП на сообщениях, в котором вместо глубоких вызовов будет активация параллельного исполнителя. Собственно, у швейцарцев в Композите технически такая возможность уже обеспечена - когда вместо вызова процедуры в большинстве случаев идёт активация исполнителя (до миллионов...). До этого таким мог похвастаться Эрланг, но там таки не предлагалось такого упора на замену вспомогательных алгоритмов на параллельных исполнителей.
...
и здесь: viewtopic.php?f=86&t=3606&p=66491&hilit=+%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%BB%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE#p66491
alexus писал(а):
...
Драконограф писал(а):
И как раз это к вопросу: так каким же языком описывать, чтобы параллельное исполнение отразить?
А зачем его [параллельное исполнение] отражать? По умолчанию принимаем, что любые действия выполняются параллельно, и только если возникают зависимости по данным (полуфабрикатам, если говорим о производстве), то тогда выстраиваем последовательность на основании выявленных зависимостей. Как в производстве... мы не можем подать полуфабрикат на следующую операцию, если он ещё не готов. Таким образом, текущая операция предваряет следующую. Если бы на следующей операции обрабатывался тот же самый полуфабрикат, что и на текущей, то эти операции выполнялись бы параллельно. Если подпрограмме нужен отсортированный массив, а он в данный момент не отсортирован, то сначала надо вызвать подпрограмму сортировки... Вот и зависимость...
...


Т.е. либо строим алгоритм "обхода графа зависимостей одним или немногими исполнителями" - либо назначаем исполнителя каждой опер-вершине графа. И здесь будет снова существенна актив-модель (как говорит alexus, "граф производственных мощностей" или "схема распространения воздействий")...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Унификация языков
СообщениеДобавлено: Воскресенье, 25 Декабрь, 2011 13:22 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Теперь вернёмся к этому:
Владимир Паронджанов в viewtopic.php?p=68799#p68799 писал(а):
План развития и частичной унификации языков программирования Опыт разработки и использования языка ДРАКОН позволяет предложить план развития и частичной унификации языков высокого уровня из трех пунктов. 1.Использовать графический синтаксис языка ДРАКОН в качестве стандарта, позволяющего осуществить частичную унификацию языков высокого уровня. 2.Текстовый синтаксис следует заимствовать из целевого языка. При этом следует удалить все элементы текстового синтаксиса, которые заменяются управляющей графикой ДРАКОНа.3.Преобразовать языки высокого уровня в гибридные языки. Метод преобразования описан в источниках.[23][24]

Практически возможны два пути гибридизации. Назову их условно "симультанным" и "сукцессивным".
От уровня языка они не зависят. Но зависят от одной вещи - степени формальности синтаксиса целевого языка (по его определению). Так что предварительно может понадобиться дать более строгое определение в каких-то аспектах.

В случае симультанного дело обстоит внешне просто :). Берём определение исходного языка, выделяем в нём составляющие согласно генклассификации и совместно переводим определения структуры каждой составляющей (ген-смысла, "интегральной", парадигмо-зависимой - и частно-"дифференциальных" - импер-, деклар-, актив-) на графовую основу. В выбранном для данной части роде топологии граф-схем - структур-классе в терминах графит-метода - м.б. заданном по собственному усмотрению. Ну и атрибутивные определения сопоставляем вершинам (м.б. и рёбрам) схем как разметку.
Так же можно определить "частно-интегрирующие" представления - те же "разрезы и сечения". В сущности, они должны определять прежде всего "межпредметные" и "внутрипредметные" связи составляющих - дабы удобнее было прослеживать, как говорит Илья, "то, что неявно в тексте".
На самом деле, конечно, работа идёт попременно над разными представлениями. И получается система графит-языков (ну или подъязыков).

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

Можно изложить это и как рекурсивный алгоритм :):
Код:
ЗАДАЧА Гибридизировать текстовый инфор-язык (* сокращённо - ТИЯ*)
ПАРМ Определение ТИЯ, Определение ГИЯ, Опыт гибридизации;
   НАЧ Определение ТИЯ имеет формальный синтаксис?=ДА;
   НАЧ В определении ТИЯ выделены составляющие по генклассификации?=ДА;
   ПОКА В определении ТИЯ НЕ исчерпаны составляющие по генклассификации?=ДА ПОВТОРЯТЬ
      ВЗЯТЬ очередную составляющую;
      ВЫДЕЛИТЬ её структурную часть И её атрибутивную часть (как дополнение);
      ПЕРЕВЕСТИ структурную часть из текстовой формы в графовую;
      СОПОСТАВИТЬ атрибутивную часть графу как текстоэлементы разметки вершин/рёбер;
      УСТАНОВИТЬ связи данной составляющей с другими заново;
      СЧИТАТЬ результат ЗА Определение ГИЯ;
      СОХРАНИТЬ Опыт гибридизации . Определения;
   КЦ ПОКА
   ЕСЛИ Структура связей в языке сложна для понимания?=ДА
   ТО
      ПОКА В определении ТИЯ НЕ исчерпаны аспекты сложности структуры?=ДА ПОВТОРЯТЬ
         ВЗЯТЬ очередной аспект;
         ВЫДЕЛИТЬ его структурную часть И его атрибутивную часть (как дополнение);
         ПЕРЕВЕСТИ структурную часть из текстовой формы в графовую;
         СОПОСТАВИТЬ атрибутивную часть графу как текстоэлементы разметки вершин/рёбер;
         УСТАНОВИТЬ связи данного аспекта с составляющими определения;
         СЧИТАТЬ результат ЗА Определение ГИЯ;
         СОХРАНИТЬ Опыт гибридизации . Сложности;
      КЦ ПОКА
   ВСЁ ЕСЛИ
   ЕСЛИ Когнитивное качество определения достаточно?=НЕТ
   ТО
      ВЫЗОВ Гибридизировать текстовый инфор-язык (Определение ТИЯ, Определение ГИЯ, Опыт гибридизации)
   ВСЁ ЕСЛИ
   КОН Определение изоморфно формальному синтаксису ТИЯ?=ДА;
КЗ Гибридизировать текстовый инфор-язык.
Оно, конечно, немного шутливое, но частично информатизует суть дела.

Заметим ещё вот какие обстоятельства:

1) За начальную гибридизируемую при сукцессивном пути можно выбрать любую составляющую смысла целевого инфор-языка. Паронджанов выбирает императивную, т.к. разработал изначально визуализацию её как дракон-схем. Валерий Лаптев выбрал ген-составляющую, имея понимание, как визуализировать её в форме АСД. Можно также взять деклар-составляющую, скажем, как АТ-схемы; кто поразмыслит над этим примером: http://grafit-basis.narod.ru/L3/part_vi ... Pril3-n122 - сообразит, куда "приткнуть" и импер-, и актив-составляющие в форме текста :). Можно пойти и от актив-составляющей; здесь путь указывают соображения alexus.

2) Как представляется, есть предпочтительный род топологии для отражения каждой составляющей; своё видение отразил в назначении структур-классов в графит-методе. М.б. где-то он не единственный.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 12 ] 

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


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

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


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

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