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

public class SomeClass
{
void Function1();
void Function2();
}

можно было бы нарисовать яркий запоминающийся графический образ, например, забавного человечка для объекта, который выполняет какую-нибудь веселую работу в проекте, или жестокого палача, например, для Garbage Collector'а. Почему бы и нет, раз уж мозг по сути выполняет подобную работу в недрах своего подсознания. Что в итоге приведет к громадной экономии энергии, а следовательно и к лучшему здоровью, и к более счастливой и полноценной жизни. Программирование превратится из программирования, этого идеала творческого онанизма, в полноценное творчество, в котором человек сможет реализовать практически все заложенные в нем возможности без лишних на то усилий. Практически все — потому что не забываем, что все-таки приходится сидеть постоянно сидеть на стуле. Графическое программирование не освобождает от физической нагрузки. Можно, конечно, было бы пофилосовствовать на тему "Программирование в танце в трехмерной виртуальной среде программирования", как в фильмах про будущее По-моему, просто, графическое программирование — это то, что не очень далеко от реальности.
Обращение мое к среднему поколению программистов. Ибо старые скорее всего истощили уже себя, а молодым все повиг, ведь они молодые еще, энергия прет. Давайте пофилосовствуем.

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

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

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

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

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

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

US>жестокого палача, например, для Garbage Collector'а.

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

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

Не, Вы не поняли, меня лечить не надо

[quote]можно было бы нарисовать яркий запоминающийся графический образ, например, забавного человечка для объекта, который выполняет какую-нибудь веселую работу в проекте, или жестокого палача, например, для Garbage Collector'а. Почему бы и нет, раз уж мозг по сути выполняет подобную работу в недрах своего подсознания.[/quote]

Я о том, что не у всех подсознание заменяет Garbage Collector картинкой. И это не болезнь

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

US>Представьте, что вместо
US>[skip]
US>можно было бы нарисовать яркий запоминающийся графический образ, например, забавного человечка для объекта, который выполняет какую-нибудь веселую работу в проекте, или жестокого палача, например, для Garbage Collector'а. .

Вот это здорово! Представляю себе настройку IDE...
Экран настройки IF STATEMENT:
1) Цвет волос: черный, блондин, рыжий
2) Голос: Прирожденный Лидер(+1 к лидерству), Отважный Забияка (+1 к смелости, -1 к харизме)
3)Допустимое колличество ELSE statements: 1, 2, 3, 5(-1 к харизме), 6 и более (-10 к харизме, умение SWITCH становиться доступно после 5000 строк, pattern matching доступен после 50 000 при условии МУДРОСТЬ больше 15).
Экран настройки специального умения GOTO:
1)Голос: Подлый Трус
2)Используеться: нет, да (-30 к харизме, требует +30 к Рукопашному Бою)

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

US>Что в итоге приведет к громадной экономии энергии, а следовательно и к лучшему здоровью, и к более счастливой и полноценной жизни.

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

Здравствуйте, 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, то мало кто сможет восстановить по нему что это такое.

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

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

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

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

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

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

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

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

Главный враг военных США – пакет PowerPoint

http://soft.mail.ru/pressrl_page.php?id=37828

Как выразился действующий бригадный генерал армии США МакМастер (H. R. McMaster), пакет PowerPoint наносит вред не только с точки зрения затрат времени. Один из главных видов ущерба заключается в том, что презентации PowerPoint создают иллюзию понимания вопросов, о которых идет речь. Когда проблема описана в виде списков, схем и стрелок, вам кажется, что вы решили проблему, хотя на самом деле это не так.

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

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

К>Т.е. в результате прочтения не должно в голове возникать ничего?
К>(Или информацию надо воспринимать кинестетически?)

С чего бы? Ты когда читаешь, то про себя проговариваешь прочитанное. Есть мнение, что в этом нет необходимости. (Хотя персонально мне тексты приходится не только проговаривать, но и по несколько раз перечитывать, но то такое). Мне совершенно естественно, что не нужно не только проговаривать, но и визуализировать.

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

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

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

М>[quote]можно было бы нарисовать яркий запоминающийся графический образ, например, забавного человечка для объекта, который выполняет какую-нибудь веселую работу в проекте, или жестокого палача, например, для Garbage Collector'а. Почему бы и нет, раз уж мозг по сути выполняет подобную работу в недрах своего подсознания.[/quote]

М>Я о том, что не у всех подсознание заменяет Garbage Collector картинкой. И это не болезнь

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

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

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

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

US>Почему предпочитают книги? За всех не буду говорить, но могут такие уникумы, которые считают, что если они читают классику в оригинале, то он намного выше всех остальных простых смертных Или у тебя какой-то один ответ для всех людей и на все случаи жизни?
Конечно. Ответ очевиден: человек визуализирует книгу при помощи воображения, которое мощнее любого рендера. К примеру, у JRRT Галадриэль — невозможная красавица. Читаешь — и вот тебе красавица. Смотришь кино — баба как баба.

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

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

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

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

US>Скорость обработки информации у сознательного мышления 2000 бит информации в секунду, скорость у подсознания доходит до 4 миллиардов бит информации в секунду.
1. Откуда дровишки?
US>Опять добавлю, что если ты не осознаешь, то это не значит, что ты этого не знаешь.
2. Нас не интересует неосознанное знание. Нас интересует осознанное программирование. Поэтому все забавности типа записи в подсознание идут мимо кассы.

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

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

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

US>>>Ссылок я тоже не собираю. Можно почитать Тони Бьюзена "Научи себя думать". Это книга про карты памяти.
G>>Это я читал, оно очень далеко от обсуждаемой темы. Хотя может именно этого ты и не понимаешь

US>В этой книге есть пример системы запоминания информации и про принципы, на которых она построена.
А с чего ты взял что исходник надо запоминать? Его надо понимать.

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

US>Потом еще одна мысль хорошая, которую я в теме не затронул, что мы, когда что-то создаем, думаем от общего к частному. Программируем в том числе. Исходники так же не отображают этот процесс. Они как бы уже результат.
Это смотря на чем программировать.

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

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

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

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

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

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

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

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

Основной мой рабочий инструмент — это, разумеется, язык Unlambda, поэтому:
BZ>ты отключаешь синтаксическую раскраску?

Раскрашивать особо и нечего. s от k и без раскраски легко отличить.

BZ>используешь однобуквенные имена переменных?

Не использую переменных.

BZ>никогда не пишешь комментариев?

Код на Unlambda самоочевиден и понятен без всяких комментариев.

BZ>пишешь код в спагетти-стиле?

Ни в коем случае, исключительно изящное комбинирование комбинаторов.

Да, кстати, а почему вы спрашивали?

Здравствуйте, BulatZiganshin, Вы писали:
BZ>почему бы тебе не опробовать эти новаторские идеи на практике? замени идентификаторы и ключевые слова в своей программе на aN, где N — случайно выбранные 20-значные числа, избавься от комментариев и делай функции максимального размера. никакими IDE/RAD средствами ни в коем случае не пользуйся. потом напишешь книжку о том, что всё развитие индустрии начиная с изобретения мнемокодов было большой ошибкой

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

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

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

BZ>так как всё-таки насчёт этого?
Зачем вы упорствуете? Вы делаете предложение, которое не имеет никакого отношения к тому, о чём я говорю, и думаете, что оно что-то аргументирует. Почему?
Почему вы на пару с топикстартером подменяете понятия, и думаете, что текст = ассемблер?
Текст — это язык, он может быть ещё более выразительным, чем любой трёхмерный фильм. Не любой набор букаф представляет собой язык. В языке есть свои правила и закономерности. Поэтому заменить в программе "все идентификаторы" без потери смысла не выйдет. Но класс Frob, тем не менее, вполне себе будет работать. Я вам ещё раз обращаю внимание на то, что термин Render не вызывает у начинающих программистов из России ровно никаких ассоциаций. И только после освоения соответствующего кода они начинают что-то с ним ассоциировать. Ровно с таким же успехом метод HtmlControl мог бы называться Frob — и ничего, все бы спокойно говорили "ну там контрол отфробился коряво, надо ему хвну выставлять на фазе преалгук", и понимали бы всё стопроцентно однозначно. Ровно так ваша повседневная речь звучит для продавщицы в киоске. Гипотеза о жизненно важной полезности образов из реальной жизни в программировании не выдерживает никакой критики.

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


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

И к тому же совершенно непонятно, что причина, а что — следствие. Программирование — одно из проявлений способности человека жонглировать символами, переводить всё с одного языка на другой. Так что не удивлюсь, если окажется, что всё как раз наоборот: занятия программированием стимулируют развитие творческих особенностей личности

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

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

LP>>Сама нейронная сеть и механизмы ее работы, конечно, полностью формализованы. А вот знания, хранящиеся в ней — не всегда. Знание в НС — это просто набор весов и пороговых значений, определяющих ее поведение (другими словами, реализующих функцию выход = f(вход) ).
S>Совершенно верно. Не вижу ничего неформализованного в такой реализации функции выход = f(вход). Она ничем принципиальным не отличается от, скажем, функции sin(x).

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

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

Я говорю о классе т.н. "семантических нейронных сетей". Вот пример, демонстрирующий такой подход. А здесь об этом написано подробнее:

Каждый нейрон в семантической нейронной сети представляет собой некоторое элементарное понятие обрабатываемого смысла[1]. Смысл, извлеченный из текста на естественном языке, формализовано представляется в семантической нейронной сети как мгновенное состояние множества нейронов — эффекторов, находящихся в слое извлечения смысла из входной символьной последовательности[2]. Градиентное значение на выходе нейрона представляет собой нечеткий фактор уверенности (certainty factor) — степень уверенности в том, что данное элементарное понятие содержится в обрабатываемом тексте. Логическому значению "истина" градиентного значения на выходе аксона соответствует полная уверенность в том, что данное понятие присутствует в тексте, градиентному значению "ложь" соответствует полная уверенность в отсутствии данного понятия в обрабатываемом тексте. Промежуточные значения соответствуют предположительному присутствию или отсутствию понятия в тексте, со степенью уверенности равному градиентному значению.

LP>>Если утверждение истинно, то соответствующий нейрон находится в состоянии "1", в противном случае — "0". Но даже в этом случае, как правило, вводятся элементы нечеткой логики, то есть может быть к примеру значение 0.8, которое можно трактовать как "скорее да, чем нет" (а это удар по формализации).
S>Не вижу никаких ударов по формализации. Просто это несколько другой формализм, чем в булевой логике. Но он ничуть не менее формальный. Нечёткая логика ничего волшебного из себя не представляет, просто немножко другая область значени и немножко другие операторы сложения и умножения. Стоит применить капельку абстрактного мышления — и fuzzy logic оказывается всего лишь одной из реализаций абстрактной концепции "алгебра".

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

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

http://www.edwardtufte.com/tufte/books_vdqi
Это его книга?

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

S>Не проблема заменить все fold-ы в программе зелеными человечками.

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

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

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

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

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

Ее нельзя пропустить — она не находится между чем-то и чем-то. И если ее пропустить, то за ней никакого человеческого мышления уже не окажется. Человек мыслит именно словами внутренней речи. И это не какие-то "смыслы", а именно слова, потому как можно фиксировать электрическую активность речевых зон (Брока и Вернике) даже когда человек решает геометрическую задачу. И когда человек решает геометрическую задачу он посылает слабые сигналы на речевые органы. Кроме того, можно наблюдать, как у детей развернутая речь сворачивается во внутреннюю.

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

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

Вот это

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

показывает что текст мозгом воспринимается именно как поток образов, а не как поток символов.

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

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

>> Можно, конечно, было бы пофилосовствовать на тему "Программирование в танце в трехмерной виртуальной среде программирования", как в фильмах про будущее

S>Вспомнилось — "Вся вселенная — это танец Шивы" (ну или как-то так).

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

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

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

Не могу себе представить выдумывание и заучивание 2-3х тысяч доменно ориентированных образов. Тут любого творца переклинит.

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

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

Графические языки получаются более объемными и менее удобными чем текстовые.

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

FR>показывает что текст мозгом воспринимается именно как поток образов, а не как поток символов.

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

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

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

S>>Допустим, ты мне дашь образ fold-а, но для меня он будет таким же как и Enumerable.Aggregate, т.е. просто ярлыком, и потому процесс его восприятия не будет прямее.

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

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

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

S>>Как можно прямее-то?

S>>Допустим, ты мне дашь образ fold-а, но для меня он будет таким же как и Enumerable.Aggregate, т.е. просто ярлыком, и потому процесс его восприятия не будет прямее.

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

Все-таки, на данном этапе пора бы уже перейти к примерам визуализации. Пусть это будут смешные и несуразные примеры, но надо хотя бы показать, что возможно хоть что-то представить в виде картинки. Так что давайте мы сейчас все-таки придумаем картинку для Enumerable.Aggregate, иначе, имхо, вся идея пойдет прахом. Если уж в самом начале на примитивщине споткнемся.

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

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

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

S>>>>Как можно прямее-то?

S>>>>Допустим, ты мне дашь образ fold-а, но для меня он будет таким же как и Enumerable.Aggregate, т.е. просто ярлыком, и потому процесс его восприятия не будет прямее.

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

S>>Все-таки, на данном этапе пора бы уже перейти к примерам визуализации. Пусть это будут смешные и несуразные примеры, но надо хотя бы показать, что возможно хоть что-то представить в виде картинки. Так что давайте мы сейчас все-таки придумаем картинку для Enumerable.Aggregate, иначе, имхо, вся идея пойдет прахом. Если уж в самом начале на примитивщине споткнемся.

US>Любая картинка, на которой человек, олицетворяющий Enumerable, собирает несколько предметов в одно целое. Представим, что я умею рисовать и быстро нарисовал забавного человека в зеленом пиджаке и красной шляпе. Он радостно собирает небольшой пазл. Можно, к примеру, договориться, что входные данные всегда будут обозначаться на картинке, не зависимо от, какими предметами они будут представлены, синим цветом. А выходные данные будут всегда окружены ярко-желтым свечением. Эту картинку можно представить как угодно. Главными здесь будут небольшие формальности: человек, олицетворяющий объект, цвет входных и выходных данных.

Т.е. в руках пазл из синих кусочков, а весь пазл окружен ярко-желтым свечением. Будет понятно, что что-то передается, и это что-то возвращается как единое целое.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

US>>Тут повторю вопрос. Кто из отписавшихся знаком с системами запоминания информации и принципами, на которых они построены?

FR>Давай лучше поговорим о влияний занятий спортом на изучение языков программирования. Например в прошлом году мы тут достоверно
FR>установили что занятия штангой очень благотворны для изучения Хаскеля.

Это практически очевидно должно быть для кинестетиков, ведь H похожа на штангу. Кстати, очень может быть, что штангой можно непосредственно не заниматься, а просто созерцать ее? Возможно З. немного злоупотребляет?

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

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

US>>Опять добавлю, что если ты не осознаешь, то это не значит, что ты этого не знаешь.
S>2. Нас не интересует неосознанное знание. Нас интересует осознанное программирование. Поэтому все забавности типа записи в подсознание идут мимо кассы.

Никого как раз не интересует, что ты осознаешь, а что не осознаешь. Ты можешь осознавать у себя дома, лежа на диване. Остальным от этого ни жарко, ни холодно. Нас интересует то, что ты можешь написать в коде и что ты можешь объяснить своим коллегам-программистам, если понадобится. Как ты получил эти знания — абсолютно неважно. "Осознанное программирование" — ты прошло решил, что это круто звучит.

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

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

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

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

US>>>>Ты говоришь "неплохо получается". Хотя так всегда думали и будут думать.
G>>>Нет, просто программист написавший код в недавнем времени держит в голове детали, которые позволяют в нем ориентироваться. Я например налабал за несколько дней кода на 2000 строк и вполне нормально могу сказать для чего нужны переменные и функции. Если я их раскрашу как мне захочется, нафигачу шрифтов, то мне понятнее код не станет, как он не станет понятнее другому человеку. А через некоторое время я забуду зачем я писал те или иные куски и дополнительная информация в виде звука\картинок\шрифтов будет гораздо менее полезной чем текстовые комменты.

US>>Во-первых, ты пытаешься представить, как оно было бы, если бы ты так сделал. Не имея опыта, это невозможно сделать. Такого опыта у тебя нет. Во-вторых, ты не знаком с исследованиями психологов на эту тему.
G>Дай ссылку на исследования психологов чтоли.
Ссылок я тоже не собираю. Можно почитать Тони Бьюзена "Научи себя думать". Это книга про карты памяти. Хотя он там сам как бы ссылается не подобные исследования. Или любая книга по когнитивной психологии.

US>>Поэтому, если сказать просто, ты ошибаешься. Вот в этом самом главном пункте ты ошибаешься, понимаешь?
G>Да уж... Ты все еще не понял. Не в психологии дело.
G>С точки зрения психологии я как раз понимаю важность этих образов для понимания. А вот в инженерном плане такое вызывает сомнения, потому что психологи не учли что кроме того что люди будут понимать эти цвета\шрифты\звук, они будут еще и создавать его.

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

Таких споров полно и без цвета, звуков и прочих. Спорят про архитектуру, спорят про кодинг стайл, спорят про С++ vs. С и прочее.

G>Другой вопрос — создание этой информации, где взять звуки, кто будет рисовать шрифты и как подобрать цвета? На это разработчики должны будут затратить время (!), причем гораздо больше чем будет сэкономлено на вникании в код, ведь после вникания эта информация будет приносить гораздо меньше пользы.

Опять ты пытаешься представить, как оно было бы. Ты много чего не учитываешь. Могу поспорить, люди, которые в свободное от программирования время занимаются какими-нибудь творческими занятиями: рисуют, поют, снимают кино, музыку пишут и прочее — показывают в программировании куда более "красивые результаты". Мой программерский опыт показывает, что так оно и есть. Есть творческие программисты, а есть опытные шаблонщики. Это разные категории. А все из-за того, что творчеством, в полном смысле этого слова, стимулируется мозг. У других он просто-напросто со временем атрофируется.

G>Третий вопрос — автоматизация работы с такой информацией. Мы часто пользуемся поиском с заменой, утилитами для диффа\мерджа — как они будут работать с такой информацией? Даже банальный рефакторинг — переименование переменной — должен будет учитывать дополнительную информацию (как сейчас умеет переименовывать в комментах). Вообще любое изменение кода потребует изменения этой метаинформации, что сильно затруднит поддержку.

G>Четвертый вопрос — инструменты для работы с информацией. Например есть ide, где на одном экране несколько переменных, к каждой из них прикреплен звук, какой будет проигрываться в данный момент?

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

US>>>>Так же думали и программисты машинных кодов. Т.е. не было их вины в том, что их все устраивало. Их просто не интересовало то, как сделать свою работу более удобной. А может быть и интересовало, но они не знали как.
G>>>Еще раз, среды графического программирования провалились. ВСЕ. Изучи почему так, найдешь ответы на все вопросы.
US>>Мне интересно, с удовольствием почитаю. Буду благодарен, если поделишься ссылкой.
G>Я ссылки не собираю, ищи статьи по критике UML.

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

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

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

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

Нет.

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

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

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

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

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

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

US>>>Есть творческие программисты, а есть опытные шаблонщики. Это разные категории. А все из-за того, что творчеством, в полном смысле этого слова, стимулируется мозг. У других он просто-напросто со временем атрофируется.
G>>Ну расскажи чем они отличаются.

US>Творческий программист найдет хорошее решение любой проблемы, потому что умеет хорошо думать. Опытный шаблонщик знает только как решать несколько проблем. Новую проблему он не решит или состряпает кривое решение из тех шаблонов, которые успел заучить. Есть хорошая книга "Programmer's stone". Там только они называются картостроители и паковщики.

Кстати, заметен творческий подход к логике.

Уменее решать проблемы это прежде всего следствие стимуляции мозга на тему решения проблем. А творческое вышивание крестиком влияет на способность решения проблем куда меньшее, чем общая физическая подготовка, если вообще влияет.

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

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

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

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

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

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

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

US>Во-во. Уже немного втянулись в визуализацию Смотрите не подсядьте
US>Как вы заметили такой разговор более веселый и следовательно более активно стимулирует мышление и творческие процессы.
Мышление и творческие процессы — да, но эти же процессы можно запустить коллективным чтением башорга. Пользы будет столько же. Т.е. к решению задачи не приблизит.

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

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

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

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

Это называется уход от ответа.

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

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

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

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

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

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

С таким подходом можно быть только художником или представителем какой нибудь другой творческой специальности. но не программистом

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

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

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

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

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

US>Не в ту сторону ты клонишь постоянно. Ты задумывался, почему TextReader называется Reader, а не Абракадабра?
Я как раз клоню в ту сторону. Зато ты игнорируешь всё, что не укладывается в твою стройную гипотезу.
К примеру, тебя не удивляет то, что русскоязычные программисты вовсе не проигрывают своим американским коллегам, несмотря на полное отсутствие культурного фона? К примеру, любой программист может прекрасно работать с классом Renderer, хотя почти никто не знает, что это означает за пределами компьютера. Этот факт никак не настораживает?

US>Хотя казалось бы какая разница, как его называть: запомним со временем и будем пользоваться. Я, если бы не знал, что это такое, имел бы по крайней мере какое-то представление, для чего это нужно и как это использовать.
Нет, не знал бы, и не имел.

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

US>Возьмем нейронные сети. Наш мозг — нейронная сеть. По крайней мере это модель, которая позволяет нам понимать очень многое о мозге.
Это модель, которая нам ничего не даёт. Я уже писал на эту тему другому оппоненту — совершенно неважно, как устроен мозг внутри. Даже если там неонка, роль играет только наблюдаемое поведение.

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

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

US>Почему spin — крутиться, или что-то вроде этого, по-английски? Наверное, эти слова отражают то, что происходило в голове у тех людей, которые эти понятия придумали.
Отражает. Но они придумали это один раз и давно, и потратили очень много усилий. Теперь нам не нужно снова проводить ту же работу для использования их результатов. (Кстати, наличие спина не имеет никакого отношения к тому, что там что-то крутится.)

Точно так же и в программировании: я могу назвать класс Frob, и всё будет работать. В первый раз программисту придётся поразбираться с интерфейсом Frob, но потом он будет им пользоваться ничуть не хуже, чем TextReader. Это факт, подтверждённый поколениями русскоязычных программистов. Практически любой программист знает и правильно понимает термины "scan, lex, parse", хотя сильно затруднится объяснить, что они означают за пределами компьютера.
Один этот факт опровергает всю твою смелую гипотезу.

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

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

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

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

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

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

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

Знаю людей, которые успешно этим занимаются много лет. Все переменные называют rabyach(от "рабочая ячейка")+ трех/четырехзначный номер вне зависимости от типов переменных.

Все работает на ура, проблема только с передачей кода третьим лицам.

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

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

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

S>Знаю людей, которые успешно этим занимаются много лет. Все переменные называют rabyach(от "рабочая ячейка")+ трех/четырехзначный номер вне зависимости от типов переменных.

S>Все работает на ура, проблема только с передачей кода третьим лицам.

Достижение. Скажи им, пусть пойдут пользуются счетами, а не компьютером.

Здравствуйте, BulatZiganshin, Вы писали:
BZ>при этом граыический язык гораздо менее мощен, чем полный SQL. но всё же если ты придёшь к БД-программистам и скажешь "выкиньте свои sql-дизайнеры", они тебя пошлют далеко и надолго
Правда что ли?
Я и сам провёл за написанием запросов несколько нескучных лет. И sql-дизайнеры мне не помогали практически ни в чём.
Вот визуальный просмотр схемы БД помогает её понять. Но это опять не программирование! Рисовать БД всё ещё в разы удобнее прямо так:

create table Orders 
(
  ID int not null primary key,
  CustomerID int not null foreign key references Customers(ID),
  ManagerID int not null foreign key references Managers(ID)
)
create table OrderDetails
(
  ID int not null primary key,
  OrderID int not null foreigh key references Orders(ID),
  ...
)

Всё. А все эти "визуальные построители запросов" я использовал за всю жизнь раз пять. И то — в аксессе, до того, как найти переключалку в SQL view.
Нет, я допускаю, что есть определённый класс людей, которые называют себя "БД-программистами", но не умеют жить без визуального дизайнера. Нас они не интересуют в контексте данного топика — у них со здоровьем всё в порядке, мозг они не особенно нагружают. Потому что визуальном дизайнере не получится писать запросы в промышленных количествах. Тем более, когда речь идёт о сложных запросах с десятком таблиц.

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

> Можно, конечно, было бы пофилосовствовать на тему "Программирование в танце в трехмерной виртуальной среде программирования", как в фильмах про будущее

Вспомнилось — "Вся вселенная — это танец Шивы" (ну или как-то так).

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

US>Обращение мое к среднему поколению программистов. Ибо старые скорее всего истощили уже себя, а молодым все повиг, ведь они молодые еще, энергия прет. Давайте пофилосовствуем.

Я правильно понял мысль: "Комиксы лучше книг"?
Если да, то я с этим не согласен. Воображение развивается только в бедном окружении, иначе зачем оно нужно. Если же мало впечатлений, то при восьмичасовом рабочем дне достаточно свободного времени, чтобы набраться впечатлений.

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

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

US>>Обращение мое к среднему поколению программистов. Ибо старые скорее всего истощили уже себя, а молодым все повиг, ведь они молодые еще, энергия прет. Давайте пофилосовствуем.

N>Я правильно понял мысль: "Комиксы лучше книг"?
N>Если да, то я с этим не согласен. Воображение развивается только в бедном окружении, иначе зачем оно нужно. Если же мало впечатлений, то при восьмичасовом рабочем дне достаточно свободного времени, чтобы набраться впечатлений.

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

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

US>Если так сравнивать, я бы сказал: "Кино лучше книг".
Для здоровья — вероятно. Однако, морковка лучше кино!

US>При прочих равных условиях, здоровый человек выберет отдых на природе, а не программирование сидя у экрана монитора, уставившись в черно-белые буквы.
Для того чтобы от чего-то отдохнуть, нужно от чего-то устать. Отдых на природе — это хорошо пока не захочется отдохнуть от природы.

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

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

М>Очевидно, вы ярко выраженный визуал по способу восприятия.
М>Как кинестетику, мне такие идеи о визуальных образах при програмировании, "ни о чем".
М>Это просто сноска )

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

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

Вполне возможно, выражу общее мнение, если скажу, что никто не против графического программирования, а только за.
Я тоже визуал .
Загвоздка лишь в реализации. На данный момент дальше UML человечество в этом вопросе вроде бы не продвинулось. Есть ли у тебя какие-либо идеи — как бы это могло выглядеть?
Дело в том, что представление Garbage Collector в виде чувака с метлой вряд-ли упростит программирование. Поскольку внесет дополнительную сложность. Проще написать
GC.Collect();
чем чем кричать виртуальному мужику что пора приступать к работе.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Помнится в учебниках по скорочтению много внимания уделяется упразднению внутреннего проговаривания читаемого. По идее визуализация тоже уменьшает продуктивность.

Т.е. в результате прочтения не должно в голове возникать ничего?
(Или информацию надо воспринимать кинестетически?)

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, маген, Вы писали:

М>>[quote]можно было бы нарисовать яркий запоминающийся графический образ, например, забавного человечка для объекта, который выполняет какую-нибудь веселую работу в проекте, или жестокого палача, например, для Garbage Collector'а. Почему бы и нет, раз уж мозг по сути выполняет подобную работу в недрах своего подсознания.[/quote]

М>>Я о том, что не у всех подсознание заменяет Garbage Collector картинкой. И это не болезнь

ANS>Хе-хе. Я бы сказал, что визуализация GC как жестокого палача явно намекает, если не на болезнь, то на какое-то расстройство точно. Возможно даже более сильное, чем у тех кто представляет GC как жесткую госпожу.

ANS>Помнится в учебниках по скорочтению много внимания уделяется упразднению внутреннего проговаривания читаемого. По идее визуализация тоже уменьшает продуктивность.

В подсознании хранится весь набор информации, связанной с каким-либо объектом. Если у тебя есть класс Visitor, то подсознательно есть ассоциации с образом посетителя, например, образом налогового инспектора, который часто заходит к тебе домой и уже мозолит глаза. Со звуком, например, его голосом. С тактильными ощущениями, например, с ощущением прикосновения к его служебному костюму. Я не говорю, что ты постоянно трогаешь налогового инспектора Просто в памяти хранится воспоминания прикосновения к материалу, из которого сделан такой костюм. Возможно, такой когда-то носил ты сам. Ты будешь помнить, как ты его одевал, как стирал, как чистил. Кинестет — тот, кто, вспоминая Visitor, вытащит из подсознания в сознательную часть только тактильные ощущения, проигнорировав все остальные. Т.е. по сути такой человек не использует свой мозг на все 100%.
Ты прав по поводу проговаривания и визуализации. Но я и не предлагал визуализировать. Визуализировать ничего не придется, так как все и так уже будет на экране монитора в явном виде. И проговаривать также ничего не придется, так как количество слов уменьшится в разы, все будет в виде красочных образов.
Когда ты читаешь, мозг в любом случае подсознательно проделывает всю работу по визуализации, аудилизации и прочее. У творческого программиста по крайней мере. Мозг либо выполняет всю эту работу, любо в итоге получает очень скудную информации и устанавливает очень скудные ассоциации. В итоге имеем не творческого программиста, а обычного кодера.

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

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

S>Вполне возможно, выражу общее мнение, если скажу, что никто не против графического программирования, а только за.
S>Я тоже визуал .
S>Загвоздка лишь в реализации. На данный момент дальше UML человечество в этом вопросе вроде бы не продвинулось. Есть ли у тебя какие-либо идеи — как бы это могло выглядеть?
S>Дело в том, что представление Garbage Collector в виде чувака с метлой вряд-ли упростит программирование. Поскольку внесет дополнительную сложность. Проще написать
S>GC.Collect();
S>чем чем кричать виртуальному мужику что пора приступать к работе.

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

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Курилка, Вы писали:

К>>Т.е. в результате прочтения не должно в голове возникать ничего?
К>>(Или информацию надо воспринимать кинестетически?)

ANS>С чего бы? Ты когда читаешь, то про себя проговариваешь прочитанное. Есть мнение, что в этом нет необходимости. (Хотя персонально мне тексты приходится не только проговаривать, но и по несколько раз перечитывать, но то такое). Мне совершенно естественно, что не нужно не только проговаривать, но и визуализировать.

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

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

Андрей, ты неправильно понял. Не надо ни проговаривать, ни визуализировать. Вопрос в том, что ты воспринимаешь. Какого качества материал. Хороший пример с исходным кодом, в котором все переменные названы a, b, c, d. В принципе в самом коде уже есть информация о том, для чего эти переменные используются, и, прочитав код несколько раз, ты это поймешь. Но проще, когда переменной дают имя, отражающее намерение, для которой она используется.
Или тебе на несколько секунд показывают 10 простых, не сильно различающихся черно-белых символов. Потом показывают на несколько секунд 10 яркий, богатых графических изображений. Очевидно, что потом, когда тебе покажут символы и образы, ты с легкостью укажешь на те образы, которые видел, и с трудом покажешь на символы, которые тебе показали. Так как мозг, за равное время, установит больше связей с богатой графикой, чем с символикой.

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

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

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

S>Не могу себе представить выдумывание и заучивание 2-3х тысяч доменно ориентированных образов. Тут любого творца переклинит.

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

"Литературное (английский термин намеренно двусмысленный), или грамотное программирование (англ. Literate Programming) — концепция, методология программирования и документирования. Термин и саму концепцию разработал Дональд Кнут в 1981 году при разработке системы компьютерной вёрстки TeX.

Возможно, что самый простой способ понять ЛП — это вспомнить объяснения в курсах программирования, написанные фразами на «псевдокоде» на «человеческом языке». ОНИ ПОНЯТНЫ, КОГДА САМ КОД ТРУДЕН, и скрывают под одной фразой-«оператором» возможно множество других вложенных абстракций и/или программного кода на непосредственно машинном языке.

Самому теперь стало понятно. Трудности распознавания естественного языка очевидны. И вот вставить в код image, с нарисованным персонажем, распознать легко, так уже в коде image будет представлен однозначной сущностью. Компилятору не придется париться.

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


S>Не могу себе представить выдумывание и заучивание 2-3х тысяч доменно ориентированных образов. Тут любого творца переклинит.

Ну китайцы и японцы выучивают
Но при этом их скорость чтения мало отличается от скорости чтения европейцев.

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

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

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

FR>Графические языки получаются более объемными и менее удобными чем текстовые.

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

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

US>В подсознании хранится весь набор информации, связанной с каким-либо объектом. Если у тебя есть класс Visitor, то
подсознательно есть ассоциации с образом посетителя, например, образом налогового инспектора, который часто заходит к тебе

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

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

То что мозг при усвоении информации строит связи и ассоциации — это ясно. Но они у всех разные. Значит картинки на мониторе тоже должны быть разные. А программа должна быть понятна не только автору. Это раз. Второе — что делать упомянутым кинестетам? Переходить на азбуку брайля?

В третих, имхо, любые вспомогательные образы, звуки, ощущения это просто ключи к вызову deus ex machina, который просто решает всё. Я не уверен, что ключ в виде уборщицы бабы Нюры, лучше текстового ключа "GC.Collect()". А последнее лучше универсального образа тем, что сразу задаёт контекст.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

US>>В подсознании хранится весь набор информации, связанной с каким-либо объектом. Если у тебя есть класс Visitor, то
ANS>подсознательно есть ассоциации с образом посетителя, например, образом налогового инспектора, который часто заходит к тебе

ANS>Visitor у меня стойко ассоциируется с двойной диспетчеризацией, а не с налоговым инспектором. Двойная диспетчеризация вполне ассоциируется с картинкой иллюстрирующей процесс обмена сообщениями. Но это если вдуматься. Когда бегло смотришь в код динамика потоков сообщений зачастую не нужна. Визитор и всё точка. Я понял что это, но не хочу захламлять текущий контекст ненужной информацией. Так как я уже понял, что это, то ключи в виде запахов, костюмов и прочего уже не нужны.

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

ANS>То что мозг при усвоении информации строит связи и ассоциации — это ясно. Но они у всех разные. Значит картинки на мониторе тоже должны быть разные. А программа должна быть понятна не только автору. Это раз. Второе — что делать упомянутым кинестетам? Переходить на азбуку брайля?

ANS>В третих, имхо, любые вспомогательные образы, звуки, ощущения это просто ключи к вызову deus ex machina, который просто решает всё. Я не уверен, что ключ в виде уборщицы бабы Нюры, лучше текстового ключа "GC.Collect()". А последнее лучше универсального образа тем, что сразу задаёт контекст.

Так чем больше ключей, тем быстрее и полнее понимание. Как считаешь? Иначе мы бы жили только в мире звуков, образов, или тактильных ощущений.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Visitor у меня стойко ассоциируется с двойной диспетчеризацией, а не с налоговым инспектором. Двойная диспетчеризация вполне ассоциируется с картинкой иллюстрирующей процесс обмена сообщениями.

А лучше было бы, если бы вся информация воспринималась непосредственно.

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

US>Так чем больше ключей, тем быстрее и полнее понимание. Как считаешь? Иначе мы бы жили только в мире звуков, образов, или тактильных ощущений.

Безусловно. По-этому в редакторах кода есть подсветка синтаксиса, выделение skope-ов, да и вообще рекомендуется писать с отступами, конвенциями и пр. Но дальше этого не особенно получается пройти.

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

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

S>>Не могу себе представить выдумывание и заучивание 2-3х тысяч доменно ориентированных образов. Тут любого творца переклинит.

FR>Ну китайцы и японцы выучивают
FR>Но при этом их скорость чтения мало отличается от скорости чтения европейцев.

У японцев в ходу около 2500 иероглифов на все случаи жизни. Все что не входит в эти случаи они записывают слоговыми азбуками. Здесь же предлагается выдумывать свои образы под каждый объект/метод каждого проекта.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

US>>Так чем больше ключей, тем быстрее и полнее понимание. Как считаешь? Иначе мы бы жили только в мире звуков, образов, или тактильных ощущений.

ANS>Безусловно. По-этому в редакторах кода есть подсветка синтаксиса, выделение skope-ов, да и вообще рекомендуется писать с отступами, конвенциями и пр. Но дальше этого не особенно получается пройти.

А начинали с перфокарт.

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

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

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

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

S>>Не могу себе представить выдумывание и заучивание 2-3х тысяч доменно ориентированных образов. Тут любого творца переклинит.

US>И не надо. Я так понимаю, ты себе представляешь это как заучивание каждого пиксела образа, чтобы потом его можно было повторить, прям точь-в-точь как написать имя уже когда-то придуманного класса. Образ создается один раз. В других случаях он уже будет использоваться как готовый или будет использоваться только для чтения.
Образы нужны для классов, методов, полей классов, параметров методов, локальных переменных. Даже если создан он один раз, я гораздо быстрее наберу myVariableWithStrangeName чем выберу образ из библиотеки или создам новый.

US>Кстати, очень даже можно было бы первым шагом перейти к литературному программированию Хотя смайлик лишний, так как этот термин уже ввел когда-то Дональд Кнут. В википедии есть статься. Там, кстати, литературное программирование называют грамотным.

Вот это гораздо реальнее, т.к. требования к программе все равно записаны "литературно" а не образами.

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

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

US>>Что в итоге приведет к громадной экономии энергии, а следовательно и к лучшему здоровью, и к более счастливой и полноценной жизни.

M>Все строго наоборот, в результате длительной практики в какой-либо отрасли, отбрасывается все лишние энергозатраты в виде посторонних образов. Хорошо видно на примере шахмат: вначале ты мысленно передвигаешь фигурки по доске, а потом у тебя формируется некая абстракция вне всяких образов. Создается свой язык, которым ты в дальнейшем пользуешься. То же и математика и другие отрасли

ОК. Замени фигуры на шахматной доске на первые буквы их названий. Пешка — П, Ферзь — Ф и так далее. А еще лучше на точку, палочку, кружок. И так играй. Хотя куда приятней играть в шахматы, в каждую фигуру которых мастер вложил всю свою душу.
Университетский преподаватель по математике говорил, что в математике ты или гений к своим — точно не помню — десяти, четырнадцати или около того, или уже никогда. Бывают, наверное, исключения. Но это только исключения. А все как раз благодаря тому, что впоследствии ты создаешь свой язык, которым в дальнейшем пользуешься. Полностью отрезаешь себя от получения новых впечатлений. Перестаешь создавать что-то новое, а просто превращаешься в робота, который только и умеет, что оперировать тем, чему успел научиться.

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

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

US>>Что в итоге приведет к громадной экономии энергии, а следовательно и к лучшему здоровью, и к более счастливой и полноценной жизни.

M>Все строго наоборот, в результате длительной практики в какой-либо отрасли, отбрасывается все лишние энергозатраты в виде посторонних образов. Хорошо видно на примере шахмат: вначале ты мысленно передвигаешь фигурки по доске, а потом у тебя формируется некая абстракция вне всяких образов. Создается свой язык, которым ты в дальнейшем пользуешься. То же и математика и другие отрасли

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

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

US>Разговор про стимуляцию мозга. Какой бы язык ты себе не придумал, подсознание оперирует всем доступным набором: образы, звуки, краски и прочие ощущения, которые ты получаешь через органы чувств. И неважно, увидел ты слово или образ. Внутренне представление будет одинаковым. Только чтобы на слово надеть весь спектр данных, твоему мозгу придется здорово подтрудится, на что потратится огромное количество энергии. Ну а если человек свой мозг не задействует: увидел слово — значит слово — то мозг такого человека скуден. К творчеству никакого отношения он иметь не будет и ничего стоящего нового никогда не создаст. А чем оперировать ему? Сенсорная депривация — это лишение одного или нескольких органов чувств внешнего воздействия — приводит к депрессии.

Визуализируй, пожалуйста парсер, умеющий разбирать символ по переданному условию:

let p_pred p s =
    match s with
    | [] → Failed
    | h::t → if p h then Parsed(h, t) else Failed

Желательно так, чтобы у сведущих людей не возникало вопросов, когда они будут смотреть на образ.

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

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

US>>Разговор про стимуляцию мозга. Какой бы язык ты себе не придумал, подсознание оперирует всем доступным набором: образы, звуки, краски и прочие ощущения, которые ты получаешь через органы чувств. И неважно, увидел ты слово или образ. Внутренне представление будет одинаковым. Только чтобы на слово надеть весь спектр данных, твоему мозгу придется здорово подтрудится, на что потратится огромное количество энергии. Ну а если человек свой мозг не задействует: увидел слово — значит слово — то мозг такого человека скуден. К творчеству никакого отношения он иметь не будет и ничего стоящего нового никогда не создаст. А чем оперировать ему? Сенсорная депривация — это лишение одного или нескольких органов чувств внешнего воздействия — приводит к депрессии.

S>Визуализируй, пожалуйста парсер, умеющий разбирать символ по переданному условию:
S>

S>let p_pred p s =
S>    match s with
S>    | [] → Failed
S>    | h::t → if p h then Parsed(h, t) else Failed
S>

S>Желательно так, чтобы у сведущих людей не возникало вопросов, когда они будут смотреть на образ.

Я не знаком с F#. С удовольствием постараюсь визуализировать что-нибудь попроще.
Я не предлагал уже готового решения. Надеялся, что мы вместе как раз подумаем над тем, как это могло бы выглядеть на практике.
Кстати, писатели не пишут рассказы от первой буквы до последней. Разве что кроме тех, кто записывает свой поток сознания. Они сначала придумывают героев, их характеры, их биографию. В общих чертах придумывают сюжет. Также обстановку, в которой будут происходить действия. Ты просто задай себе вопрос, почему литературное произведение намного интереснее читать, чем список героев, их характеров, их биографий, сюжет, который подан в общих чертах, и обстановку, описанную в трех словах.
Ты пришли пример попроще, можно на C#, мне самому интересно визуализировать.

Здравствуйте, UnseriousSam

ИМХО программирование как процесс кодирования возник исторически. Первые компьютерщики мечтали, что компьютер будет с ними разговаривать. Стали придумывать команды близкие по написанию к естественной речи, типа "whyami". Дальше — больше, стали разрабатывать редакторы и компиляторы псевдо-естественных языков. Текстовая консоль и клавиатура — все что нужно было пытливому уму компьютерщика.

Теперь мы имеем огромное множество языков программирования, огромное количество программ на них написанное. Обратной дороги нет. Теперь мы быдлокодеры.

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

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

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

S>Визуализируй, пожалуйста парсер...

А что такого в визуализации парсеров? Визуализация грамматики — это, фактически, визуализация парсера.

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

US>Я не знаком с F#. С удовольствием постараюсь визуализировать что-нибудь попроще.
На счет чего-нибудь попроще я как-то не сомневался. Легко вызвать ассоциацию со списком, словарем, GC и посетителем. А как насчет того, для чего образов нет? Читая код я понимаю (чаще всего) как ведет себя та или иная сущность, даже если я в глаза ничего подобного не видел. Глядя на образ налогового инспектора я возможно догадаюсь что это посетитель (без пол-литра вряд ли), но особенности его реализации я не увижу из такого образа. Но увижу из кода, когда посмотрю на этот код как на совокупность текстовых образов.

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

US>Кстати, писатели не пишут рассказы от первой буквы до последней. Разве что кроме тех, кто записывает свой поток сознания. Они сначала придумывают героев, их характеры, их биографию. В общих чертах придумывают сюжет. Также обстановку, в которой будут происходить действия. Ты просто задай себе вопрос, почему литературное произведение намного интереснее читать, чем список героев, их характеров, их биографий, сюжет, который подан в общих чертах, и обстановку, описанную в трех словах.
Интересность программного кода — вещь вторичная. Первичная — это его понятность, причем для человека прежде всего. И чем меньше неоднозначностей, тем лучше. Код = спецификация, переведенная на язык, понятный и человеку и машине в равной степени.

US>Ты пришли пример попроще, можно на C#, мне самому интересно визуализировать.
Пусть это будет генератор простых чисел в абстрактном виде без деталей реализации, оформленный в виде IEnumerable<int>.

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

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

S>>Визуализируй, пожалуйста парсер...

K>А что такого в визуализации парсеров? Визуализация грамматики — это, фактически, визуализация парсера.
K>

Я ожидал увидеть человека-паука затягивающего в сеть буквы и анализирующего их каким-нибудь тестером. Ну а грамматика — это не интересно. Не стимулирует мозг. Речь ведь об этом!

Возможно, идеи автора топика стали бы более понятны публике, если бы тот визуализировал (ну в паинте пример картинки нарисовал) на примере какого-нибудь куста кода.

Как бы это могло выглядеть? Ну хотя вот, первый попавшийся под руку:

using System;
using System.Collections.Specialized;

namespace GacInstaller
{
    //  Refreshes an assembly in the GAC
    public class FreshAssembly
    {
        #region Constructor
        public FreshAssembly(string file)
        {
            this._assemblyFile = file;
        }
        #endregion
 
        
        #region Methods
        // Installs assembly by full name
        // Returns 
        // Ok = True
        // Any errors = False
        public bool Install(string fileName)
        {
            try
            {
                Fusion.InstallAssembly(fileName);
                return true;
            }
            catch (Exception e)
            {
                GacInstaller.OutputLine("");
                GacInstaller.OutputLine(e.Message);
                System.Environment.ExitCode = GacInstaller.RESULT_SUCCESSFUL_WITH_WARNINGS;
                return false;
            }
        }

        public void Perform(Options options)
        {
            StringCollection oldAssemblies = new StringCollection();
            if (this.Install(this._assemblyFile))
            {
                GacInstaller.OutputLineFormat("{0} Ok.", this._assemblyFile);
            }
            else
            {
                GacInstaller.OutputLineFormat("Could not install assembly: {0}", this._assemblyFile);
                if (Environment.ExitCode < GacInstaller.RESULT_SUCCESSFUL_WITH_WARNINGS)
                {
                    Environment.ExitCode = GacInstaller.RESULT_SUCCESSFUL_WITH_WARNINGS;
                }
            }
        }
        #endregion
 

        #region Fields
        private readonly string _assemblyFile;
        #endregion

    }
}

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

FR>показывает что текст мозгом воспринимается именно как поток образов, а не как поток символов.

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

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

S>Я ожидал увидеть человека-паука затягивающего в сеть буквы и анализирующего их каким-нибудь тестером. Ну а
S>грамматика — это не интересно. Не стимулирует мозг. Речь ведь об этом!

Ха! Это все потому, что я не "художник", не "гений" и не "мастер, вкладывающий всю душу", потому как в существование души не верю.
А речь тут идет одноврмененно про душу (и прочее сопутствующее мракобесие в программировании) и визуализацию одновременно. Понятно, что с "душой" ничего не выйдет, а с визуализацией (в ограниченном ряде случаев) особых проблем нет.

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

US>ОК. Замени фигуры на шахматной доске на первые буквы их названий. Пешка — П, Ферзь — Ф и так далее. А еще лучше на точку, палочку, кружок. И так играй. Хотя куда приятней играть в шахматы, в каждую фигуру которых мастер вложил всю свою душу.

Вслепую играл? У меня в голове только связи (правда, пространственные), я даже доску не вижу, может быть кусками иногда. Хотя играл одновременно 4 партии. Правда, это давно было. Так что нарисуешь П,Ф или палочки и через 10 минут игры к ним привыкнешь и перестанешь замечать. Это как смена шрифта.

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

ССЗБ?

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

K>А речь тут идет одноврмененно про душу (и прочее сопутствующее мракобесие в программировании) и визуализацию одновременно. Понятно, что с "душой" ничего не выйдет, а с визуализацией (в ограниченном ряде случаев) особых проблем нет.

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

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

K>Это показывает, что текст воспринимается не как поток символов, а как поток слов. Собственно, даже поток визуальных образов обрабатывается мозгом, как поток слов внутренней речи.

Нет не поток слов точно, те же специалисты по скорочтению читают не словами а чем то вроде "потока смыслов", то есть пропуская эту самую внутреннюю речь.

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

US>ОК. Замени фигуры на шахматной доске на первые буквы их названий. Пешка — П, Ферзь — Ф и так далее. А еще лучше на точку, палочку, кружок. И так играй. Хотя куда приятней играть в шахматы, в каждую фигуру которых мастер вложил всю свою душу.

Вообще, мне шахматная доска не нужна. Хватит и слов, что пешка с поля d2 пошла на d4 Далее, можно взять китайские шахматы или японский шахматы, там на фигуре пишется иероглиф, который ее обозначает. И тоже не вижу никакой проблемы играть (примеры ниже). Фигуры, в которые мастер вложил душу, если честно, отвлекают от игры. Лучше стандартный набор Стаунтон номер шесть. Или семь

Это типичная позиция, которая возникает в сеги:



А это сянци:



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

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

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

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

М>Как бы это могло выглядеть? Ну хотя вот, первый попавшийся под руку:

М>

М>using System;
М>using System.Collections.Specialized;

М>namespace GacInstaller
М>{
М>    //  Refreshes an assembly in the GAC
М>    public class FreshAssembly
М>    {
М>        #region Constructor
М>        public FreshAssembly(string file)
М>        {
М>            this._assemblyFile = file;
М>        }
М>        #endregion
 
        
М>        #region Methods
М>        // Installs assembly by full name
М>        // Returns 
М>        // Ok = True
М>        // Any errors = False
М>        public bool Install(string fileName)
М>        {
М>            try
М>            {
М>                Fusion.InstallAssembly(fileName);
М>                return true;
М>            }
М>            catch (Exception e)
М>            {
М>                GacInstaller.OutputLine("");
М>                GacInstaller.OutputLine(e.Message);
М>                System.Environment.ExitCode = GacInstaller.RESULT_SUCCESSFUL_WITH_WARNINGS;
М>                return false;
М>            }
М>        }

М>        public void Perform(Options options)
М>        {
М>            StringCollection oldAssemblies = new StringCollection();
М>            if (this.Install(this._assemblyFile))
М>            {
М>                GacInstaller.OutputLineFormat("{0} Ok.", this._assemblyFile);
М>            }
М>            else
М>            {
М>                GacInstaller.OutputLineFormat("Could not install assembly: {0}", this._assemblyFile);
М>                if (Environment.ExitCode < GacInstaller.RESULT_SUCCESSFUL_WITH_WARNINGS)
М>                {
М>                    Environment.ExitCode = GacInstaller.RESULT_SUCCESSFUL_WITH_WARNINGS;
М>                }
М>            }
М>        }
М>        #endregion
 

М>        #region Fields
М>        private readonly string _assemblyFile;
М>        #endregion

М>    }
М>}
М>

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

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

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

Можно показать на примере, каков прямой и без лишних преобразований процесс скармливания мозгу Enumerable.Aggregate (а по простому fold).
Вот я когда вижу Enumerable.Aggregate, то знаю что это есть fold, а как работает fold я знаю, и потому когда вижу Aggregate я понимаю что просиходит в коде.

Как можно прямее-то?

Допустим, ты мне дашь образ fold-а, но для меня он будет таким же как и Enumerable.Aggregate, т.е. просто ярлыком, и потому процесс его восприятия не будет прямее.

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

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

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

S>Можно показать на примере, каков прямой и без лишних преобразований процесс скармливания мозгу Enumerable.Aggregate (а по простому fold).
S>Вот я когда вижу Enumerable.Aggregate, то знаю что это есть fold, а как работает fold я знаю, и потому когда вижу Aggregate я понимаю что просиходит в коде.

S>Как можно прямее-то?

S>Допустим, ты мне дашь образ fold-а, но для меня он будет таким же как и Enumerable.Aggregate, т.е. просто ярлыком, и потому процесс его восприятия не будет прямее.

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

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

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

S>>>Как можно прямее-то?

S>>>Допустим, ты мне дашь образ fold-а, но для меня он будет таким же как и Enumerable.Aggregate, т.е. просто ярлыком, и потому процесс его восприятия не будет прямее.

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

S>Все-таки, на данном этапе пора бы уже перейти к примерам визуализации. Пусть это будут смешные и несуразные примеры, но надо хотя бы показать, что возможно хоть что-то представить в виде картинки. Так что давайте мы сейчас все-таки придумаем картинку для Enumerable.Aggregate, иначе, имхо, вся идея пойдет прахом. Если уж в самом начале на примитивщине споткнемся.

Любая картинка, на которой человек, олицетворяющий Enumerable, собирает несколько предметов в одно целое. Представим, что я умею рисовать и быстро нарисовал забавного человека в зеленом пиджаке и красной шляпе. Он радостно собирает небольшой пазл. Можно, к примеру, договориться, что входные данные всегда будут обозначаться на картинке, не зависимо от, какими предметами они будут представлены, синим цветом. А выходные данные будут всегда окружены ярко-желтым свечением. Эту картинку можно представить как угодно. Главными здесь будут небольшие формальности: человек, олицетворяющий объект, цвет входных и выходных данных.

По поводу имен переменных. Почему мы не называем классы, объекты, функции и переменные такими словами, как qwert, asdfg, zxcvb? Почему мы называет их Визитер, Создатель, Перечислитель, Сохранитель, Записать, Сохранить, Написать? Назовите их абракадаброй и программа работать не перестанет. Потому что комьютеру все равно. Мы не только пишем, мы еще объмениваемся информацией, читаем ее. В нас есть естественная потребность использовать язык описательный.

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

US>По поводу имен переменных. Почему мы не называем классы, объекты, функции и переменные такими словами, как qwert, asdfg, zxcvb? Почему мы называет их Визитер, Создатель, Перечислитель, Сохранитель, Записать, Сохранить, Написать? Назовите их абракадаброй и программа работать не перестанет. Потому что комьютеру все равно. Мы не только пишем, мы еще объмениваемся информацией, читаем ее. В нас есть естественная потребность использовать язык описательный.

Уже много лет человек обменивается информацией письменностью, а не рисунками.

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

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

US>>По поводу имен переменных. Почему мы не называем классы, объекты, функции и переменные такими словами, как qwert, asdfg, zxcvb? Почему мы называет их Визитер, Создатель, Перечислитель, Сохранитель, Записать, Сохранить, Написать? Назовите их абракадаброй и программа работать не перестанет. Потому что комьютеру все равно. Мы не только пишем, мы еще объмениваемся информацией, читаем ее. В нас есть естественная потребность использовать язык описательный.

S>Уже много лет человек обменивается информацией письменностью, а не рисунками.

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

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

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

US>>По поводу имен переменных. Почему мы не называем классы, объекты, функции и переменные такими словами, как qwert, asdfg, zxcvb? Почему мы называет их Визитер, Создатель, Перечислитель, Сохранитель, Записать, Сохранить, Написать? Назовите их абракадаброй и программа работать не перестанет. Потому что комьютеру все равно. Мы не только пишем, мы еще объмениваемся информацией, читаем ее. В нас есть естественная потребность использовать язык описательный.

S>Уже много лет человек обменивается информацией письменностью, а не рисунками.

Даже можно сказать, что просто ты называешь информацией только то, что представлено словами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 миллиардов бит информации в секунду. Опять добавлю, что если ты не осознаешь, то это не значит, что ты этого не знаешь.

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

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

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

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

US>Могу только сказать, что ты ошибаешься.
В чём?
Я привёл пример. Сколько времени займет ролик со всей этой информацией?

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

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

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

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

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

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

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


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

Дык "английские ученные" все давно подсчитали
Хотя по сути он прав подсознательно обрабатывается на много порядков больше информации чем сознательно.

Спасибо, народ, за критику.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Мне кажется нужно просто нормально грокать, а образы это фигня по сравнению с грокингом. Грокинг же он объединяет в себе и смысл и образ и альфу и омегу. Ну и конечно главное не политурить.

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

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

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

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

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

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

При появлении объектно-ориентированного программирования также приходилось кому переучиваться, а кому уже с самого начала учить новую технологию. Может быть ты считаешь, что хотя бы такое занятие, как придумывание иконок для пользовательского интерфейса — дар Божий? Это навык. Я вот с легкостью могу представить время, когда это будет восприниматься легко и естественно.

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

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

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

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

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

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

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

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

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

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

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

Это все равно что если ты увидишь название функции, а потом еще почитаешь ее описание — и все равно не поймешь, о чем эта функция и когда ее использовать. Чтобы понимать, мы учились много лет. Я когда самостоятельно по молодости, когда только на паскале умел чуть-чуть программировать, читал Win32 API, я не понимал ничего воооообще. И продирался через невообразимые трудности, чтобы понять, о чем речь. А сейчас могу абслолютно свободно бегло пробежать по описанию функции и понять, что она делает. Это навык, и все.
Кошка с маленьким мозгом, которая знает только слова "мяу" и "фыр", очень быстро понимаем, что означает тапочек.
Ты пытаешься понять новую идею через призму старого. Не будет вообще в привычном понимании "buy" и "sell". Тебе не придется постоянно делать преобразование от образа к слову. Ты будешь все воспринимать непосредственно и также непосредственно будешь знать, как на это реагировать, как это использовать и что с этим делать. Прям как кошка, когда видит тапок А ведь кошка думать в нашем понимании не умеет.

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

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

US>Тут повторю вопрос. Кто из отписавшихся знаком с системами запоминания информации и принципами, на которых они построены?

Давай лучше поговорим о влияний занятий спортом на изучение языков программирования. Например в прошлом году мы тут достоверно
установили что занятия штангой очень благотворны для изучения Хаскеля.

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

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

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

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

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

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

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

US>Это все равно что если ты увидишь название функции, а потом еще почитаешь ее описание — и все равно не поймешь, о чем эта функция и когда ее использовать. Чтобы понимать, мы учились много лет. Я когда самостоятельно по молодости, когда только на паскале умел чуть-чуть программировать, читал Win32 API, я не понимал ничего воооообще. И продирался через невообразимые трудности, чтобы понять, о чем речь. А сейчас могу абслолютно свободно бегло пробежать по описанию функции и понять, что она делает. Это навык, и все.
Я могу понять что делает функция и не пробегаясь по описанию, если знаком с термином, употребенным в ее названии. С иконкой я не знаком, как не знаком с 2500 наиболее употребимых японцами иероглифами.

US>Ты пытаешься понять новую идею через призму старого. Не будет вообще в привычном понимании "buy" и "sell". Тебе не придется постоянно делать преобразование от образа к слову. Ты будешь все воспринимать непосредственно и также непосредственно будешь знать, как на это реагировать, как это использовать и что с этим делать.

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

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

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

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

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

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

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

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

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

US>>Это все равно что если ты увидишь название функции, а потом еще почитаешь ее описание — и все равно не поймешь, о чем эта функция и когда ее использовать. Чтобы понимать, мы учились много лет. Я когда самостоятельно по молодости, когда только на паскале умел чуть-чуть программировать, читал Win32 API, я не понимал ничего воооообще. И продирался через невообразимые трудности, чтобы понять, о чем речь. А сейчас могу абслолютно свободно бегло пробежать по описанию функции и понять, что она делает. Это навык, и все.
S>Я могу понять что делает функция и не пробегаясь по описанию, если знаком с термином, употребенным в ее названии. С иконкой я не знаком, как не знаком с 2500 наиболее употребимых японцами иероглифами.

US>>Ты пытаешься понять новую идею через призму старого. Не будет вообще в привычном понимании "buy" и "sell". Тебе не придется постоянно делать преобразование от образа к слову. Ты будешь все воспринимать непосредственно и также непосредственно будешь знать, как на это реагировать, как это использовать и что с этим делать.

S>Давай начнем с общения ребусами, а потом уже на программирование переходить. Если ты сможешь выражать свои мысли образами, а кто-то (не компьютер) их будет адекватно воспринимать, то это уже будет серьезным шагом к отмене "buy" и "sell".

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

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

S>Это практически очевидно должно быть для кинестетиков, ведь H похожа на штангу. Кстати, очень может быть, что штангой можно непосредственно не заниматься, а просто созерцать ее? Возможно З. немного злоупотребляет?

Надо попробовать. Я пробовал думать о штанге, но это не помогло в освоении Хаскеля

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

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

Как раз человек и пазл там лишние.

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

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

S>>Это практически очевидно должно быть для кинестетиков, ведь H похожа на штангу. Кстати, очень может быть, что штангой можно непосредственно не заниматься, а просто созерцать ее? Возможно З. немного злоупотребляет?

FR>Надо попробовать. Я пробовал думать о штанге, но это не помогло в освоении Хаскеля

Может вес нетот выбрал? С thesz консультировался?

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

FR>>Надо попробовать. Я пробовал думать о штанге, но это не помогло в освоении Хаскеля

К>Может вес нетот выбрал? С thesz консультировался?

thesz к сожалению пропал с rsdn, но я думаю меня спасет "графическое программирование" буду рисовать штанги вместо монад.

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

FR>То что я обозвал "потоком смыслов" это и есть внутренняя речь. Но насколько мне позволяет склероз внутренняя структура
FR>у нее совершенна другая как раз свернутая до этого самого потока смыслов.

Ну, "поток смыслов" это что-то малопонятное. Внутренняя речь предикативная, так что предложения действительно имеют структуру отличную от развернутой речи. А слова, можно сказать, обычные. Слова как слова.

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

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

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

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

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

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

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

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

int a;
int b;
int c;
int d;

Можем запомнить, что в функции объявлено четыре перменные. Потом по ходу чтения функции мы будет извлекать из памяти эту инфмормацию. Так вот экспериментальная психология утверждает, что если, во-первых, дать каждой переменной свой цвет, то для запоминания и извелчения информации об объявленных перменных понадобится меньше усилий и меньше времени. Пример простой, поэтому разница не очевидна. Все равно поехали дальше. Если теперь каждую переменную написать не обычными печатными буквами, а подобрать какой-нибудь красивый нестандартный шрифит, то наша производительность опять увеличится. Если нарисовать, например, первую переменную как букву "a", с глазами с ногами, с улыбкой... и так далее. Можно теперь добавить звук. Неважно, что он не будет иметь как бы технической нагрузки и необязателен для нормальной работы программы. Важно то, что мозг получит больше информации, а значит установит у себя внутри более прочные и более разнообразные связи. А это — я уже сто раз тут писал об этом — оптимизирует работу самого мозга. В любом случае на переменную "a" в мозгу навешивается не только сам символ "a", но и, например, слова, сказанные коллегой по работе об этой переменной, или слова заказчика, в которых явно прозвучала эта переменная. Она, например, могла называться Account.
Можно сказать, что такие приемы увеличивают пропускную способность нашего мозга. Недаром ведь со временем опытным путем мы пришли к тому, что стали давать переменным осмысленные названия, стали делать функции небольшими, перестали смешивать в одном месте разные уровни абстракции. Т.е. не перестали, а знаем, что такие приемы упрощают жизнь и тем, кто пишет код, и тем, кто впоследствии будет его читать.
Если пойти дальше, то можно применять "эти приемы" для любой информации, которую содержит исходный код программы: вызовы функций, передача параметров, связи между классами и объектами и т.д. и т.п. Вопрос в самом способе записи этой информации. Я еще в сто первый раз повторюсь — странно, что это постоянно игнорируется — мы даем переменным осмысленные имена, хотя для работы компьютера достаточно однобуквенных названий. Так же для работы программы абсолютно не нужны классы.

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

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

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

Я как раз стараюсь сделать так, чтобы тебе было еще удобнее. Иначе ограничил бы ты себя машинными кодами и был бы этим более чем доволен.

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

US>Я про другое хотел сказать. Окраска — не как способок передачи знаний, а как способ, позволяющий мозгу лучше запомнить и в дальнейшем лучше оперировать информацией. Пример...

US>int a;
US>int b;
US>int c;
US>int d;

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

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

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

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

US>В любом случае на переменную "a" в мозгу навешивается не только сам символ "a", но и, например, слова, сказанные коллегой по работе об этой переменной, или слова заказчика, в которых явно прозвучала эта переменная. Она, например, могла называться Account.
XML-документацию уже придумали.

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


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

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

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

US>>Я про другое хотел сказать. Окраска — не как способок передачи знаний, а как способ, позволяющий мозгу лучше запомнить и в дальнейшем лучше оперировать информацией. Пример...

US>>int a;
US>>int b;
US>>int c;
US>>int d;

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

G>И как задавать цвет? Попробуйте сделать в ворде выделение цветом. Как делать так чтобы цвет всегда был контрастным с фоном? Или ты предлагаешь передавать вместе с исходником всю цветовую схему? Даже это не поможет, человек может использовать твою переменную в своей цветовой схеме.

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

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

US>>В любом случае на переменную "a" в мозгу навешивается не только сам символ "a", но и, например, слова, сказанные коллегой по работе об этой переменной, или слова заказчика, в которых явно прозвучала эта переменная. Она, например, могла называться Account.
G>XML-документацию уже придумали.

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


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

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

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

US>Откуда взять все? Я, например, пришел сюда просто пообщаться, ничего реализовывать я не собираюсь. Я тут филосовствую.
Абстрактная философия никого не интересует ибо упирается в реальность.
Думаешь почему среды графического программирования провалились вообще все?
Хотя всяческие UML-диаграммы удобнее кода, но используются они для иллюстрации, а не для программирования. И часто такие диаграммы строятся прямо по коду (не не наоборот);

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

US>Ведь исходный файл другой программист может использовать со "своей" кодировкой, также ничего не поймет. Сделают и договорятся.
Ты в каком веке живешь? Сейчас все на unicode.

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

US>В этом примере цвет и образ информацию не передают.
Ага, есть два варианта — нереализуемый и бесполезный.

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

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

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

K>Только как дополнение к формальному описанию. дополнение, которое можно легко не читать. Описание алгоритма должно быть именно формальным,

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

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

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

US>Ты говоришь "неплохо получается". Хотя так всегда думали и будут думать.
Нет, просто программист написавший код в недавнем времени держит в голове детали, которые позволяют в нем ориентироваться. Я например налабал за несколько дней кода на 2000 строк и вполне нормально могу сказать для чего нужны переменные и функции. Если я их раскрашу как мне захочется, нафигачу шрифтов, то мне понятнее код не станет, как он не станет понятнее другому человеку. А через некоторое время я забуду зачем я писал те или иные куски и дополнительная информация в виде звука\картинок\шрифтов будет гораздо менее полезной чем текстовые комменты.

US>Так же думали и программисты машинных кодов. Т.е. не было их вины в том, что их все устраивало. Их просто не интересовало то, как сделать свою работу более удобной. А может быть и интересовало, но они не знали как.
Еще раз, среды графического программирования провалились. ВСЕ. Изучи почему так, найдешь ответы на все вопросы.

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