DRAKON.SU

viewtopic.php?p=99015#p99015

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

Следует выполнить два шага:

1. разработать алгоритм, чтобы "нормально поставить задачу и продумать решение". И тем самым получить ответ на вопрос Ильи Ермакова: "Что я буду делать? На хрена я это буду делать?"

2. и только после этого приступать к программированию. Или, как говорит Илья Ермаков, к "кодоизвержению".

Основная проблема в IT-это раздувание сложности и излишние возможности, среди которых люди теряются и допускают ошибки.

Возможно, будет глупая аналогия, но все же, если бы математики действовали также, как IТ-специалисты, то для того, чтобы описать местоположение точки в трехмерном пространстве они бы использовали не 3 оси x, y, z, а 26: a, b, c, ...., x, y, z В данном случае, большинство бы математиков использовало бы все 26 осей и говорили бы что это очень удобно и еще бы говорили, что осей только маловато, вот бы еще 676 осей добавить: aa, ab, ac, ..., ba, bb, bc для бОльшего удобства. И только бы немногие умные руководители проектов бы говорили, что инструмент с 26 осями избыточен, будет достаточно только 3 взаимно перпендикулярные оси и в нашей организации мы будем использовать только их, при этом напишем руководство по стилю и там это опишем, а кто не будет это соблюдать, то тех будем лишать премии При этом математики бы постоянно испытывали стресс с тем, как бы случайно не использовать лишние оси.

Примерно про это же писал S.Metzeler:


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

Покажите, что у Вас получается на Драконе в "чистом структурном стиле".

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

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

И все-таки лучше было бы привести пример - что Вы имеете в виду конкретно.

Все слова, слова, слова ... .
Хорошо бы все это подтверждать конкретно
(обычно всегда появляются некоторые особенности и т.п.)

Пример структурной схемы:
http://forum.oberoncore.ru/viewtopic.php?f=78&t=1489#p28522

Очень похоже на определение "чистых" и "нечистых" спортсменов.
Ранее Вы использовали словосочетание - "в чистом структурном стиле". Чехарда.
Вы высказываетесь, а предлагаете другим иллюстрировать ваши высказывания. Однако.

Ваши "основные правила" не соответствуют правилам языка Дракон.

Скорее всего, Вы ошибочно переносите понимание "структурного программирования" на отображение алгоритмов.

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

По поводу того, что мои основные правила не соответсветствуют правилам языка Дракона, с этим я не согласен. Мои правила - это подмножество правил Дракона.
Или я чего-то не знаю и в Драконе есть правила:
- что у каждой ветки должно быть не менее одного выхода;
- обязательно должно быть ветки, которые в адресах встречаются не менее одного раза?

Передо мной книга "Теория и практика структурного программирования" - Лингер, Миллс, Уитт, должна быть Вам знакома.
В ней нет чистых и нечистых, идет речь о программировании, а не о алгоритмизации, нет понятия структурный алгоритм.

В Драконе определены правила, они реализованы в редакторах.
Сверьте Ваши вопросы (цитата) с описанием Дракона:

В другой ветке форума недавно уже было что-то вроде дискуссии по поводу Силуэта, мол он голимый GOTO. Мы вышли из "дискуссии" в разных местах и появление здесь свидетельствует видимо о том , что и весь форум опоясан Силуэтом
Ваше 1-е правило (нет нескольким заземлённым лианам в одной ветке) - это следствие интерпретации - "GOTO-шный Силуэт".
Хотя само слово "заземлённый" несколько противоречит представлению о нескольких выходах
Рассмотрите адресные иконки перед заземлением, не как GOTO, а как оператор установки некого состояния, и кол-во "выходов" резко уменьшится до одного.

По ссылке:
Очень оторвано от жизни.

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

Rifat, реально, что надо или хотите разъяснить?

Это очень похоже на троллинг, когда требуют объяснить и определить каждую мелочь, которая и так всем понятна. Если что-то не понятно, то всегда есть книги, статьи, Интернет.

Спасибо.
Сейчас яснее, что вы имеете в виду - это структурные последовательные алгоритмы.
Не очень понято, что значит "чистый структурный вид".
А как это будет в обобщении на параллельные структурные алгоритмы?
Вообще и в чистом виде?

Дело в том, что мне надо описать в теоретическом форме
специфику силуэта в сопоставлении с примитивами
(для ее введения в структурную теорию параллельных алгоритмов).

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

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

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

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

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

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

Но у Вас пошел разговор о разнообразии класса структурных алгоритмов.
Вот это-то и интересно - в каком таком смысле.
Во всяком случае, спасибо за наводку.
Есть информация к размышлению по этому поводу.
Особенно в параллельных "структурных" структурах, где многое нет так, как обычно.

-----------------------------
Например, какие могут быть подклассы базового структурного класса параллельных алгоритмов?
Это последовательно-параллельные (двухполюсные) параллельные структуры
(без условных ветвлений и циклов).
В программной реализации - это первичные опорные каркасы,
в которые могут вписываться любые другие структуры.
Есть подвод подумать.

Немного подумавши пришла первая полезная мысля:
базовые структуры параллельных алгоритмов могут быть однородные и неоднородные.
Однородные структуры поддаются компактной свертке в записи
(разные дополнительные подклассы):
-- продольная свертка - по аналогии с обычными циклами в последовательном программировании;
-- поперечная свертка (по конъюнкции и дизъюнкции) - нет аналогов в последовательном программировании.

----------------------------
А "которая и так всем понятна" - это не тот разговор.
У Вас свой контекст в голове, а других может быть другой.

Есть такой обычай - вместо ответа посылать на интернет.
Чужой дурью маяться (шутка)

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

Можно это ассоциировать с подходами типа:
"чистый структурный подход"
и, в противовес к нему,
некоторый "нечистый структурный подход".
Почти, что нечистая сила.
Но автор этого поста его сторонник.
Для него языки без goto - это неполноценные языки.
И неспроста автор Дракона так нажимает на Силуэт:
в частности - это компенсация чистого структурного подхода в Примитивах.

И здесь надо бы подобрать более подходящие термины в их противопоставлении:
"чистый структурный подход" и "нечистый структурный подход".
Так что еще раз спасибо спасибо за наводку.
Но у Вас это в некотором другом - в классном смысле.

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

1
Есть понятие "структурное программирование".
С ним логически связано понятие "структурная программа".
Кстати, что-то вдруг возникло сомнение.
И в поисковике нашлось только два источник с таким термином.
Но это можно считать как подтверждение.

2
Программа - это машинный алгоритм
(алгоритм в его программной реализации, пригодной для исполнения автоматом).
По обобщению вполне допустимы понятия под терминами:
структурная алгоритмизация и структурный алгоритм.
Так что все в порядке в том плане.
---------------------------

3
Однако термины типа:
структурное и неструктурное программирование,
структурная и неструктурная алгоритмизация
структурная и неструктурная программа,
структурный и неструктурный алгоритм

это концептуальная нелепица типа:
структурная структура и неструктурная структура (программы или алгоритма).

Необходима корректная корректировка терминологии
по существу (смысла) этих понятий.

И это хотелось бы иметь в наличии в выкладках типа:
Глава 36. ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ И ПРОГРАММАМ (ШАМПУР-МЕТОД)
http://forum.oberoncore.ru/viewtopic.php?p=99079#p99079
Иначе изначальная нелепица изначально чревата.

Термин "шампур метод" является термином паразитом, никчемным термином.
Об этом было заявлено (http://forum.oberoncore.ru/viewtopic.php?p=98492#p98492) и В.Д. Паронджанов согласился (http://forum.oberoncore.ru/viewtopic.php?p=98497#p98497).

Эпатажное изложение мешает распространению Дракона.
Критика TAU - участника нашего форума, преподавателя в 3-х университетах:
(http://forum.easyelectronics.ru/viewtopic.php?p=467995#p467995) от 18 окт 2016, 01:23
Эпатажная терминология и необоснованные утверждения В.Д. Паронджанова не позволяют Rifat_у объединить Дракон с его задачей преподавать формальные методы доказательства правильности программ.

Суровые оценки.
Действительно, по отечественным традициям терминология типа "Дракон", "шампур" несколько напрягает.
Но у англо-саксов такое профессиональное терминологическое применение непрофессиональных слов очень распространено.
Например:
Python (язык Питон), cache (кеш - заначка), iron (железо, метиз) и т.п. - вплоть до разной фени.

А Шампур - это очень точное образное терминологическое выражение.

Но вопрос все-таки маячит в подсознании.

Спасибо за критическое замечание. А каким термином Вы бы предложили его заменить?