Re[2]: Графическое программирование и здоровье
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.06.10 18:54
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

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

Давайте наоборот — представьте, что вы читаете интересную книгу.

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


А теперь попробуйте всё это визуализировать в фильме, а? Сколько времени займет ролик, который покажет вам и дона Тамэо, и седьмую могилу святого Мики, и унылое мотание головой, и звон комаров, и осень, и дни, и вечера, и море неподалёку?
А прочесть вы это можете за несколько секунд.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ёку
Re[4]: Графическое программирование и здоровье
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.06.10 19:07
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

US>А живопись, кино, театр?

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

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

Ещё рекомендую ознакомиться с трудами товарища Tufte. Он один из лучших специалистов по восприятию информации.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 16.06.10 19:20
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

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


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

S>Давайте наоборот — представьте, что вы читаете интересную книгу.
S>

S>Когда Румата миновал могилу святого Мики — седьмую по счету и последнюю на этой дороге, было уже совсем темно. Хваленый хамахарский жеребец, взятый у дона Тамэо за карточный долг, оказался сущим барахлом.
S>Он вспотел, сбил ноги и двигался скверной, вихляющейся рысью. Румата сжимал ему коленями бока, хлестал между ушами перчаткой, но он только уныло мотал головой, не ускоряя шага. Вдоль дороги тянулись кусты, похожие
S>в сумраке на клубы застывшего дыма. Нестерпимо звенели комары. В мутном небе дрожали редкие тусклые звезды. Дул порывами несильный ветер, теплый и холодный одновременно, как всегда осенью в этой приморской стране с
S>душными, пыльными днями и зябкими вечерами.


S>А теперь попробуйте всё это визуализировать в фильме, а? Сколько времени займет ролик, который покажет вам и дона Тамэо, и седьмую могилу святого Мики, и унылое мотание головой, и звон комаров, и осень, и дни, и вечера, и море неподалёку?

S>А прочесть вы это можете за несколько секунд.

Могу только сказать, что ты ошибаешься. Количество информации несравнимо больше в фильме. Это как если бы ты посмотрел фильм, а потом тебя спросили, про что он. Ты бы ответил двумя-тремя предложениями, а потом подумал, зачем тебе нужно было париться и смотреть весь фильм, когда можно было точно также у кого-нибудь спросить про смысл. Тебе бы точно также ответили бы двумя-тремя предложениями. Ты потрабил бы не полтора часа, а 20 секунд. Ты сравниваешь в контексте использования полученной информации, обрезая все остальное. Только потом, когда кто-то спросит, как было главное имя героя фильма — ты не будешь знать. Или спросят, на какой машине ездил главный герой — ты этого также не будешь знать. Все потому, что предпочел послушать краткое изложение смысла.
Вопрос к тебе лично. Скажи, почему ты не программируешь на машинных кодах? Компьютеру кроме машинных кодов больше ничего не надо.
Re[5]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 16.06.10 19:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


US>>А живопись, кино, театр?

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

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

S>К примеру, тензор человек воспринимает именно как тензор. Независимо от того, кинестетик ли он или визуал. Тензор — это просто штука, которая ведёт себя определённым образом. Я визуал, тем не менее у меня термин "масса" в различных контекстах может означать "величину, которая определяет меру гравитационного взаимодействия тел", "величину, которая определяет зависимость ускорения тела от приложенной силы", "большое количество чего-нибудь", "условную землю в электротехнике". Никаких визуальных, звуковых или кинестетических образов с этим словом не ассоциируется.
S>На этом, собственно, заканчивается идея передавать графически содержание компьютерных программ.
S>Для некоторых частных случаев визуальное представление может помогать (как, например, для сеток в численном моделировании), для массового применения — нет.

S>Ещё рекомендую ознакомиться с трудами товарища Tufte. Он один из лучших специалистов по восприятию информации.


Когда ты говоришь, что у тебя не ассоциируется — только значит, что ты этого не осознаешь.
Скажи, что из следующего просто не может быть...
"величину, которая определяет меру гравитационного взаимодействия тел" — ассоциации с двумя притягивающимися планетами: Землей и Марсом. Я уверен, что ты видел подобные иллюстрации, когда изучал Астрономию.
"величину, которая определяет зависимость ускорения тела от приложенной силы" — хотя бы иллюстрация из учебника по физике, которая наглядно показывает эту формулу.
"большое количество чего-нибудь" — толпа людей
"условную землю в электротехнике" — уверен, эту условную землю ты также мог наблюдать в учебнике по электротехинке.
Re[6]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 16.06.10 19:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


US>>Да, проще написать GC.Collect(), чем нарисовать образ мужика. Почему тогда художник вместо того, чтобы париться и рисовать картину, просто бы на холсте не написал "девочка стоит на мячике, рядом сидит мужик"

S>Потому, что это делает писатель.

US>> Или почему не создают текстовое кино: "главный герой нажал на курок, злодей упал, мир спасен"

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

US>>Почему вместо GC.Collect не написать G.C()? Во времена ассемблера вроде как проекты не выходили за пределы несколько тысяч строк кода: сложность была непреодолимая. А теперь проекты с миллионом строк кода. Переменные мы больше не называем направо и налево a, b, c, d, а стараемся писать осмысленные именна. Мы не программируем на C в объектно-ориентированной парадигме. Для это мы используем C++. Кстати, объектно-ориентированно можно программировать на ассемблере. Вопрос только будет в той пропасти, что между тем, что мы видим на экране монитора и тем, что происходит у нас в голове. Насколько хватит мозгового ресурса при программировании на C++ и при программировании на ассемблере? Все это выльется в соответствующий результат: пострадает и скорость, и качество.

US>>В итоге разница получается есть для тех, кто будет читать наш код, а не для тех, кто его пишет. Любимое наше программерское: код чаще читаем, чем пишем.
US>>Я графическое программирование представляю как процесс создания картины или мультика. А если просто, то вместо текстового языка использовать графический, где можно будет по полной развернуть свои творческие способности.
S>Пока что все среды графического программирования потерпели фундаментальные фиаско. Есть мнение, что это из-за катастрофической непригодности их для таких задач. Плотность информации в картине или мультике на порядки ниже, чем в самой простой программе. Подумайте о том, почему хорошие фильмы получаются не из романов, а из рассказов. А из романов получаются какие-то выжимки, где опущено 2/3 содержания, а то и больше.

S>Не стоит недооценивать текст.


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

Про романы и фильмы по ним. Возьмем фильм без звука. Если его, скажешь, ускорить хотя бы в 10 раз, то человек сможет ответить на все те же вопросы по фильму, что и человек, который смотрел фильм на обычной скорости. Обычный фильм длится полтора часа, а на роман человек может потратить несколько дней. Дай кинематографискам снять фильм, длительностью в несколько дней, потом уже сравнивай. К тому, если у человека активный внутренний диалог, то скорее всего он будет успевать осознавать при просмотре фильма только ту часть, которая будет комментироваться его внутренним голосом. Скорость обработки информации у сознательного мышления 2000 бит информации в секунду, скорость у подсознания доходит до 4 миллиардов бит информации в секунду. Опять добавлю, что если ты не осознаешь, то это не значит, что ты этого не знаешь.
Re[3]: Графическое программирование и здоровье
От: FR  
Дата: 16.06.10 19:51
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

US>А пойдем мы по направлению упрощения скармливания мозгу информации, делание этого процесса прямым, без лишних преобразований. А мозг любит образы.


Если брать человеческий мозг то эти образы организуются во вторую сигнальную систему наиболее выраженное проявление которой это речь, слова, текст.
Re[4]: Графическое программирование и здоровье
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.06.10 22:53
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

US>Могу только сказать, что ты ошибаешься.

В чём?
Я привёл пример. Сколько времени займет ролик со всей этой информацией?

US> Количество информации несравнимо больше в фильме. Это как если бы ты посмотрел фильм, а потом тебя спросили, про что он. Ты бы ответил двумя-тремя предложениями, а потом подумал, зачем тебе нужно было париться и смотреть весь фильм, когда можно было точно также у кого-нибудь спросить про смысл.

Неверная аналогия.

US>Тебе бы точно также ответили бы двумя-тремя предложениями. Ты потрабил бы не полтора часа, а 20 секунд. Ты сравниваешь в контексте использования полученной информации, обрезая все остальное. Только потом, когда кто-то спросит, как было главное имя героя фильма — ты не будешь знать. Или спросят, на какой машине ездил главный герой — ты этого также не будешь знать.

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

US>Вопрос к тебе лично. Скажи, почему ты не программируешь на машинных кодах? Компьютеру кроме машинных кодов больше ничего не надо.

Вопрос не имеет отношения к остальному тексту. Тем не менее отвечу: я программирую на том, что удобно мне, а не компьютеру.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Графическое программирование и здоровье
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.06.10 23:01
Оценка: +1
Здравствуйте, UnseriousSam, Вы писали:

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


US>Когда ты говоришь, что у тебя не ассоциируется — только значит, что ты этого не осознаешь.

US>Скажи, что из следующего просто не может быть...
US>"величину, которая определяет меру гравитационного взаимодействия тел" — ассоциации с двумя притягивающимися планетами: Землей и Марсом. Я уверен, что ты видел подобные иллюстрации, когда изучал Астрономию.
Нету у меня никакой ассоциации с планетами. Вообще физическое понятие "тело" не ассоциируется ни с чем из реального мира. Это абстракция, наделённая определёнными свойствами. Я гравитацию вообще представляю так, как ни на какой картинке не нарисуешь, и в фильме не покажешь.

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

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

Какие нафиг могут быть "кинестетические ассоциации" у терминов типа "производная", "первообразная", "тензор", "инфинитезимальный"? Вы придумали свою модель человеческого мышления, которая не соответствует действительности, и пытаетесь натянуть на эту модель наблюдаемые факты.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Графическое программирование и здоровье
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.06.10 23:12
Оценка: +2
Здравствуйте, UnseriousSam, Вы писали:

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

Конечно. Ответ очевиден: человек визуализирует книгу при помощи воображения, которое мощнее любого рендера. К примеру, у JRRT Галадриэль — невозможная красавица. Читаешь — и вот тебе красавица. Смотришь кино — баба как баба.

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

Как вы собрались передать в ролике то, что плащ не с красным, а с кровавым подбоем? Как вы передадите кавалерийскость походки — да ещё так, чтобы её осознал человек, в жизни не видевший кавалериста?

US>Про романы и фильмы по ним. Возьмем фильм без звука. Если его, скажешь, ускорить хотя бы в 10 раз, то человек сможет ответить на все те же вопросы по фильму, что и человек, который смотрел фильм на обычной скорости.

При чём тут вопросы?
US>Обычный фильм длится полтора часа, а на роман человек может потратить несколько дней.
А может и не потратить. У меня крейсерская скорость чтения — 100 страниц в час. То есть, LOTR я за десять часов прочитаю. А теперь сравним фильм с книгой — получится, что фильм — только "краткое содержание".

US>К тому, если у человека активный внутренний диалог, то скорее всего он будет успевать осознавать при просмотре фильма только ту часть, которая будет комментироваться его внутренним голосом.


US>Скорость обработки информации у сознательного мышления 2000 бит информации в секунду, скорость у подсознания доходит до 4 миллиардов бит информации в секунду.

1. Откуда дровишки?
US>Опять добавлю, что если ты не осознаешь, то это не значит, что ты этого не знаешь.
2. Нас не интересует неосознанное знание. Нас интересует осознанное программирование. Поэтому все забавности типа записи в подсознание идут мимо кассы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Графическое программирование и здоровье
От: FR  
Дата: 17.06.10 03:21
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

US>Скажи, почему ты не программируешь на машинных кодах? Компьютеру кроме машинных кодов больше ничего не надо.


Потому-что язык программирования должен быть понятен как человеку так и машине. Кроме того человеку он должен быть не только
понятен но и удобен. И на роль такого языка не подходят не только твои непонятные образы, но даже естественный человеческий
язык так как он недостаточно формален и однозначен.
Дальше ты предлагаешь по сути использовать для общения по сути внутренний язык мозга, который является именно аналогом
ассемблера для машины. Эффективность думаю будет близкой к использованию машинного ассемблера.
Re[8]: Графическое программирование и здоровье
От: FR  
Дата: 17.06.10 03:34
Оценка:
Здравствуйте, Sinclair, Вы писали:


US>>Скорость обработки информации у сознательного мышления 2000 бит информации в секунду, скорость у подсознания доходит до 4 миллиардов бит информации в секунду.

S>1. Откуда дровишки?

Дык "английские ученные" все давно подсчитали
Хотя по сути он прав подсознательно обрабатывается на много порядков больше информации чем сознательно.
Re: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 17.06.10 08:25
Оценка:
Спасибо, народ, за критику.
Re[7]: Графическое программирование и здоровье
От: Klapaucius  
Дата: 17.06.10 08:56
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Ты когда читаешь, то про себя проговариваешь прочитанное. Есть мнение, что в этом нет необходимости.


В этом не просто есть необходимость — это неизбежно. Каждый человек проговаривает прочитанное, комментирует услышанное, комментирует каждое свое действие. Просто он может не использовать для этого развернутую речь, но не использовать внутреннюю он не может.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[11]: Графическое программирование и здоровье
От: Klapaucius  
Дата: 17.06.10 08:56
Оценка: 2 (1)
Здравствуйте, FR, Вы писали:

FR>Нет не поток слов точно, те же специалисты по скорочтению читают не словами а чем то вроде "потока смыслов",


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

FR>пропуская эту самую внутреннюю речь.


Ее нельзя пропустить — она не находится между чем-то и чем-то. И если ее пропустить, то за ней никакого человеческого мышления уже не окажется. Человек мыслит именно словами внутренней речи. И это не какие-то "смыслы", а именно слова, потому как можно фиксировать электрическую активность речевых зон (Брока и Вернике) даже когда человек решает геометрическую задачу. И когда человек решает геометрическую задачу он посылает слабые сигналы на речевые органы. Кроме того, можно наблюдать, как у детей развернутая речь сворачивается во внутреннюю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[8]: Графическое программирование и здоровье
От: Klapaucius  
Дата: 17.06.10 09:12
Оценка: +1
Здравствуйте, samius, Вы писали:

S>Визуализация — это то, как кто-то себе что-то представил. Она субъективна.


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

S>В то время как код — это спецификация того, как оно работает. Код объективен.


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

S>Если мне что-то из кода не ясно, возможно мне поможет сопутствующая схема, желательно близкая к неким стандартам аки UML. Но вот красноречивые образы из комиксов будут явно отвлекать от сути.


Совершенно верно. Проблема подхода к программированию Несерьезного Сэма, который он здесь излагает, не в "визуальности", а в субъективности и общем неправильном подходе к инженерной деятельности с какими-то иррациональными понятиями.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[12]: Графическое программирование и здоровье
От: FR  
Дата: 17.06.10 09:34
Оценка:
Здравствуйте, Klapaucius, Вы писали:

FR>>Нет не поток слов точно, те же специалисты по скорочтению читают не словами а чем то вроде "потока смыслов",


K>Это противоречит, если я правильно понимаю, современным и общепринятым у психолингвистов представлениям.

K>"Что-то вроде потока смыслов" это именно поток слов, только не развернутой речи, а внутренней.

Ну это я просто плаваю в пси терминологии.
То что я обозвал "потоком смыслов" это и есть внутренняя речь. Но насколько мне позволяет склероз внутренняя структура
у нее совершенна другая как раз свернутая до этого самого потока смыслов.
Re[9]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 17.06.10 09:44
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


S>>Визуализация — это то, как кто-то себе что-то представил. Она субъективна.


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

K>При этом "язык кинематографа" к которому Сэм апеллирует как раз этими свойствами не обладает и чудовищно беден по сравнению с литературным языком (хотя Сэм почему-то заявляет, что дело обстоит противоположным образом).

S>>В то время как код — это спецификация того, как оно работает. Код объективен.


K>Код объективен потому, что существует автомат, который как-то этот код выполняет или его (автомата) спецификация.

K>Если это выполняется для графического, визуального языка, то тут никаких отличий от кода не будет.

S>>Если мне что-то из кода не ясно, возможно мне поможет сопутствующая схема, желательно близкая к неким стандартам аки UML. Но вот красноречивые образы из комиксов будут явно отвлекать от сути.


K>Совершенно верно. Проблема подхода к программированию Несерьезного Сэма, который он здесь излагает, не в "визуальности", а в субъективности и общем неправильном подходе к инженерной деятельности с какими-то иррациональными понятиями.


Давай тогда побеседуем. Может быть вопрос пока что только в непонимании, а не в неправильности подхода.
Вопрос к тебе лично. Представь, что какой-то алгоритм описан литературным языком, при чем по возможности украшен разными литературными приемами, которые делают описание не формальным, а литературным. Т.е. по сути описание такое, что позволяет воспринимающему его мозгу установить намного больше ассоциаций, чем при восприятии формального описания. Пока что про визуальное описание говорить не будем. Ты лично видишь целесообразность такой подачи алгоритма? Предположим, что каким-то образом компьютер разберется, как понять такое литературное описание.
Re[9]: Графическое программирование и здоровье
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.06.10 09:45
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

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


S>>Если мне что-то из кода не ясно, возможно мне поможет сопутствующая схема, желательно близкая к неким стандартам аки UML. Но вот красноречивые образы из комиксов будут явно отвлекать от сути.


K>Совершенно верно. Проблема подхода к программированию Несерьезного Сэма, который он здесь излагает, не в "визуальности", а в субъективности и общем неправильном подходе к инженерной деятельности с какими-то иррациональными понятиями.


Да, я думал об этом. Не проблема заменить все fold-ы в программе зелеными человечками. Проблема в том, что когда мы заменим все sum и product такими же зелеными человечками, то мы запутаемся. Что лишнее в образе стандартной функции — так это зеленый человечек. Мне понравилась идея отображать в образе типы данных на входе, выходе, возможно отличать цветами скаляры от функций, символически обозначать списки, последовательности, ну и возможно даже вставлять символику операций (аки сигму для sum). Т.е. теоретически образы можно сделать информационно насыщеннее чем собственно текстовое название функции.
Но боюсь, что когда речь пойдет о том чтобы выразить термины "продать", "купить", "запустить в космос", то опять полезут зеленые чертики. У программистов и с названиями-то не все гладко, а если их заставить выдумывать визуальные образы для всего что они пишут, то программисты разбегутся, и их место займут дизайнеры.
Re[10]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 17.06.10 09:53
Оценка:
Здравствуйте, samius, Вы писали:

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


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


S>>>Если мне что-то из кода не ясно, возможно мне поможет сопутствующая схема, желательно близкая к неким стандартам аки UML. Но вот красноречивые образы из комиксов будут явно отвлекать от сути.


K>>Совершенно верно. Проблема подхода к программированию Несерьезного Сэма, который он здесь излагает, не в "визуальности", а в субъективности и общем неправильном подходе к инженерной деятельности с какими-то иррациональными понятиями.


S>Да, я думал об этом. Не проблема заменить все fold-ы в программе зелеными человечками. Проблема в том, что когда мы заменим все sum и product такими же зелеными человечками, то мы запутаемся. Что лишнее в образе стандартной функции — так это зеленый человечек. Мне понравилась идея отображать в образе типы данных на входе, выходе, возможно отличать цветами скаляры от функций, символически обозначать списки, последовательности, ну и возможно даже вставлять символику операций (аки сигму для sum). Т.е. теоретически образы можно сделать информационно насыщеннее чем собственно текстовое название функции.

S>Но боюсь, что когда речь пойдет о том чтобы выразить термины "продать", "купить", "запустить в космос", то опять полезут зеленые чертики. У программистов и с названиями-то не все гладко, а если их заставить выдумывать визуальные образы для всего что они пишут, то программисты разбегутся, и их место займут дизайнеры.

Да, программист в его текущем качестве перестанет существовать. Как, в принципе, сейчас существует на так много программистов машинных кодов. Все изменяется.
Одна простая истина, которую я здесь пишу уже в сотый раз и никто никакх не хочет ее замечать. Почему мы раньше называли функции F(), а сейчас называем их по типу CreateInstace(). Потому что мозг с легкостью запоминает и усваивает информацию, которая быстро позволяет установить связи с чем-то, что уже нам хорошо знакомо и легко распознается. Поэтому мы не называем функции FunctionBlaBlaBla1(), FunctionBlaBlaBla2() и так далее, хотя могли бы запомнить и такие названия и потом ими оперировать и ими обмениваться с коллегами. Вопрос в том, что мозгу придется потратить больше усилий, чтобы запомнить такие названия, потому в мозге со словами BlaBlaBla1 и BlaBlaBla2 никаких ассоциаций не содержится. А если пойти дальше и представить функцию в виде красочного легкозапоминающего знакомого образа, что информация усвоится моментально и с такой же легкостью мозг сможет ей оперировать. Вопрос не в том, что кому-то этого не хочется или кому-то это не нравится, вопрос в том, что так мозг лучше усваивает иформацию.
Кто вообще из отписавшихся знаком с какими-либо системами запоминания информации и с принципами, на которых они построены?
Re[11]: Графическое программирование и здоровье
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.06.10 10:05
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

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


S>>Но боюсь, что когда речь пойдет о том чтобы выразить термины "продать", "купить", "запустить в космос", то опять полезут зеленые чертики. У программистов и с названиями-то не все гладко, а если их заставить выдумывать визуальные образы для всего что они пишут, то программисты разбегутся, и их место займут дизайнеры.


US>Да, программист в его текущем качестве перестанет существовать. Как, в принципе, сейчас существует на так много программистов машинных кодов. Все изменяется.

US>Одна простая истина, которую я здесь пишу уже в сотый раз и никто никакх не хочет ее замечать. Почему мы раньше называли функции F(), а сейчас называем их по типу CreateInstace(). Потому что мозг с легкостью запоминает и усваивает информацию, которая быстро позволяет установить связи с чем-то, что уже нам хорошо знакомо и легко распознается. Поэтому мы не называем функции FunctionBlaBlaBla1(), FunctionBlaBlaBla2() и так далее, хотя могли бы запомнить и такие названия и потом ими оперировать и ими обмениваться с коллегами. Вопрос в том, что мозгу придется потратить больше усилий, чтобы запомнить такие названия, потому в мозге со словами BlaBlaBla1 и BlaBlaBla2 никаких ассоциаций не содержится. А если пойти дальше и представить функцию в виде красочного легкозапоминающего знакомого образа, что информация усвоится моментально и с такой же легкостью мозг сможет ей оперировать.

В выделенном как раз и проблема. Если средний программист может относительно легко давать сущностям осмысленные названия, то создавать красочный и лекозапоминающися образ, в котором остальные увидят то что нужно, сможет далеко не каждый программист.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.