DRAKON.SU

Текущее время: Пятница, 05 Март, 2021 13:20

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 376 ]  На страницу Пред.  1 ... 11, 12, 13, 14, 15, 16, 17 ... 19  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 18 Апрель, 2008 10:16 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
Сергей Прохоренко писал(а):
Здесь содержится неявно выраженный постулат, что исходным способом выражения алгоритма является граф. Но практика знает и другие способы, например, функциональный стиль программирования, когда порядок вычислений формируется автоматически. Или, например, оператор ForEach, создающий цикл для каждого элемента коллекции.

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

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

Редчайший случай, я бы рискнул так сказать... Повседневная практика показывает, что решать приходится весьма нечётко определённые задачи (от идиотских, нестыкующихся друг с другом форм отчётности ЦБ РФ, до реализации изначально кривых протоколов связи, возведённых в стандарт...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 10:33 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Alexey_Donskoy писал(а):
Сергей Прохоренко писал(а):
Здесь содержится неявно выраженный постулат, что исходным способом выражения алгоритма является граф. Но практика знает и другие способы, например, функциональный стиль программирования, когда порядок вычислений формируется автоматически. Или, например, оператор ForEach, создающий цикл для каждого элемента коллекции.

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 10:48 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Сергей Прохоренко писал(а):
Мне кажется, лучше использовать такие языковые конструкции (замкнутые, инкапсулирующие, иерархически организованные, использующие функциональный стиль программирования), которые принципиально не могут породить никаких пересечений. Пересечения - это следствие избыточной свободы системы программирования, которая (избыточная свобода) провоцируюет ошибки. Мало избавиться от оператора GOTO. Надо для наиболее часто используемых моделей и алгоритмов (конечный автомат и т.п.) иметь адекватные и безопасные языковые конструкции, шаблоны, библиотечные функции и т.п. Таким образом, каждое пересечение - это сигнал о ненадежности алгоритма.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 12:27 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
Сергей Прохоренко писал(а):
Поскольку наиболее безопасная языковая конструкция, описывающая алгоритм, - это функция/процедура, то другие конструкции (циклы, ветвления, операторы выбора Select/Switch, конечные автоматы), чтобы быть безопасными, должны иметь похожие свойства.

Что-то в этом есть... Надо работать в этом направлении...

И вот ещё про функции:
- не инкапсулированные ни в каком месте (классический Бейсик, ассемблер...);
- инкапсулирован только код; данные все глобальны (Форт);
- инкапсуляция частичная или полная (большинство ЯВУ с определенной областью видимости переменных)...

Если принципиально делать только полную инкапсуляцию, то сразу найдутся недовольные... Впрочем, ведь их никто не заставляет ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 12:28 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Здесь содержится неявно выраженный постулат, что исходным способом выражения алгоритма является граф. Но практика знает и другие способы, например, функциональный стиль программирования, когда порядок вычислений формируется автоматически.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 12:37 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Поскольку наиболее безопасная языковая конструкция, описывающая алгоритм, - это функция/процедура, то другие конструкции (циклы, ветвления, операторы выбора Select/Switch, конечные автоматы), чтобы быть безопасными, должны иметь похожие свойства. В этом направлении уже сделаны некоторые шаги. Так оператор цикла ForEach похож на функцию с параметром - коллекцией, для каждого элемента которой создается отдельный цикл. Параметр цикла For стоило бы сделать локальным - невидимым за пределами цикла.

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

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

Так что сложно всё... :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 15:58 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Сергей Прохоренко писал(а):
Здесь содержится неявно выраженный постулат, что исходным способом выражения алгоритма является граф. Но практика знает и другие способы, например, функциональный стиль программирования, когда порядок вычислений формируется автоматически.

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 16:36 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Сергей Прохоренко писал(а):
Поскольку наиболее безопасная языковая конструкция, описывающая алгоритм, - это функция/процедура, то другие конструкции (циклы, ветвления, операторы выбора Select/Switch, конечные автоматы), чтобы быть безопасными, должны иметь похожие свойства. В этом направлении уже сделаны некоторые шаги. Так оператор цикла ForEach похож на функцию с параметром - коллекцией, для каждого элемента которой создается отдельный цикл. Параметр цикла For стоило бы сделать локальным - невидимым за пределами цикла.

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

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

Так что сложно всё... :-)



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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 17:01 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Это да. И от глобального состояния надо отказываться безусловно...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Апрель, 2008 20:38 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
TMX от 17.04.2008 писал(а):
Уважаемый Геннадий, не удается открыть приведенные вложения :(

Я проверил, все в норме.
Необходимо скачать и разархивировать каталог, в него разархивировать DR.EXE, выполнить
программу Дракон-редактора. При этом выводится последнее состояние редактирования
алгоритма.
Кнопками меню "<", ">" можно просмотреть последовательность состояний от 0 до 65.
Номер состояния и выполняемое действие отображается в строке состояний.

Желаю успеха.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Апрель, 2008 12:31 

Зарегистрирован: Пятница, 21 Март, 2008 11:23
Сообщения: 4
Андрей КСП писал(а):
Из-за этого и запрет на пересечение линий. Иначе зрительно надо разруливать - пересечение или замыкание и отсюда конец наглядности.
Строим пентаграмму (предположим требует модель) и соединяем вершины. Без пересечений не отобразить.
Вы скажите используй шины (силует с ветками). Но это тоже "сор под ковёр".


Илья Ермаков писал(а):
(Блин, я эту кнопку "Редактировать" на форуме выломаю... Андрей, дико извиняюсь, в спешке не туда ткнул кнопкой - испортил это Ваше сообщение).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Апрель, 2008 16:42 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5107
Откуда: Москва
TMX писал(а):
Некоторые неудобства нотации ДРАКОН:
1. представление таймеров:
ДРАКОН - отличный инструмент для представления конечных автоматов. Конечных автоматов может быть несколько параллельно действующих. При этом таймер представляет собой простую задержку (типа: ЖДАТЬ 5 МИН.).
Во-первых, не предусмотрено досрочного выхода из ожидания.
Во-вторых, как должны работать параллельные автоматы в этом случае? Даже при использовании многозадачной ОС возникает вопрос: как их сихнхронизовать?
Вывод: мы в своих реальных проектах не используем таймеры в первоначальном виде.

2. поддерживаю предыдущее сообщение:
Бывают проблемы с пересечением состояний.
Пример:
Код:
switch (state_value)
{
  case FIRST:
   return NEW_STATE;
  case SECOND:
...
}

Внутри ветки ПЕРЕКЛЮЧАТЕЛЬ может быть адресная метка (выход из состояния).
Что делать?


Уважаемый ТМХ!

Спасибо за критику. К сожалению, я не понял Ваших замечаний. Мне кажется, описанные Вами недостатки отсутствуют. Рассмотрю их по очереди.

:!: Вы пишете: "Не предусмотрено досрочного выхода из ожидания".

Отвечаю: Это не так. Досрочный выход из ожидания предусмотрен. Следует использовать цикл ЖДАТЬ (См. Как улучшить работу ума, стр. 169-170). Цикл ЖДАТЬ - мощная штука. Используется у нас очень широко.
Конкретный пример из моей книги. См. рис. 84. Цикл ЖДАТЬ нарисован в первой ветке. Чтобы досрочно выйти из сложного ожидания, надо сделать ЗАЗЕМЛЕНИЕ ЛИАНЫ.
Например,выход иконы "Включить фотонный двигатель" отрывается и присоединяется к нижней шине с помощью иконы Адрес".
Пояснение. Для Вашего случая процедура "Включить фотонный двигатель" не нужна. Мысленно заменим ее линией. Получим цикл ЖДАТЬ с тремя условиями. Если выполняются эти три условия, произойдет досрочный выход из цикла ЖДАТЬ.
Предполагаю, что Вам не нужна проверка трех условий. Ради Бога, сделайте только одно или два условия. Отсюда видно, что
досрочный выход (даже из очень сложного) ожидания для Дракона не представляет трудностей. А если нужен досрочный выход из простого ожидания, то цикл ЖДАТЬ существенно упрощается и превращается в тривиальную конструкцию.

:!: На Ваше второе замечание (о трудностях синхронизации) ответ тот же самый. Цикл ЖДАТЬ как раз и создан для синхронизации.

:!: Ваше третье замечание: "Внутри ветки ПЕРЕКЛЮЧАТЕЛЬ может быть адресная метка (выход из состояния). Что делать?"

Отвечаю: Все выходы переключателя, которые "собираются пересекаться", надо оторвать и применить операцию ЗАЗЕМЛЕНИЕ ЛИАНЫ. Пересечения исчезнут.

Уважаемый ТМХ! Вполне возможно, что я не понял Ваших замечаний и поэтому мои ответы бьют мимо цели. Если это так, поправьте меня.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Апрель, 2008 21:17 

Зарегистрирован: Среда, 09 Апрель, 2008 17:42
Сообщения: 21
1. Вы абсолютно правы. И мы для организации ожидания используем цикл ЖДАТЬ (как отдельное состояние). Я просто имел ввиду избыточность иконы ЗАДЕРЖКА, которая никогда не используется.
А также хотел обратить внимание на следующее остоятельство:
состояния ожидания - довольно частая процедура и для каждого приходится заводить свое состояние.
В других нотациях для решения этой проблемы используется т.н. состояния с памятью откуда осуществлен вход. Они обозначаются специальными символами. А в ДРАКОНе такого нет - т.е. невозможно сделать переменную адресную метку, например, по которой возвращаешься откуда пришел.
С одной стороны, чем проще тем надежнее. С другой - может придумать какие-то особые пометки?

2. Под синхронизацией я имел ввиду вот что:
самый простой способ реализации параллельно работающих автоматов - это просто вызов их в цикле один за другим, причем за одну итерацию каждый проходит от входа в состояние до выхода (т.е. от верха диаграммы до низа). Синхронизация при этом очень проста - если один автомат принудительно переключит второго, можно быть уверенным, что этот второй сейчас не работает, а как раз ждет перехода по адресной метке. Но если один из автоматов задержится на действии ЗАДЕРЖКА, остальные будут вынуждены ждать его. Отсюда вывод - не использовать эту самую ЗАДЕРЖКУ.
С другой стороны, если реализовать автоматы как отдельные задачи или процессы в ОС, то она возьмет на себя организацию времени их работы, однако синхронизация будет уже сложнее - потребуются семафоры и т.п.

3. Использование досрочного выхода очень удобно при реализации. В том числе и на ассемблере, когда при выходе из функции надо переходить на процедуру очистки стека, восстановления регистров и т.п.
Повторение веток не всегда помогает:
Код:
switch (state_var)
{
  case STATE_1:
    for (i = 0; i < N; i++)
    {
      for (j = 0; j < M; j++)
      {
        do_something();
        if (a > b)
          return STATE_3;
      }
    }
  break;
 
  case STATE_2:
....


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Апрель, 2008 09:53 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 56
Откуда: Узбекистан, Чирчик
TMX писал(а):
Вообще, работая с автоматами я подумал, что можно, наверное, создать язык, ориентированный на автоматы - например записывать циклы как специальное состояние. Для этого к автоматам надо добавить стек переходов по состояниям, чтобы многократно входить в одни и те же. Наверное, что-то подобное уже есть, интересно было бы посмотреть.
Не могли бы Вы привести пример такого автомата? А то сдаётся мне, что Хаскелл для таких вещей почти идеален...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 21:34 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5107
Откуда: Москва
Уважаемый Илья Ермаков!

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

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


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

Просьба пояснить, что Вы имеете в виду, говоря об ОДНОЙ СТРАНИЦЕ". Это лист бумаги формата А4? Или, может быть, это бумажный лист любого другого формата? Например, А3, А2, А1, А4х4 и т.д.? Или здесь речь идет совсем не о бумаге, а об экране монитора?

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

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

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

Учитывая сказанное, было бы желательно прояснить этот вопрос. Хотелось бы понять: совпадают наши точки зрения? или расходятся? Если расходятся, было бы полезно обсудить эту проблему более детально.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 21:48 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Владимир Данилович,
про "определён на одной странице" я имел в виду не страницу чертежа, а страницу текста в книжке, где формально описан синтаксис Дракона... Ну, не на одной, но очень компактно.
(Просто у нас тут "клуб любителей компактных языков" - вот мы страницы в описании и считаем. В авторском описании Оберона их, например, 16...)

По поводу больших форматов и плоттеров - почему бы и нет? Мне идея нравится. Чем бедные программисты хуже строителей и полководцев из генштабов? :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Апрель, 2008 04:38 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Илья Ермаков писал(а):
... По поводу больших форматов и плоттеров - почему бы и нет? Мне идея нравится. Чем бедные программисты хуже строителей и полководцев из генштабов? :-)

Вот!
Мне тут тоже обещали притащить из старых запасов несколько кг сплошных лент из листов А3 -- сколько всяких интегральчиков можно нарисовать...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Апрель, 2008 09:47 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1096
Откуда: Россия, Чебоксары
Владимир Паронджанов писал(а):
Мои вопросы связаны с тем, что я придаю большое значение правильному выбору размера диосцены (зрительной сцены).

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

Почему же привлекателен чертёж большого формата? Потому что цена полного переключения контекста (листание страниц) значительно выше цены движения взгляда из одного угла чертежа в другой. Но! При условии:
- что на чертеже мало линий и взгляд в них не запутывается;
- что информация на чертеже хорошо структурирована (кстати, простой приём выделения цветом больших функциональных блоков существенно помогает в этом);
- что ВЕСЬ проект помещается на одном чертеже.
При невыполнении этих условий восприятие неизбежно опять становится сукцессивным, причём большой чертёж начинает проигрывать мелким 7-чанковым фрагметнам по всем параметрам!

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

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

Кроме того, учитывать ограничения технических средств всё равно придётся... максимум, что можно рекомендовать - это широкие дисплеи.

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

Так, известно, что движение воспринимается человеком легче, чем статическая картинка. Почему мы должны ограничиваться статикой? Все ведущиеся здесь дебаты о ЯВУ, Драконе и проч. становятся абсолютно неинтересны с точки зрения эргономики, как только мы увидим движение потока на визуальной схеме!
Вот о чём думать надо сегодня, а не о том, какой размер плоттера выбрать!

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

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

А вы тут всё про квадратик vs. текст... Грустно, господа!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Апрель, 2008 10:43 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Alexey_Donskoy писал(а):
Владимир Паронджанов писал(а):
Мои вопросы связаны с тем, что я придаю большое значение правильному выбору размера диосцены (зрительной сцены).

С одной стороны, есть эргономическое требование, вытекающее из объёма оперативной памяти человека - для симультанного восприятия размер листа не должен превышать 7 чанков (то есть 7 логических единиц, которые можно одновременно удержать в памяти). Если меньше, то декомпозиция неоправданно глубока. Если больше, то восприятие неизбежно становится сукцессивным (уникумов, способных за секундный взгляд запомнить шахматную позицию или страницу текста, в расчёт брать определённо не стоит). Вроде как психофизиологами такой факт давно установлен; я писал Вам об этом несколько лет назад, но ответа так и не получил...
... Грустно, господа!


Совершенно согласен с Алексеем Донским. Просто не стал воспроизводить всю цитату целиком.

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

Характерным примером являются презентации в формате MS PowerPoint. Размер каждого кадра настолько мал, что в него помещается только 5-7 банальных пунктов, совершенно оторванных от остальной части презентации. После просмотра презентации человеку редко удается вспомнить, о чем же была презентация. Это очень удобно для заморачивания головы большого начальника или клиента.

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

И теперь сравните с презентацией MS PowerPoint хорошо структурированную и оформленную стандартным образом статью в формате pdf того же объема (в количестве знаков). В pdf у автора есть место для отображения общей структуры, связей между частями статьи и ссылок на внешние источники. После прочтения статьи остается целостное восприятие. Структура статьи и ключевые моменты сохраняются в человеческой памяти и могут быть использованы в дальнейшей деятельности.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Апрель, 2008 10:49 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Вот почему мне не нравятся маленькие примитивные блок-схемки, которые только подтверждают банальную мысль, что стандартный цикл или ветвление работает правильно, в то время как модель системы в целом может быть полной ахинеей. И нигде это невозможно увидеть. Виртуальные процессы обмениваются сообщениями в надпространстве... как им заблагорассудится. Авось правильно.

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

Может, у Вас и нигде "невозможно увидеть", а у меня вполне себе "где". Я Вам просто много раз уже сказал, что обсуждать способ этого "где" не буду, а обсуждаю только Дракон как "элементную базу".


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 376 ]  На страницу Пред.  1 ... 11, 12, 13, 14, 15, 16, 17 ... 19  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2021, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB