Pull to refresh

Comments 27

Планируете выложить наработки на GitHub или подобный сервис?

Чем ругать чужой учебник, проще написать свой — лучше конечно

Ну по python я и написал свой, посмотрев, как не надо) java мне не настолько интересна, чтобы найти время и силы

Я, возможно, окажусь непопулярным, но типы данных, антипаттерны и "дихотомия" это чтобы возненавидеть программирование. Я так понял, что про ООП пошло после 6 часов первой главы (12-13 по полчаса). Не надо так


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

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


Второе, я как раз делаю так, чтобы в моём мини учебнике не было антипаттернов в коде, это может не упоминаться в тексте к коду напрямую, тем не менее может приучить к хорошему


Ну и по поводу дихотомии, так несправедливо поставленной, Вами в кавычки, очевидно, что с учениками помладше я такой терминологией не пользуюсь, а вот постарше (15-17), если им просто интересно, хотя бы новые слова узнавать, то почему бы и нет


ООП естественно объяснялось не досконально, а достаточно поверхностно, чтобы заложить базовое понимае, для лучшего усвоения объяснялось на примере создания консолькой мини игры

Если начать с типов данных — скукота будет несусветная. Больше практики. Больше примеров. Причем, и примеров, на которых разбираются ошибки.

1. Пишем hello world
2. Пишем 7 раз hello world
3. Вот можно и цикл объяснить

И, кстати, писать игру гораздо увлекательнее, чем разбирать синтетические и скучные примеры ооп. Вот на примере врагов (класс) делаем много соперников (экземпляр класса) которые могут двигаться (методы)… ну и так далее. Где-то видел очень толковый туториал на 14 глав по pygame.

Про типы: их можно объяснять по разному, я не отказываюсь от hello world в консоль на первом занятии, так как традиция)


Типы я объяснял так: идёт глава, например, про итерируемые типы, вместе с ними или в след главе я даю циклы, то есть типы и конструкции языка, как бы чередуются ну и естественно в конце занятия мин. 5 небольших практических заданий. В конце первой части проект, на выбор. Про ООП написал коммент выше.


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

Как вы понимаете, что студенты усвоили итерируемые типы, если они циклы еще не изучали? Почему не наоборот?

Это может шокировать, но итерируемые типы != циклы, поэтому под пониманием итерируемых типов, я понимаю усвоение базовых методов, например, есть задание: в коде задан список students — ученики в классе, приходит новенький John, добавьте его в конец списка.


Эти две темы идут одна за другой, поэтому я не считаю, что это как то портит впечатление или мешает усвоению

Поддерживаю. Нужно больше практики, больше примеров и меньше долгих разговоров о теории.


Но конкретно про циклы добавлю


  1. Пишем hello world
  2. Пишем 7 раз hello world
  3. Вот можно и цикл объяснить

Это не самый удачный вариант начала объяснения циклов. В первом примере счетчик должен выводиться на экран. Про объяснение циклов у меня целая статья есть.

Циклы разные и нужны для разных задач. И совсем не всегда нужен индекс.
for name in ['Masha', 'Mike', 'Alex', 'Olga']:
	print "Hello " + name
Зачем тут индекс? Просто перебираем все имена и приветствуем людей.

Заодно рассмотрим вариант с индексом.
names = ['Masha', 'Mike', 'Alex', 'Olga']
for i in range(len(names)):
	print str(i) + ". Hello " + names[i]
Тут и код более громоздкий, и приведение типов. Да и просто для обычного списка и для такой задачи больше подходит 1-й вариант. Для чтения файла построчно удобно использовать while. При обучении как раз надо объяснять разницу «что и для чего».

В действительности, я, например, сначала показываю ученикам первый "тип" цикла фор на уже изученных списках, а потом показываю for с range, объясняя, что по сути это одно и тоже, и если не вдаваться в определение генератора, то для простоты понимания можно им показать, как range спокойно конвертируется в список и цикл точно так же по нему может идти, давая нам индесы

Хотя, например, я объясняю, что строковый тип данных можно складывать, вместе с этим говрю, что лучше использовать форматирование

Именно. Следующий пункт про форматирование очень уместен. Чтобы понять «что лучше», надо также показать «что нехорошо».
Зачем тут индекс? Просто перебираем все имена и приветствуем людей.

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


В таком варианте подачи люди начинают воспринимать эту конструкцию как единый неделимый иероглиф. Эта проблема становится особенно заметна при усложнении условия задачи хотя бы до FizzBuzz.


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

Согласен, 7 раз вывести в цикле, не тоже, что перебрать список. И в принципе, неважно, с какого цикла начинать объяснение.

Я больше про то, что часто удобнее «плясать» от задач, и сразу делать практику, а уже потом объяснять что есть индексы, типы и пр. Причём, надо разбирать и плохие практики, и потом их рефакторить. Теория очень быстро забывается. Практика остаётся на кончиках пальцев.

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

Любопытно узнать, что именно вы называете "типами данных" и "антипаттернами в коде".
Я правильно понимаю, что у вас всего одно практическое задание на первую половину учебника и оно в конце?

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


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

Я понимаю, что на Хабре в комментах полезной информации бывает больше, чем в статье. Но возводить это в правило считаю плохой идеей. Не могли бы вы добавить разъяснение по моему вопросу в тексте статьи?

Конечно, как до комухтера доберусь)

5-й год преподаю в школе по совместительству (вообще я пишу на Си под Linux всякие low-level и high-load вещи и прошивки для FPGA), учу детей в маленьком центре дополнительного образования в Подмосковье.


  1. Большинство этих центров — шлак, который работает по той же системе, что развлекательные бизнесы (а родители думают, что за деньги получат лучший результат, чем в школе). Особенный треш — кружки робототехники — после них никаких систематических познаний ни в механике, ни в программировании у 99% детей нет — просто хорошо поиграли в чужой Лего за деньги, на которые можно купить свой. На хороших кружках робототехники действительно учат основам программирования на базе Scratch-подобных графических языков, рассказывают про зубчатые передачи, ремни и пр., готовят к НПК. Но уложить и то, и другое за ограниченное количество занятий очень сложно.
  2. Тех, кто даёт детям, начинающим изучать программирование с нуля, ООП нужно больно бить чем-нибудь тяжёлым. У среднего семиклассника проблемы с отрицательными числами и напрочь забыта Декартова система координат, о том что такое уравнение, выражение и переменная в математике у него самое смутное представление. Они долго и трудно въезжают в алгоритмическую конструкцию "следование" — понятие переменной, как чего-то, что хранит состояние, операция присваивания — это просто взрыв мозга для значительно числа детей 7-9 кл., которые до этого не видели программирования. Если начинать с нуля, то при занятиях раз в неделю с не самыми тупыми детьми можно начинать разговор о ветвлении через месяц-полтора, а о циклах — через три. О массивах — через полгода. Это хороший темп для детей чуть выше среднего.
  3. Легче всего забыть насколько же мы все были тупыми в их возрасте. Труднее всего не позволять себе гнать вперёд, чётко контролировать настоящие знания каждого (т.е. то, что он/она может сделать сам, без подсказок, подглядок и помощи товарищей)
  4. Группа должна быть до 15 человек. Если преподаватель хороший, то он даже при таком размере может обеспечить более-менее индивидуальный подход.
  5. ДОЛЖЕН БЫТЬ ОТБОР. Нельзя сажать вместе "нулевых" и тех, кто уже ходил на районную олимпиаду, только писал на Pascal. Главная тайна всяких гарвардов и пр. "элитных" вузов: средний уровень поступающих — определяющий фактор успеха. С сильной группой можно вести разговор на совершенно другом уровне. Я бы сказал, что сильная группа вытерпит даже не очень хорошего преподавателя, а слабая группа не достигнет ничего даже с очень хорошим.
  6. Начинать нужно либо с простого функционального языка типа Scheme (но никто сейчас так не делает, даже я только мечтаю), либо с простого процедурного языка или поддерживающего эту парадигму типа Pascal/Python/Go/Javascript или даже C. Java/C#/С++ — плохая идея.
  7. Вы вряд ли придумаете более хорошую программу, чем уже выстрадана хорошими учителями ещё с советских времён. Зайдите на сайт Полякова (автор учебника), скачайте пару учебников, если у вас есть минимальный опыт преподавания, то вы не будете смотреть на блок-схемы и последовательность простая арифметика — простой ввод/вывод — ветвление — циклы — массивы свысока.

Как опознать говённый кружок для детей:


  • выйти на контакт с преподавателями до оплаты нереально — с вами разговаривают девочки на телефоне, которые назойливо и подлизываясь впаривают товар, при этом не могут поговорить по сути
  • в группах сильный разброс по уровню (на этапе созвона можно спросить про разброс возраста — если мнутся или говорят, что он больше 3-х лет — сразу до свидания) — да, когда нужно срубить бабла, а народу мало, то 11-классник садится рядом с 7-классником и у них разная скорость освоения материала, потому что какой бы говённой ни была математика в школах, мозги всё-таки как-то растут, в итоге либо одному скучно, либо другой на грани истерики от непонимания
  • мало практики, нет хорошего домашнего задания каждую неделю, а сами занятия проходят в формате бла-бла-бла у доски или "смотрите как я умею" с трансляцией экрана и просьбой набить то же у себя
  • с вами никогда не спорят (Ваш Вовочка из 7-го Б хочет программировать игры на C# под Unity? Никогда до этого не программировал, а в школе информатики не было? Но ведь… Всё равно хочет? Ну хорошо, приходите). 99% родителей далеки от тематики образования, сами зачастую школу не любили, и не понимают, что четвёрка по математике превращается в тройку по физике в следующем году и пр.


P.S. Министерство образования должно быть распущено в полном составе, вплоть до районных управлений образования. Эти люди просто не нужны. Хорошие преподаватели лучше их знают что и как преподавать, на плохих никакой управы нет, а всё остальное, что имеет значения — это зарплата и помещения.

Начну со второго пункта, так как с первым в принципе согласен :)


  1. Внимательность прочтения статьи у некоторых людей, просто поражает (бить в таком случаи нужно этих людей). До БАЗОВОГО введения в ООП идёт 40 (!) часов практики и теории (не только по программированию, но и по математике, которая понадобится при освоении материала, у меня так!) + дз + контроль и разбор непонятных тем, по поводу раписываемых темпов, вообще промолчу, видимо, хоть я так и не хочу думать, нам попадались разные дети.


  2. Собственно, что я и смог сделать, поставив себя на их место.


  3. Тут тоже согласен, об этом я и пишу в статье.


  4. Когда я сделал курс по Python, ещё до учебника, то я сделал базовое тестирование, где, например, были вопросы и задачи про переменные, да и вообще необходимым основам алгебры и арифметики.


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


  6. Скажем так, моя программа (особенно в первой части) основана на базовых понятиях языка (числа, ветвления, итерируемые типы, циклы), чтобы ученик понимал, как можно использовать для решения определённых задач изученные типы и как можно их обрабатывать. "Вы вряд ли придумаете более хорошую программу, чем уже выстрадана хорошими учителями ещё с советских времён." — отсылка к лучшему в мире советскому образованию не котируется, так как помимо всех прочих вопросов, например, почему после распада люди с ТЕХНИЧЕСКИМ ВЫСШИМ побежали заряжать воду от телевизора, есть ещё очевидный момент быстрой изменчивости, как самих языков, так и их парадигм, вводящих новые понятия в программирование. А по поводу смогу ли я придумать или нет — решу сам и практика преподавания по моим материалам (спойлер: регулярно интересуюсь и сейчас всё хорошо)



Про мин. просвет согласен, так как в текущем виде понятие преподавательского эксперемента и свободы программы всё больше убивается ФГОСами, что совершенно недопустимо, хотя казалось бы после ввода ЕГЭ...

  1. Да, действительно про 40 часов я упустил, извините. Но я и не видел свой список как критику изначального поста, скорее появилось желание резюмировать.
    Ещё один момент заключается в том, что в случае обучения с полного нуля каждый лишний кусок информации — плохо. Особенно плохо, если в самом начале требуется делать много "магии": ты сейчас не поймёшь, просто запомни. Когда в самом начале детей сажают в IDE с интерфейсом авиалайнера, они создают папочки "проектов", когда нельзя просто вывести на экран 2+2, а нужно написать


    #include <stdio.h>
    int main( void ) {
    printf("%d", 2+2);
    }

    то это реально путает и пугает. Именно поэтому начинать с Java или C#, где шагу нельзя ступить, не создав класс (аналогичный по непонятности и многословности кусок получается), неправильно. И именно в этом плюс Python для обучения. Там можно просто написать


    print(2+2)

  2. Это далеко не только мой опыт. То, что уровень поступающих — ключевой фактор, понимают очень много людей. Неспроста многие рейтинги вузов одним из главных факторов берут баллы ЕГЭ поступающих.


  3. Я имел в виду лучших представителей преподавательского сообщества, а не всех подряд. Посмотрите на списки победителей и призёров олимпиад по информатике Московской области: Дубна, Мытищи, Долгопрудный, Королёв. Вот в таких местах концентрируются талантливые дети (ученики всяких там лицеев при вузах, интернатов и пр., дети работников этих "наукоградов") и соотв. преподаватели. И опять же — я когда писал, то не критиковал напрямую вас — это далеко не первая статья на хабре про эти проблемы и это первый раз, когда я такую статью прокомментировал, поэтому отвечал сразу "облаку воображаемых адресатов". Надо было быть точнее в формулировках.


Особенно плохо, если в самом начале требуется делать много "магии": ты сейчас не поймёшь, просто запомни. Когда в самом начале детей сажают в IDE с интерфейсом авиалайнера, они создают папочки "проектов", когда нельзя просто вывести на экран 2+2, а нужно написать

На мой взгляд, написать пару шаблонных строк для базового оформления программы не так уж страшно.
Настоящий ужас происходит когда человек решает позаниматься, скачивает, например, visual studio code и для того, чтобы сделать простой проект, ему нужно поставить пару плагинов, написать в PATH какую-нибудь штуку и запустить магическую команду в командной строке.
Ну или как у меня на домашнем компьютере недавно случилось. Решил я поставить питон для тестов на селениуме. Казалось бы, вот самый простой язык, который всем рекомендуют для начала. Пробую запустить интерпретатор, а он выдает 0x000005 при запуске. Пришлось разбираться, почему он не видит системные библиотеки и решать конфликты между x64 и x86 либами от VC++Redistributable. Ни один человек "с нуля" такое уж точно не провернет.


В этом смысле IntellijIDEA от JetBrains — просто божественна. Скачивается одним файлом, устанавливается по алгоритму "далее, далее, ок". Можно создать всего один проект и запускать любой произвольный класс с main одним кликом.
Ну а то, что там нужно создать файлик с классом и "потом поймете" — совсем не проблема.


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

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

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


За ссылку на Полякова спасибо.

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

Кроме языка Python можно попробовать Lua. Он достаточно простой и мощный, чтобы на нём лепить всякие интересные штуки и запустить их на практически любом PC, который вообще работает.
Sign up to leave a comment.

Articles