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

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

Совершенно согласен с info21, что у разных людей разный способ решать задачи.

Собственно, в »сообщение 2259« и »сообщение 2270« этот тезис и был раскрыт.

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

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

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

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

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

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

Почему? Как говаривали греки приведя в качестве решения чертёж: "Смотри!".

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



Вот тут-то и выявились приоритеты. Всё понятно - всем писать код на ассемблере! И никаких "рюшечек" - на них приоритата не хватило.

О каких таких правах программы Вы говорите? Это новое слово в юриспруденции!

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




Чем-то мне это напоминает дискуссию о том, как лучше работать с химическими структурами. Безусловно, их можно отображать графически, строить в объеме (в 3D-редакторе), разбивать на группы. Но при этом есть и компактная форма -- в виде формул и правил их преобразования. И она очень удобна для работы с такими структурами. Особенно если речь идет о преобразованиях.


Вы бы лучше химиков спросили! Какой такой формулой Вы опишите ДНК или другой полимер? А есть еще масса РАЗНЫХ веществ с ОДИНАКОВОЙ химической формулой, отличающихся пространственным расположением атомов в молекуле. И кто сказал что химическую формулу (вместе с названием) нельзя выбрать из нескольких в графичеком интерфейсе, предварительно выбрав класс вещества по параметрам?


Графическое представление ориентировано преимущественно на анализ.
Текстовое представление -- в большей мере на синтез.

Это большое заблуждение. Графическое представление ориентировано на конструирование принципиально нового. Текстовое - на уточнение с помощью образцов из старого, если графическое не содержит таких образцов.

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


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


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

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

Совершенно согласен с info21, что у разных людей разный способ решать задачи.

Собственно, в »сообщение 2259« и »сообщение 2270« этот тезис и был раскрыт.

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

Это на 10 000 позиций? Ктулху выпйет твой мосх.

Если мы сократим это значение на порядок и будем говорить о 1000 позициях (100 процессов по 10 флажков состояний), это прольет бальзам на Вашу душу?

По поводу графического или текстового представления. Рассматривать его нужно с учетом материала, который оно представляет. Есть ситуации, задачи, исходно "графические", когда например изучаются пространственные соотношения. Это может быть задача из геометрии, где объекты сами посебе графические. Это может быть задача из физики, например, найти распределение зарядов на проводящей сфере в электрическом поле. Здесь сама задача по сути - "картинка".
Но есть объекты изучения изначально абстрактные, неграфические. Например, нужно определить относительную частоту, с которой встречаются буквы алфавита в тексте. Или определить рентабельность производства.
В программировании графические схемы зачастую иллюстрируют логические отношения элементов системы. Т.е. это - перевод изначально логической задачи в другое представление.
Совершенно согласен с info21, что у разных людей разный способ решать задачи. Мой однокурсник, вполне успешно занимавшийся физикой, а потом программированием, как-то говорил мне, что никогда не понимал, когда люди говорили о "картинках" в уме применительно к решению физических задач. Точно слов не помню, но смысл был такой. Наверное, это не для всех задач, я особо не уточнял, есть ведь и действительно "графические" по сути, но тем не менее - реальный пример.

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

Поэтому надежному Оберону трудно себя проявить в глазах этих 90%.  Приходится искать специфические ниши, например, ОС и приложения реального времени для управления транспортными средствами, технологическими процессами, сетями, вооружениями и т.п.

Т.е. там, где надежность ценится очень высоко. :)

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

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

Система, построенная только из надёжных элементов может быть ненадёжной. Упущение этого - основная трудность Оберон направления.


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

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

Почему? Как говаривали греки приведя в качестве решения чертёж: "Смотри!".

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

Чем-то мне это напоминает дискуссию о том, как лучше работать с химическими структурами. Безусловно, их можно отображать графически, строить в объеме (в 3D-редакторе), разбивать на группы. Но при этом есть и компактная форма -- в виде формул и правил их преобразования. И она очень удобна для работы с такими структурами. Особенно если речь идет о преобразованиях.

Графическое представление ориентировано преимущественно на анализ.
Текстовое представление -- в большей мере на синтез.

Анализ и синтез -- две важных стороны любого мыслительного процесса.

Здесь можно провести параллели и с работой на компьютере. Есть GUI (graphic user interface), есть CLI (command language interface). При работе в текстовом редакторе есть меню (и мышка), а есть горячие клавиши (и клавиатура). Чтобы добраться до меню, надо спозиционировать мышь на нужной зоне экрана, прочитать-посмотреть варианты, выбрать нужный пункт (случайно при этом не попав на соседний), затем нажать/отжать кнопку мыши. Чтобы выполнить команду горячей клавишей, достаточно на клавиатуре нажать заранее известную комбинацию. Как известно, верстальщики, профессионально работающие с композицией текста и графики и ценящие свое время, к мыши притрагиваются довольно редко.

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

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

Так что предмета для спора не вижу.