Обсуждение

> Он не понимает, зачем ему помнить все эти странные слова "из теории" ну дык пока попа не заболит на третий день поиска перезаписи где-то в мутабельной структуре, оставленной предыдущим сотрудником, понимание, зачем нужны гарантии не придёт. это как раз нормально, ящитаю для более сложного материала (производные, интегралы, ...) есть замечательный задачник Гюнтера-Кузьмина, где задачи попадаются сложные, но нет ориентирования на олимпиады

Пока только-только закончился седьмой класс, а восьмой класс только осенью. Никаких сотрудников, а попа болит только от всяких Робокрафтов. Задачники по математике в изобилии есть (хотя производные и интегралы будут только через годик-другой), речь пока идёт про информатику.

просто они твердо знают, что диплом им по-любому выдадут. Виноват Минобр. Не поощряет отчисление тупых лентяев, поощряет их содержание за казенный счет.

"Общее впечатление от недели -- будущее имеет дикое инфраструктурное предложение, но людям нужны не инфраструктуры, а конечные сервисы. Не хватает "последней мили" во всех технологических сегментах" Вспомнился прекрасный программерский анекдот. Сидят два прогера за пивом, разговаривают. -Вот бы сделать идеальную программу в интерфейсе которой будет только одна кнопка "сделать хорошо"... -Да-а-а, это был бы очень востребованный продукт! Накатили еще по одной. -Не-е, я всё поняля! Кнопка тоже не нужна! -??? -Надо чтоб в программе был только отчет в котором было написано: " Расслабтесь... Всё хорошо!".

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

1) Паттерны, задачи на моделирование физических объектов с произвольным типом данных 2) Структуры, алгоритмы с произвольным типом данных (templates, generics)

Спасибо за ссылку, но я против тамошнего подхода. С одной стороны, я согласен со многим там написанным (типа цели иметь к 10 классу покрытую вузовскую программу мехамата). Но я не согласен с тамошним подходом к структурированию предмета. Я различаю там два предмета: computer science и software engineering (а для школы нужно давать, конечно, systems engineering, ибо software engineering это какая-то специализация более общей дисциплины -- не все программистами профессиональными станут). И нужно, конечно, давать обе дисциплины. Но давать не просто "проектно", но добиваться осознанности в понимании дисциплины и общности этой дисциплины для разных технологий. Мне кажется, вот этот заход на знание теории и воспитание строгого предметного мышления и убивается современным "проектным подходом": в представленной презентации ничего на эти темы не говорится, а это основное. Это значит, что "результаты" могут быть не результатом методики (то есть я не смогу повторить эти результаты по данной методике), а результатом применения каких-то недекларированных индивидуальных умений автора методики. То есть в его руках методика будет работать, а в других местах -- нет. И эта неработа будет списываться на какие-нибудь "недружественные отношения", "отсутствие мотивированности" и т.д. Ну, и у меня много вопросов про сами акценты на содержании образования (например, структуры данных мне кажутся более важными, чем алгоритмы: современное программирование основано на богатых кучерявых структурах данных, в пределе -- базах данных, и относительно простых алгоритмов над всей этой кучерявостью. Вот и учить нужно с учётом этого изменения в программировании, которое прошло где-то в конце 70-х. И таких замечаний множество). Ну, и опять же: я ж не профессиональный учитель информатики! Мне нужно какой-то набор задач, набор объясняющих материалов и инструментальный комплекс, который бы проверял выполнение задач, не ограничиваясь прогоном тестов, а заглядывая в код и показывая какой-то "машинный" результат (а не мои субъективные оценки, которые воспринимаются как "придирки"). Такого не находится, увы.

Чем дальше в лес, тем больше я их понимаю.

Ну где, где эти задачи? Я ж не брошу всё и не сяду их сочинять! А олимпиадные задачи есть в сотнях штук, да с автоматической проверкой решения. Задач по математике -- вообще завались, на любой вкус. Задач по физике уже в разы меньше. Задач по computer science (на постановку мышления) с гулькин нос, только головоломки олимпиадные в количестве.

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

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

Я бы по прошествии 30—35 лет согласился скорее с Витей (или его источниками). В спорте ценен сам навык работы в заданном темпе в течение заданного периода,а плавать или бегать — не очень важно.

> Он не понимает, зачем ему помнить все эти странные слова "из теории" Имхо, это скорее всего говорит о простоте выдаваемых ему задач. А тратить время на ручное выравнивание кода в коде, написанном для себя -- это полнейшая глупость, и вообще, все нормальные IDE это сами делают. Профессиональный учитель, готовящий мировых олимпиадников, рассказывал нам, что задачи должны быстро усложняться. Решил -- даётся задача сложнее. Не решил -- другая задача этого же уровня. Ну и задачи должны быть по возможности интересными / интересно поданными. При этом, конечно, есть разница, какой класс у ученика, но не сильно большая. К 12-13 годам должно уже абстрактное мышление вполне сформироваться. А задачи со звёздочкой есть и в учебниках для 5х классов. >Зачем читать документацию по языку и запоминать что-то оттуда (когда можно просто погуглить какой-то сниппет кода -- и выдрать его без сопутствующих текстовых объяснений, использовать "по наитию" А вот это уже формируется с возрастом -- это просто аккуратность и использование логики вместо интуиции. Оно само придёт, когда сложность программ перевалит за 10000 строк, готовых решений не будет, а на отладку будут уходить часы. Но интуиция тоже обязательно нужна, и её тоже нужно тренировать. Тренируется -- вот и замечательно. А ещё можно играть в какие-нибудь шахматы. В шахматах на интуиции не выехать. Второй нюанс -- может появиться желание схалявить в муторных задачах (не дорешивать со словами "дальше очевидно"), а это влияет на качество решения задач -- нужно тренироваться и доводить вычисления до конца. Так что нужно ещё и трудолюбие развивать. Но без повторений и без откровенной мутоты на три страницы переписываний формул и чистописания. Нам было хорошо в этом плане -- нас в лицее самостоятельные работы для школ с физ-мат уклоном на каждом занятии давали с 8го класса. Такая мини-олимпиада по математике на полтора часа два-три раза в неделю. > но во всех его программах есть int NY (ага, NoYes), которая принимает значения 0 и 1 -- и он категорически отказывается вводить в таких случаях булевы переменные с осмысленными именами, так и говорит: "я это не люблю". А какая разница-то принципиальная? 0 и 1 быстрее писать, чем true и false. Это и есть хорошее понимание теории -- знать, что в int вполне может храниться булево значение, и не во всех ЯП есть даже тип bool. Если код пишется для себя, а не для других людей за деньги -- это абсолютно НОРМАЛЬНО.

>например, структуры данных мне кажутся более важными, чем алгоритмы: современное программирование основано на богатых кучерявых структурах данных, в пределе -- базах данных, и относительно простых алгоритмов над всей этой кучерявостью. Как там, "Вирт Н. Алгоритмы + структуры данных = программы" . Читается один раз и всё. И/или "Структуры данных и алгоритмы" Ахо-Ульман. А современное программирование основано на 99% на тяп-ляп. Чаще, чем раз в год, алгоритмы и структуры данных сложнее словаря, кортежа и вложенного цикла не применяются. В крайнем случае, используется функция из библиотеки.

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

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

По олимпиадным задачам -- ему должен подойти http://acm.timus.ru/ для начала. Там задачи попроще, чем на https://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=3 >Буду лечить его забывчивость, Не поможет. Забывчивость всегда связана с отсутствием значимости запоминаемой информации. Учёные в очередной раз доказали, что информация, которая находится на пути к награде, запоминается в разы и десятки раз лучше, чем вся остальная информация. Пока код не пишется на бумажке без интернета, а награда маленькая или отсутствует -- API учить никто никогда не будет.

И вот ещё пост и комментарии по теме: https://habrahabr.ru/post/301674/ Особенно умиляет вполне себе неплохая классификация https://habrahabr.ru/post/301674/#comment_9625406

"Сложные" в смысле развесистых (а не хитровывернутых) — это вообще не про спорт.

Спринтерам не важно уметь бегать марафон, да. Но марафонцам важно уметь пробегать 3 километра не за полчаса.