DRAKON.SU

http://forum.oberoncore.ru/viewtopic.php?p=98471#p98471

У В. Паронджанова есть еще термин ШАМПУР-МЕТОД (глава 36, книга "Учись ...").

Такой же, как термин ШАМПУР-СХЕМА, лишенный смысла термин, вводящий в заблуждение, засоряет язык. Нет примеров его применения, нигде не указан объект приложения метода и смысл его исполнения.

Приходится с сожалением констатировать - изложение языка Дракон засорено терминами паразитами.
---
На форуме видим старые картинки с измененным поясняющими текстами.
Заявлено о написании новой книги.

Пожелание В. Паронжанову: - приведите лексику книги к общепринятой терминологии.

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

Выяснилось, что термин используется в книге 15 раз, в том числе в разделе "Предметный указатель" (стр. 449-472). Вы без труда можете перепроверить.
Вот ссылка на книгу.
http://drakon.su/_media/01._parondzhano ... oritmy.pdf

На стр 449 сказано:

В. Пароджанов, я ранее выполнял поиск.

Кроме указанной главы термин ШАМПУР-МЕТОД нигде не встречается, т.е. о нем вы забываете, он не нужен.
В самой же главе удалите его и текст будет прозрачнее, понятнее.

Вы правы. В остальной части книги он не нужен.

Но этот раздел теоретический. Термин полезен при ответе на вопрос: какой новый метод предложен в книге?
Можно ответить длинно: визуальный структурный подход к алгоритмам и программам.
А можно ответить кратко: шампур-метод.
Смысл один и тот же.

Приживется ли этот термин? Я не знаю. Время покажет.
Полезен ли он? Это дело вкуса.

Кому не нравится, можно его не использовать.

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

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

Вы правы. Дело это не простое.

Но дело не в одном каком-то термине. Это мелочь.

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

А теоретическая сторона дела? Которая описана в специальном теоретическом разделе книги "Учись..." До этих глубин мало кто добрался.

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

Так что дело не в том, что какой-то термин трудный, дело глубже.
Новое пробивает себе дорогу с большим трудом.

=========================

Кому интересно, приглашаю изучить Часть VII моей книги:

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

Нету там научной новизны. Никакой.

В общем, смысла в этих играх нет никакого.
Займитесь уже когнитивной эргономикой, в конце-то концов!

Степан, поздравляю, очень рад, что Вы реализовали исчисление икон.

Почему Вы не упомянули заземление лианы?

Приведу цитату из Эдсгера Дейкстры, но не оригинальную, а в английском пересказе русского автора Пышкина отсюда
http://springerplus.springeropen.com/ar ... 1801-3-186
Я трактую мысль Дейкстры как необходимость объединения усилий математики (logical elegance) и эргономики, чтобы сделать компьютерные программы удобными для человеческого восприятия (for the human perception).

Мне кажется, что язык ДРАКОН следует завету Дейкстры.

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

===============================

Кто такой Евгений Пышкин?
http://kspt.icc.spbstu.ru/info/staff/pyshkin/

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

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

Собственно, такой подход применён в "семантическом редакторе" (кстати, какие там новости?).
Да и он был не первым. Попыток создания таких инструментов было много.
Почему они не стали мэйнстримом? Да потому что их задавили массой.

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

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

Алексей, вот точная цитата из русского перевода Дейкстры "Дисциплина программирования", взята отсюда:
http://elib.sbras.ru:8080/jspui/bitstre ... ewdx01.pdf

Я выделил синим слова, которые пересказал Пышкин.

Зачем?
Не упирайтесь в одну цитату, обратите внимание на то, что я выше написал:

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

Собственно, такой подход применён в "семантическом редакторе" (кстати, какие там новости?).
Да и он был не первым. Попыток создания таких инструментов было много.
Почему они не стали мэйнстримом? Да потому что их задавили массой.

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

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

Думаю, что Дейкстре ДРАКОН в том виде, как он есть, не понравился бы, по следующей причине:
http://www.u.arizona.edu/~rubinson/copy ... rmful.html

Рифат, спасибо за замечание. Я хорошо знаю и это Письмо в редакцию, и историю его появления в печати (о чем сам Дейкстра поведал за год до смерти). Согласен с Вами, что это великий исторический документ.

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

Объясню почему. Дейкстра предложил программистам не использовать (запретить) оператор goto в исходном коде программ на ЯВУ. При этом Дейкстра отлично понимал, что оператор перехода АВТОМАТИЧЕСКИ появится после компиляции исходного кода ЯВУ в ассемблер и машинный код.
Рифат, прошу Вас обратить внимание на слово «АВТОМАТИЧЕСКИ», то есть без участия человека.

Язык ДРАКОН развивает идею Дейкстры. В дракон-схеме (то есть в исходном тексте языка ДРАКОН) запрещены не только goto, но и все остальные императивные ключевые слова: if, then, else, case, switch, break, while, do, repeat, until, for, foreach, continue, loop, exit, when, last и т. д. При этом мы отлично понимаем, что они могут появиться АВТОМАТИЧЕСКИ после преобразования управляющей графики ДРАКОНа в текст.

ВЫВОДЫ

1. Разница в том, что в ЯВУ программисты пишут оператор goto ВРУЧНУЮ и это плохо. Именно с этим боролся Дейкстра.

2. В языке ДРАКОН никто не пишет оператор goto ВРУЧНУЮ. Это запрещено.

3. Не только оператор goto является вредным. Вредными также являются операторы: if, then, else, case, switch, break, while, do, repeat, until, for, foreach, continue, loop, exit, when, last и т.д. Все эти операторы порождают ошибки.

4. Поэтому в языке ДРАКОН запрещены не только goto, но и остальные императивные ключевые слова: if, then, else, case, switch, break, while, do, repeat, until, for, foreach, continue, loop, exit, when, last и т.д.

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

6. Разумеется, указанные слова могут появиться АВТОМАТИЧЕСКИ. Но это не влечет за собой появление ошибок. Это не страшно.

При всем уважении к вам, смею заметить, что вы не понимаете сути текста, который написал Дейкстра.

Есть перевод статьи Дейкстры http://hosting.vspu.ac.ru/~chul/dijkstra/goto/goto.htm

Если текст программы заменить на Дракон-схему программы, то суть останется та же.

Основной вопрос из которого следует, что goto вреден:




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

А если есть структуры, в которых участвуют "неструктурные" переходы (в тексте они могут конструироваться при помощи goto, break, continue, return, а Дракон-схеме путем указатения адреса шампура (возможно не точная терминология)), то такую коодинату сложно найти.
Дейкстра пишет:

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

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

схема станет более эргономичной.

Rifat,

Вы о чем пишите? Ведь в Дракон-схемах нет goto!

Что обсуждаете и что предлагаете: дополнить, исключить, изменить?

Зачем Дейкстра беспокоите?

Рифат, благодарю Вас за обширный комментарий.

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

У меня к Вам просьба. Вы сосредоточили свое внимание на разъяснении позиции Дейкстры и, к сожалению, не ответили на мои аргументы.
Если Вас не очень затруднит, ответьте на мои аргументы, представленные в моем последнем посте.

Я делаю особый акцент на следующем. Одно дело, когда программист пишет некий оператор (например, goto) ВРУЧНУЮ. И совсем другое, если оператор (например, goto) формируется АВТОМАТИЧЕСКИ.

Позвольте встрять.
Rifat, а если заменить многоветочный силуэт таким образом:
- ввести переменную состояния (=адрес ветки)
- while + case (switch) по переменной состояния (детали опускаю, так как подобное многократно уже мелькало во многих местах)
Вопрос - что принципиально изменится?

Ответ для LKom.

http://www.arbinada.com/en/system/files ... tu_uma.pdf страница 86.

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

Я уже рассказывал, как в ИС Дракон увидеть визуальную линию между иконами Адрес и Ветка. И здесь нет разрыва маршрута выполнения.