OberonCore

Пришла в голову мысль.
Вот мы говорим о необходимости постановки техники в программировании. Согласились с тем, что должны быть шаблоны-образцы использования языковых конструкций, которые надо "вбивать" в мозги программистов.
Но ИМХО гораздо важнее научить декомпозиции - без этого никакие шаблоны использования не помогут. А вот научить декомпозиции бывает значительно сложнее. Во всяком случае я постоянно сталкиваюсь с тем, что начинающие программеры не в состоянии разложить большое действие на ряд простых и поставить их в нужном порядке.
Как учить ТЕХНИКЕ ДЕКОМПОЗИЦИИ?
На черепашках?
У меня такие вопросы возникают потому, что у самого почему-то проблем не возникает,
и мне часто не понятно, а что может быть студиозу непонятно?

http://www.inr.ac.ru/~info21/troitsklic ... jetap6.htm

http://www.inr.ac.ru/~info21/

У меня одна большая сложность по сравнению с ФВ. У него - школьники-пятиклашки. А у меня - студенты 1-го курса. И в учебном плане просто нет места для черепашек. Если только менять программу одной-двух дисциплин.
И еще преподов научить этому подходу.
Но действительно, получается неплохо.
Правда нас учили в кодах Минска-22 писать вычисление формул. Тоже сильно помогает понимать декомпозицию.

Во-первых, 5-клашек учить гораздо труднее. Во-вторых, у меня есть весь спектр по аспирантов включительно.

Чтобы начинать говорить о декомпозиции, нужно иметь К ЧЕМУ декомпоновать.

Ну правильно! Формула - к последовательности команд Минска-22...
Но аспирантов вы же не на черепашках учите? Я так понимаю, что их декомпозиции вообще учить не требуется...
Кстати, а чем вы сайт пополняете? С помощью какого инструмента? Или ручками в html?

Info21, Каждый год слышим о 5-клашках, куда они деваются, чем они заняты перейдя в 6, 7, 8, 9 класс?

Учить ТЕХНИКЕ ДЕКОМПОЗИЦИИ не надо, это ведь одна из операций алгоритмизации задачи. Следовательно надо научить алгоритмизации.

Алгоритмизация нужна не только перед программированием, но и при организации любой деятельности.

В теме: Культурология языка Дракон 02 Июнь, 2008 http://forum.oberoncore.ru/viewtopic.php?p=15870#p15870

Обучению программированию обязательно должно предшествовать обучение алгоритмизации.

У меня в этом году в курсе несколько начальных занятий посвящено чисто алгоритмам, рисуемым на доске (ДРАКОН-схемой и рядом на КП), по разным жизненным примерам.
Впечатления - удачно. Сразу надо вводить понятие вспомогательного алгоритма - процедуры. Житейские примеры имеют то преимущество, что там можно показать эту "бесконечную декомпозицию": т.е. что любое действие можно рассматривать или как элементарное, или как реализованное процедурой, состоящее из поддействий.

Удалось даже понятие инварианта цикла понятно проиллюстрировать уже на этом этапе.

Ценно! Совпадает с практикой ФВ у пятиклашек - там тоже получилось, что процедуры надо вводить раньше циклов.

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

Они приходят в Байтик. Некоторые.

Черепашки тут не помогут. Лучше всего тут поможет опыт. Но опыт не в программировании.

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

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

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

Грубо говоря - так.

Таким образом, для старших классов и выше предлагаю писать определения (на доске, в тетради) без написания собственно программы. По началу. Скажем, одно практическое занятие в начале полугодия и одно в середине.

А черепашка здесь не поможет.

Вот такой макет. Пусть педагоги его рассмотрят и подкорректируют.

Погрешу, сдеру определение из википедии: Задача рисования черепашкой дома спокойно делится на рисование стен, окон, двери и т.п.

Гм... а если ввести возможность установить ограничения на уровень вложенности для составных операторов и длину последовательности операторов?

Под курс/набор задач можно подобрать величину опытным путём, и... пусть компилятор принуждает к декомпозиции...

Я дал более узкое понятие, соответствующее контексту.

А к определению из википедии у меня претензии. Почему научный метод? Им не учёные не пользуются? Что значит "серия задач"? Может, ситема для них - это набор элементов?

Подозреваю, там тоже дано частное определение.

Но компилятор отвечает за синтаксическую составляющую. А декомпозиция лежит на семантическом уровне.

Да, недодуманное определение.

А про тетрадь вместо клавы -- это тонко подмечено. Одна проблема: комп их прям как магнит притягивает. Очень трудно приучать к карандашу и бумаге.

В предложении говорилось об учебном компиляторе и специально подобранном наборе задач.

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

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