Comments 23
Сегодня отчётливо понимаешь, почему в школах и университетах программирование стартует с древних бейсиков и паскалей, а не с более современных языков. И если раньше я думал, почему мы учимся на таком старье (в школе это были БК, в универе — 386-ые), то сегодня опять же понимаешь, что чем проще — тем лучше для обучения
Пробовал объяснять с помощью ящиков, но не видел понимания.
Пробовал показывать стакан с разными ручками, тоже не сработало.
Тут нужно что-то другое :)
Спасибо.
Абстракция "на ящичках" ломается вот таким примером:
int a = 0, b = 3, c = 5;
a = b;
c = b;
Console.Write(c);Если мы "вытащили" число из b и положили это число в a, то что случилось во второй команде?
Переменные и массивы, на мой взгляд, объяснить довольно просто. Переменные — ящичек, куда мы
У меня нет опыта преподавания, если не считать объяснения домашних заданий одноклассникам, лабораторных однокурсникам и объяснения всего остального, программирования в том числе, своему ребенку, поэтому мой подход возможно не всегда и не везде работает, но. Я считаю, что в таких объяснениях важнее не принципы и аналогии (ящички, карманы, ряд ящиков и т.д.), а проблемы которые решаются с помощью тех конструкций, которые надо объяснить. То есть идти от задачи. Я не помню точно с помощью какой аналогии я объяснял смысл переменной, кажется говорил как раз про коробку или ящик, но зато лучше помню как я объяснял необходимость переменной. Мы написали программу печатающую «Привет, Миша! Как дела». Чтобы программа могла потом напечатать «Привет, Маша! Как дела?» или «Привет, Петя… » можно переписать cтрочку в коде. И мы так сделали несколько раз. А можно передавать имя в программу. И вот это имя надо где-то хранить. И для хранения нужны переменные. Похожим образом показал пользу от циклов, которые позволяют не писать двадцать раз почти одинаковый код, рисующий картинку на экране (но сначала эти двадцать строчек все же написать и потом еще отредактировать, и ошибиться специально в паре мест) и так далее.
С программированием, правда, все эти объяснения пока на уровне пролета из одного уха в другое. Ребенок маленький еще и сам писать не пытается, только терзает вопросами, через плечо смотрит и говорит мне что делать (наверное у меня растет не программист а ПМ). Но с арифметикой я стараюсь использовать такой же подход и мне кажется, что это работает. Например, сложение в столбик получилось объяснить очень быстро потому что сначала у нас было много примеров на сложение двузначных чисел, которые сын пытался делать в уме и на пальцах. После этого смысл и польза столбика были очевидны. Мне кажется, если бы я сначала стал объяснять сам прием, то он бы спросил «а зачем? большие числа складывать? а это точно надо? никто ведь не просит пока»
Т.е. вы говорите о том, что нужно ученика научить его собственным опытом, чтобы он понял. Очень интересно, попробую. Спасибо.
Очень хорошо, что вы обратили внимание на такие проблемы, как медленная скорость печати и низкая внимательность. Они мешают как детям, так и взрослым в их первых шагах в мире программирования. При этом люди пренебрегают этими навыками. Нужно больше статей, которые обращают внимание на такие вещи. Поставил вам плюс за это.
В целом, спасибо, что сформулировали свой опыт и выставили его на всеобщее обозрение.
На мой взгляд, не нужно сразу бросаться на помощь в поиске опечаток. Лучше по кусочкам дать эталон, а потом превращать поиск ошибок в игру "найди 10 отличий". Почему в этом месте ошибка, а в этом — все работало?
Плюсы подхода к доске слабоваты. Ученик может быть и пишет сам. Но это частенько превращается в "написал под диктовку".
Записывать в плюсы то, что ученик двигается пока идет к доске, просто странно. Переменки с осмысленной разминкой дадут больше толку.
Запоминание кода "чтобы записать его на доске" скорее всего порождает еще пачку опечаток из за несовершенства человеческой памяти в целом. В итоге может получиться, что на доске придется разбирать такие ошибки, которых на самом деле не было.
Непонятно зачем судить о внимательности. Какие конкретно следствия у того факта, что некоторый ученик забывает точки с запятыми?
Я однажды присутствовал на занятии, где преподаватель вызвал ученика к доске и пытался вытянуть из него ответ. Со стороны выглядело как пытка из анекдота про эзотериков и диффуры
Группа математиков поймала эзотерика, утверждавшего, что все знания изначально есть в людях, и заставила его медитировать до тех пор, пока он не научится решать дифференциальные уравнения.
Содержание курсов напомнило рисование совы.
Сложилось впечатление, что автору было интереснее делать IDE с вышеописанными ограничениями, чем непосредственно учить.
Это нашло отражение и в целях обучения:
Лично для себя я выделил две основные цели, к которым иду с помощью курсов:
- создать удобный инструмент для создания простейших игр, понятный заинтересованным людям в возрасте от 10 лет;
- создать программу обучения программированию, позволяющая заинтересованным людям в возрасте от 10 лет самостоятельно делать простейшие игры.
Вольно или невольно, но автор вообще не ставил целью научить детей чему-то.
Да и вся статья не про "обучение", а про то, какая получилась IDE и какие возникали проблемы у ее пользователей.
Лучше по кусочкам дать эталон, а потом превращать поиск ошибок в игру "найди 10 отличий". Почему в этом месте ошибка, а в этом — все работало?
Попытки такие тоже были, но в ответ была лишь тишина, ибо ученики не умеют программировать, они не знают законы/принципы/правила.
Ученик может быть и пишет сам. Но это частенько превращается в "написал под диктовку".
Поэтому я отдельно подчёркивал о запрете подсказок учителя, однако, разговор учителя с классом лишь одобряется, т.к. иногда можно получить два разных мнения на то, как записать что-то. В таком случае выбор за учеником. На мой взгляд, именно этот самостоятельный выбор и ценен, т.к. ответственность на ученике, а не на учителе.
Записывать в плюсы то, что ученик двигается пока идет к доске, просто странно. Переменки с осмысленной разминкой дадут больше толку.
Курс занимает в сумме 20 часов: 10 дней по 2 часа на урок. Причём в курс ещё вклиниваются пару недель, когда в выходные либо праздники, либо каникулы. Успеть что-то за 20 часов в принципе довольно сложно, а если уменьшить их ещё и переменками, то врядли выйдет толк. С другой стороны, если эти переменки плавно встроены в тему конкретного урока и усиливают его, то, может быть, в них будет толк. Спасибо за мысль, попробую пошерстить Интернет на этот счёт.
Запоминание кода "чтобы записать его на доске" скорее всего порождает еще пачку опечаток из за несовершенства человеческой памяти в целом. В итоге может получиться, что на доске придется разбирать такие ошибки, которых на самом деле не было.
Учитель может помогать лишь через класс, а класс должен контролировать написанное на доске. Конкретно этот контроль работает на практики отлично, и вызывает немало смеха и положительных эмоций.
Непонятно зачем судить о внимательности. Какие конкретно следствия у того факта, что некоторый ученик забывает точки с запятыми?
Хороший вопрос, на который у меня пока нет ответа. Есть мысли, что усердность прямо пропорционально заинтересованности. Возможно, по оценке усердности есть смысл отсеивать перед началом курса.
Я однажды присутствовал на занятии, где преподаватель вызвал ученика к доске и пытался вытянуть из него ответ.
Насильно учителя не вызывали учеников, да и они сами не выходили, если не были уверены в себе. На практике либо кто-то в классе знает ответ, либо нет. Если нет, то… это как раз те случаи, когда объяснение не работает, поэтому я тут и пишу в попытке получить помощь :)
Сложилось впечатление, что автору было интереснее делать IDE с вышеописанными ограничениями, чем непосредственно учить.
Вольно или невольно, но автор вообще не ставил целью научить детей чему-то.
На самом деле, нет критерия "я научил учеников чему-то". Есть критерий "ученики более-менее самостоятельно могут использовать инструмент X для того, чтобы сделать Y". В прошлой статье за 2018-й год инструментом был Scratch, и игру ученики смоги сделать. В 2019-м году я попробовал свой инструмент, в котором я постарался убрать всё лишнее и мешаюшее процессу обучения вроде настройки окружения, установки зависимостей, сборки и т.п… Всё это получилось убрать, однако, в отличие от инструмента Scratch, где вместо языка программирования используются визуальные блоки, я хотел попробовать настоящее программирование на настоящем языке. Безусловно со своей архитектурой, т.к. эта архитектура тоже задумывалась как помощь.
На мой взгляд, возможность что-то уметь однозначно связана с инструментами, которые могут реализовать это умение. Использование своего инструмента как раз даёт мне возможность оставить лишь необходимый минимум без всего, что может быть нужно в работе, но лишь затрудняет обучение. Поэтому обучение и инструмент у меня неразрывно связаны.
Заставлять писать код ручками на доске — решение более чем спорное. У меня, например, без подсветки синтаксиса и автодополнения сразу -10 к интеллекту, что уж говорить про детей, которые только-только учатся.
Для первого занятия я подготовил 80 строк кода на JavaScript, распечатал их и раздал каждому. Каждый ученик должен был набрать распечатанный код в инструменте. Набором кода я преследовал две цели: узнать скорость набора текста учениками;
А это и вовсе какие-то дикие метрики. Набрать распечатанный код? Скорость набора? О_о
В общем, что-то подобное было у меня лет в 11 в школе с Паскалем — примерно такой же подход с доской и переписыванием кода, который я встретил стеной непонимания. Пришлось отложить обучение программированию на 5 лет, и только потом осознать, что вообще-то программирование это здорово и весело.
Спасибо вам за статью. Сам занимаюсь преподаванием и немного затрагиваю программирование. Очень интересно читать как вы преподаёт и с какими трудностями сталкиваетесь.
Желаю успехов.
Хотел ответить кратко, но это уже лонгрид. Может кому будет интересно.
Самая важная мысль: определитесь, вы хотите чему-то научить или заинтересовать? От ответа на этот вопрос зависит … всё! Это две совершенно разные цели с совершенно разными дорогами и сложностями.
Вы в статье часто употребляете слово «обучение», я исходил из этого.
Общие мысли.
Вы хотите за очень короткое время научить чему-то осознанному – это довольно трудная задача, причём здесь есть как минимум 3 больших подводных камня:
1) Вы пишете «дети 10-15 лет» — как раз в этом месте ОЧЕНЬ большая разница между детьми: и в восприятии материала, и в понимании, и в самостоятельности и тд.тп. (причём, это никак не исключает частного случая, что кто-то в 10 мыслит лучше, чем другой в 15. – но тогда нужен отбор или нечто подобное. Вести разноуровневую группу ещё более сложно.)
2) Цели и мотивация. Зачем они пришли к вам?
Опыт из жизни: однажды на кружок робототехники привели мальчика со словами «он бредит роботами, вы должны его взять». Взял. Действительно бредит. Рисует очень детальные красивейшие рисунки всевозможных роботов. Ни одной инженерной задачи в кружке не решил, но ходил долго и упорно.
Вывод: они все приходят с разными целями, и эти цели, зачастую, весьма далеки от вашей. Сейчас практически у всех детей цель — это хайп: я хочу быстрый и красивый результат. Заметьте, это сильно отличается от слов «я хочу уметь сделать быстрый и красивый результат». Встречаются дети, которые в чём-то хотят разобраться, а не просто «сделал и забыл», но это большая редкость. Это «хочу уметь сделать» появляется позже в более осознанном возрасте. (это ещё не упоминаю мотивацию «родители заставили» — отдельная песня)
В итоге: вы находитесь на вражеской территории. Они идут к хайпу, а вы их тайно ведёте к знаниям. :) Методы соответствующие: маскируем одно под другое, устраиваем соревнования «кто хайповее» но через знания и тдтп.
3) Очень важно понимать, что за ограниченный срок у вас не получится научить всех. Будут откровенно тормознутые дети (даже среди тех кто пришёл осознанно!), которым вы можете хоть 100 раз разными словами объяснять – бесполезно. И тут важно соблюсти некую «общую скорость группы» чтобы те, кто идёт вперёд не сильно тормозили. А кого-то придётся тащить как бесполезный балласт.
Основное правило урока: каждый ребёнок должен быть занят делом. А задача препода создать массу различных дел в едином русле обучения, и выдавать их детям в зависимости от уровня и текущих успехов. Классические ситуации: очень трудная задача = нечего делать, очень лёгкая задача – лень = нечего делать. Лучше всего иметь отдельные задачки тем, кто бежит вперёд – посильнее и поинтереснее, а тем, кто отстаёт – попроще. Причём задачки могут быть и «в бок» — не в основном русле программы.
Ещё из общего: очень понимаю вас с созданием собственного инструмента без заморочек, так как нет ничего хуже, чем тратить время урока на решение технических проблем с компами и тдтп. Но есть и обратная сторона медали – какова для них ценность освоения именно этого инструмента? Вопрос, наверное, не первого плана, но он есть.
«Для первого занятия я подготовил 80 строк кода на JavaScript, распечатал их и раздал каждому. Каждый ученик должен был набрать распечатанный код в инструменте.»
Занятие, кажущееся полезным, но сталкивающееся с суровой реальностью: они НЕ набирают текст (в обычной жизни), соответственно не знакомы с этим _типом деятельности_. С поиском опечаток – тем более. Новый тип деятельности требует тренировки. Тренировки довольно быстро убивают современную мотивацию «хочу быстрый и яркий результат». Общие мысли тут простые: делим на мелкие куски, причём после каждого куска желателен визуальный результат – «конфетка». Тогда это более-менее сработает. Но и не перебарщивать в целом. Кому-то можно выдавать частично готовый код.
«За шесть занятий мы — два преподавателя — осознали, что подход к каждому и погружение в частные опечатки/ошибки занимает времени больше, чем объяснение нового материала.»
Тоже сталкиваемся с этими проблемами. Опечатки – это мелочи, по сравнению с логикой работы программы. Опечатки – это то, что дети в состоянии найти и сами. Тратить время занятия на поиск опечаток преподами – очень расточительно. Я бы посоветовал делить на куски, и отдавать на самостоятельную проработку дома.
Про «события, реакции, функции, проверки условий и тдтп». Большинство программистов (и я в том числе) забывают о том, сколько бесконечных лет в наших головах счастливо и плодотворно живут названные и ещё десятки неназванных абстракций. Причём живут в чётком понимании как именно они функционируют, какие с какими можно соединить для получения сложных конструкций и тдтптдтп. Это огромный объём материала. Начинать сразу с таких понятий (событие, реакция) можно, но какова цель? С моей тз объяснять это надо после понимания обычного «потока исполнения программы». Причём объяснения строятся на осознании отличий от предыдущего более простого уровня.
Мы в нашей программе чётко разделяем, и явно задаём «парадигмы написания кода».
Опыт из жизни: приходилось сталкиваться с интересным явлением: дети считали, что программа это _цельный текст_ и робот/компьютер «читает его целиком на своём языке, и пытается понять, что ты от него хочешь». Понимания, что программа выполняется по шагам и можно это проверить-увидеть не было. (теперь это исправлено) При переходе на новую парадигму программирования тратится значительное время на объяснения и перестроение мышления.
Парадигмы: Лапша код, Лапша-код с ветвлениями/циклами, Функции и процедуры, Событийно ориентированные программы(+ ООП), Многозвенные приложения.
ИМХО. Сюда же отнесу бесполезность GitHub на данном этапе. Нужно сосредотачиваться и учить чему-то одному с контролем результата. Тратить время на правильные логины в гитхаб мне кажется расточительным.
они НЕ набирают текст
Да, имея намного более успешный опыт обучения с итерфейсом Scratch в виде "щёлкни здесь, перенеси туда", я уже задумываюсь о том, чтобы кардинально поменять инструмент в сторону визуального программирования в виде основы, а настоящего текста лишь для заданий со звёздочкой.
в наших головах счастливо и плодотворно живут названные и ещё десятки неназванных абстракций
Я тут скорее хочу найти такой набор инструментов программирования, который будет доступен и ребятам от 10 лет, и суровым мужикам (нам) для более серьёзной работы :)
Спасибо за дельные мысли!
Я в любой непонятной ситуации беру маркер и начинаю рисовать на доске, так что с доской полностью согласен! :)
Я преподаю школьникам (7-11 кл) С++.
Переменные, массивы я объясняю так, как есть. Рисую полосу, две черты по краям и говорю, что это участок памяти в компьютере. Потом в "выделенном участке памяти" я обвожу квадратик и говорю, что здесь лежит переменная (квадратик сверху подписываю). И все действия с переменными я объясняю по квадратикам! С массивами аналогично, только добавляю специфическую для С++ информацию. С таким подходом мне удается донести суть указателей, ссылок и т.п. (на необходимом для школьников уровне).
Обучение программированию 2019, или в поисках идеальной программы: Последовательность