Контент, который может быть интересен каждому. Без ограничений по темам, форматам и стилям подачи.
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. Понятно, что исходником служит дракон-схема. При отладке программы не следует вносить исправления в промежуточные текстовые Си-файлы. Все исправления нужно вносить в исходный код, то есть в дракон-схему.
Подробнее см. [16]
[править] Достоинства гибридных языков
С точки зрения человеческого фактора, в истории развития языков программирования условно можно выделить два этапа.
На первом этапе появились языки высокого уровня, которые по сравнению ассемблером сделали исходный текст программы более понятным и удобным для человека. И значительно увеличили производительность труда программистов.
На втором этапе (который, по-видимому, только начинается) некоторые языки высокого уровня смогут работать в сочетании с языком ДРАКОН, образуя гибридные языки. При этом функция исходного кода программы переходит к дракон-схемам.
Это позволит отказаться от текстовых управляющих структур, используемых в языках высокого уровня, и заменить их на управляющую графику ДРАКОНа.
Что это даст? Исходный код программы станет еще более понятным и удобным для человека. И, следовательно, еще больше увеличится производительность труда программистов.
Как и все прочие языки, ДРАКОН опирается на математику и логику. Однако сверх того, он самым тщательным образом учитывает когнитивные вопросы. Благодаря систематическому использованию когнитивно-эргономических методов ДРАКОН приобрел уникальные эргономические характеристики. Можно предположить, что в будущем ДРАКОН сможет претендовать на звание чемпиона по критерию «понимаемость алгоритмов и программ» (в классе императивных языков) .
ДРАКОН можно определить как общедоступный визуальный язык, предназначенный для описания структуры деятельности, для систематизации, структуризации, наглядного представления и формализации императивных знаний, а также для проектирования, программирования, моделирования и обучения.
Человечность языка ДРАКОН, стремление создать максимальный комфорт для работы человеческого мозга, всемерная забота о повышении творческой продуктивности персонала позволяет надеяться, что ДРАКОН получит . широкое применение в народном хозяйстве, бизнесе, обороне, науке и системе образования.
Используя не просто наглядные, а предельно наглядные формы представления знаний, облегчая работу мозга, ДРАКОН обеспечивает заметный рост производительности интеллектуального труда.
В основе языка ДРАКОН лежит идея когнитивной формализации знаний, позволяющая сочетать строгость логико-математической формализации с точным учетом когнитивных (познавательных) характеристик человека.[17]
[править] Гибридные языки ДРАКОН-семейства и оператор GOTO
Чтобы глубже понять роль оператора GOTO, можно выделить два этапа в истории развития языков программирования.
На первом этапе — после изобретения структурного программирования и призыва Эдсгера Дейкстры: «оператор go to должен быть отменен в языках программирования высокого уровня» [18] — начался процесс исключения GOTO из вновь создаваемых языков. Сегодня имеется целый ряд языков без GOTO: Java, Python, Tcl, Модула-2, Оберон и др.
На втором этапе появился язык ДРАКОН, в котором исключен не только GOTO, но и все остальные текстовые управляющие операторы. Начался постепенный переход к гибридным языкам с целью дальнейшего повышения производительности труда.
При этом открылись два обстоятельства. Транслятор из ДРАКОНа в целевой язык лучше всего делать с использованием GOTO, имеющемся в целевом языке. Если же оператор GOTO в целевом языке отсутствует, этот оператор приходится эмулировать. Это можно сделать, например, так.[19]
Подобная эмуляция оператора GOTO вносит ненужные трудности. Эти трудности сразу исчезают, если в целевом языке есть оператор GOTO. Следовательно, с точки зрения языка ДРАКОН, было бы лучше, если бы в целевом языке был предусмотрен оператор GOTO.
Как отмечает Петр Приклонский:
Отсюда следует предположительный вывод. Если гибридные языки ДРАКОН-семейства ощутимо повысят производительность труда программистов и со временем получат широкое распространение, это может послужить достаточным основанием, чтобы судьба оператора GOTO снова круто изменилась. Это значит, что в языки высокого уровня, по-видимому, снова будет введен некогда изгнанный оттуда оператор GOTO.
При описанных условиях ввод оператора GOTO не представляет никакой опасности. Он не приведет к нарушению структурности и появлению «спагетти», так как GOTO будет вводиться в текст целевого языка только автоматически в результате работы транслятора, а не в результате действий человека. Человек будет иметь доступ только к дракон-схеме.
В свою очередь, дракон-схема имеет надежную защиту от подобных неприятностей благодаря использованию ДВУМЕРНОГО структурного программирования. Принципы двумерного структурного программирования подробно описаны в литературе.[21][22][22а]
[править] План развития и частичной унификации языков программирования
Опыт разработки и использования языка ДРАКОН позволяет предложить план развития и частичной унификации языков высокого уровня из трех пунктов.
2.Текстовый синтаксис следует заимствовать из целевого языка. При этом следует удалить все элементы текстового синтаксиса, которые заменяются управляющей графикой ДРАКОНа.
[править] Целесообразно создать международный стандарт на дракон-схемы
Обоснование необходимости нового стандарта поясняется ниже.
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 раз(а).
Это текст для Википедии.Прошу критиковать.. Литература
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. Понятно, что исходником служит дракон-схема. При отладке программы не следует вносить исправления в промежуточные текстовые Си-файлы. Все исправления нужно вносить в исходный код, то есть в дракон-схему.
Подробнее см. [16]
[править] Достоинства гибридных языков
С точки зрения человеческого фактора, в истории развития языков программирования условно можно выделить два этапа.
На первом этапе появились языки высокого уровня, которые по сравнению ассемблером сделали исходный текст программы более понятным и удобным для человека. И значительно увеличили производительность труда программистов.
На втором этапе (который, по-видимому, только начинается) некоторые языки высокого уровня смогут работать в сочетании с языком ДРАКОН, образуя гибридные языки. При этом функция исходного кода программы переходит к дракон-схемам.
Это позволит отказаться от текстовых управляющих структур, используемых в языках высокого уровня, и заменить их на управляющую графику ДРАКОНа. .
Соответственно все "обычные" языки высокого уровня (как и Ассемблеры) нужно так и называть - "чисто текстовыми". И не забывать, что и машинные коды также м.б. визуализированы - и здесь естественная сфера приложения дракон-силуэта.
Переписывать весь проблемный текст самому - IMHO, как бэ неуважение к Владимиру Даниеловичу будет. при отсутствии явной просьбы. так что только обозначаю.
В таком контексте будет хорошо и упомянуть результаты того же Ярослава (о "дереве таблиц", конечно - не о текстовке непроцедурной части в комментариях ). В том ключе, что они не просто повторяют техноязык, а развивают его до прогязыка. Именно в видах поднять авторитетность как источника для статьи. Об АТ-языке не говорю - это не стоит прямо сейчас "на реализацию". А в Википедии, по моему впечатлению, это будет на первом месте при определении АИ по такому вопросу. Да, и не забыть сказанное Валерием здесь (когда будет что показать "в коде").
В общем, уточнять, что ДРАКОН - не "обёртка" для прогязыка, а форма записи для его процедурной части. Пока всё - но это самое важное.
. [править] Гибридные языки ДРАКОН-семейства и оператор GOTO
Чтобы глубже понять роль оператора GOTO, можно выделить два этапа в истории развития языков программирования.
На первом этапе — после изобретения структурного программирования и призыва Эдсгера Дейкстры: «оператор go to должен быть отменен в языках программирования высокого уровня» [18] — начался процесс исключения GOTO из вновь создаваемых языков. Сегодня имеется целый ряд языков без GOTO: Java, Python, Tcl, Модула-2, Оберон и др.
На втором этапе появился язык ДРАКОН, в котором исключен не только GOTO, но и все остальные текстовые управляющие операторы. Начался постепенный переход к гибридным языкам с целью дальнейшего повышения производительности труда.
При этом открылись два обстоятельства. Транслятор из ДРАКОНа в целевой язык лучше всего делать с использованием GOTO, имеющемся в целевом языке. Если же оператор GOTO в целевом языке отсутствует, этот оператор приходится эмулировать. Это можно сделать, например, так.[19]
Подобная эмуляция оператора GOTO вносит ненужные трудности. Эти трудности сразу исчезают, если в целевом языке есть оператор GOTO. Следовательно, с точки зрения языка ДРАКОН, было бы лучше, если бы в целевом языке был предусмотрен оператор GOTO.
Как отмечает Петр Приклонский:
Отсюда следует предположительный вывод. Если гибридные языки ДРАКОН-семейства ощутимо повысят производительность труда программистов и со временем получат широкое распространение, это может послужить достаточным основанием, чтобы судьба оператора GOTO снова круто изменилась. Это значит, что в языки высокого уровня, по-видимому, снова будет введен некогда изгнанный оттуда оператор GOTO.
При описанных условиях ввод оператора GOTO не представляет никакой опасности. Он не приведет к нарушению структурности и появлению «спагетти», так как GOTO будет вводиться в текст целевого языка только автоматически в результате работы транслятора, а не в результате действий человека. Человек будет иметь доступ только к дракон-схеме..
2) В отличие от goto - да, "силуэтно-разрешённый" явный БП уже не произвольный, а вводится по правилам "физического" аранжирования (укладки) маршрутного графа на плоскости.
В тексте "Особенности языка ДРАКОН" я пропустил подраздел. Сейчас я вставил пропущенное. Теперь текст "Особенности языка ДРАКОН" можно считать завершенным.Для удобства чтения дублирую пропущенный подраздел ниже
План развития и частичной унификации языков программирования
Опыт разработки и использования языка ДРАКОН позволяет предложить план развития и частичной унификации языков высокого уровня из трех пунктов.
2.Текстовый синтаксис следует заимствовать из целевого языка. При этом следует удалить все элементы текстового синтаксиса, которые заменяются управляющей графикой ДРАКОНа.
Как показывают первые опыты подобной работы, переход от языков высокого уровня к гибридным языкам свидетельствует о заметном повышении производительности труда.
Владимир Даниелович, чтобы Ваше высказывание было безупречным, я бы рекомендовал подправить его так:".. о заметном повышении производительности труда для ряда категорий задач (таких, как управляющие и реагирующие компоненты ПО и алгоритмы бизнес-логики)".
Потому что опыт так же говорит о том, что есть классы задач, где значимого повышения производительности не происходит (алгоритмы вычислений и обработки данных - "обычные" алгоритмы).
А как Вы думаете по опыту (м.б. можете формально обосновать) - в принципе значимого повышения производительности не будет происходить от перехода к описанию структуры графово? или нужно просто по каким-то другим принципам строить графовый язык.
И взаимосвязанно - корректно ли говорить, что в техноязыке есть правила сохранения структурности, а в текстовых (или нешампур-графовых) языках "контроль за соблюдением структурности программы остается за исполнителем (программистом)". В частности - можем ли мы считать структурирование маршрутов в цикле Дейкстры за такое же "двумерное структурное программирование" - возможное что в чистом тексте, что с использованием графов. И вообще - надо ли сопрягать мерность со структурностью.
1) Я думаю, что эффект от графового представления есть только тогда, когда оно делает явным что-то, что оказывается неявным в тексте. Граф управления для реактивных программ проясняет структуру поведения программы - все возможные маршруты, "грамматику событий". Для вычислительных программ в структуре поведения прояснять особо нечего. Зато там может быть полезным прояснять структуру зависимостей данных при вычислениях. Так что. можно на эту тему поразмышлять.
2) Говорить "контроль за соблюдением структурности программы остается за исполнителем (программистом)" я думаю, некорретктно. Очень мутное высказывание.
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 ? Или что-то другое.
. План развития и частичной унификации языков программирования
Опыт разработки и использования языка ДРАКОН позволяет предложить план развития и частичной унификации языков высокого уровня из трех пунктов.
. 9.Многие ограничения и запреты, неизбежные при текстовом структурном программировании, во многих случаях противоречат здравому смыслу, затрудняют понимание алгоритмов и программ, искажают нормальный ход человеческой мысли.
10.Недопустимо запрещать правильный процесс мышления. Его надо разрешить. Шампур-метод и язык ДРАКОН устраняют этот недостаток.
Ну, про 10) и сказать нечего - естественная эргономическая позиция. Вопрос в том, что считать правильным процессом. И тут настоятельное требование к 9) - вместо неопределённого "многие" написать "а именно" - и перечислить ограничения и запреты, наделяемые указанными в пункте свойствами.
. 1.Процедурная часть языка ДРАКОН опирается на новый метод – двумерное структурное программирование.
2.Правила двумерного структурного программирования существенно отличаются от традиционного одномерного (текстового) структурного программирования.
3.Идеи структурного программирования разрабатывались, когда компьютерная графика фактически еще не существовала и основным инструментом алгоритмиста и программиста был одномерный (линейный или ступенчатый) текст.
Итак, давайте отделять "логическую" мерность от "физической". Физически одномерный текст без формальных проблем представляет логически неодномерные структуры - при наличии адекватных выразительных средств. Вопрос лишь в эргономичности такого представления. Отсюда - надо говорить просто о текстовом или графовом структурном программировании. И отдельно - о проблемах представления человеку неодномерных структур текстом или графикой. В частности, эргономических. Как попытка решить их, сохраняя чисто текстовую запись, возникло двумерное ( физически ) текстовое программирование - с операторными скобками (и/или эмулирующими их ключевыми словами), интендациями, переносом строк.У Вас (как и у Дейкстры на свой лад) - двумерное (опять же физически ) графовое. А есть ли физически одномерное графовое? Да - это при ограничении лиоформой, т.е. при обязательной "выкладке" графов в линию. Что обсуждалось для логически одномерных структур здесь: http://drakonografika.narod.ru/L3/linsu . html#n2211 , а для неодномерных - здесь: http://drakonografika.narod.ru/L3/vetvs . html#n2222 и здесь: http://drakonografika.narod.ru/L3/cikls . html#n2231 . Как видим, здесь снова нужны явные переходы - несмотря на иную форму записи.
Может возникнуть вопрос - если не в "мерности" новизна шампур-подхода, то в чём. Прежде всего - в "веточном" способе структурирования графа (как мы видели, имеющем изоморфное текстовое выражение). К этому мы сейчас и перейдём.
. 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 . И главное - нужно уточнение, что соединители - это артефакты "нестрогой" визуализации. И не являются операторами целевого языка.
. 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) стоит указать ключевую идею мировоззрения.
И в общем - не забывать указывать, что всё это относится к структурированию маршрутов. А об остальных составляющих смысла информодели деятельности (программы, "бизнес-процесса") разговор отдельный.
Итак, из предыдущего видно, что без учёта различных возможностей представления маршрутов применимость шампур-метода для визуализации будет ограниченной. Хотя ясно, что это не внутренние ограничения метода.
А кроме того, есть ещё один аспект - зависимость от характера задачи. О чём говорил Илья:
. Суть в том, что мы имеем множество (взаимо)действующих объектов, но при этом они приводятся в движение только одним (или небольшим количеством) потоков выполнения. И эти потоки "шуруют" насквозь через граф из огромного числа обьектов.
Однако естественно ждать перехода к нормальной ситуации, когда "каждый объект сможет поиграть собственным мячом" (С) "Хоттабыч". Собственно, это уже и наблюдается. Параллельное ООП на сообщениях, в котором вместо глубоких вызовов будет активация параллельного исполнителя. Собственно, у швейцарцев в Композите технически такая возможность уже обеспечена - когда вместо вызова процедуры в большинстве случаев идёт активация исполнителя (до миллионов. ). До этого таким мог похвастаться Эрланг, но там таки не предлагалось такого упора на замену вспомогательных алгоритмов на параллельных исполнителей..
Т.е. либо строим алгоритм "обхода графа зависимостей одним или немногими исполнителями" - либо назначаем исполнителя каждой опер-вершине графа. И здесь будет снова существенна актив-модель (как говорит alexus, "граф производственных мощностей" или "схема распространения воздействий").
Практически возможны два пути гибридизации. Назову их условно "симультанным" и "сукцессивным". От уровня языка они не зависят. Но зависят от одной вещи - степени формальности синтаксиса целевого языка (по его определению). Так что предварительно может понадобиться дать более строгое определение в каких-то аспектах.
Можно изложить это и как рекурсивный алгоритм :
Оно, конечно, немного шутливое, но частично информатизует суть дела.
Заметим ещё вот какие обстоятельства:
1) За начальную гибридизируемую при сукцессивном пути можно выбрать любую составляющую смысла целевого инфор-языка. Паронджанов выбирает императивную, т.к. разработал изначально визуализацию её как дракон-схем. Валерий Лаптев выбрал ген-составляющую, имея понимание, как визуализировать её в форме АСД. Можно также взять деклар-составляющую, скажем, как АТ-схемы; кто поразмыслит над этим примером: http://grafit-basis.narod.ru/L3/part_vi . Pril3-n122 - сообразит, куда "приткнуть" и импер-, и актив-составляющие в форме текста . Можно пойти и от актив-составляющей; здесь путь указывают соображения alexus.
2) Как представляется, есть предпочтительный род топологии для отражения каждой составляющей; своё видение отразил в назначении структур-классов в графит-методе. М.б. где-то он не единственный.
Часовой пояс: UTC + 3 часа
Кто сейчас на конференцииСейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0
Платформа предназначена для свободного распространения информации, собранной из доступных сетевых источников. Мы стремимся дать пользователю выбор и разнообразие, не навязывая тематику и формат.
Дайджесты по темам, вызывающим интерес у широкой аудитории.
Справочная информация по бытовым, культурным, технологическим вопросам.
Подборки контента, отобранного по тематике и релевантности.
Хронологическая лента публикаций без ограничений доступа.
📍 г. Челябинск, ул. Рубежная, д. 5, офис 122
☎ +7 (351) 800-54-91
📧 info@site.ru
🕓 Время приёма: ежедневно с 09:00 до 21:00
Сайт использует контент, размещённый в открытом доступе. Мы не проверяем его происхождение вручную и не редактируем содержимое. Материалы обрабатываются в автоматическом режиме.
Если вы считаете, что ваши права нарушены, пожалуйста, сообщите нам — информация будет проверена и при необходимости удалена.
Ресурс не является СМИ и не осуществляет журналистскую деятельность.