Здравствуйте, 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>Еще складывается мнение, что ты утверждаешь, что способ подачи информации не имеет никакого значения, а важна только сама информация.
С чего ты взял? Важен не только способ подачи информации (как показать), но и способ создания этой информации, способ хранения её и способы автоматической обработки. (я это уже несколько раз повторил).
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, UnseriousSam, Вы писали:
US>>Ты говоришь "неплохо получается". Хотя так всегда думали и будут думать. G>Нет, просто программист написавший код в недавнем времени держит в голове детали, которые позволяют в нем ориентироваться. Я например налабал за несколько дней кода на 2000 строк и вполне нормально могу сказать для чего нужны переменные и функции. Если я их раскрашу как мне захочется, нафигачу шрифтов, то мне понятнее код не станет, как он не станет понятнее другому человеку. А через некоторое время я забуду зачем я писал те или иные куски и дополнительная информация в виде звука\картинок\шрифтов будет гораздо менее полезной чем текстовые комменты.
Во-первых, ты пытаешься представить, как оно было бы, если бы ты так сделал. Не имея опыта, это невозможно сделать. Такого опыта у тебя нет. Во-вторых, ты не знаком с исследованиями психологов на эту тему.
Поэтому, если сказать просто, ты ошибаешься. Вот в этом самом главном пункте ты ошибаешься, понимаешь?
US>>Так же думали и программисты машинных кодов. Т.е. не было их вины в том, что их все устраивало. Их просто не интересовало то, как сделать свою работу более удобной. А может быть и интересовало, но они не знали как. G>Еще раз, среды графического программирования провалились. ВСЕ. Изучи почему так, найдешь ответы на все вопросы.
Мне интересно, с удовольствием почитаю. Буду благодарен, если поделишься ссылкой.
Здравствуйте, UnseriousSam, Вы писали:
US>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, UnseriousSam, Вы писали:
US>>>Ты говоришь "неплохо получается". Хотя так всегда думали и будут думать. G>>Нет, просто программист написавший код в недавнем времени держит в голове детали, которые позволяют в нем ориентироваться. Я например налабал за несколько дней кода на 2000 строк и вполне нормально могу сказать для чего нужны переменные и функции. Если я их раскрашу как мне захочется, нафигачу шрифтов, то мне понятнее код не станет, как он не станет понятнее другому человеку. А через некоторое время я забуду зачем я писал те или иные куски и дополнительная информация в виде звука\картинок\шрифтов будет гораздо менее полезной чем текстовые комменты.
US>Во-первых, ты пытаешься представить, как оно было бы, если бы ты так сделал. Не имея опыта, это невозможно сделать. Такого опыта у тебя нет. Во-вторых, ты не знаком с исследованиями психологов на эту тему.
Дай ссылку на исследования психологов чтоли.
US>Поэтому, если сказать просто, ты ошибаешься. Вот в этом самом главном пункте ты ошибаешься, понимаешь?
Да уж... Ты все еще не понял. Не в психологии дело.
С точки зрения психологии я как раз понимаю важность этих образов для понимания. А вот в инженерном плане такое вызывает сомнения, потому что психологи не учли что кроме того что люди будут понимать эти цвета\шрифты\звук, они будут еще и создавать его.
Как минимум нужно добиться одинакового понимания между людьми, тут уже возникает много разногласий ибо восприятие цветов, звуков, форм зависит не только от физиологии, но и от культурных особенностей и от банальных привычек и вкусов.
Другой вопрос — создание этой информации, где взять звуки, кто будет рисовать шрифты и как подобрать цвета? На это разработчики должны будут затратить время (!), причем гораздо больше чем будет сэкономлено на вникании в код, ведь после вникания эта информация будет приносить гораздо меньше пользы.
Третий вопрос — автоматизация работы с такой информацией. Мы часто пользуемся поиском с заменой, утилитами для диффа\мерджа — как они будут работать с такой информацией? Даже банальный рефакторинг — переименование переменной — должен будет учитывать дополнительную информацию (как сейчас умеет переименовывать в комментах). Вообще любое изменение кода потребует изменения этой метаинформации, что сильно затруднит поддержку.
Четвертый вопрос — инструменты для работы с информацией. Например есть ide, где на одном экране несколько переменных, к каждой из них прикреплен звук, какой будет проигрываться в данный момент?
US>>>Так же думали и программисты машинных кодов. Т.е. не было их вины в том, что их все устраивало. Их просто не интересовало то, как сделать свою работу более удобной. А может быть и интересовало, но они не знали как. G>>Еще раз, среды графического программирования провалились. ВСЕ. Изучи почему так, найдешь ответы на все вопросы. US>Мне интересно, с удовольствием почитаю. Буду благодарен, если поделишься ссылкой.
Я ссылки не собираю, ищи статьи по критике UML.
Кстати аналогичная ситуация с простыми текстовыми комментами. В старых книгах можно найти советы что надо код обильно комментировать чтобы он был понятным (ну практически то что ты предлагаешь, только оно работает). Практика показала что много писать текстовой информации неэффективно, комменты также требуется поддерживать, как и код. Поэтому пришли к мысли самодокументируемого кода, с понятными идентификаторами, короткими функциями и тому подобным.
Здравствуйте, 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>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, UnseriousSam, Вы писали:
US>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, UnseriousSam, Вы писали:
US>>>>>Ты говоришь "неплохо получается". Хотя так всегда думали и будут думать. G>>>>Нет, просто программист написавший код в недавнем времени держит в голове детали, которые позволяют в нем ориентироваться. Я например налабал за несколько дней кода на 2000 строк и вполне нормально могу сказать для чего нужны переменные и функции. Если я их раскрашу как мне захочется, нафигачу шрифтов, то мне понятнее код не станет, как он не станет понятнее другому человеку. А через некоторое время я забуду зачем я писал те или иные куски и дополнительная информация в виде звука\картинок\шрифтов будет гораздо менее полезной чем текстовые комменты.
US>>>Во-первых, ты пытаешься представить, как оно было бы, если бы ты так сделал. Не имея опыта, это невозможно сделать. Такого опыта у тебя нет. Во-вторых, ты не знаком с исследованиями психологов на эту тему. G>>Дай ссылку на исследования психологов чтоли. US>Ссылок я тоже не собираю. Можно почитать Тони Бьюзена "Научи себя думать". Это книга про карты памяти.
Это я читал, оно очень далеко от обсуждаемой темы. Хотя может именно этого ты и не понимаешь
US>Хотя он там сам как бы ссылается не подобные исследования. Или любая книга по когнитивной психологии.
"Любые книги по психологии" в данном разговоре неуместны, они не учитывают многих факторов.
G>>Как минимум нужно добиться одинакового понимания между людьми, тут уже возникает много разногласий ибо восприятие цветов, звуков, форм зависит не только от физиологии, но и от культурных особенностей и от банальных привычек и вкусов.
US>Таких споров полно и без цвета, звуков и прочих. Спорят про архитектуру, спорят про кодинг стайл, спорят про С++ vs. С и прочее.
Я не прокусы и привычки говорю, а про восприятие того, что должно облегчить понимание. Не будет восприятия — не будет положительного эффекта вообще.
G>>Другой вопрос — создание этой информации, где взять звуки, кто будет рисовать шрифты и как подобрать цвета? На это разработчики должны будут затратить время (!), причем гораздо больше чем будет сэкономлено на вникании в код, ведь после вникания эта информация будет приносить гораздо меньше пользы.
US>Опять ты пытаешься представить, как оно было бы.
Именно. Иначе пустой разговор.
US>Ты много чего не учитываешь.
Чего например? Я уже понял что пытаюсь учесть даже то, о чем ты понятия не имеешь покачто.
US>Могу поспорить, люди, которые в свободное от программирования время занимаются какими-нибудь творческими занятиями: рисуют, поют, снимают кино, музыку пишут и прочее — показывают в программировании куда более "красивые результаты".
Уууу, ты затронул самую непонятную тему "красивости результатов", вкратце — красивость относительна на 100%.
US>Мой программерский опыт показывает, что так оно и есть.
А мой показывает что умение программировать зависит от умения программировать.
US>Есть творческие программисты, а есть опытные шаблонщики. Это разные категории. А все из-за того, что творчеством, в полном смысле этого слова, стимулируется мозг. У других он просто-напросто со временем атрофируется.
Ну расскажи чем они отличаются.
G>>Третий вопрос — автоматизация работы с такой информацией. Мы часто пользуемся поиском с заменой, утилитами для диффа\мерджа — как они будут работать с такой информацией? Даже банальный рефакторинг — переименование переменной — должен будет учитывать дополнительную информацию (как сейчас умеет переименовывать в комментах). Вообще любое изменение кода потребует изменения этой метаинформации, что сильно затруднит поддержку.
G>>Четвертый вопрос — инструменты для работы с информацией. Например есть ide, где на одном экране несколько переменных, к каждой из них прикреплен звук, какой будет проигрываться в данный момент?
US>Хорошие вопросы. Я лично реализовывать такую среду не собираюсь, поэтому и голову на этими вопросами ломать не буду.
Любая идея без реализации ничего не стоит. Не готов воплотить в жизнь хотябы подмножество — разговоры ни к чему.
US>Просто хотел пообщаться на тему и поделиться своим видением того, как будет выглядеть программирование в будущем.
Алан Кей придумал ООП, в таком виде, в котором его никто не представлял, он не стал много философствовать, а просто воплотил идею в языке Smalltalk.
До сих пор идеи Smalltalk_а используются во многих языках.
US>>>>>Так же думали и программисты машинных кодов. Т.е. не было их вины в том, что их все устраивало. Их просто не интересовало то, как сделать свою работу более удобной. А может быть и интересовало, но они не знали как. G>>>>Еще раз, среды графического программирования провалились. ВСЕ. Изучи почему так, найдешь ответы на все вопросы. US>>>Мне интересно, с удовольствием почитаю. Буду благодарен, если поделишься ссылкой. G>>Я ссылки не собираю, ищи статьи по критике UML.
US>Предполагал, что ссылка будет на UML. Там, как я понимаю, упор делается на крадратики и стрелочки. Я же про образность информации говорю.
Ну возьми Use Case диаграмму с человечками Почитай критику UML, поймешь почему текст рулит.
Здравствуйте, Klapaucius, Вы писали:
K>...можно фиксировать электрическую активность речевых зон (Брока и Вернике) даже когда человек решает геометрическую задачу. И когда человек решает геометрическую задачу он посылает слабые сигналы на речевые органы.
Здравствуйте, artelk, Вы писали:
K>>...можно фиксировать электрическую активность речевых зон (Брока и Вернике) даже когда человек решает геометрическую задачу. И когда человек решает геометрическую задачу он посылает слабые сигналы на речевые органы.
A>Кстати, а что это доказывает?
По моему в данном случае речь параллельный паразитный процесс
Здравствуйте, UnseriousSam, Вы писали:
US>Давайте пофантазируем. US>Хотели бы вы, чтобы, например, заказчик предъявил требования в виде двухчасового художественного фильма?
Нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, sereginseregin, Вы писали:
S>В принципе, нет необходимости собирать код программы в текстовом редакторе из набора символов с последующим лексическим и синтаксическим анализом. ИМХО можно, наверное, собирать программу в ином виде, типа визуальные блоки-команды, которые сразу готовы к выполнению. Только редакторов подходящих нет — эволюция пошла не тем путем.
Ты всерьез считаешь, что проблема в отсутствии графических редакторов?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, UnseriousSam, Вы писали:
US>>Есть творческие программисты, а есть опытные шаблонщики. Это разные категории. А все из-за того, что творчеством, в полном смысле этого слова, стимулируется мозг. У других он просто-напросто со временем атрофируется. G>Ну расскажи чем они отличаются.
Творческий программист найдет хорошее решение любой проблемы, потому что умеет хорошо думать. Опытный шаблонщик знает только как решать несколько проблем. Новую проблему он не решит или состряпает кривое решение из тех шаблонов, которые успел заучить. Есть хорошая книга "Programmer's stone". Там только они называются картостроители и паковщики.
Здравствуйте, UnseriousSam, Вы писали:
US>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, UnseriousSam, Вы писали:
US>>>Есть творческие программисты, а есть опытные шаблонщики. Это разные категории. А все из-за того, что творчеством, в полном смысле этого слова, стимулируется мозг. У других он просто-напросто со временем атрофируется. G>>Ну расскажи чем они отличаются.
US>Творческий программист найдет хорошее решение любой проблемы, потому что умеет хорошо думать. Опытный шаблонщик знает только как решать несколько проблем. Новую проблему он не решит или состряпает кривое решение из тех шаблонов, которые успел заучить. Есть хорошая книга "Programmer's stone". Там только они называются картостроители и паковщики.
Творчество и умение думать не одно и тоже. Более того "творчество" в программировании обычно идет поперек здравого смысла.
Кроме того есть задачи где творчество только вредно, а нужно методично применять известные приемы для реализации. Бизнес логика корпоративных приложений, вебсайты, программирование UI обладает как раз такими свойствами.
Здравствуйте, UnseriousSam, Вы писали:
US>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, UnseriousSam, Вы писали:
US>>>Есть творческие программисты, а есть опытные шаблонщики. Это разные категории. А все из-за того, что творчеством, в полном смысле этого слова, стимулируется мозг. У других он просто-напросто со временем атрофируется. G>>Ну расскажи чем они отличаются.
US>Творческий программист найдет хорошее решение любой проблемы, потому что умеет хорошо думать. Опытный шаблонщик знает только как решать несколько проблем. Новую проблему он не решит или состряпает кривое решение из тех шаблонов, которые успел заучить. Есть хорошая книга "Programmer's stone". Там только они называются картостроители и паковщики.
Кстати, заметен творческий подход к логике.
Уменее решать проблемы это прежде всего следствие стимуляции мозга на тему решения проблем. А творческое вышивание крестиком влияет на способность решения проблем куда меньшее, чем общая физическая подготовка, если вообще влияет.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, UnseriousSam, Вы писали:
US>>Ссылок я тоже не собираю. Можно почитать Тони Бьюзена "Научи себя думать". Это книга про карты памяти. G>Это я читал, оно очень далеко от обсуждаемой темы. Хотя может именно этого ты и не понимаешь
В этой книге есть пример системы запоминания информации и про принципы, на которых она построена. Это как раз натолкнуло на мысль, что информация, которую мы передаем через исходные коды, должна стремиться соответствовать этим принципам. Поэтому разговоры про цвет, звук, образность и т.д.
Потом еще одна мысль хорошая, которую я в теме не затронул, что мы, когда что-то создаем, думаем от общего к частному. Программируем в том числе. Исходники так же не отображают этот процесс. Они как бы уже результат.
Здравствуйте, UnseriousSam, Вы писали:
US>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, UnseriousSam, Вы писали:
US>>>Ссылок я тоже не собираю. Можно почитать Тони Бьюзена "Научи себя думать". Это книга про карты памяти. G>>Это я читал, оно очень далеко от обсуждаемой темы. Хотя может именно этого ты и не понимаешь
US>В этой книге есть пример системы запоминания информации и про принципы, на которых она построена.
А с чего ты взял что исходник надо запоминать? Его надо понимать.
US>Это как раз натолкнуло на мысль, что информация, которую мы передаем через исходные коды, должна стремиться соответствовать этим принципам. Поэтому разговоры про цвет, звук, образность и т.д.
Ты еще не понял что создавать эту образность гораздо сложнее самого восприятия информации?
US>Потом еще одна мысль хорошая, которую я в теме не затронул, что мы, когда что-то создаем, думаем от общего к частному. Программируем в том числе. Исходники так же не отображают этот процесс. Они как бы уже результат.
Это смотря на чем программировать.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, UnseriousSam, Вы писали:
US>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, UnseriousSam, Вы писали:
US>>>>Ссылок я тоже не собираю. Можно почитать Тони Бьюзена "Научи себя думать". Это книга про карты памяти. G>>>Это я читал, оно очень далеко от обсуждаемой темы. Хотя может именно этого ты и не понимаешь
US>>В этой книге есть пример системы запоминания информации и про принципы, на которых она построена. G>А с чего ты взял что исходник надо запоминать? Его надо понимать.
Во-первых, я не писал, что исходник надо запоминать. Во-вторых, запоминание и понимание — две тесно взаимосвязанные функции мозга. Ты когда думаешь, ты оперируешь информацией, которую когда-то запомнил. Так вот чем лучше ты запомнил, тем проще мозгу оперировать информацией.
Здравствуйте, UnseriousSam, Вы писали:
US>В этой книге есть пример системы запоминания информации и про принципы, на которых она построена. Это как раз натолкнуло на мысль, что информация, которую мы передаем через исходные коды, должна стремиться соответствовать этим принципам. Поэтому разговоры про цвет, звук, образность и т.д.
Код не нужно запоминать, его нужно понимать. И строиться он должен именно на принципах облегчения понимания, а не запоминания.
US>Потом еще одна мысль хорошая, которую я в теме не затронул, что мы, когда что-то создаем, думаем от общего к частному. Программируем в том числе. Исходники так же не отображают этот процесс. Они как бы уже результат.
Значительная часть программирования сегодня это решение частных задач с помощью средств обобщенного назначения. И именно такой подход более способствует пониманию, чем наоборот.
