Ответ на »сообщение 2700« (panda)
___________________________

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

Сергей, Вам не кажется странным, что все, кто зарабатывает (или ранее зарабатывал) себе на хлеб именно разработкой ПО, занимают позицию противоположную Вашей?

Во-первых, я сам зарабатываю себе на хлеб именно разработкой ПО (на Access'е) и написанием ТЗ на разработку (другими средствами разработки) и бесконечно долгим ожиданием результата, а затем тестированием.

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

Ответ на »сообщение 2698« (Руслан Богатырев)
___________________________
Отлично. Тогда о тексте надо в тексте. И забудем про графику. Так Вам больше нравится?

Не могу я забыть графику. Полюбил я её. Меня от плоских бледных черепашек с зазубринами коробит.

Только для одного взгляда деталь является сутью, а для другого -- суть является деталью.

Вот это по-генеральски!

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

Сергей, Вам не кажется странным, что все, кто зарабатывает (или ранее зарабатывал) себе на хлеб именно разработкой ПО, занимают позицию противоположную Вашей?

Ответ на »сообщение 2697« (Сергей Прохоренко)
___________________________
Если нет примеров удачного графического интерфейса, то возникает подозрение о несостоятельности концепции. Текстовой способ разработки традиционен и сторонники графики, коим я также являюсь, должны доказывать, убеждать, иллюстрировать, а не наоборот. Текстовикам, не отвлекаясь от долбёжки клавиатуры, достаточно сказать "Ну и что?". И они, увы, окажутся правее нас с Вами.

Ответ на »сообщение 2695« (Beginner)
___________________________

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

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

И ещё раз повторю (мысль полюбилась) о графике надо в графике. Пока игра на чужом поле.

Отлично. Тогда о тексте надо в тексте. И забудем про графику. Так Вам больше нравится?

В отношении формы и содержания. Для языка (программирования) привыкли использовать только одну форму (view), тогда как их может быть несколько (и не только графика и текст, могут быть разные тексты, разные варианты графики, разная их комбинация). Язык -- это модель (model), его реализация -- контроллер (controller), его форма -- внешнее представление (view). Получили универсальную схему MVC.

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

Ответ на »сообщение 2689« (Руслан Богатырев)
___________________________

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

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

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


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


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


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

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

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


Модула-2 и Оберон с их упором на "тупые" модули (а в Обероне и на гипертекстовую основу) -- близкое к идеалу представление, которое позволяет держать под контролем систему.


Ну, с идеалами спорить трудно. Если идеал достигнут, то дальше развиваться уже некуда.


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


Почему визуальное управление ведет к потере контроля? Где доказательства: факты, аргументы и т.п.?


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


Почему визуальное управление усложняет общий анализ всей системы? Где доказательства: факты, аргументы и т.п.? Может, потому, что Вы себе представляете только визуальное управление на локальном уровне и не представляете на уровне всей системы и внешней среды? Ну, не доводилось Вам этого видеть, но не надо на основании этого факта сразу делать далеко идущие выводы.


Есть другая аналогия, вскрывающая ту же проблему. Языки с Си-синтаксисом.


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

Кстати, графический интерфейс предназначен не для быстрого набора текста программы, а для быстрого и АККУРАТНОГО конструирования программ. Если это не так, то Вы имеете дело с ПЛОХИМ графическим интерфейсом.

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

Ответ на »сообщение 2694« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2693« (Beginner)
___________________________

Не понял почему Си для синтеза.

А говорят лучше запоминается последняя фраза...

Ответ на »сообщение 2694« (Руслан Богатырев)
___________________________
Что синтаксис Си "пиши" больше, чем "читай" согласен. Но почему синтез "пиши", а анализ "читай" - мозги ещё не доросли. Да и что нам Гекуба .. т.е Си. Речь о тексте и графике.
Я думал, что синтез - это интеграция, "окинуть орлиным взором" и проверить сочетаемость деталей в комплексе, а анализ - это разбить на кусочки, чтобы понять (или создать) механизм действия, "посмотрим что там внутри" и "какого цвета у него мозги".

И ещё раз повторю (мысль полюбилась) о графике надо в графике. Пока игра на чужом поле.

Ответ на »сообщение 2693« (Beginner)
___________________________

Не понял почему Си для синтеза.

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

Ответ на »сообщение 2689« (Руслан Богатырев)
___________________________
Не понял почему Си для синтеза.
IMHO Си - это не для синтеза, а для большей гибкости, подключаемости, ремонта на лету (в том числе языка), хоть и в ущерб надёжности.
Для синтеза как раз визуальные инструменты. Когда именно по Вашему тексту для Си пренебрегают деталями компонентов-блоков и теряют контроль над деталями с целью охватить (синтезировать) общую картину.
Если инструмент хороший, то есть возможность "иметь полный контроль за всеми деталями "агрегата" и его состояниями". Пример тому - место диспетчера АЭС с его графическими схемами. Представляю, как бы он контролировал по текстам, таблицам и т.п.
Это пример того, что неверно утверждение "Визуальное управление также облегчает синтез, но усложняет анализ... всей системы".
Желание контролировать текст похоже на предпочтение собирать электронные устройства из "рассыпухи", когда давно используются микросхемы и программируемые чипы.
Конечно, микросхемы собирают из тех же транзисторов - резисторов, особеннот разработчики чипов - аналог ОС :)

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