Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, UnseriousSam, Вы писали:

US>>Ассемблерный код — тоже текст. Но одного-двух взглядов для его понимания не хватит.

AVK>Но совсем не потому что он недостаточно образен.

Абстрагируемся немного от программирования.
Есть у тебя GarbageCollector. Ты, предположим, понятия не имеешь, что это такое. Это не то, что в .NET является сборщиком мусора. Но ты очень хочешь узнать, что это такое. Тебе говорят, что GarbageCollector — это маньяк. А о маньяках, предположим, ты знаешь много. Это не говорит о том, что ты теперь знаешь, что такое GarbageCollector. Но это равносильно тому, как если бы ты писал книгу, ты бы уже набросал в общем сюжет, основных героев, их характеры. Т.е. у тебя был бы общий набросок. А потом в короткой беседе останется только уточнить сюжет, героев и их характеры, чтобы получить полную картину.
Понимаешь? Это метафора. Что-то неизвестное сравнивают с чем-то хорошо известным и это что-то неизвестное уже становится чем-то более или менее понятным. Это, если хочешь, принцип, на котром построены Шаблоны Проектирования. Ты один раз изучаешь шаблон а потом уже оперируешь готовым образцом. Ты говоришь Visitor — а в голове с этим словом уже ассоциируется много всякой разной информации: классы, объекты, взаимодействия, примеры использования и прочее. Называя класс Visitor тебе не все сразу становится понятным, но общий такой большой набросок уже есть, остается только добавить штрихи.
У нас за нашу прожитую жизнь есть ОГРОМНЫЙ багаж опыта и знаний, которые можно использовать как метафоры в программировании. Я про это говорю.
Если сейчас абстрагироваться от пугающих уже всех слов "графическое программирование" и "образы", то, что я написал выше понятно?

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, UnseriousSam, Вы писали:

US>>Если теперь каждую переменную написать не обычными печатными буквами, а подобрать какой-нибудь красивый нестандартный шрифит.
US>>Если нарисовать, например, первую переменную как букву "a", с глазами с ногами, с улыбкой...
US>>Можно теперь добавить звук.

K>Можно, но не нужно. У меня, скорее всего, возникнет раздражение уже после первого пункта, а после второго возникнет непреодолимое желание нанести травмы автору этого художества. И я еще горячий сторонник визуализации всего, чего только можно в иллюстративных целях. Но вот это вот — не иллюстрация — это шизофренизация.

Какой ты важный. Пену изо рта пускаешь. Ну уволят тебя просто-напросто, будешь пену дома пускать. Или ты думаешь, что все вертится вокруг твоего раздражения?

Здравствуйте, UnseriousSam, Вы писали:

US>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>Здравствуйте, LaPerouse, Вы писали:

LP>>>>Здравствуйте, Klapaucius, Вы писали:
K>>>>>Здравствуйте, UnseriousSam, Вы писали:
US>>>>>>жестокого палача, например, для Garbage Collector'а.
K>>>>>Несерьезные массы, как обычно, неправильно понимают работу GC. Это не палач, а санитар, который разыскивает на поле боя живых среди трупов.

LP>>>>Вообще-то, это шакал, который выискивает трупы среди живых

KV>>>Ничего подобного. Это маньяк , который ходит по полю с топором среди живых, хватает каждого за руку и спрашивает окружающих, не знают ли они кто он такой. Если его никто не знает, он убивает несчастного, выносит тело за поле боя и идет дальше в поисках очередной жертвы.

G>>Не, он просто всех мочит, а потом собирает живых там где трупов нет.

US>Во-во. Уже немного втянулись в визуализацию Смотрите не подсядьте
US>Как вы заметили такой разговор более веселый и следовательно более активно стимулирует мышление и творческие процессы. А все дело в волшебных... связах в головном мозге, которых в данном общении на порядки порядков больше, чем если бы GarbageCollector сравнивался с ConfigurationReader'ом или BusinessObjectMapper'ом.

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

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

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, UnseriousSam, Вы писали:

US>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>>Здравствуйте, LaPerouse, Вы писали:

LP>>>>>Здравствуйте, Klapaucius, Вы писали:
K>>>>>>Здравствуйте, UnseriousSam, Вы писали:
US>>>>>>>жестокого палача, например, для Garbage Collector'а.
K>>>>>>Несерьезные массы, как обычно, неправильно понимают работу GC. Это не палач, а санитар, который разыскивает на поле боя живых среди трупов.

LP>>>>>Вообще-то, это шакал, который выискивает трупы среди живых

KV>>>>Ничего подобного. Это маньяк , который ходит по полю с топором среди живых, хватает каждого за руку и спрашивает окружающих, не знают ли они кто он такой. Если его никто не знает, он убивает несчастного, выносит тело за поле боя и идет дальше в поисках очередной жертвы.

G>>>Не, он просто всех мочит, а потом собирает живых там где трупов нет.

US>>Во-во. Уже немного втянулись в визуализацию Смотрите не подсядьте
US>>Как вы заметили такой разговор более веселый и следовательно более активно стимулирует мышление и творческие процессы. А все дело в волшебных... связах в головном мозге, которых в данном общении на порядки порядков больше, чем если бы GarbageCollector сравнивался с ConfigurationReader'ом или BusinessObjectMapper'ом.

G>Как раз обратный эффект наблюдается. Высказано уже несколько отличающихся друг от другого "образов" GC, при этом если образ оторвать от самого определения GC, то мало кто сможет восстановить по нему что это такое.

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

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

Здравствуйте, UnseriousSam, Вы писали:

AVK>>Но совсем не потому что он недостаточно образен.

US>Абстрагируемся немного от программирования.

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

US>Есть у тебя GarbageCollector. Ты, предположим, понятия не имеешь, что это такое. Это не то, что в .NET является сборщиком мусора. Но ты очень хочешь узнать, что это такое. Тебе говорят, что GarbageCollector — это маньяк. А о маньяках, предположим, ты знаешь много.

Не слишком ли много предположений?

US> Это не говорит о том, что ты теперь знаешь, что такое GarbageCollector. Но это равносильно тому, как если бы ты писал книгу, ты бы уже набросал в общем сюжет, основных героев, их характеры. Т.е. у тебя был бы общий набросок. А потом в короткой беседе останется только уточнить сюжет, героев и их характеры, чтобы получить полную картину.
US>Понимаешь?

Нет.

US> Это метафора.

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

US> Что-то неизвестное сравнивают с чем-то хорошо известным и это что-то неизвестное уже становится чем-то более или менее понятным.

Кто сравнивает? Зачем сравнивает?

US> Это, если хочешь, принцип, на котром построены Шаблоны Проектирования.

Не хочу. И те шаблоны, о которых речь у банды, на этом не построены.

US> Ты один раз изучаешь шаблон а потом уже оперируешь готовым образцом.

Нет.

US> Ты говоришь Visitor — а в голове с этим словом уже ассоциируется много всякой разной информации: классы, объекты, взаимодействия, примеры использования и прочее. Называя класс Visitor тебе не все сразу становится понятным, но общий такой большой набросок уже есть, остается только добавить штрихи.

Не вижу связи с вышеизложенным.

US>У нас за нашу прожитую жизнь есть ОГРОМНЫЙ багаж опыта и знаний

Есть.

US>, которые можно использовать как метафоры в программировании.

Как метафоры — нельзя. Можно использовать как элемент архитектурной азбуки. Но никакой связи у этой азбуки с непонятными образами нет. Язык паттернов в немалой степени формален и не имеет ничего общего с описываемыми тобой размытыми образами и метафорами.

US>Если сейчас абстрагироваться от пугающих уже всех слов "графическое программирование" и "образы", то, что я написал выше понятно?

Нет.

Здравствуйте, UnseriousSam, Вы писали:

US>Абстрагируемся немного от программирования.
US>Есть у тебя GarbageCollector. Ты, предположим, понятия не имеешь, что это такое. Это не то, что в .NET является сборщиком мусора. Но ты очень хочешь узнать, что это такое. Тебе говорят, что GarbageCollector — это маньяк. А о маньяках, предположим, ты знаешь много.

Жесть.

Здравствуйте, UnseriousSam, Вы писали:

US>Ассемблерный код — тоже текст. Но одного-двух взглядов для его понимания не хватит.
Я не понимаю смысла делать такое утверждение в контексте данной беседы. С этим утверждением никто не спорит.
Чтобы оно стало полезным, имеет смысл проанализировать причины того, что понимание ассемблера затруднено. Ты вот делаешь акцент именно на текстовости представления, не удосуживаясь обосновать причины.
Хорошо, сделаем ход конём: уберём из ассемблера текст, заменим его графикой. Неужто он вдруг станет понятнее?
Я вот что-то не могу себе такого представить. Хоть в виде блок-схемы рисуй, хоть заменяй mov-ы и cmpxchg-ы на "человечков", а регистры на цветовые обозначения — понятность никак не изменится. Проблемы ассемблера (если мы, конечно, говорим про мнемоническое представление исполняемого кода, а не про макроассемблер, который совсем-совсем другой язык) в том, что он оперирует слишком мелкими кирпичиками. Некоторые виды диаграмм могут помочь осознать какие-нибудь скрытые в тексте аспекты ассемблерной программы — например, потенциал распараллеливаемости команд по конвеерам, или равномерность использования регистров. Но собственно смысл программы и её корректность будут столь же малопонятны из любого графического изображения, и тем более фильма.


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

Здравствуйте, LaPerouse, Вы писали:

LP>Объекты — это термы в логике предикатов. Объект — сущность формализованная, строго определенная, находящаяся в опять же строго определенном отношении с другими объектами.
Ну, допустим.
LP>Образы же свойственны исключительно человеческому мышлению. Знаешь, какая разница между логикой предикатов и человеческим мышлением? Эта разница приблизительно равна разнице между имплементацией Пролога и нейронной сеткой. Две принципиально разные способы представления и обработки информации. Первый способ предполагает формализованный подход, вторая — неформализованный, нечеткий.
Не вижу ничего неформализованного в нейронной сетке. Возможно, в силу узости кругозора.
LP>Наш интеллект реализован в виде нейронной сетки, поэтому хотим мы того или нет, мы оперируем образами — не зависимо от того, слушаем оперу или доказываем теорему Пифагора. В последнем случае образы являются бекэндом для логики предикатов, но от них все равно никуда не деться, ибо такова архитектура нашего мозга.
Пока всё вроде ок. Ну, кроме разве что того, что мне неизвестно точно, как именно реализован интеллект. У меня есть веские сомнения, что наличие нейронной сетки играет здесь хоть какую-то роль. На мой взгляд, уровень нейронов отстоит от уровня мышления даже дальше, чем уровень транзисторов от уровня JavaScript. Аналогом таких рассуждений на мой взгляд могла бы быть цепочка типа "компьютер реализован в виде полупроводниковой схемотехники, где доминируют квантовые эффекты для электронов, так что вычислительной технике никуда не деться от квантовой неопределённости, ибо такова архитектура компьютера". Очевидно, она не соответствует действительности.
Впрочем, это неважно — даже если бы мышление человека было бы построено на основе соломы и мышиного помёта, как мышление Страшилы из Изумрудной страны, все выводы остануться справедливыми. До тех пор, пока они опираются на образность мышления, как неотъемлемую его характеристику.

LP>Из этого, само собой, не следует, что информацию следует хранить и обрабатывать в виде образов. Но вот представление информации ввиде образов для удобной работы с ней может быть полезным. Вот конкретный пример. Возьмем семантик веб, построенный на веб-онтологиях RDF/OWL. Онтологии RDF/OWL — это подмножество логики первого порядка (логики предикатов). Зайди на страничку COMM — A Core Ontology for Multimedia и посмотри на визуализацию онтологий, полученную с помощью аавтоматических средств просмотра RDF. Также можешь закачать RDF Gravity — бесплатный инструмент для визуализации онтологий (к сожалению, довольно убогий, но хорошие стоят денег). А потом скачай по ссылке zip-архив с онтологиями и посмотри текстовые файлы Что для тебя понятнее?
Лично мне было бы гораздо понятнее внятное описание "кто на ком стоял" на обычном английском или русском языке.
На всякий случай напомню, что ведущие собаководы рекомендуют крайне осторожно относиться, например, к злоупотреблению диаграммами для описания use-cases. Подчёркивают необходимость текстового описания, которое может дополняться диаграммами. Это, кстати, к вопросу "хотели бы вы, чтобы заказчик формулировал ТЗ в виде двухчасового фильма". Да, если к фильму будет прилагаться внятное текстовое описание того, что в фильме важно, а что — эмоциональные детали. Что — проблема, а что — предлагаемое решение.
Вернёмся к онтологиям: моё личное непонимание здесь, конечно же, не аргумент. С тем же успехом я бы мог протестовать против записи меню ресторана на японском языке — это ничего не говорит пригодности языка для описания блюд; это только говорит о моём незнакомстве с этим языком.
Так что я не буду утверждать, что конкретно для онтологий текстовый язык лучше всего. Ещё раз поясню свою позицию: графическое представление может хорошо подходить для конкретных применений. Текст — пригоден для всего.
Сила текста — в умении строить новые языки. Он одинаково хорош для описания конечных автоматов и для описания взаимно-рекурсивных функций.
Товарищ Tufte демонстрирует очень эффектные применения графики для представления информации.
Кстати, местами он прямо-таки рвёт и мечет "схематичные" представления информации, типа PowerPoint, агитируя в пользу текста — типа таблиц.

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

И ведь мы всё ещё бесконечно далеки от того, о чем писал топикстартер. Блок-схемы и HTML разметка — это ведь никакой не фильм. Никакие эмоции она не затрагивает; работает, грубо говоря, с той же частью сознания, что и текст программы.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, UnseriousSam, Вы писали:

US>>Ассемблерный код — тоже текст. Но одного-двух взглядов для его понимания не хватит.
S>Я не понимаю смысла делать такое утверждение в контексте данной беседы. С этим утверждением никто не спорит.
S>Чтобы оно стало полезным, имеет смысл проанализировать причины того, что понимание ассемблера затруднено. Ты вот делаешь акцент именно на текстовости представления, не удосуживаясь обосновать причины.
S>Хорошо, сделаем ход конём: уберём из ассемблера текст, заменим его графикой. Неужто он вдруг станет понятнее?
S>Я вот что-то не могу себе такого представить. Хоть в виде блок-схемы рисуй, хоть заменяй mov-ы и cmpxchg-ы на "человечков", а регистры на цветовые обозначения — понятность никак не изменится. Проблемы ассемблера (если мы, конечно, говорим про мнемоническое представление исполняемого кода, а не про макроассемблер, который совсем-совсем другой язык) в том, что он оперирует слишком мелкими кирпичиками. Некоторые виды диаграмм могут помочь осознать какие-нибудь скрытые в тексте аспекты ассемблерной программы — например, потенциал распараллеливаемости команд по конвеерам, или равномерность использования регистров. Но собственно смысл программы и её корректность будут столь же малопонятны из любого графического изображения, и тем более фильма.

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

Здравствуйте, UnseriousSam, Вы писали:

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

Точно так же я могу утверждать что намного проще не заморачивать себе голову всяким шумом.

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

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

Возьмем непрерывную функцию. Наверное все могут представить ее на каком-нибудь примере f:R->R. Или все могут представить пространство (или думают что могут представить пространство, а на самом деле дальше R^4 вряд ли представлялка сработает). А теперь возьмем пространство непрерывных функций. Словами описать можно, а представить картинку — ну его нафик.
Ну и мне как бы немного жаль творческих людей, которые будут строить метафору для такого рода объектов, а потом работать с ними основываясь на свойствах метафор.

Может я просто из леса и меня плохо учили? покажите мне метафору для пространства непрерывных функций.

Здравствуйте, UnseriousSam, Вы писали:

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

US>Т.е. "Вова купил булку" осядет у тебя в голове очень лекго и без проблем. Без проблем ты также сможешь потом этой информацией оперировать. У мозга такое свойство: чем проще положилось внутрь, тем проще потом оно достается. Ассемблерный код, по моему мнению, тем и сложен, что предаставляет собой информацию, которая как бы нова для нас, которая позволяет установить с ней небольшой количество связей.
Это мнение, скажем так, неплохо бы хоть чем-нибудь подкрепить. Потому что сложность ассемблера — вовсе не в новизне. Даже после того, как человек заучивает понятия регистров, памяти, портов, и команд, ассемблер не становится проще для восприятия. Это всё равно как смотреть на слона с расстояния в три миллиметра: видны складки кожи, щетина, неравномерность цвета. Но слона не видно. Ассемблер просто слишком низкоуровневый для того, чтобы на нём объяснять сложные концепции. В нём нет способов для композиции понятий. Уже в Форте — есть, благодаря чему Форт нетрудно понять.

US>Поэтому такой код сложен и для написания, и для чтения, и для понимания. При объектно-ориентированном подходе мы видим совсем другую картину: программный мир кишит знакомыми объектами, с "аналогами" которых мы успели познакомиться за предыдущий наш жизненный опыт. Тут Поставщики, Коллекторы, Списки, Множества, Заказчики, Ридеры, Криэйторы, Читатели, Писатели и т.д, и т.п. Познакомился с предметной областью — и часть дела сделана.
Это заблуждение. Наличие предыдущего жизненного опыта никак не помогает при ООП, тем более, что большинство объектов в нём никакого отношения к реальному миру не имеют. Банальный TextReader не имеет никакого отношения к человеку, читающему книжку без картинок. TextReader — это всего лишь абстракция. Чем быстрее программист осознает это, тем быстрее он начнёт программировать. Реальные программисты никогда не представляют себе в голове никакого Читателя, когда воспринимают или проектируют программу с TextReader-ами. В голове сразу есть образ, которому нет аналогов в реальном мире. Этот образ не трёхмерный и не плоский, у него нет ни цвета, ни запаха, ни текстуры, ни упругости, ни массы. У него есть только поведение. У IEnumerable<T> — тоже.

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

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

Это вообще типичная ловушка, в которую попадают жертвы плохого преподавания ООП. Те, кто верит, что ООП имеет какое-то отношение к моделированию реального мира. Те, кто учился, скажем, физике, знают, что некоторым вещам никаких аналогов нет. Ну вот как вы, к примеру, представляете себе банальный электрический заряд? Или магнитное поле? С учётом того, что человек их воспринимать непосредственно не способен вообще? А как вы будете представлять себе спин? Даже понятия "силы" и "работы" в физике имеют весьма отдалённое отношение к бытовым понятиям. Это всего лишь символы.
Как вы будете представлять себе оператор Д'Аламбера? А четырёхмерный вектор-потенциал, к которому он применяется?
И зачем вы будете это делать? Метафора хороша до тех пор, пока её взаимоотношения с другими метафорами позволяют корректно описывать модель — ну там, принцип невылета цвета в квантовой хромодинамике. Вот только такие метафоры придумать крайне сложно, и уж конечно заставлять это делать каждого программиста — бессмысленная трата усилий.

Здравствуйте, Sinclair, Вы писали:

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

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

так вот, я полагаю, что люди которые добиваются наибольших успехов в областях, требующих абстрактного мышления, делают это именно за счёт того, что они ухитряются подтягивать к нему мышление конкретное, оперируя как правило определёнными образами (поскольку зрительная часть занимает 80% этого "gpu"), а не за счёт того, что у yb] абстрактное мышление само по себе имеет какое-то небывалое развитие. и потому всякое усовершенствование, "визуализирующее" человеку его предметную область, облегчает ему работу. простой пример — в каком виде лучше видеть breakpoint — в виде строки main.cpp:888 или подсвеченной строки в исходниках? или данные в виде шестнадцатеричной или текстовой строки? или сигнал тревоги в ядерном реакторе — в виде цифры или резкого звукового+визуального сигнала?

принцип wysiwyg не зря развился — он позволяет человеку подключить своё "gpu" и обрабатывать информацию на порядки эффективней. и глупо говорить что он применим только к "конкретной" информации. асбтратное — это то, что ешё не успели представить в виде конкретного

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, UnseriousSam, Вы писали:

US>>Я не представляю графическое программирование, как заменут ассемблера просто на картинки. Сама суть, сама идея основывается на другом. Мозг при поступлении новой информации устанавливает связи этой информации с уже существующей, в нем содержащейся. По сути устанавливаются все возможные связи, которые он только сможет установить. Если ты прочитал в книге "Вова купил булку", то в мозгу эта информация будет ассоциироваться со всеми Вовами, которых ты знаешь, со всеми людьми, которые когда-либо покупали булку и которых ты видел, со всеми булками, которые ты сам покупал или когда-либо видел.
S>Это не совсем так. Стоит потренировать человека буквально несколько минут, как "Вова купил булку" будут означать "банк взят, подъезжай к запасному выходу, как мы договорились". Слова — это всего лишь символы. Программисты очень хорошо натренированы заменять одни символы другими.

US>>Т.е. "Вова купил булку" осядет у тебя в голове очень лекго и без проблем. Без проблем ты также сможешь потом этой информацией оперировать. У мозга такое свойство: чем проще положилось внутрь, тем проще потом оно достается. Ассемблерный код, по моему мнению, тем и сложен, что предаставляет собой информацию, которая как бы нова для нас, которая позволяет установить с ней небольшой количество связей.
S>Это мнение, скажем так, неплохо бы хоть чем-нибудь подкрепить. Потому что сложность ассемблера — вовсе не в новизне. Даже после того, как человек заучивает понятия регистров, памяти, портов, и команд, ассемблер не становится проще для восприятия. Это всё равно как смотреть на слона с расстояния в три миллиметра: видны складки кожи, щетина, неравномерность цвета. Но слона не видно. Ассемблер просто слишком низкоуровневый для того, чтобы на нём объяснять сложные концепции. В нём нет способов для композиции понятий. Уже в Форте — есть, благодаря чему Форт нетрудно понять.

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

US>>Поэтому такой код сложен и для написания, и для чтения, и для понимания. При объектно-ориентированном подходе мы видим совсем другую картину: программный мир кишит знакомыми объектами, с "аналогами" которых мы успели познакомиться за предыдущий наш жизненный опыт. Тут Поставщики, Коллекторы, Списки, Множества, Заказчики, Ридеры, Криэйторы, Читатели, Писатели и т.д, и т.п. Познакомился с предметной областью — и часть дела сделана.
S>Это заблуждение. Наличие предыдущего жизненного опыта никак не помогает при ООП, тем более, что большинство объектов в нём никакого отношения к реальному миру не имеют. Банальный TextReader не имеет никакого отношения к человеку, читающему книжку без картинок. TextReader — это всего лишь абстракция. Чем быстрее программист осознает это, тем быстрее он начнёт программировать. Реальные программисты никогда не представляют себе в голове никакого Читателя, когда воспринимают или проектируют программу с TextReader-ами. В голове сразу есть образ, которому нет аналогов в реальном мире. Этот образ не трёхмерный и не плоский, у него нет ни цвета, ни запаха, ни текстуры, ни упругости, ни массы. У него есть только поведение. У IEnumerable<T> — тоже.

Не в ту сторону ты клонишь постоянно. Ты задумывался, почему TextReader называется Reader, а не Абракадабра? Хотя казалось бы какая разница, как его называть: запомним со временем и будем пользоваться. Я, если бы не знал, что это такое, имел бы по крайней мере какое-то представление, для чего это нужно и как это использовать. А покажи это неграмотному африканскому подростку, которые не знает ни что такое Text, ни что такое Read... И ты говоришь предыдущий жизненный опыт никак не помогаем.

US>>Если про ассемблер опять. Намного проще, чем представлять себе регистры процессора и помнить, какой занять, какой свободен, предат, к примеру, комнату из десяти столов разных цветов, за которыми сидят знакомые тебе люди: если регистр занят, то стол занят, если свободен — стол также свободен.
S>Нет. Проще сразу представлять себе регистр.

Ну да, проще. Я немного не то сказал. Тут важно, что при запоминании информации используется что-то уже известное. Если ты программируешь регистры, то, конечно, не стоит придумывать никакие столы.

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

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

S>Это вообще типичная ловушка, в которую попадают жертвы плохого преподавания ООП. Те, кто верит, что ООП имеет какое-то отношение к моделированию реального мира. Те, кто учился, скажем, физике, знают, что некоторым вещам никаких аналогов нет. Ну вот как вы, к примеру, представляете себе банальный электрический заряд? Или магнитное поле? С учётом того, что человек их воспринимать непосредственно не способен вообще? А как вы будете представлять себе спин? Даже понятия "силы" и "работы" в физике имеют весьма отдалённое отношение к бытовым понятиям. Это всего лишь символы.
S>Как вы будете представлять себе оператор Д'Аламбера? А четырёхмерный вектор-потенциал, к которому он применяется?
S>И зачем вы будете это делать? Метафора хороша до тех пор, пока её взаимоотношения с другими метафорами позволяют корректно описывать модель — ну там, принцип невылета цвета в квантовой хромодинамике. Вот только такие метафоры придумать крайне сложно, и уж конечно заставлять это делать каждого программиста — бессмысленная трата усилий.

Я никак не собираюсь это представлять. Я говорю, что независимо от нашего желания это неосознанно делает наш мозг. Ты спрашиваешь, как представить "магнитное поле". А ты задумывался, почему его назвали "полем"? Хочешь я тебе опишу, как я представляю пшеничное поле во время ветра. Представь и ты. Ничего не напоминает? Почему spin — крутиться, или что-то вроде этого, по-английски? Наверное, эти слова отражают то, что происходило в голове у тех людей, которые эти понятия придумали. Отражает те сравнения, через которые они постигали реальность. Есть пример из химии, когда змея кусает себя за хвост. Так была придумана какая-то химическая формула.

Здравствуйте, BulatZiganshin, Вы писали:

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

BZ>к чему я это говорю. человек — это животное. все его психологчиеские способности появились как средство рещния обычных задач, стоящих перед животным — добыча пиши, забота о потомстве и т.п. все эти задачи рещаются в мире конкретного, абстрактное же — лишь небольшая вспомогательная часть его психики. это можно сравнить с компом — абстрактное мышление это аналог CPU, спосбное решать любые задачи, но медленно и последовательно, основная же мощь — в GPU, специализированных участках мозга, решающих конкретные задачи. например, попробуй чисто логическими рассуждениями узнать своего знакомого по лицу. тебе и в голову никогда не приходило сознательно проанализировать, как ты его узнаёшь!

BZ>так вот, я полагаю, что люди которые добиваются наибольших успехов в областях, требующих абстрактного мышления, делают это именно за счёт того, что они ухитряются подтягивать к нему мышление конкретное, оперируя как правило определёнными образами (поскольку зрительная часть занимает 80% этого "gpu"), а не за счёт того, что у yb] абстрактное мышление само по себе имеет какое-то небывалое развитие. и потому всякое усовершенствование, "визуализирующее" человеку его предметную область, облегчает ему работу. простой пример — в каком виде лучше видеть breakpoint — в виде строки main.cpp:888 или подсвеченной строки в исходниках? или данные в виде шестнадцатеричной или текстовой строки? или сигнал тревоги в ядерном реакторе — в виде цифры или резкого звукового+визуального сигнала?

BZ>принцип wysiwyg не зря развился — он позволяет человеку подключить своё "gpu" и обрабатывать информацию на порядки эффективней. и глупо говорить что он применим только к "конкретной" информации. асбтратное — это то, что ешё не успели представить в виде конкретного

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

Здравствуйте, Klapaucius, Вы писали:

K>Консервативный — возможно. Но как может искать трупы точный? Они для него только пустое место между живыми.

Вернее даже не в консервативности дело. А во вспомогательности. Если ГЦ вспомогательный инструмент для какого-нибудь ручного управления или автоматического детерминированного освобождения памяти. Когда он основной — как такового "удаления" не происходит.
Тот же простейший копирующий ГЦ — это, к примеру, санитар, который заходит в палату и переводит всех живых пациентов в соседнюю, пустую. А когда приходит время делать то же самое уже в ней — первоначальная палата считается пустой. "Сборщик мусора" это, наверное, подходящее название для отображения того, для чего ГЦ нужен. Но совершенно не соотвествует тому, что он делает. Потому что сборщик мусора мусор не собирает. Для него мусора просто не существует.

Здравствуйте, UnseriousSam, Вы писали:

US>Какой ты важный. Пену изо рта пускаешь. Ну уволят тебя просто-напросто, будешь пену дома пускать. Или ты думаешь, что все вертится вокруг твоего раздражения?

Разумеется нет, если эта моя идиосинкразия встанет на пути совершенствования средств разработки — тут и вопросов нет — прогресс пойдет дальше, а я буду отброшен, как дефективный. Другое дело, что исходя из актуальных представлений о человеческом мышлении, отбросить придется почти всех — и без особых бенефитов для оставшихся по части производительности работы. Т.е. это никакой не прогресс, а возвращение в доязыковое детство человечества — обратно на деревья.

Здравствуйте, Klapaucius, Вы писали:

скажи, ты отключаешь синтаксическую раскраску? используешь однобуквенные имена переменных? никогда не пишешь комментариев? пишешь код в спагетти-стиле?

Здравствуйте, UnseriousSam, Вы писали:

US>Здравствуй, человек. Насколько вижу, мы с тобой на одной волне в этом вопросе. Может быть ты тогда отпишешься о идее графического программирования.

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>к чему я это говорю. человек — это животное. все его психологчиеские способности появились как средство рещния обычных задач, стоящих перед животным — добыча пиши, забота о потомстве и т.п. все эти задачи рещаются в мире конкретного, абстрактное же — лишь небольшая вспомогательная часть его психики.

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

Здравствуйте, Sinclair, Вы писали:

LP>>Образы же свойственны исключительно человеческому мышлению. Знаешь, какая разница между логикой предикатов и человеческим мышлением? Эта разница приблизительно равна разнице между имплементацией Пролога и нейронной сеткой. Две принципиально разные способы представления и обработки информации. Первый способ предполагает формализованный подход, вторая — неформализованный, нечеткий.
S>Не вижу ничего неформализованного в нейронной сетке. Возможно, в силу узости кругозора.

Сама нейронная сеть и механизмы ее работы, конечно, полностью формализованы. А вот знания, хранящиеся в ней — не всегда. Знание в НС — это просто набор весов и пороговых значений, определяющих ее поведение (другими словами, реализующих функцию выход = f(вход) ). "Не важно, о чем ты думаешь, лишь бы делал свою работу". Как-то так. Но иногда НС проектируют специально для формализации какой-то области знаний. В этом случае некоторые нейроны соответствуют объекту или понятию из предметной области. Если утверждение истинно, то соответствующий нейрон находится в состоянии "1", в противном случае — "0". Но даже в этом случае, как правило, вводятся элементы нечеткой логики, то есть может быть к примеру значение 0.8, которое можно трактовать как "скорее да, чем нет" (а это удар по формализации). Очевидно, подобные костыли служат выполнению узкоспециализированной задачи и имеют мало отношения к биологическим НС. Наш мозг — не такой.

LP>>Наш интеллект реализован в виде нейронной сетки, поэтому хотим мы того или нет, мы оперируем образами — не зависимо от того, слушаем оперу или доказываем теорему Пифагора. В последнем случае образы являются бекэндом для логики предикатов, но от них все равно никуда не деться, ибо такова архитектура нашего мозга.
S>Пока всё вроде ок. Ну, кроме разве что того, что мне неизвестно точно, как именно реализован интеллект. У меня есть веские сомнения, что наличие нейронной сетки играет здесь хоть какую-то роль. На мой взгляд, уровень нейронов отстоит от уровня мышления даже дальше, чем уровень транзисторов от уровня JavaScript. Аналогом таких рассуждений на мой взгляд могла бы быть цепочка типа "компьютер реализован в виде полупроводниковой схемотехники, где доминируют квантовые эффекты для электронов, так что вычислительной технике никуда не деться от квантовой неопределённости, ибо такова архитектура компьютера". Очевидно, она не соответствует действительности.

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

S>Лично мне было бы гораздо понятнее внятное описание "кто на ком стоял" на обычном английском или русском языке.



S>На всякий случай напомню, что ведущие собаководы рекомендуют крайне осторожно относиться, например, к злоупотреблению диаграммами для описания use-cases. Подчёркивают необходимость текстового описания, которое может дополняться диаграммами. Это, кстати, к вопросу "хотели бы вы, чтобы заказчик формулировал ТЗ в виде двухчасового фильма". Да, если к фильму будет прилагаться внятное текстовое описание того, что в фильме важно, а что — эмоциональные детали. Что — проблема, а что — предлагаемое решение.
S>Вернёмся к онтологиям: моё личное непонимание здесь, конечно же, не аргумент. С тем же успехом я бы мог протестовать против записи меню ресторана на японском языке — это ничего не говорит пригодности языка для описания блюд; это только говорит о моём незнакомстве с этим языком.
S>Так что я не буду утверждать, что конкретно для онтологий текстовый язык лучше всего. Ещё раз поясню свою позицию: графическое представление может хорошо подходить для конкретных применений. Текст — пригоден для всего.

Да, текст — универсальный способ хранения знаний. В этом я с тобой согласен на все сто. RDF/OWL — штука из той же оперы, что и обычный текст, просто они реализуют лишь небольшую часть логики первого порядка. А у графического представления как раз вполне конкретное применение — облегчение восприятия информации, изложенной в тексте, человеком. Именно по той причине, что подобное представление информации гораздо скорее порождает в голове у человека нужные образы, чем текст, который нужно еще распарсить, понять, и сгенерировать эти образы самостоятельно. Графическая информация как бы ближе нативному языку нашего мозга — языку образов, это как бы готовый суп для мозга, а не кровавый бифтшекс, который нужно еще переварить. Тут есть один тонкий момент — если графика столько близка к нашему мозгу, почему часто бывает так, что сложная информация, изложенная в виде текста, понятнее графики? У меня есть одно объяснение, но я не уверен, что оно правильное

S>И ведь мы всё ещё бесконечно далеки от того, о чем писал топикстартер. Блок-схемы и HTML разметка — это ведь никакой не фильм. Никакие эмоции она не затрагивает; работает, грубо говоря, с той же частью сознания, что и текст программы.

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