Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Вы поймите, что чем более общая точка зрения выбрана, тем более бесполезны суждения об объекте. Это происходит просто потому, что на достаточно общем уровне используемые абстракции чрезвычайно примитивны и просты, поэтому они обладают примитивными и простыми свойствами, и следовательно суждения об этих абстракциях тривиальны.
С этим не совсем согласен. Чем более абстрактная точка зрения выбрана с одной стороны эти абстракции действительно более примитивны, с другой стороны они применимы к гораздо большему числу сущностей (короче — гораздо чаще применимы) это повышает эффективность.
Эффективность от абстрагирования — это когда научимся делать одну вещь, и вместе с этим приобретаем много других скилзов, о которых даже не подозреваем.
LCR>Если суждения не открывают ничего нового, зачем на них переводить байты?
Тут говорили — могут ли помочь подобные тезисы(не обязательно именно эти) в програмировании. И как их использовать, ну выучили их и что дальше.
Если хочется конкретных рецептов — что с такими тезисами делать и как из них извлечь пользу, могу дать рецепт ... ИМХО'вый.
Запоминать их не нужно. В механической памяти (и в сочетании с механической логикой) они бесполезны и вредны. Их нужно загрузить в интуицию.
Примерный алгоритм загрузки их в интуицию:
Вдумчиво читаем каждый тезис, и пытаемся примерить его к своему опыту, чтоб на ум пришло побольше примеров из разных областей. Например что значит "Все гениальное просто.Надо стремиться к простоте." Каждый это понимает по своему. У каждого свои примеры из реальной жизни где простота оказалась гениальной.
...Затем после этого занятия, стараемся забыть нафик эти вычитанные тезисы.
А через некоторое время, когда на уме будут совсем другие проблемы и задачи. Снова также проходимся по этим тезисам, и забываем про них. Можно и запомнить их — но только чтобы не лазить каждый раз на форум за ними.
И так много много раз.
Через некоторое время интуиция сама их будет подымать в нужное время в нужном месте. Не требуя на это специальных усилий.
Но с этим главное не перестараться, не перемудрить. т.к. интуицию нельзя насиловать слишком жесткой и медленной логикой. Чтобы ее обучить нужно подкармливать примерами на абстрагирование. Т.е. идеальный вариант, большое количество примеров в которых изучаемая абстракция общая, а детали очень сильно отличаются. Если же эту абстракцию выразить словами и заучить, то это почти ничего не даст(интуиция ее не подцепит).
Изучаются абстракции не просто, но их знание крайне полезно, т.к. у них очень обширная область применения. Мышление такими абстракциями очень быстрое, доли секунды не напрягаясь — вжик и готово
А вобще это словоблудие можно заменить простым тезисом "Есть вещи которые лучше запомнить, а есть вещи которые лучше понять и постараться забыть (выкинуть из механической памяти чтобы не мешались, тк они уже совсем в другом виде хранятся)"
Если же захочешь рапечатать эти тезисы на листочке, повесить возле компа, и когда при написании программы возникнут затыки, глянуть в этот листок и вычитать там решение проблемы то нихрена там полезного не найдешь.
Рецепт использования этих тезисов сложноватый, но проще не получится.
Здравствуйте, MM_ASH, Вы писали:
M>>Лично я не провожу четкой грани между этими вещами. Для меня программирование, проектирование и отдых зачастую суть одно и то же Обсуждения часто выливаются во флейм. А почему обязательно с единомышлениками?
MM_>На счет единомышленников, конечно, еще можно и поспорить, а вот по поводу того, что нужно иногда прерываться, что бы понять что ты не тупишь и просто передохнуть, направить мысли на что-то отвлеченное, думаю спорить ни кто не станет.
Не только спорить никто не станет, но и буду настаивать что важно хорошо чувствовать когда нужно передохнуть. И критерий здесь даже не усталость...
Для принятия решений которые можно назвать стратегические, требуется более высокоуровневое мышление. Для технических деталей требуется краткосрочная память — информация в ней держится недолго но в больших обьемах. При черезмерном переполнении краткосрочной памяти, могут блокироваться другие виды мышления. И нужно периодически делать Reset.
Был реальный случай, когда один программер трахался с проблемой несколько часов в конце дня, все безуспешно. Потом забил, оставил на завтра и уже пошел домой. И через 10 минут прибегает обратно, радостный...говорит понял в чем проблема. И сделал все за 5-10 минут.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, MM_ASH, Вы писали:
M>Отлично! Давайте кто скорее доберется до Австралии? Я на самолете или Вы на телепортаторе?
Конечно же я, потому что решу проблему в корне и мне не нужно будет ехать в Австралию.
M>Это если ты решения не видишь Тут все зависит от конкретной ситуации. В большинстве бизнес-приложений возникают задачи технического характера. Строить общую теорию не надо
Не уверен. Есть еще новые мысли и новые тезисы. Например вот этот я не включил в концепцию, но планирую
"Для достижения результата у нас уже есть средства, их просто нужно увидеть и воспользоваться ими"
Так что когда решения нет, вместо того, что бы рыться в хелпах и мануалах, можно просто подумать а нужно ли это далать именно так...