OberonCore

попробовал сделать один урок со схемой ООД и серией задач.

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

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

т.е. идем по алгоритму отладки, натыкаемся на "проверку", ищем на листочках, как делать проверку и тд.
вроде просто.

на скорую руку сделал серию задач с ошибками синтаксическими.(надо лучше продумывать)

проверил на 8ом, 10ом и трех 9х.
фиаско полное.

0) подготовка материала: идея была простая, а реализовать оказалось сложнее. и схема и выжимка получились не фонтан. в схеме алгоритм кривовато выглядел. в выжимке несколько ошибок всплыло + коряво написано. в общем разрабатывать не так просто. от (не)качества схемы и задач кпд резко падает, неудачные схемы видимо к 0лю сводят.

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

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

3) были дети, которые уже пару программ сами писали, они на кресты ориентировались массово. кто занимался активно(до этого задания) выполнил задания мигом, даже 3и4 уровня сложности (там были часть элементов, которые не проходили). т.е. тем, у кого получалось ранее, эта задача легка и не нужна (они синтаксис впитали в процессе решения, а структуру задачи в листочках не прочитали тк не обращались к нему).

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

5) ступор от класса не зависит почти. в 10м чуть полегче.

Спасибо, поучительно.

На самом деле тема синтаксиса -- для взрослого тривиальная до незаметности -- у детей действительно вылазит.

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

Надо думать отдельно про синтаксис.

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

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

и так же для компа, только строже и правил побольше.


можно, во вложении схема и выжимка.
скорее пример, как делать не надо))
схема неэргономичная, непрдуманная. выжимка с ошибками разного рода.
одно пояснение: в выжимке многое прописано словами "МОДУЛЬ - служебное слово, сообщающее..." и тд. делалось вот для чего: во время чтения ребенок должен был проговаривать. написано словами, а не сокращениями, чтобы он верно читал (и мог прочитать).

Идея изложена здорово. Аналогия с выражениями - да, это и имел в виду под "рассказом". Само собой, формальным. Отсюда штуку вижу в том, чтобы проверять по стандарту синтаксиса. В общем, форм основных дать его две, наверное: РБНФ и синтдиаграммы. Эргономично, надо думать, второе. Тут такие вопросы возможны:

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

Вот перечисляем нетерминалы по ИЛИ (текстовому, схематическому - неважно), а почему так или этак, объяснения нет или оно нечёткое.
Да и для терминалов по ИЛИ тоже эргономично было бы объяснить, по каким основаниям выбирается каждый из них...

Важны также зависимости выбора в разных правилах, не подчинённых через вхождения. Скажем, от того, обозначен ли идентификатор как VAR, IN или OUT, кое-что ведь зависит... результат процедуры-функции м.б. не любого типа...

2. Бывает также недоопределение синтаксиса, тоже восполняемое разве что неформально. Так, синтаксис КомПаса проверил по "Искусству..." Потопахина (Приложение 4) - и обнаружил используемый, но не определяемый нетерминал StatementSequence... насчёт IdentDef надо догадываться (он только охарактеризован), что это вроде как ident, но в какой-то ситуации употребления... MethAttributes тоже вроде как не раскрывается...

3. Структуризация правил м.б. неудобной. Так, DeclarationSequence используется в модуле. А раскрывается в пункте про процедуру... т.е. подчинённую единицу... т.к. этот нетерминал используетсяи там. Воспринимая такую структуру, можно установить неверные отношения между её элементами... Для логичности всё "повторно используемое" хорошо бы выносить в самостоятельные пункты.

Это об эргономике определения. Ваши описания - это, можно сказать, "синтаксические таблицы". Интересно и д.б. наглядно. Тут тоже главное каждое понятие объяснить и связать с другими, наверное...

По Вашей ООД понятно, что это вроде технологической карты. Так себе и представлял. Тут какие возможности другие?

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

* организовать "полуторамерно" (подобно тексту программы), дабы лучше связывалось с предметной частью;
* записать в нотации структурных скобок, учитывая замечания Алмазова о циклах и о минимализме выразительных средств.

Оно так на схеме и сделано...

Б. Различные понятия, которые у Вас даются "вокруг" фрагментов проверки, можно организовать в словарь вроде представленных здесь: viewtopic.php?p=78188#p78188. Кстати, то, что словами - может, и правильно для школьников?..

В. Всю проверку можно представить как процедуру (систему процедур) по схеме из А. Тогда словарь можно даже считать "предметной переменной", передаваемой в эту процедуру...

И вообще можно попробовать изложить ООД как квазипрограмму на КомПас-подобном псевдокоде... В качестве предмета для проверки заодно...

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

Может, чего и сгодится...

Интересный опыт. Попробуем на первокурсниках...

Да, это м.б. паттерном для разных заданий как техопераций. Имею в виду документ во вложении. Разумеется, форму можно развивать.

Насчёт схемы и эргономики ещё такие мысли в связи с этим.
1. Для "проговаривания" порядка деятельности м.б. важно не добиваться предельной "упаковки" маршрутов по Ермакову-Жигуненко. Попросту - прежде всего без "объединений", хотя бы при этом и дублировались какие-то шаги. Т.е. запретить себе все операции исчисления графа маршрутов, кроме "ввода атомов" (кои все д.б. тоже "распакованными", составные имеются в виду). А м.б. ещё эффективней - развернуть в дерево "юзкейсов", только оставив свёртку циклов, примерно как здесь описано.
2. Синтаксис программы как системы (целого, состоящего из процедур) задаёт ведь не всегда только линейные передачи. Отсюда вопросы, кои vdimas поставил здесь: viewtopic.php?p=73812#p73812. Вот это бы научить проверять...

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

Тогда учням можно сразу объяснять: "Вот, дети, вообще-то правильно (для развития будущего инженера, как дядя Илья в своём докладе говорил ) всякую схему процедуры записать и на текстовом ЯВУ. Но такую схему на КомПас не переложишь, потому что видите, вот тут и вот тут бяка." Ну и показывать, как убираются откровенные макароны и скрытые на НЦ/КЦ, КОН...

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

Почему тривиальная? Первый же затык возникает сразу: как соотносятся имена модуля и файла его содержащего. Содержит ли файл один модуль или же может содержать их несколько? Если один, зачем тогда словечко module? Что значит конструкция begin-end после модуля и куда совать определения процедур, а куда тут-же-исполнимый код. Порядок загрузки-выгрузки. И зачем вообще этот синтаксис нужен...Это даже взрослого в тупик поставит, если ему не дать документацию. А детишкам нужно как-то объяснить концепцию модуля, и то, как запустить программу на исполнение. В паскале словечко programm было понятно и без этих деталей, а запуск осуществлялся по одной клавише. Про бейсик и говорить нечего: пиши в любом месте PRINT "ку-ку" и все. Не факт что дети задают себе эти вопросы, но то, что это повод для выпадания в ступор - это точно. Ученик должен заходить в среду и писать :
> ? 1+2
3
Как это, например, было в Рапире. Про go-to в школе тоже отдельный разговор. Построение курса может стать гораздо увлекательнее, если разбирать со школьниками способы реализации циклов и процедур и проч. с помощь того же goto. - Дети как сделать то-то и то-то?..а затем уже говорить: а вот для этого, нехорошие но правильные дяди, придумали слово Loop. Так убивается сразу много зайцев: демонстрируется сугубо "машинный" подход, с ячейками и переходами, а получение информатических познаний становиться в параллель историческому развитию этих тем. Более онтологичным рассматриваемым вопросам. Излагать же все эти темы по отдельности не представляется возможным из-за малого количества часов. Технически тоже получаем удобство - изложить loop-цикл, как идею, можно не таща за собой все последующие исторические наслоения структурного подхода. Их естественнее включать в изложение в естественном порядке. Т.е. от частного к общему. Дети тормозят из-за обратного подхода, требующего развитого абстрактного мышления и рефлексии.

Что бы потом, оказавшись в другой языковой обстановке эти дети изъяснялись, как "герболайф" - сектанты на своих сборищах: "- Мы рады теперь приветствовать вас всех тут сейчас, ура!".
Это ни есть:

Это есть бояться синтаксис.

От того что слово goto заменили на слово call, мало что изменилось( кроме состояния стека ). Зато вылезла на поверхность целая "концепция" и сразу всем стало ясно, что рекурсия - это совсем не цикл с меткой.
Пусть попытаются внятно объяснить, чем:

goto proc
N:
...
proc:
...
goto N

отличается от

call proc
...
proc:
...
end proc;

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

push p1:push p2:push p3:mt=N:goto proc
N:
...
proc:
...
pop p3:pop p2:pop p1:goto mt

Соответствующее:

call proc( p1:p2:p3)
...
proc( p1:p2:p3)
...
end proc;

Три буквы разницы, а шуму на все ивановскую. А детям будет интереснее понять: как было и почему именно так стало. И с указателями бы прояснилось. Что оно такое, что есть адрес, а что есть указатель. Как работает new-dispose и зачем оно вообще нужно.

Т.е. на вот этом простом примере:

ПОЛОЖИТЬ p1
ПОЛОЖИТЬ p2
ПОЛОЖИТЬ p3
СЧКОМ=МЕТКАВОЗВРАТА
БП ПРОГ
МЕТКАВОЗВРАТА:
...
ПРОГ:
...
СНЯТЬ p3:
СНЯТЬ p2:
СНЯТЬ p1:
БП СЧКОМ

дитя получает представление, как минимум: о стеке и его важности в программировании, о процедуре, о счетчике команд, о передаче параметров по значению и ссылке, о локальных переменных процедуры, о способе реализации концепции процедуры. А так же о важности структурного подхода и о том, почему лучше использовать: procedure(p1;p1;p3;var p4)..
В противном случае все эти конструкции в сознании дитя - повисают в воздухе.
Используя массивы для организации структур данных, можно дать: концепцию указателя, удобство использования структур в противовес только длишь массивам, технику распределения и освобождения памяти, сущность кучи. Необходимость модульности. Т.е. вплотную подвести дитя к концепциям Оберона, продемонстрировав при этом несостоятельность оператора Goto, через реализацию на его основе, алгоритмов и структур данных.

Или же еще лучше:

УПРЯТАТЬ(p1,p2,p3,СЧКОМ+2): ИДИ ПРОГ
...
ПРОГ:
.НЕЛЬЗЯСТЕК
. ...
.МОЖНОСТЕК
ИЗВЛЕЧЬ(M,p3,p2,p1): ИДИ M

Или еще лучше:

ДЕФОПР CALL[<>,NAME]->МОЖНОСТЕК:УПРЯТАТЬ(<>,СЧКОМ+3):НЕЛЬЗЯСТЕК:ИДИ NAME
ДЕФОПР ENDPROC[<>]->МОЖНОСТЕК:ИЗВЛЕЧЬ(<>,M):ИДИ M

CALL[p1,p2,p3,NAME]

NAME:
....
ENDPROC[p1,p2,p3]

ЕСЛИВДРУГ[NAME, ВЫР,<КОРТ1>,<КОРТ2>] ->УПРЯТАТЬ(NAME): ИДИ <КОРТ2,NAME>[(ВЫР ИЗ <КОРТ1>)]
КОНВДРУГ -> УПРЯТАТЬ(ИДИ ИЗВЛЕЧЬ())
КОНЕСЛИ-> ИЗВЛЕЧЬ():ИДИ CЧКОМ+1


ЕСЛИВДРУГ[Бабай_пришел,(ДА),<ТОННАЖ ИЗ <1:10>,ВИДБАБАЯ<30,ВЕКО="ОПУЩЕНО">,<МАЛЫЙ,СРЕДНИЙ,ВИЙ>]

....
MАЛЫЙ:
....
...
КОНВДРУГ
...
СРЕДНИЙ:
...
...
КОНВДРУГ
...
ВИЙ:
...
...
КОНВДРУГ

Бабай_пришел: КОНЕСЛИ

ДЕФОПР ГЛЯНУТЬЧТОТАМ->УПРЯТАТЬ(ИЗВЛЕЧЬ())
ДЕФОПР ПОКАЧТО[NAME,ВЫР]->ИДИ УПРЯТАТЬ(<1+СЧКОМ,NAME>[ВЫР ИЗ <ДА,НЕТ>] )
ДЕФОПР СЛЕДУЮЩИЙ->ИДИ <1+ИЗВЛЕЧЬ(),ИЗВЛЕЧЬ()-1>[(СЧКОМ=ГЛЯНУТЬЧТОТАМ) ИЗ <ДА,НЕТ>]

ПОКАЧТО[БАБАЙ_НЕ_ПРИШЕЛ,ВЕС_БАБАЯ=0]
...
БАБАЙ_НЕ_ПРИШЕЛ:СЛЕДУЮЩИЙ
Т.о.в нашем школьном языке "Бантик" все структурные конструкции четко определены и отделены друг от друга. Напр, при вызове процедуры:

КАРТ=<1,2>
CALL[p1,p2,p3,NAME]

NAME:
<p1:p2>=КАРТ
p3=4;
....
ENDPROC[p1,p2,p3]

Каждый видит, что p1 и p2 - параметры переданные по значению, а p3- локальная переменная.
Мощность и познавательная ценность "бантика" невообразимы: мы можем вызывать ENDPROC в любой точке, даже до вызова самой вызываемой процедуры, сколько угодно раз. Все структурные конструкции определяются в отдельном месте и преинтерпертируются на стадии предкомпиляции. Все соответсвующие друг другу операторные скобки могут свободно располагаться в любом месте программы, в любом порядке, и вызываться независимо друг от друга. Дитя т.о. может, руководствуясь указаниями старших, само убедиться во всей силе "структурного" и какого угодно программирования.

А если серьезно, то я бы удавился такие картинки смотреть, будучи пионэром.

Дык и я где-то о том же - что за счёт "чересчур плотной упаковки" имеем необходимость распаковки читателем... Кстати, а "Бантик" реализован?..

А, так это типа языка микроопераций... например, такого, как тут описан?..