Вот, поднял тему на PEDSOVET.ORG (http://pedsovet.org/forum/index.php?sho ... 612&st=300) - продублирую и здесь.
-------------------------------
...просто свежие личные впечатления: два года работал со способными старшеклассниками и довольно успешно, но при этом никак не мог "поймать" методику для стартовой постановки алгоритмики. Самый первый этап  - правильного построение циклов, простейшие схемы алгоритмов - проскакивали как-то интуитивно, на набивании руки и за счет способности детей. В этом году вел спецкурс для студентов - и кратко рассматривали алгоритмизацию уже с формальной точки зрения - с инвариантами, формальным выводом и т.п. И тут вдруг к концу года попадается педагогическая задачка - натаскать студентов, у которых в школе не было информатики толком вообще, и весь год изучения "Программирования на С++", которым их пичкали, - насмарку... У детей просто нет базы, а в результате - полный ступор и комплекс тупости при начилии, в общем-то, средних способностей. И ни один, ни другой подход из ранее мной применявшихся в этом случае, естественно, не сработал. Вовремя подвернулся под руку учебник А.Г. Кушниренко и др. 90-го года издания, с задачками на КуМире. Вот на этих-то задачках, и удалось поднатаскать ребят - используя модель команд Робота, правда, в сочетании с конструкциями Си (дал бы Паскаль, само собой, но им сдавать именно Си и уже скоро).
Честно говоря, я сам пожалел, что когда-то в школе меня не учили по этому курсу - т.к. на порядок меньше было бы самоучества и проб и ошибок тогда...

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

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

Продолжу свою мысль (и некоторые другие попутные мысли) на примере освоения конкретной темы - циклов. Естественно, умение строить циклы - это львиная доля умения алгоритмировать.
Если классифицировать циклы по категориям, то...

1) Циклы с фиксированным числов проходов (FOR).
Само собой разумеется, goto-рудименты навроде break/continue не рассматриваем, им не место в современных высокоуровневых языках, и ежли возникает назойливое желание где-то их использовать, значит, составление цикла начато неправильно.
Кстати, замечена большая проблема с FOR (особенно, когда break таки есть в языке и про него рассказано учащимся): школьники/студенты, имеющие уже опыт самоучек, начинают любой цикл прохода по данным (например, по массиву в сортировках) клепать с помощью FOR, затем обнаруживают, что нужно как-то выходить из цикла по условию - доклепывают break... И... И начинают лихорадочно соображать, что делать дальше и куда break-нуть еще...
Лечится: - использованием языка без break или умолчанием про break
- объяснением того, что FOR применяется только при фиксированном числе проходов (нельзя "спрыгнуть с поезда" в середине)
- программированием на начальном этапе вообще без FOR, на основе только WHILE, а затем ввод FOR как дополнительного "удобного средства" (Вирт в первом Обероне вообще исключил FOR, именно из этих соображений, потом его вернули для удобства).

2) Циклы c предусловием на основе базовых схем
а) полный проход (от начального состояния до конечного)
б) полный проход с фильтрацией внутри по условию или классификацией по нескольким условиям
в) линейный поиск
Отличительная особенность этих циклов - для их составления не нужно "искусства", это делается совершенно формально (выделяем из задачи начальное и конечное состояние для цикла, находим отличительную особенность конечного состояния, записываем условие окончания цикла, инвертируем в условие продолжения. В тело цикла ставим изменение, полезную нагрузку, в б) и в) формулируем дополнительно условие фильтрации/поиска). у выпускника школы все это должно происходить вообще на автомате, не задумываясь, как таблица умножения. Ибо в реальных приложениях эти циклы количественно составляют 70%, а в системном программировании - все 90%... Однако на деле такого знания не наблюдается, иначе на 4 курсе у студентов специальности "Системное программирование" не проявлялся бы описанный выше "синдром навязчивого FOR" там, где требуется просто применить схему линейного поиска... Поэтому уделять внимание этим циклам при начальном обучении нужно в первую и главную очередь. И вот как раз это и позволяет сделать работа с исполнителями - о чем чуть позже.

3) Более сложные циклы - связаны с преобразованиями данных, и преобразуемые данные одновременно входят в условие цикла. Чтобы грамотно и безошибочно строить такие циклы, нужно иметь понятие об основах формального доказательства алгоритмов - синтезе на основе пред/постусловий и инварианта. Эта тема выходит за рамки стандартного школьного курса (Хотя в физмат-профиле, я уверен, стоит ее давать. А в ВУЗе - вообще непременно и очень серьезно, т.к. большинство сегодня программирующих понятия о грамотном доказательном программировании вообще не имеют).
Таким образом, третья категория циклов - самая сложная. Научиться составлять такие циклы без знания соотв. теории - для новичка это действительно искусство (а если в дальнейшем в жизни он эту теорию не изучит, то может и всю жизнь пропрограммировать с убежденностью, что "умом тут циклы не понять", а можно только интуитивно методом тыка и пошаговой отладки. Пошаговый отладчик - отдельная песня. Если профессионально программировать можно - и в конечном счете лучше - без него, то уж при обучении он точно не нужен. Кстати, провел тест на давешних студентах: после многих тренировок на составление циклов на доске с мелом задал им вопрос - "Как вы думаете, при таком вот грамотном составлении алгоримтов нужен ли пошаговый отладчик?" - сразу получил дружный ответ "Нет".).
И обучать тут в школе можно только путем постепенного "набивания руки", на множестве задачек.
И успех в рамках стандартного курса не всегда гарантирован, это зависит от способностей и желания обучаемого (человек может быть способным в той же математике, но по чистой психологической случайности "стать в ступор" и так и не научиться программировать, если сразу начать с задач, где требуется такое "интуитивное" составление, миновав систематические тренировки с п. 2, который уж точно доступен большинству учащихся).

Теперь в связи с проведенной классификацией о достоинствах исполнителей вообще и кушниренковского курса в частности. Я уже отметил, что большая ценность в том, что алгоритмическое управление может быть изучено отдельно от обработки данных (кстати, здесь есть и глубинный смысл, т.к. задачи в программировании можно условно разместить на шкале с двумя полюсами - задачи на преобразование данных, превалирующие в прикладном программировании, - и задачи на управление, превалирующие в системном программировании).
И это позволяет очень эффектно решать проблему с обучением построению циклов. Пункт 2), который очень важен в начальной подготовке, и к тому же формален и потому доступен всем учащимся без исключения, может быть изучен и оттренирован в самом начале курса алгоритмизации - еще до изучения переменных, состояния, ввода-вывода и т.п. Именно так материал у Кушниренки и был расположен. И такое изучение создает некий фундамент для движения дальше, гарантию более или менее общего понимания темы на этот момент - и плюс уверенность учащихся в своих силах. К сожалению, многие задачи в том учебнике разобраны недостаточно подробно и отправлены на самостоятельное изучение, а ведь средний учитель с ходу не поймет, в чем их методическая ценность и на что там заострить внимание. А внимание в задачках учебника может быть заострено на важных мелочах - например, в каких случаях полезное действие выполняется столько же раз, сколько тело цикла с изменением, а в каких - на один больше и требуется его вынос до/после WHILE; как в зависимости от этого выбирается порядок тела цикла - действие до изменения или наоборот. Наличие или отсутсвие у исполнителя возможности заглянуть вперед (если работаем по стенкам - то есть. Если работаем по закрашенным клеткам - то нет. В последнем случае исполнитель всегда должен зайти в цикле дальше целевого состояния, а затем откатиться обратно). Очень интересно наглядно продемонстрировать учащимся роль наличия/отсутствия памяти у управляющего алгоритма. Переменных на первом этапе нет, алгоритм памяти не имеет - и "вот, ребята, смотрите, какая интересная проблема: мы не может запомнить, на сколько клеток ушли, чтобы вернуться обратно. Поэтому мы должны пометить путь и возвращаться по разметке". Ну и т.п.

Ну, с преимуществами исполнителей (а предложены они были для обучения, не будем забывать, академиком А.П. Ершовым) мы разобрались. А вот без их использования возникает реальная проблема. На самом первом этапе обучения, как только изучили циклы, надо решать задачи. Массивов и структур данных не знаем. Какие остаются задачи? Сугубо вычислительные, вариации на математические темы. Но эти задачи как раз-таки требуют составления циклов по типу 3), т.е. самых сложных. На самых первых шагах, только и зная как пишется конструкция цикла, ученик вынужден разбираться с темой, которую понять можно только набиванием руки на примерах, интуитивно. Что же удивляться потом низкому КПД и тому, что уверенность и желание пропадают? Как устроены первые главы большинства книг для освоения программирования с нуля на основе конкретного языка программирования? По одной схеме - объяснили конструкцию цикла, насыпали груду примеров, которые нужно долго разбирать, потом методом проб и ошибок составлять свои, пока оно само все в голове не сложится...

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

Кину небольшой камень в огород сторонников усердного натаскивания на олимпиадных задачах... Иногда получается так, что сильный олимпиадник не готов к практическому программированию - и не только потому, что жил в мире задач, довольно редко встречающихся на практике. А еще и потому, что слишком большой перекос получился в сторону интуитивного алгоритмирования в ущерб грамотности и техничности. Поэтому нужно не забывать и об этом... 70% кода программ будет иметь весьма тривиальное алгоритмическое содержание, зато будет определять по большей части надежность и безошибочность продукта (т.к. на сложные части больше внимания и сосредоточенности, меньше возможности совершить ошибку - а тривиальные места пишутся с рассеяным вниманием). И надежность как раз будет зависить от того, насколько натренирован "автопилот" базовых схем алгоритмизации. Больше внимания уделим этому в базовых курсах программирования в школе и ВУЗе - через N лет получим меньше сбоев в окружающих нас программных системах.

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