DRAKON.SU

Модератор: Обсуждение использования псевдокода вместо ДРАКОН-схем вынесено из темы "Пример алгоритма на ДРАКОНе" (viewtopic.php?f=62&t=957).

См. viewtopic.php?p=28448#p28448.

Псевдокод не пробовали использовать?
Извиняюсь за резкость (это мой первый пост), но вы что, тут ослепли все?
Люди восторгаются БЛОК-СХЕМАМИ!
Ребята, ну вы хоть Брукса для начала почитайте, что ли. Вот ссылка http://www.podgoretsky.com/ftp/Docs/Misc/brooks/XV.htm , раздел Несостоятельность блок-схем

Надеюсь меня сразу же не забанят

Извините, ДРАКОН это не блок-схемы, это язык программирования.
Эдак и на Обероне можно, другое дело что плакат ДРАКОНа нагляднее.

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

А Вы сами-то читали, Брукса-то? Там, на самом деле, больше вопросов чем ответов. Но вот характерная цитата:


Даже Брукс считает визуализацию алгоритмов полезным делом! А про генерацию программ из "блок-схем", у него ни слова, между прочим...

См. viewtopic.php?p=28639#p28639


Ну да, ДРАКОН это не блок-схемы, это язык программирования
Отсюда, кстати, следует, что блок-схемы - это не язык программирования. Подумайте над этим.
Но даже если считать, что "ДРАКОН это не блок-схемы", у него те же недостатки, что и у блок-схем. Дополню это ссылкой на мнение Вирта: http://blogs.gotdotnet.ru/personal/allo ... d8b3aa598c , с которым я полностью согласен.

На Дракон и форум попал с сайта http://www.computerra.ru. Я там на форуме зарегистрирован как "Пётр А"

Илья, поясните, пожалуйста, что такого фундаментального-автоматного содержится в Драконе? На псевдокоде реализация автомата выглядит так (A):


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

to Peter Almazov
Про "автоматность" дракона здесь есть отдельная тема.
Формальный язык - это алфавит + грамматика (строгие правила построения слов, предложений).
Всё это в ДРАКОНе есть, но алфавит- графический. Это при поверхностном взгляде конечно может вводить в заблуждение. И есть СТРОГИЕ правила соединенная графических элементов в графические же "слова" (макроиконы) и в предложения (в ветви силуэтов, в "примитивы"). И правила эти таковы, что их соблюдение "автоматом" даёт наибольшую понимаемость, эргономичность. В этих правилах, в этом строгом синтаксисе и содержится весь "изюм" ДРАКОНа, его ноу-хау, его "формула открытия", а не в геометрических фигурках самих по себе.
В традиционных блок-схемах есть в лучшем случае только алфавит, обязывающего синтаксиса нет, максимум общие рекомендации того или иного автора. Они не язык, они - свободная иллюстрация вашей мысли. ДРАКОН-схема же не иллюстрация мысли, а сама мысль выраженная в правилах языка, как и в правилах любого другого языка вообще.
А коль скоро разных областей специалисты в лице ДРАКОНА могут говорить по одним правилам, зримым и легко читаемым, то это серьёзно способствует их совместной работе.

Дракон БОЛЬШЕ чем язык программирования, он МОЖЕТ быть языком программирования (и кое-где, там где "делают ракеты", ЕСТЬ), но не обязан, он может служить и для описания рецептов в поваренной книге например или инструкцией для начинающего хирурга по вырезанию аппендикса. Везде, где есть процесс и сложная последовательность действий.

То есть ДРАКОН едва ли не первый из ФОРМАЛЬНЫХ ЯЗЫКОВ, вышедший за область программирования, да ещё и в графической форме. Это вдвойне новое явление, и как всё чересчур новое поначалу вызывает недоумение.

У меня, кроме стыда за уровень российских программистов, которые им восторгаются, Дракон ничего не вызывает.

Вам же жирным по белому сказано: ДРАКОН перекрывает узкую область программирования, выходит за рамки этой области. Так же как UML например. Фейнман, кажется, говаривал "Если какая-то вещь не физика (здесь- не программирование), это не значит что с ней что-то не в порядке." И с ДРАКОНОМ и с программистами всё в порядке.

Ну я понял, что доказывать что-то верующим - бесполезно. Флаг вам в руки. Аналогичных случаев было много, ещё Дейкстра это описывал:

Мы тоже это поняли, про вас.

Ничего, привыкнете.

Верить или не верить это как говорится, личное дело каждого. А вот проявление уважения к труду и устремлениям людей очень характерная черта данного форума. Хорошо бы и Вам этому научиться.

Ну вот и ладушки.

Насколько я понял, первой работой по псевдокоду была:
Harlan D. Mills. How to write correct programs and know it. SIGPLAN Not., 10(6):363–370, 1975.

Только уж очень она неуловимая. Может есть у кого?

Спасибо за ссылку Убедили!!!
Брукс говорит тоже самое что и Паронджанов:
Это прямые цитаты...
Ко второй хочется добавить - а следующий уровень объединения? Когда надо объединить несколько операторов? Опять оператор?

Вероятно, некоторые подходы могут быть найдены в современной лингвистике. Разумеется, при определённых граничных условиях, таких как конечный синтаксис исполнителя. Начать можно с:
Chomsky N. Syntactic Structures (2Ed). 1957. 2002.
Chomsky N. The Minimalist Program. 1995.

Дальше, очевидно, процедура, затем модуль (юнит, библиотека), ну и т.д.

Что интересно, Форт стирает различия между оператором и процедурой, и всё это так легко наращивается, что получается "размазывание" иерархических уровней. Иногда это хорошо

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

Поправочка - Брукс говорит о полезности блок-схем.

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