DRAKON.SU

Нельзя.
Аналогия неадекватная, аргументация некорректная.

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

Сравните основные свойства и задачи.
Свойства кода / данных в таблице:
- высокая связность / практически отсутствующая в рамках отображения связность;
- линейная логическая последовательность / отсутствие последовательности;
- сложный синтаксис / практическое отсутствие синтаксиса;
- структурная группировка в рамках синтаксиса представления / группировка по критериям вне рамок представления;
- и т.д...

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

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

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

Разве только от бедности (отсутствия адекватных инструментов). Но их уже давно вагон и маленькая тележка.

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

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

Вижу дилетантский подход. В приведенном примере совершенно не отражены степень и характер связности, например, бухгалтерских регистров и отчетов, равно как и линейная логическая последовательность бухгалтерии совершенно упущена. Остальная аргументация на том же уровне: "возьмем распространенные клише, и докажем то, что хотим".

Вы пробовали создать развернутый аналитический отчет из сырого табличного представления средствами Excel? Любой из пунктов, приведенный вами, применительно к таблицам, совершенно не соответствует практической работе с табличными материалами. Вас послушать, экономистам нужно только графики нарисовать, а бухгалтера читают только ИТОГО: "Профессиональное сообщество эффективно использует графическую визуализацию данных. Никто не смотрит в таблицу, когда можно видеть тренд и т.п." (с) Анекдот

Я думаю что вид икон сейчас не самое главное.
Их можно будет подправить на втором этапе.
Самым сложным вопросом сейчас является режим визуального исполнения .
Ранее не в одном дракон редакторе не было такого режима

Вижу, вы категорически не настроены на конструктивный диалог. Дело ваше.

Вы хотите в сообщении на форуме развёрнутую статью с подробным исследованием? Ну-ну.
И таки да, про "связность бухгалтерских регистров и отчётов" вешайте лапшу кому угодно, только не человеку, проработавшему в банке десять лет и написавшему с нуля банковскую систему!

Упражняйтесь дальше, но не забывайте о существенной разнице между кодом и данными в таблице. Которая отображается на существенно разные задачи и разные методы.

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

Не принимайте близко к сердцу. Возможно просто у меня не всегда получается.

"Вешать лапшу" не мой способ донесения идей. А бухгалтерские регистры на то и регистры, что в них информация связана, и причинно-следственная связь там прослеживается четко. Может вы и писали для банка, но от этого вряд ли стали банкиром, равно как и программисты 1С не становятся Главными бухгалтерами. Не тянут-с. Ваш визави, к слову, главбухом проработал несколько лет, и экономистом, не главным, и аналитиком, финансовым, и программы для банка писал, тоже...

Поделюсь немного опытом: экономисты не только с цифрами работают, но и с их взаимосвязью. И часто создают на основе сгруппированных чисел из внешних источников внутритабличные математические структуры, подчиненные Логике и имеющие Замысел. Формулы в Суперкалке не на пустом месте появились. Помните такую программу?

Ткните пальцем, где я утверждал обратное.
Разница таблицы данных с кодом в том, что эта связь ВНЕШНЯЯ по отношению к рассматриваемому представлению. Её нет в таблице.
А в коде она наличествует непосредственно в синтаксисе и воспринимается непосредственно работающим с этим кодом.

Можно, конечно, сказать, что тот же синтаксис описан ВНЕ кода (и вообще свести всё к элементарному движению материи), но это никак не отменит СУЩЕСТВЕННОЙ разницы в задачах и методах работы с кодом и таблицей данных.

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

И получается стандартное противоречие: хотим развернуть данные - теряем алгоритм, хоти развернуть алгоритм - теряем обозримость данных.
Разные задачи - разные подходы.
Соответственно, приводить в качестве аргумента примеры из "другого измерения" - категорически неправильно.

"И таки да, про "связность бухгалтерских регистров..." вешайте лапшу кому угодно" (с)

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

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

Не выдёргивайте из контекста диалога. Вот исходная, по существу, цитата: "Свойства кода / данных в таблице:
- высокая связность / практически отсутствующая в рамках отображения связность;"

Продолжаете ломиться в открытую дверь.
Отличается.
Отличается существенно.
Когнитивные проблемы имеются (иначе бы этого форума не было). Но они РАЗНЫЕ.

Да.
Но пока нет адекватной методологии управления её сложностью, говорить по существу не о чем.

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

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

Я утверждал, что они идентичные? Разные, равно как и в любой области знания.

Если не обсуждать, она не появится никогда. Генерировать идеи - не ваш стиль?


Выгодно пользователям, которые неизбежно появятся. Я знаю, т.к. создавал рынок под себя: маленький, локальный, но он появился, из пустоты, практически. И потянул за собой таких же людей, которые в итоге хотя бы немного, но расшевелили болото, и стали одними из первых в России, и стали учить других людей, как работать на рынке. Именно они приложили свой немалый опыт уже к современной системе "Кванториум", и еще много полезного сделают. Обсуждая Дракон, я думаю и о них, и об их учениках.

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

И в Дракон я скорее верю, вы правы, но вера моя не фанатична. Просто я вижу, что у меня есть инструмент, с помощью которого я могу за одну учебную пару объяснить ученикам то, что с другими инструментами делал бы 2-3 пары. И да, у меня есть "хотелки": хочу его улучшить, чтобы он стал еще удобнее.

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

К вопросу о недетминированных алгоритмах: Познакомился с книгой "Нечеткие множества в моделях управления и искусственного интеллекта/Под ред. Д. А. Поспелова.— М.: Наука. Гл. ред. физ.-мат. лит., 1986.— 312 с.— (Проблемы искусственного интеллекта).", а именно с главой о нечетких алгоритмах (8-я). Мне кажется, что тема недостаточно охвачена методологией Дракона, что и привело к сомнению сообщества в применимости "Временной вставки", нарушающей базовые правила алгоритмики - детерминированность (определенность) и дискретность определяемого алгоритмом процесса. С массовостью, КМК, проблем не наблюдается. Поправьте, пожалуйста, если не прав.

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

Исходную диаграмму поправим с учетом требования об обязательном наличии иконы Выход.

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

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

Итог: в традиционной записи есть ритмичность, однозначность, и новая форма тут ничему не помогает, а скорее, мешает. Я с этим выводом согласен.

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

Рассмотрим данную диаграмму с применением иконы Временная вставка


Группа моих экспертов оценила эту пару диаграмм практически однозначно, приписав понятность второй, как более информативной. Вторая диаграмма более лаконична, в ней нет лишних линий. Причем, была высказана мысль, что по второй диаграмме становится понятно, какой процесс является первичным (светоиндикация), а какой вторичным (звукоиндикация). Без вторичного процесса (дополнительного, временного) работоспособность устройства сохраняется, хоть и в не полном составе. При нарушении первичного - устройство не работоспособно совсем. По первой диаграмме такого вывода сделать нельзя, все процессы равноценны.

Повторюсь, вывод о дополнительности, временности команд звукоиндикации мои эксперты сделали самостоятельно, без подсказок и намеков.

Итог: вторая диаграмма более понятна, т.к. в ней меньше отвлекающих линий.
Бонус: вторая диаграмма содержит дополнительную информацию о приоритетности команд для исполнителя.

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

Алгоритм работы нашего светофора изменится незначительно


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

А значит, способ записи алгоритма с применением Временной вставки останется тем же.


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

Занятно, что я дольше объяснял своим слушателям, что означает такая форма записи, чем они поняли, как работает устройство. Думаю, это хорошая иллюстрация применимости ВВ.

Исходя из вышеозначенной логики, следует признать, что такой вариант использования ВВ не применим


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

Алексею Донскому - респект