Здравствуйте, Геннадий Майко, Вы писали:

ГМ>IMHO, вполне можно сравнивать изменение техники программирования одного и того же студента с течением времени, наблюдая (или не наблюдая) изменение "хромоты" его кода, нет?

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

ГМ>C уважением,
ГМ>Геннадий Майко.

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

LVV>Практически в любой сфере деятельности (особенно в творческих профессиях) "ставят" технику. Особенно наглядно это видно у музыкантов и спортсменов.
LVV>Причем, совершенно очевидно, что у профи техника "поставлена" и это их РАЗИТЕЛЬНО отличает от любителей.
LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?

Тут вот аналогии проводили, которые навеяли вот это: Спецназовец Сергей Будюкин: «Мы не терминаторы, просто подготовлены чуть лучше других»

Финальный бой не забуду никогда. Тогда мне, еще мальчишке, объяснили, в чем разница между спортсменом и человеком, который прошел через настоящие боевые действия. Соперником был офицер, командир разведывательной роты из Рязани. Он нанес столь стремительный и сильный удар, что проломил защитную маску, закрывавшую мое лицо. Естественно, он и победил.

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

LVV>Это непонятно. Как это — непрерывно меняющийся? Техника, она на то и техника, что она на уровне подсознания работает. То есть постоянна.

А если техника базируется на предположении, что всё в мире меняется?

LVV>Кроме того, например, корпоративный стандарт кодирования сразу пресекает всякое "свободное изложение".

Правильный стандарт рекомендует, а не пресекает. А правильные корпорации понимают, что такие вещи как стандарт кодирования — это набор предпочтений, которые со временем могут меняться.

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

LVV>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!

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

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

LVV>>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!
IT>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
Не... В любой борьбе приемов — десятки.
И с другой стороны, может быть просто в программировании не выделены БАЗОВЫЕ приемы? А просто мешают в кучу приемы разного уровня?

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

LVV>И с другой стороны, может быть просто в программировании не выделены БАЗОВЫЕ приемы? А просто мешают в кучу приемы разного уровня?

Если их не выделили за 50 лет, то может нечего выделать?

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

LVV>>И с другой стороны, может быть просто в программировании не выделены БАЗОВЫЕ приемы? А просто мешают в кучу приемы разного уровня?

IT>Если их не выделили за 50 лет, то может нечего выделать?

А как же приемы стиля "китайского программирования" или "я вам, суки, помодифицирую" ?

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

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

LVV>>И с другой стороны, может быть просто в программировании не выделены БАЗОВЫЕ приемы? А просто мешают в кучу приемы разного уровня?

IT>Если их не выделили за 50 лет, то может нечего выделать?

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

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

IT>>Если их не выделили за 50 лет, то может нечего выделать?

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

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

Зачем учиться писать циклы — не понятно Какая цель? Циклы ради циклов?

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

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

LVV>>А это — обучение методом проб и ошибок! В боевых искусствах — совсем не так. Там проб и ошибок нет, там сразу ставят прием правильно!

IT>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.

Кха... Цикл, условие и подпрограмма.
Этого хватит на любую (кроме совсем уж экзотики) программу.

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

D>>Я думаю, они существуют, просто имеют исключительно учебное значение. Это как в начальной школе, когда учили детей писать буквы, использовали в прописях элементы этих букв — для постановки руки.
Я тоже так думаю. Только об уровне чуть повыше. То есть не отдельные элементы буквы, а буква. Цикл — это буква в программировании. И надо научиться правильно писать эту букву.
IT>Думаю, не существуют. В правописании и боевых искусствах понятна конечная цель упраждений. В боевых искусствах ученики повторяют за мастером чтобы поставить удар и научиться его применять. Палочки нужны, чтобы научиться из них составлять буквы и в конечном счёте писать.
IT>Зачем учиться писать циклы — не понятно Какая цель? Циклы ради циклов?
Затем же, зачем учатся наносить удар — чтобы применять.

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

IT>>Это потому что в боевых искусствах количество приёмов можно пересчитать на пальцах. Приёмы в программировании исчисляются совсем другими порядками.
A>Кха... Цикл, условие и подпрограмма.
A>Этого хватит на любую (кроме совсем уж экзотики) программу.
Это правильно. Но речь о дальнейшем разделении.
Я тут уже упоминал, что основных видов цикла — два: полный перебор и поиск по заданному условию. И техника написания этих циклов несколько различается. Например, я категорически не приемлю использование для поиска цикла for. Этот оператор как раз ПРЕДНАЗНАЧЕН для полного перебора.
Или вот для процедур могут быть такие правила:

Например:
— запрет иметь больше одного цикла в процедуре — речь о независимых циклах; вложенные... часто тоже надо в процедуру, а при обучении — всегда; но в ряде случаев, конечно, они необходимы по эффективности;
— запрет организовывать циклы на уровне вложенности глубже, чем 1 (т.е. IF WHILE ... END ELSE .. END — можно, а вот в более глубокие IF-ы фигачить уже нельзя; разрешение на 1-м уровне — из опыта, опять же, что часто какая-то охрана перед циклом бывает нужна; а вот если глубже — то уже явно надо делить логику);

Мне кажется — это очень хорошие правила при постановке техники программирования.

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

LVV>Я тут уже упоминал, что основных видов цикла — два: полный перебор и поиск по заданному условию. И техника написания этих циклов несколько различается. Например, я категорически не приемлю использование для поиска цикла for. Этот оператор как раз ПРЕДНАЗНАЧЕН для полного перебора.

Чушь! for не предназначен для полного перебора. Для полного перебора больше предназначен оператор foreach (кстати, как насчет операторов map, dolist, loop, foldr, foldl и т.д. или list comprehensions?). А for, раз уж на то пошло, изначально предназначен для того, чтобы производить некоторое действие заданное число раз. И то, что в низкоуровневых языках (типа С/С++) отсутствует оператор foreach, и его приходится эмулировать for'ом, не меняет предназначение for'а.

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

LVV>Или вот для процедур могут быть такие правила:
LVV>

LVV>Например:
LVV>- запрет иметь больше одного цикла в процедуре — речь о независимых циклах; вложенные... часто тоже надо в процедуру, а при обучении — всегда; но в ряде случаев, конечно, они необходимы по эффективности;
LVV>- запрет организовывать циклы на уровне вложенности глубже, чем 1 (т.е. IF WHILE ... END ELSE .. END — можно, а вот в более глубокие IF-ы фигачить уже нельзя; разрешение на 1-м уровне — из опыта, опять же, что часто какая-то охрана перед циклом бывает нужна; а вот если глубже — то уже явно надо делить логику);

LVV>Мне кажется — это очень хорошие правила при постановке техники программирования.

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

Здравствуйте, LaptevVV, Вы писали:
LVV>Мне кажется — это очень хорошие правила при постановке техники программирования.
А чем эти правила обоснованы?

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

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

LVV>>Я тут уже упоминал, что основных видов цикла — два: полный перебор и поиск по заданному условию. И техника написания этих циклов несколько различается. Например, я категорически не приемлю использование для поиска цикла for. Этот оператор как раз ПРЕДНАЗНАЧЕН для полного перебора.
А>Чушь! for не предназначен для полного перебора. Для полного перебора больше предназначен оператор foreach (кстати, как насчет операторов map, dolist, loop, foldr, foldl и т.д. или list comprehensions?). А for, раз уж на то пошло, изначально предназначен для того, чтобы производить некоторое действие заданное число раз. И то, что в низкоуровневых языках (типа С/С++) отсутствует оператор foreach, и его приходится эмулировать for'ом, не меняет предназначение for'а.
Те же яйца, тока вид сбоку. Под полным перебором понимается не только физические существующие элементы контейнеров, но и выполнение действий заданное число раз. Главное, что это — не поиск.
А>И это не говоря уже о том, что выделение только двух видов циклов и притягивание за уши всего остального к этим двум видам — несусветная глупость. С такой логикой и эти два вида можно свести к одному: "выполнение тела, пока условие не сработает".
Не... У нас же два основных квантора: для любого (перебор) и существует (поиск).
Если нужно истчо, то ничто не мешает нам добавить в нашей отдельной специфической задаче все, что считаем нужным. Но изначально-то учат только два: для любого и существует.
LVV>>Или вот для процедур могут быть такие правила:
LVV>>

LVV>>Например:
LVV>>- запрет иметь больше одного цикла в процедуре — речь о независимых циклах; вложенные... часто тоже надо в процедуру, а при обучении — всегда; но в ряде случаев, конечно, они необходимы по эффективности;
LVV>>- запрет организовывать циклы на уровне вложенности глубже, чем 1 (т.е. IF WHILE ... END ELSE .. END — можно, а вот в более глубокие IF-ы фигачить уже нельзя; разрешение на 1-м уровне — из опыта, опять же, что часто какая-то охрана перед циклом бывает нужна; а вот если глубже — то уже явно надо делить логику);

LVV>>Мне кажется — это очень хорошие правила при постановке техники программирования.
А>А мне кажется, что вы слишком узко мыслите (в рамках примитивного императивного низкоуровневого подхода), и придумываете себе (а что самое отвратительное, и студентов заставляете делать то же самое) какие-то жесткие вымышленные ограничения, не имеющие ничего общего с умением программировать. В результате безвозвратно ломаете людям мозги. Подумайте над этим.
Ко мне приходят уже с "поломанными" мозгами. А эти правила не выдуманные, а реальный многолетний опыт реального программиста. Который просто их так сформулировал.
И напомню вам принцип KISS — эти правила как раз отвечают этому принципу в полной мере.
И лучше СРАЗУ приучать чела следовать этому принципу, чем он на работе (как я в свое время) потом и кровью самостоятельно придет к тому же.

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

MC>Здравствуйте, LaptevVV, Вы писали:
LVV>>Мне кажется — это очень хорошие правила при постановке техники программирования.
MC>А чем эти правила обоснованы?
1. Принцип KISS — вы согласны?
2. Это реальный многолетний опыт реального программиста.
3. Посмотрите на Рефакторинг. Там неоднократно призывается уменьшать размеры методов, оставляя за методом ЕДИНСТВЕННУЮ задачу.
4. Это не абсолютный запрет. Если очень хочется — то можно. Но не нужно...
Если у вас много вложенных циклов в процедуре, то как раз есть смысл пересмотреть ее структуру с точки зрения рефакторинга...

Здравствуйте, LaptevVV, Вы писали:
MC>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>Мне кажется — это очень хорошие правила при постановке техники программирования.
MC>>А чем эти правила обоснованы?
LVV>1. Принцип KISS — вы согласны?
Нет. То, что ты предлагаешь — это требования к структуре программы, не учитывающие ее семантику. Эти требования всегда будут усложнять программу за счет появления в ней лишних сущностей, которые вводятся ради удовлетворения ограничений.

LVV>2. Это реальный многолетний опыт реального программиста.
Кого именно? Тут ведь rsdn — куда ни плюнь — в программиста попадешь.

LVV>3. Посмотрите на Рефакторинг. Там неоднократно призывается уменьшать размеры методов, оставляя за методом ЕДИНСТВЕННУЮ задачу.
Тут речь о задачах — т.е. семантике. Ты же накладываешь ограничения на структуру.

LVV>4. Это не абсолютный запрет. Если очень хочется — то можно. Но не нужно...
В чем тогда смысл правила? "Если очень хочется, то можно" — это, на мой взгляд, неудачная позиция. Правильнее определить допустимые и недопустимые варианты использования.

LVV>Если у вас много вложенных циклов в процедуре, то как раз есть смысл пересмотреть ее структуру с точки зрения рефакторинга...
Ты изначально говорил и про независимые тоже.

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

LVV>Не... У нас же два основных квантора: для любого (перебор) и существует (поиск).

И какое отношение эти кванторы имеют к циклам, а? Тем более, что математические высказывания зачастую содержат оба этих квантора: "для любого Х существует Y, такой что Z". Следуя вашей логике, это должно вылиться в цикл, который одновременно будет и перебором и поиском?

LVV>Ко мне приходят уже с "поломанными" мозгами.

Ну так надо их выправлять, а не ломать до конца.

LVV>А эти правила не выдуманные, а реальный многолетний опыт реального программиста. Который просто их так сформулировал.
LVV>И напомню вам принцип KISS — эти правила как раз отвечают этому принципу в полной мере.

Не всегда и не везде. И кстати, принцип KISS куда как более полезно рассказать, чем городить огород из правил, которые из него вытекают.

LVV>И лучше СРАЗУ приучать чела следовать этому принципу, чем он на работе (как я в свое время) потом и кровью самостоятельно придет к тому же.

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

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

LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев):
LVV>а) полный перебор;
LVV>б) поиск по заданному условию;
LVV>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так!
LVV>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск.

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

Обычно в ВУЗе циклы даются мимоходом — вот синтаксис, вот задача, вот экзамен.

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

Дык в том и то и проблема. Когда у человека нет техники, то про ООП и функциональщину можно забыть.

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

3>Мне это проблема представляется надуманной. Согласитесь, что как-то странно сначала учить технике на примере какого-то специального языка. Собственно зачем? Чтобы потом человек хорошо программировал в реальной жизни уже на реальном языке? Так не проще ли (и практичней) оттачивать технику на "боевом" языке.

Проще, да, преподавателю не надо учить чтото еще. А вот учащемуся придется преодолевать совершенно другую нагрузку.