Один из методов обучения — постановка перед обучающимся задач в нужном порядке и посильной сложности, постепенно повышая планку. При этом преподаватель может быть ограничен в часах и в темах, поэтому на очных занятиях получается рассмотреть образцы заданий и подтянуть бегемотов из их болота. А дома вы вроде бы за время преподавателя не платите и можете при желании сколько угодно сидеть разбираться.
Еще может быть у вашей дочери есть способности и ей подкидывают немного больше.
Проблема схожести присваивания и оператора сравнения актуальна только поначалу.
Например в java и в C# вот такой код будет подсвечен как синтаксическая ошибка.
int a = 3, b = 5;
if (a = b){ //Отсутствует неявное преобразование int в bool
}
Вот js точно не заметит скрытой ошибки. C++ и C кажется тоже.
var x = 3, y = 5;
if (x = y){
console.log(x);
}
Дело не столько в экономии бумаги, но прежде всего в обозримости листинга: при одинаковом числе операторов листинг на одной странице легче воспринять, чем листинг на трех страницах.
Тут стоит задуматься над тем, нужно ли вообще давать на бумаге листинг более одной печатной страницы? Иллюстрации отдельных полезных фрагментов программы обычно маленькие. А если это реализация какого-либо алгоритма, то в чем будет заключаться задача обучаемого? Переписывание кода в компьютер тренирует не знание алгоритмов, а скорость быстрой печати.
Если мне нужно доставить студентам много кода, то я оформляю пулл-реквест в их репозиторий. Задача при этом ставится как "допиши, чтобы работало".
В черновиках (и на доске) всякие знаки препинания выделяю жирным шрифтом. Код всегда подлежит написанию в IDE и запуску.
Всякие "+=" и "=+" (как в некоторых ЯП) — источник многих ошибок не только у школьников.
В материалах для обучения лучше вместо x += y; использовать x = x + y;. Это минимальный работоспособный вариант. А сокращенный вариант пускай самостоятельно узнают и пользуются.
можно использовать не весь язык, но только его подмножество. В современных условиях это выглядит несерьезной отговоркой.
Даже в популярных промышленных языках есть такое наследие, которое при работе лучше в настоящее время не использовать. Например те же goto в шарпе. Про них постепенно забывают, но они же есть. Все равно получается "подмножество".
"Можно но не нужно".
Задача на вывод чисел Фибонначи не очень показательная. Мы ведь не только оформление цикла хотим учитывать. Есть же еще как минимум массивы и файлы. Предлагаю задачу, которую я использую для выяснения уровня слушателей.
Условие задачи
Пoльзoватeль ввoдит два маccива данных. cравнить coдeржимoe двух маccивoв и вывecти рeзультат в видe таблицы в файл. Значeния пeрвoгo маccива — загoлoвки кoлoнoк. Значeния втoрoгo маccива — загoлoвки cтрoк. ecли загoлoвoк кoлoнки coвпадаeт c загoлoвкoм cтрoки, тo в ячeйкe нужнo пocтавить плюc. oткрыть файл cтандартным рeдактoрoм при завeршeнии рабoты прoграммы.
Исходные данные:
q a z w s x
q w e
Примерный результат
# q a z w s x
q + |
w + |
e |
#------------
Реализация C#
String topRaw = Console.ReadLine();
String leftRaw = Console.ReadLine();
if (String.IsNullOrWhiteSpace(leftRaw))
{
Console.WriteLine("Данные слева отсутствуют");
return;
}
if (String.IsNullOrWhiteSpace(topRaw))
{
Console.WriteLine("Данные сверху отсутствуют");
return;
}
String filename = "dest.txt";
using (System.IO.StreamWriter dest = new System.IO.StreamWriter(filename)){
String[] leftArr = leftRaw.Split(' ');
String[] topArr = topRaw.Split(' ');
dest.Write("# ");
dest.WriteLine(topRaw);
for (int i = 0; i < leftArr.Length; i++)
{
dest.Write(leftArr[i]);
for (int j = 0; j < topArr.Length; j++)
{
if (leftArr[i].Equals(topArr[j]))
{
dest.Write(" +");
}
else
{
dest.Write(" ");
}
}
dest.WriteLine("|");
}
dest.Write(" ");
for (int i = 0; i < topArr.Length; i++)
{
dest.Write("--");
}
System.Diagnostics.Process.Start(filename);
}
А теперь мы полученную программу оформим вот так… В таком виде она может быть подключена к другой программе. Такой подход называется модульным
Стоит добавить еще несколько пунктов:
Вот так нужно оформлять подключение в другой программе и вызов этого модуля.
Вот так нужно передавать информацию в модуль.
Вот так нужно обрабатывать ошибки, возникающие в модуле.
Вот так нужно получать результаты работы модуля.
Такой подход может быть полезен вот в этом, в этом и в этом случае.
А если мы хотим, чтобы информация не только дошла до сознания слушателей, но и закрепилась в нем?
Тогда на каждый пункт еще желательно по одному примеру, который нужно как минимум записать, а как максимум — выполнить задачку, похожую на него, в классе и еще несколько дома.
Я размышлял над обратной проблемой. Когда спрашивающий знает из каких элементов нужно составить решение и (допустим) понимает к чему нужно прийти. А собрать целое из частей не может.
Если человек действительно хочет, то развитию навыка может помочь решение классических геометрических головоломок. Танграм, пентамино, кубик Рубика и т.п. Может быть даже конструкторы наподобие лего. Но я плохо представляю себе как включить их в программу какого-либо образовательного учреждения.
А по сути, если введение в модульное программирование займёт, прости госпади, 15 минут одного урока, и больше к нему возвращаться не придётся, то почему его не дать? Хуже точно не будет.
А если не 15 минут, а минимум два урока? Один — чтобы рассказать, потом домашнее задание чтобы попробовать и еще один — чтобы ответить на вопросы по домашнему заданию.
Но как известно решеток несколько. Поэтому следующим этапом рассказываем как представить решетку в виде класса: сразу и инкапсуляция и наследование (например от IEnumerable).
Классы хорошо заходят на геометрических задачках. Прямоугольники, квадраты, круги. Объяснение на всяких алгоритмах с решетами еще не пробовал, но предполагаю, что будет черезчур сложно.
IEnumerable можно на графиках (линейных, квадратичных) функций показывать. Но сначала желательно объяснять отличие списка и множества от массива.
Смотря к какому. Сортировку — да, а какой-нибудь non-dominated sorting genetic algorithm или TimberWolf 3.2 — это уже будет уровень научной работы, которую уже проделали лет 10-20 тому назад.
Даже к таким можно самому дойти. Просто времени уйдет непозволительно много. И действительно сложные алгоритмы совершенно точно не нужно знать всем. Чтобы их применять, нужно научиться понимать решаемую проблему. То есть тренировать навыки анализа и поиска, которые вы упоминали.
Наблюдая за всеми этими темами, я прихожу к выводу, что нет единой точки зрения по поводу того, чему именно учить. В первую очередь потому, что у разных преподавателей разная аудитория. То, что подходит школьникам, не подойдет хирургам, меняющим профессию, и наоборот.
Плюс это ресурс для профессионалов и специалистов разработки, а не для учителей школ-СПО-ВУЗ. Поэтому дискуссия регулярно уходит в оффтопик про ООП и фичи ЯП.
Викиучебник наверное стоит просто начать. А там уже видно будет.
А как вы определите, что человек понял что такое алгоритм?
Если ориентироваться на следующее определение "Алгоритм это набор инструкций, описывающих порядок действий исполнителя для достижения некоторого результата."
то "понимание" можно оценить например по способности человека написать программу для условного башенного крана для частного случая перестановки ящиков с палубы корабля на площадку в порту.
Если под "пониманием алгоритма" вы имеете в виду "знание классических алгоритмов", то я с вами не согласен. Знание некоторого множества готовых решений проблем значительно менее полезно, чем умение определить проблему и самостоятельно прийти к ее решению. Даже если это решение уже известно.
Для решета Эратосфена ООП выглядит весьма надуманно. Одного метода тут будет более чем достаточно.
Однако я согласен с вами в другом — нужны навыки анализа и декомпозиции задачи, построения логики программы. "Как из кубиков построить дом?", "Какой дом нам вообще нужен?".
Автор статьи не прав в том, что нужно пичкать школьников алгоритмами. Не усвоятся они.
На самом деле к любому алгоритму можно прийти самостоятельно, если будет необходимость применить его. "Знание алгоритмов" тут всего лишь экономит время на поиск.
Нужны не столько готовые решения, сколько интересные проблемы, подаваемые в посильном порядке. Хотя бы на примере игры.
Еще немного поразмыслив, пришел к выводу, что в программировании еще очень важно решать четыре типа головоломок:
Найди 10 отличий
Определи закономерность
Замени одни фрагменты выражения на другие, получив эквивалентное выражение
Соверши неизвестный заранее набор действий с известными блоками для получения известного результата.
Может быть еще какая-нибудь типичная головоломка есть. Пока что только это в голову пришло.
Третья головоломка это школьная алгебра 7-9 классов. Четвертая тренируется головоломками типа пентамино. А вот первые две — не припоминаю в программе. На образовательных сайтах для школьников определение закономерности превращается в задачу на смекалку, где нужно просто знать ответ. Есть ли книга с подобными задачками на примете?
Если хочется, чтобы от ООП остались не просто вызубренные термины про инкапсуляцию, полиморфизм и наследование, то надо вводить эти термины постепенно и с объяснением "зачем".
Сначала инкапсуляцию. Показать как классно уменьшается простыня кода, если описать АТД с парой методов и полей.
Потом наследование. Сделать несколько родственных АТД с пачкой похожих методов. Показать как упрощается написание каждого отдельного АТД при выделении родительского класса.
Потом полиморфизм. Все те же АТД вперемешку сложить в коллекцию и попробовать поработать с ними.
А картинки на доске и многословные объяснения плохо откладываются в памяти. Все доходит через руки. Главная проблема — на маленьких программах ООП малополезно. А большие программы писать значительно дольше, ориентироваться в них сложнее и нужно уметь кормить им много данных и автоматически тестировать. Плюс само задание к ним будет уже смахивать на полноценное ТЗ.
В учреждениях средне-специального и высшего образования есть разделение практики и теории. На практике не вызывают к доске для демонстрационного решения. А на теории не приходится решать задачи. Для тренировки публичных выступлений устраивают рефераты.
Школу я плохо помню. Кажется вызывали не тех, кто только что "смог", а тех, у кого не хватало оценок, или тех, кто поднял руку. В первую очередь с целью "поставить оценку". К тому же в школе тоже приходилось выступать с рефератами.
Есть же бесплатные клавиатурные тренажеры. В том числе и в игровой форме.
Пробовали внедрять их в учебный процесс?
Задача преподавателя не в том, чтобы научить умных, а в том, чтобы научить всех. Не всегда получается, но стремиться надо к этому.
Один из методов обучения — постановка перед обучающимся задач в нужном порядке и посильной сложности, постепенно повышая планку. При этом преподаватель может быть ограничен в часах и в темах, поэтому на очных занятиях получается рассмотреть образцы заданий и подтянуть бегемотов из их болота. А дома вы вроде бы за время преподавателя не платите и можете при желании сколько угодно сидеть разбираться.
Еще может быть у вашей дочери есть способности и ей подкидывают немного больше.
Другой вариант компактной записи. Если уж очень хочется так писать, то надо побольше пробелов между блоками.
Проблема схожести присваивания и оператора сравнения актуальна только поначалу.
Например в java и в C# вот такой код будет подсвечен как синтаксическая ошибка.
Вот js точно не заметит скрытой ошибки. C++ и C кажется тоже.
Тут стоит задуматься над тем, нужно ли вообще давать на бумаге листинг более одной печатной страницы? Иллюстрации отдельных полезных фрагментов программы обычно маленькие. А если это реализация какого-либо алгоритма, то в чем будет заключаться задача обучаемого? Переписывание кода в компьютер тренирует не знание алгоритмов, а скорость быстрой печати.
Если мне нужно доставить студентам много кода, то я оформляю пулл-реквест в их репозиторий. Задача при этом ставится как "допиши, чтобы работало".
В черновиках (и на доске) всякие знаки препинания выделяю жирным шрифтом. Код всегда подлежит написанию в IDE и запуску.
В материалах для обучения лучше вместо
x += y;использоватьx = x + y;. Это минимальный работоспособный вариант. А сокращенный вариант пускай самостоятельно узнают и пользуются.Даже в популярных промышленных языках есть такое наследие, которое при работе лучше в настоящее время не использовать. Например те же goto в шарпе. Про них постепенно забывают, но они же есть. Все равно получается "подмножество".
"Можно но не нужно".
Промахнулся с ответом. Посмотрите этот комментарий, пожалуйста.
Задача на вывод чисел Фибонначи не очень показательная. Мы ведь не только оформление цикла хотим учитывать. Есть же еще как минимум массивы и файлы. Предлагаю задачу, которую я использую для выяснения уровня слушателей.
Никто не предлагает наследовать прямоугольник от квадрата. И то и другое наследуется от "фигуры". Для иллюстрации этого достаточно.
Если вы пробовали объяснять на чем-то другом и у вас получилось, поделитесь пожалуйста.
Куда "туда же"?
Стоит добавить еще несколько пунктов:
А если мы хотим, чтобы информация не только дошла до сознания слушателей, но и закрепилась в нем?
Тогда на каждый пункт еще желательно по одному примеру, который нужно как минимум записать, а как максимум — выполнить задачку, похожую на него, в классе и еще несколько дома.
Я размышлял над обратной проблемой. Когда спрашивающий знает из каких элементов нужно составить решение и (допустим) понимает к чему нужно прийти. А собрать целое из частей не может.
Если человек действительно хочет, то развитию навыка может помочь решение классических геометрических головоломок. Танграм, пентамино, кубик Рубика и т.п. Может быть даже конструкторы наподобие лего. Но я плохо представляю себе как включить их в программу какого-либо образовательного учреждения.
А если не 15 минут, а минимум два урока? Один — чтобы рассказать, потом домашнее задание чтобы попробовать и еще один — чтобы ответить на вопросы по домашнему заданию.
Классы хорошо заходят на геометрических задачках. Прямоугольники, квадраты, круги. Объяснение на всяких алгоритмах с решетами еще не пробовал, но предполагаю, что будет черезчур сложно.
IEnumerable можно на графиках (линейных, квадратичных) функций показывать. Но сначала желательно объяснять отличие списка и множества от массива.
Даже к таким можно самому дойти. Просто времени уйдет непозволительно много. И действительно сложные алгоритмы совершенно точно не нужно знать всем. Чтобы их применять, нужно научиться понимать решаемую проблему. То есть тренировать навыки анализа и поиска, которые вы упоминали.
Наблюдая за всеми этими темами, я прихожу к выводу, что нет единой точки зрения по поводу того, чему именно учить. В первую очередь потому, что у разных преподавателей разная аудитория. То, что подходит школьникам, не подойдет хирургам, меняющим профессию, и наоборот.
Плюс это ресурс для профессионалов и специалистов разработки, а не для учителей школ-СПО-ВУЗ. Поэтому дискуссия регулярно уходит в оффтопик про ООП и фичи ЯП.
Викиучебник наверное стоит просто начать. А там уже видно будет.
Ну, допустим, назначение сортировки в быту еще более менее понятно. Но вы ведь не только ее собираетесь доносить студентам? А что еще?
А как вы определите, что человек понял что такое алгоритм?
Если ориентироваться на следующее определение "Алгоритм это набор инструкций, описывающих порядок действий исполнителя для достижения некоторого результата."
то "понимание" можно оценить например по способности человека написать программу для условного башенного крана для частного случая перестановки ящиков с палубы корабля на площадку в порту.
Если под "пониманием алгоритма" вы имеете в виду "знание классических алгоритмов", то я с вами не согласен. Знание некоторого множества готовых решений проблем значительно менее полезно, чем умение определить проблему и самостоятельно прийти к ее решению. Даже если это решение уже известно.
Для решета Эратосфена ООП выглядит весьма надуманно. Одного метода тут будет более чем достаточно.
Однако я согласен с вами в другом — нужны навыки анализа и декомпозиции задачи, построения логики программы. "Как из кубиков построить дом?", "Какой дом нам вообще нужен?".
Автор статьи не прав в том, что нужно пичкать школьников алгоритмами. Не усвоятся они.
На самом деле к любому алгоритму можно прийти самостоятельно, если будет необходимость применить его. "Знание алгоритмов" тут всего лишь экономит время на поиск.
Нужны не столько готовые решения, сколько интересные проблемы, подаваемые в посильном порядке. Хотя бы на примере игры.
Компьютеры Mac, на которых можно заниматься, может быть и малодоступны. Но успешно заниматься можно и на технике попроще, которая доступна многим.
Еще немного поразмыслив, пришел к выводу, что в программировании еще очень важно решать четыре типа головоломок:
Может быть еще какая-нибудь типичная головоломка есть. Пока что только это в голову пришло.
Третья головоломка это школьная алгебра 7-9 классов. Четвертая тренируется головоломками типа пентамино. А вот первые две — не припоминаю в программе. На образовательных сайтах для школьников определение закономерности превращается в задачу на смекалку, где нужно просто знать ответ. Есть ли книга с подобными задачками на примете?
Если хочется, чтобы от ООП остались не просто вызубренные термины про инкапсуляцию, полиморфизм и наследование, то надо вводить эти термины постепенно и с объяснением "зачем".
Сначала инкапсуляцию. Показать как классно уменьшается простыня кода, если описать АТД с парой методов и полей.
Потом наследование. Сделать несколько родственных АТД с пачкой похожих методов. Показать как упрощается написание каждого отдельного АТД при выделении родительского класса.
Потом полиморфизм. Все те же АТД вперемешку сложить в коллекцию и попробовать поработать с ними.
А картинки на доске и многословные объяснения плохо откладываются в памяти. Все доходит через руки. Главная проблема — на маленьких программах ООП малополезно. А большие программы писать значительно дольше, ориентироваться в них сложнее и нужно уметь кормить им много данных и автоматически тестировать. Плюс само задание к ним будет уже смахивать на полноценное ТЗ.
"Использование только функций" это все еще процедурное программирование. Настоящее функциональное может быть даже сложнее, чем ООП.
В учреждениях средне-специального и высшего образования есть разделение практики и теории. На практике не вызывают к доске для демонстрационного решения. А на теории не приходится решать задачи. Для тренировки публичных выступлений устраивают рефераты.
Школу я плохо помню. Кажется вызывали не тех, кто только что "смог", а тех, у кого не хватало оценок, или тех, кто поднял руку. В первую очередь с целью "поставить оценку". К тому же в школе тоже приходилось выступать с рефератами.