Обсуждение

Давеча в центре Тулы сунули листовку с призывом отправлять мелких в "Математический лагерь Бурбаки" ...

-- язык (lua? Python? Julia? C++? Mathematica?). А почему не Racket?

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

В фейсбуке уже шутили по поводу пролога. Ещё учат на Factor в некоторых университетах, concatenative языки тоже забывать нельзя. С языками тем хорошо, что их много! Всегда можно предложить ещё пару-тройку!

Он на Ершоле писал несколько лет назад, в в последний год на Wired (си-подобный) и, Scratch для Arduino, работал с аналоговыми портами -- обслуживал навешанную электронику. Так что наличие многих языков для него не секрет. Мозги на всю жизнь ничем не убиваются, люди и после бейсика с фортраном вполне себе переучивались, и даже после Кобола прецедентов тьма. Замечания приветствуются не абстрактные, а конкретные. Задачник и среда исполнения с автоматической проверкой -- у курса Кириенко это есть. Это означает, что моё время учителя будет минимальным. Все остальные решения требуют моей переквалификации в педагога, а это нафиг. Если б я сам учил, я б учил его писать на Julia. Но там в части задач и автоматической проверки исполнения пока пустыня. Ну, и поговорить будет не с кем после окончания обучения. А язык в существенной мере социальная сущность, не только концептуально-рациональная.

... и портрет Бурбаки на листовке, для солидности.

Научиться программировать на Фортране и Бейсике на других языках - это просто. Вот мусор из головы вынуть - это сложнее. Я бы смотрел не задачник, а проект. Чего-нибудь на С (можно с ассемблером и gcc) и какие-нибудь задачи на низком уровне, чтобы понять память, указатели и указатели на указатели, и функциональное программирование, можно даже JavaScript. Автоматическая проверка учит удовлетворять автоматическую проверку. Не думаю, что результаты будут правильными.

Я ж написал, что учу пока computer science. Sofware engineering это совсем другая дисциплина, и нужно учить там прежде всего инженерии, а потом уже софтверной. И там, конечно, проекты. А в science не проекты, а эксперименты-задачи.

Могу порекомендовать методичку "Размерность и подобие": http://mipt.ru/students/organization/mezhpr/biblio/razmernost.php Система СИ там тоже обсуждается.

Спасибо! Проблема в СИ не в том, что она непонятна. Проблема в том, что соответствующие фрагменты объяснений прокидываются путём резкого отвлечения от просмотра или чтения, соответствующие части задач прокрастинируются (то есть необходимость их выполнять признаётся, но ход решения прерывается на походы в туалет, на кухню, задание не относящихся к делу вопросов и т.д.). Но лишние материалы не мешают. В сержантском методе если есть затык (а хоть и прокрастинирование), то немедленно добавляется тренажёр -- кучка задач ровно на этот затык, чтобы сама тема стала банальностью вместо источника прокрастинации.

А каков жизненный цикл у проекта "образование сына"?

Это не проект, это программа ))) Я очень не уверен, что можно сюда подходить с классическим инженерным подходом. Ибо системная инженерия с людьми не работает, сын ведь не кусок железа, его образование нельзя просто СПРОЕКТИРОВАТЬ и ВОПЛОТИТЬ. Лошадь можно подвести к воде, напоить нельзя.

"Ибо системная инженерия с людьми не работает, сын ведь не кусок железа" а с чем вы работаете здесь? и как это сочетается с "использовать надёжный сержантский метод, ибо никакой заинтересованности отрока хоть в какой-то программистской деятельности пока не было обнаружено"? пс: лошадь можно завести в воду по шею и выпускать только после того, как она сделает глоток

Добавить конечно можно, но в случае схемы аргумент за, это SICP.

Ну так именно в SICP Абельсон говорит о том: что Computer Science во первых не computer, а во вторых не science :)

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

В 1984 году (год выпуска SICP), насколько я помню, как раз лисп-машины стали выходить из моды, и лисп перестал быть "этим нашим всем". Опять же, в алгоритмике использовались более процедурные языки (взять многотомничек того же Кнута). Так что оставим полномасштабный проход по computer science на чуть более далёкое будущее. Берём маленький кусочек, который можно прожевать школьнику.

Здесь я работаю с собственным сыном, которого я как раз завожу в воду (иногда и поглубже, чем по шею). Но это не инженерия, ни разу. Можно, конечно, думать и про жизненные циклы, но это меньше помогает чем думать про всякие теории адаптивного обучения, различие ролей тьютора и преподавателя и т.д. Когда-то я посоветовал одной своей студентке, чтобы она не использовала для event-management системной инженерии. Это ведь нормальная вузовская теперь специальность: event-management. Ну, она послушалась. Бросила МФТИ, занимается event-management, ей интересно, она счастлива. Вот и в случае образования сына: нужно интересоваться современной образовательной мыслью, а не инженерной -- и быть счастливым.

SICP же, вроде, как раз на Python перешли?

Ок, я прямым текстом. При том, что я сам многое у вас почерпнул и использовал... у меня сложилось впечатление, что вы относитесь к сыну как к программе, или скорее нейронной сетке перед ее обучением. Основания для тких впечатлений вот: Ваши слова "заинтересованности отрока хоть в какой-то программистской деятельности пока не было обнаружено" выдают ожидание, что "потом заинтересованность появится". Вы в своей программе для сына игнорируете его "заинтересованность" и не работаете на то, чтобы она пРоявилась. Он в рамках такой программы не получит опыта быть самому себе "разумным" сержантом, и без вашего сержанства не будет способен достигать результатов. Умение слушать и развивать свою заинтересованность важно ничуть не меньше, чем уметь программировать. Впрочем, я могу и ошибаться.