Re[11]: Графическое программирование и здоровье
От: FR  
Дата: 17.06.10 10:08
Оценка:
Здравствуйте, UnseriousSam, Вы писали:


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


Мне кажется нужно просто нормально грокать, а образы это фигня по сравнению с грокингом. Грокинг же он объединяет в себе и смысл и образ и альфу и омегу. Ну и конечно главное не политурить.
Re[12]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 17.06.10 10:14
Оценка:
Здравствуйте, samius, Вы писали:

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


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


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


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

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

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


При появлении объектно-ориентированного программирования также приходилось кому переучиваться, а кому уже с самого начала учить новую технологию. Может быть ты считаешь, что хотя бы такое занятие, как придумывание иконок для пользовательского интерфейса — дар Божий? Это навык. Я вот с легкостью могу представить время, когда это будет восприниматься легко и естественно.
Re[13]: Графическое программирование и здоровье
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.06.10 10:31
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

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


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


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


А я с трудом могу представить чем будет отличаться иконки "buy" и "sell", а так же как я их буду искать в библиотеке, когда потребуется вызвать соответствующий метод. Но больше всего я боюсь ситуации, когда увижу иконку и не пойму, что она обозначает.
Re[14]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 17.06.10 10:44
Оценка:
Здравствуйте, samius, Вы писали:

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


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


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


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


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


Это все равно что если ты увидишь название функции, а потом еще почитаешь ее описание — и все равно не поймешь, о чем эта функция и когда ее использовать. Чтобы понимать, мы учились много лет. Я когда самостоятельно по молодости, когда только на паскале умел чуть-чуть программировать, читал Win32 API, я не понимал ничего воооообще. И продирался через невообразимые трудности, чтобы понять, о чем речь. А сейчас могу абслолютно свободно бегло пробежать по описанию функции и понять, что она делает. Это навык, и все.
Кошка с маленьким мозгом, которая знает только слова "мяу" и "фыр", очень быстро понимаем, что означает тапочек.
Ты пытаешься понять новую идею через призму старого. Не будет вообще в привычном понимании "buy" и "sell". Тебе не придется постоянно делать преобразование от образа к слову. Ты будешь все воспринимать непосредственно и также непосредственно будешь знать, как на это реагировать, как это использовать и что с этим делать. Прям как кошка, когда видит тапок А ведь кошка думать в нашем понимании не умеет.
Re: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 17.06.10 10:55
Оценка:
Кто-то тут писал, что живопись и подобные используются, чтобы передать только эмоции. Тогда вопрос.
Для передачи каких эмоции используются иконки в Microsoft Word? И раз уж ты решил проигнорировать эмоции вообще, то попробуй попрограммируй, подумай о какой-нибудь проблеме головой в состоянии деперссии, а после этого я тебя спрошу, важны эмоции для творческой продуктивной деятельности или нет.
Вообще споры сейчас с графическим представлением информации — это споры не со мной, не заблуждайтесь, это споры по крайней со здравым смыслом, если вы человек наблюдательный, или по крайней мере с наукой — чей авторитет сейчас признается больше, чем авторитет здравого смысла — которая уже очень хорошо исследовала, как работает мозг, что ему нужно для творческой продуктивной дейятельности, чтобы и креатив был и память не подводила.
Тут повторю вопрос. Кто из отписавшихся знаком с системами запоминания информации и принципами, на которых они построены?
Re[2]: Графическое программирование и здоровье
От: FR  
Дата: 17.06.10 11:05
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

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


Давай лучше поговорим о влияний занятий спортом на изучение языков программирования. Например в прошлом году мы тут достоверно
установили что занятия штангой очень благотворны для изучения Хаскеля.
Re[15]: Графическое программирование и здоровье
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.06.10 11:06
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

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


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


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


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


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


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


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

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

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


Давай начнем с общения ребусами, а потом уже на программирование переходить. Если ты сможешь выражать свои мысли образами, а кто-то (не компьютер) их будет адекватно воспринимать, то это уже будет серьезным шагом к отмене "buy" и "sell".
Re[3]: Графическое программирование и здоровье
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.06.10 11:12
Оценка: :)
Здравствуйте, FR, Вы писали:

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


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


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

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

Это практически очевидно должно быть для кинестетиков, ведь H похожа на штангу. Кстати, очень может быть, что штангой можно непосредственно не заниматься, а просто созерцать ее? Возможно З. немного злоупотребляет?
Re[16]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 17.06.10 11:15
Оценка:
Здравствуйте, 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".


Ты хитрый. Когда-то ты не был знаком и с терминов, употребляемым в названии функции. Потом познакомился. Так же познакомишься и с неким принципом, который будет закладываться в образ и что-то обозначать. Выше я уже указывал пример про человечка, который собирает пазл.
Re[4]: Графическое программирование и здоровье
От: FR  
Дата: 17.06.10 11:18
Оценка:
Здравствуйте, samius, Вы писали:

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


Надо попробовать. Я пробовал думать о штанге, но это не помогло в освоении Хаскеля
Re[17]: Графическое программирование и здоровье
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.06.10 11:23
Оценка:
Здравствуйте, UnseriousSam, Вы писали:

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


Как раз человек и пазл там лишние.
Re[5]: Графическое программирование и здоровье
От: Курилка Россия http://kirya.narod.ru/
Дата: 17.06.10 16:12
Оценка:
Здравствуйте, FR, Вы писали:

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


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


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


Может вес нетот выбрал? С thesz консультировался?
Re[6]: Графическое программирование и здоровье
От: FR  
Дата: 18.06.10 04:41
Оценка:
Здравствуйте, Курилка, Вы писали:

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


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


thesz к сожалению пропал с rsdn, но я думаю меня спасет "графическое программирование" буду рисовать штанги вместо монад.
Re[13]: Графическое программирование и здоровье
От: Klapaucius  
Дата: 21.06.10 07:17
Оценка:
Здравствуйте, FR, Вы писали:

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

FR>у нее совершенна другая как раз свернутая до этого самого потока смыслов.

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

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

US>Ты лично видишь целесообразность такой подачи алгоритма?

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

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


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

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


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

US>>Ты лично видишь целесообразность такой подачи алгоритма?

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

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

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

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

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

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


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

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

Я как раз стараюсь сделать так, чтобы тебе было еще удобнее. Иначе ограничил бы ты себя машинными кодами и был бы этим более чем доволен.
Re[8]: Графическое программирование и здоровье
От: UnseriousSam  
Дата: 21.06.10 11:33
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

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


US>>Опять добавлю, что если ты не осознаешь, то это не значит, что ты этого не знаешь.

S>2. Нас не интересует неосознанное знание. Нас интересует осознанное программирование. Поэтому все забавности типа записи в подсознание идут мимо кассы.

Никого как раз не интересует, что ты осознаешь, а что не осознаешь. Ты можешь осознавать у себя дома, лежа на диване. Остальным от этого ни жарко, ни холодно. Нас интересует то, что ты можешь написать в коде и что ты можешь объяснить своим коллегам-программистам, если понадобится. Как ты получил эти знания — абсолютно неважно. "Осознанное программирование" — ты прошло решил, что это круто звучит.
Re[12]: Графическое программирование и здоровье
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.06.10 11:47
Оценка:
Здравствуйте, 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>Я еще в сто первый раз повторюсь — странно, что это постоянно игнорируется — мы даем переменным осмысленные имена, хотя для работы компьютера достаточно однобуквенных названий. Так же для работы программы абсолютно не нужны классы.

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