>>> Я хотел сказать, что собственно сложная статическая картинка воспринимается с большими проблемами.
???
Речь, вроде, шла об оживлении сложного механизма в AutoCAD графикой и текстом.

>>> А в схему тот же самый текст, тока в рамочке.
Теряю нить дискуссии. Правильно говорил Jack - морепродукты надо есть :)
У меня, видимо, сказывается отсутствие йода в мозгу :)
Текст в рамочке ... некролог, объявления в газете .. при чём здесь графика?

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

>>> никакого программирования до полной формализации модели
А так как полной формализации в природе не существует,
то просто никакого программирования?

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

Ответ на »сообщение 3040« (Сергей Перовский)
___________________________
Такое "экспериментальное" программирование годится для небольших задач, "умещающихся в одной голове".

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

Будет время, поищу ссылки на конкретные сообщения.
По моему вы тоже учавстовавли в обсуждении. Неужели забыли ?

Ответ на »сообщение 3039« (Сергей Перовский)
___________________________

Ответ на »сообщение 3038« (Сергей Прохоренко)
___________________________
Но главное, как Вы правильно отметили, графика необходима для осмысления. Поэтому с нее должна начинаться разработка программного обеспечения,
В некоторых случаях это так, в ветке про Обероны уже пришли к тому, что Оберон - средство "думания", а во вторую очередь программирования. Такое "экспериментальное" программирование годится для
Я стараюсь придерживаться другой технологии: никакого программирования до полной формализации модели.
Для осмысливания годятся рисунки на бумажке или на компьютере. Но система программирования, это строго формальный инструмент, тут уже обдумывать нечего.
Прошу прощения, ушло недописанное сообщение.
Такое "экспериментальное" программирование годится для небольших задач, "умещающихся в одной голове".

Стандартный пример из курса программирования - программа для решения квадратных уравнений.
Формулировка проста и решение известно. Ученики начинают бодро стучать по клавишам.
Хотя совершенно очевидно, что формулировка задачи неполна: идет речь только о вещественных корнях или о комплексных, должен ли обрабатываться вырожденный случай А=0 и т.д. и т.п. Все эти тонкости должны быть выявлены. Проще всего путем задания области определеня для исходных данных и области значения решений - т.е. строго математически.
Программирование шире, чем математика
К сожалению программирование часто совсем не математика, а некоторый поток сознания.
Насколько дорого это всем нам обходится...

Ответ на »сообщение 3038« (Сергей Прохоренко)
___________________________
Но главное, как Вы правильно отметили, графика необходима для осмысления. Поэтому с нее должна начинаться разработка программного обеспечения,
В некоторых случаях это так, в ветке про Обероны уже пришли к тому, что Оберон - средство "думания", а во вторую очередь программирования. Такое "экспериментальное" программирование годится для
Я стараюсь придерживаться другой технологии: никакого программирования до полной формализации модели.
Для осмысливания годятся рисунки на бумажке или на компьютере. Но система программирования, это строго формальный инструмент, тут уже обдумывать нечего.

Ответ на »сообщение 3037« (Сергей Перовский)
___________________________

Ответ на »сообщение 3035« (Сергей Прохоренко)
___________________________
Существует масса способов КОМПАКТНОГО отображения графики (структуризация текста – тоже графический прием и интеграции графики с текстом):
Как-то очень расширительно Вы трактуете термин "графика". Можно конечно и введение математических знаков отнести к графическим приемам.
Но значительная часть перечисленного, по моему к графическому представлению имеет отдаленное отношение. Например гиперссылки или препроцессор.
Давайте вводить определение.


Я трактую термин "графика" даже значительно уже, чем это принято: http://en.wikipedia.org/wiki/Graphics
Я трактую графику как любые изобразительные (т.е. формирующие изображение) средства системы программирования, кроме собственно чистого исходного текста на языке программирования. Графика создает зрительные образы, в которых текст может быть объектом, помещенным в те или иные контейнеры (блоки, элементы списков и т.п.), названием тех или иных графических объектов или ссылкой на них.


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

Программирование шире, чем математика: http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F

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

Ответ на »сообщение 3035« (Сергей Прохоренко)
___________________________
Существует масса способов КОМПАКТНОГО отображения графики (структуризация текста – тоже графический прием и интеграции графики с текстом):
Как-то очень расширительно Вы трактуете термин "графика". Можно конечно и введение математических знаков отнести к графическим приемам.
Но значительная часть перечисленного, по моему к графическому представлению имеет отдаленное отношение. Например гиперссылки или препроцессор.
Давайте вводить определение.

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

Ответ на »сообщение 3035« (Сергей Прохоренко)
___________________________
Добавлю - Подсветка синтаксиса, code folding тоже графическое представление информации.

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

Ответ на »сообщение 3028« (Сергей Перовский)
___________________________

Ответ на »сообщение 3021« (Сергей Прохоренко)
___________________________
Такие графические средства разработки, как автокад или геоинформационные системы (список можно продолжить) "тянут" очень сложные проектируемые системы.
Но это статические системы. Попробуйте понять, как будет двигаться сложная механическая система по ее автокадовскому чертежу, без подробных пояснений.
Просто для проектных работ, где чертежи являются официальным результатом, другого пути представления информации нет.
Просто для сложных программных систем еще нет хороших графических средств разработки. Видимо, сказалась сравнительная молодость, сложность для понимания и анархичность программной отрасли.
Сколько существует программирование, столько предпринимаются попытки графического представления программ. Блок-схемы только самая известная попытка, было множество разнообразных диаграмм. И результат именно такой, о котором пишет  Jack Of Shadows - при росте сложности программы, наглядность графического представления очень быстро снижается. Пока схему можно воспринимать целиком, она удобнее текста, как только приходится рассматривать частями, преимущество графической наглядности исчезают. Текст гораздо проще рассматривать фрагментами, чем графическую схему. Это естественное свойство мозга.
Кстати, при проектировании интерфейса, мы все учитываем, что нельзя одновременно выводить на экран слишком много информации.


Это трудно назвать иначе, чем СТОЙКОЕ  ПРЕДУБЕЖДЕНИЕ. Ну что можно возразить таким людям против их довода «этого не может быть потому, что не может быть никогда»?

Существует масса способов КОМПАКТНОГО отображения графики (структуризация текста – тоже графический прием и интеграции графики с текстом):
репозиторий;
когнитивные карты;
раскрывающийся многоуровневый список;
гиперссылки;
таблица параметров;
переключение фокуса;
контекстная зависимость отображения;
локальное меню;
фильтры;
переключение представления;
переключение между уровнями модели;
шаблоны;
инкапсуляция;
слайды;
визуальные метафоры;
группировка по выделению;
индексные списки и тезаурусы;
автоматически генерируемые оглавления и рефераты;
пиктограммы;
средства поиска;
препроцессор;
глобальные операции редактирования выделенных объектов/текста;
всплывающие комментарии;
и т.д.

Но у оппонентов намертво засели в голове только неоглядные блок-схемы и drag-and-drop.

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

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

Ответ на »сообщение 3030« (Как слышно? Приём!)
___________________________
Пример Вы выбрали не в свою пользу.
Там есть такая штука как рендеринг во fli.
Это мы в курсе :)
Я хотел сказать, что собственно сложная статическая картинка воспринимается с большими проблемами.

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

Ответ на »сообщение 3032« (Jack Of Shadows)
___________________________
Я думаю спор без почвенный поскольку использовать клавиатуру или мышь, отображать в виде графических схем и уметь читать их или отображать в виде текста и опять таки уметь читать этот текст - ЭТО ВОПРОС ПРИВЫЧКИ и ЛИЧНЫХ СПОСОБНОСТЕЙ КАЖДОГО ЧЕЛОВЕКА.
Если большая сложная графическая схема то мы должны иметь возможность вывести кусок этой схемы в графическом виде и возможно с текстовым неким описанием, в то же время у любого текстового описания должна быть возможность вывести некую область (или целиком) в графическом виде. И возможность редактирования как в графики так и в тексте
Примеров подобных систем много.