DRAKON.SU

Во многих случаях на электрической принципиальной схеме пересечений не избежать. Да ни кто к этому и не стремится.

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

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

Авторское право. Я всегда рассматриваю программу как передачу информации от автора к читателю:) Выбранный способ представления должен как можно ярче выражать, доносить идею. Разумеется. идея всегда в чём-то субъективна. Расставляйте приоритеты именно как ВЫ видите важным

Задачу баланса, нахождения меры вообще нельзя до конца "объективизировать".

Просто пример на "выражение идеи":
я всегда пишу INC(count); m[count-1] := newElem. С чьей-то чисто-программёрской точки зрения можно даже назвать это безграмотным. Но я хочу явно выражать то, что у нас стало на один элемент больше, и что мы кладём его на последнюю позиции массива (а последняя всегда с -1 пишется).

Платформная зависимость. Это плохо.

Да, оно само собой в большинстве случаев так выходит (List.Add; with List[List.Count-1] do ...). Но плохо.
Равно как ничем не лучше было бы m[count]:=newElem; inc(count);
К тому же, кое-где массивы организованы по-другому. Особенно строки в Дельфи - там с 1 нумерация

Что-то вроде with List.Add do ... было бы прозрачнее. Без явного юзания count.

Но всё это существенно выходит за рамки темы...

А к теме ближе вот что.
Какой бы авторской ни была программа, вся эта информация а) дополнительная; б) не очевидной полезности.

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

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

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

Вы имеете в виду подобное тому, что описано здесь как "БП-соеднинители"?

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

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

Так.
И ещё несколько замечаний.
1) К сожалению, пока рассматриваемые визуальные технологии (включая Дракон) никак не помогают решать главную задачу - проектирование программной системы. К тем вопросам, которые А.Седов ставил в Фидо ещё 15 лет назад, и близко не подошли.
2) Дракон помогает уменьшить издержки в ряде частных случаев. Но также и вводит дополнительные издержки в других местах. Средняя температура по больнице не изменяется.
3) Элементарная (в смысле лоической целостности) алгоритмическая задача с точки зрения оптимизации может иметь один или несколько экстремумов (наиболее оптимальных алгоритмических решений). Топология этих алгоритмов не зависит ни от представления, ни от "мысленных построений сочинителя".
4) Ориентированный граф наиболее математически точно описывает топологию алгоритма.
5) Для удобства человека этот граф можно представлять в разных проекциях (на разных языках), в том числе визуально изобразить на плоскости.

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

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

А от чего зависит? От заданных свойств предполагаемого исполнителя решения? ещё от чего-то?

От задачи
Вернее, от модели, используемой для её решения...

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

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

Интересно.

"исходя ..." -- это доп. ограничение на решение. Причем сильное. Что затрудняет решение.

Любопытно было бы посмотреть на решения этой задачи БЕЗ таких ограничений.

Рассуждение сугубо формальное, конечно, но....

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

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

Естественно. Я как раз не ставлю знак равенства, а обращаю внимание на задачу-максимум.

Ну дык, наивно хочется механизировать искусство!

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

Мне тоже было бы любопытно посмотреть на "серебряную пулю"!
Но, если строительство такого... гм... здания... вообще возможно, то лучше бы его направлять сразу.
А иначе "получится, как всегда" - задача вроде бы решена, но пользоваться решением до того муторно, что прощё выкинуть!

И потом - почему именно пугает ограничение? Ограничения в любом случае есть (критерии решения задачи).

Так в этой теме вылезает, что даже для записи алгоритмов издержки неприемлемые
Кроме того, полезность чисто алгоритмической проекции программной системы как-то... сомнительна

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

Дык, а что у нас первично? Задача или правила, по которым её невозможно (неудобно) решать?

Честно говоря, не понял... У нас ведь в алгоритме исполнитель всегда один, точка активности одна... А если не одна (параллельные процессы, сети Петри и т.п.), так всё равно для большинства практических целей (включая низкоуровневые кирпичики) приводится к одной (временная последовательность действий, очередь транзакций в кошельке и т.п.). О каких "результатах алгоритма" речь?

А, возможно, он там и не нужен, орграф-то?

А то.
Правила - те же данные. В них может быть всё, что угодно. А в исполнителе этих правил всё же есть алгоритм, на так ли?

Ну, хвала Всевышнему! Наконец-то в области обсуждения Дракона это прозвучало!!!

Дык, а "правила оформления" - это ж и есть язык!

В мире нет ничего, что нельзя было бы сделать еще более трудным для понимания... Хотя я не уверен в том, что надо к этому стремиться.
Несколько лет я, как мог, боролся с теми, кто ходил по предприятиям и... описывал бизнес-процессы. Процесс формализации/отчуждения знаний - это частный случай подобного бизнес-процесса. То, что это трудно, я понимаю... однако, это трудности начала пути. Потом трудностей станет гораздо больше. Поскольку этот путь... в никуда. Чем больше решений удастся описать... тем больше будет тех решений, которые еще не описаны.
Да, только это задача не для Дракона.
Под "правилами" я имел ввиду несколько иное. Скажем, Алгол ввел в практику правило использования отступов для вложенных блоков. Здесь говорят о правилах "шампур"-метод, отсутствие пересечений и т.п. Но возводить "правила" в ранг "закона" (обязательного для исполнения)... является ошибкой, IMHO. Должен признаться, что я до сих пор пользуюсь GoTo, там, где мне это кажется оправданным.
Зачем нужны суррогаты?.. Описание объектов - это одно (они и в конструкторской документации, при деталировке, описываются отдельно), а получение результатов - это совсем другое. Конструкторам безразлично, как будут получены детали, главное чтобы они соответствовали документации. А вот планово-экономическому отделу и производственникам - не безразлично. То есть, речь идет скорее о технологии производства и последующем планировании, чем о конструировании.
Речь о том, что орграф - это частное решение, приложение системы к решению конкретной задачи. Это не совсем то же самое, что проектирование системы.
Системы документирования (ЕСКД, в частности) морально устарели с появлением систем трехмерного моделирования и конструирования. Производителям тех же печатных плат не нужны чертежи по ЕСКД, им подавай файлы в формате PCAD... Они из этих файлов автоматически получают и фотошаблоны, и программы сверления, и пр., и пр. Чертежи на бумаге... уходят в прошлое.

Вероятно, Вы предлагали что-то взамен описаний бизнес-процессов. Что же именно?

Это не наивно... Механизация и автоматизация искусства давно происходит. Одно дело руками прорисовывать каждый кадр мультфильма, совсем другое дело компьютерная анимация... То же самое относится ко многим другим видам искусства. Сейчас даже скульпторы... получают сначала 3D-модели... Техническая часть искусства автоматизируется весьма успешно, но порой в ущерб содержательной/творческой части.
Законы? Методики?
Вроде бы за эти утопии уже нобелевские премии давать начали...
Сомнительна? Не факт, что она вообще существует... как цельное и самоценное... длительное время.
С моей точки зрения, задача важнее... но для "ревнителей чистоты"... в общем, однозначного ответа для любого случая жизни у меня нет.
Все правильно. Исполнитель один, а результатов много. Это давняя дискуссия. Например, что делать, если из функции надо вернуть более одного значения? Создавать временные структуры? Вводить формальные var параметры? Костыли?..
Программа, в конечном итоге, это некоторая модель... Модель должна быть адекватной... В жизни бывает так, что сериализация не помогает.
Именно.
Нет, не так, если под алгоритмом понимать заданную последовательность действий. Чтобы было понятнее, попробую пояснить. Перед пользователем на экране монитора "висит" форма. Что на этой форме в следующий момент времени нажмет, введет, отметит пользователь? Неизвестно. Является ли форма алгоритмом? В систему из разных источников поступает много самой разной информации, которая внутри системы как-то обрабатывается, и в результате получается некая реакция. Является ли система алгоритмом?
Так я Вам еще раньше намекал на 3D очки...
Нет, ни в коем случае... Есть язык, а есть правила оформления отступов, правила комментирования, правила использования GoTo и т.д. и т.п. К языку это прямого отношения не имеет.

Я предлагал воспринимать предприятие, как систему...