July 6th, 2016

2019

Гомельская школа обучения программированию

Гомельская школа обучения программированию воспитывает (устойчиво!) победителей олимпиад по программированию, включая чемпионов мира -- суть её можно понять, читая ссылки по текстам отсюда: http://dl.gsu.by/NForum/posts/topicshow/76.dl?postid=59214#59214

Как я к этому отношусь? Если бы я начинал учить своего сына сейчас (а там возможно это с начальной школы -- http://logic.by/, затем http://dl.gsu.by/), то я всенепременно этим бы воспользовался. С ПиктоМира на КуМир прыгать было легко, но затем нужно было просто прыгать на общепринятый сегодня в школах олимпиадный Паскаль, и не ждать много-много лет до известного мне курса для 8 класса на Питоне.

В Гомельской школе обучения программированию понимают, что образование должно быть многолетним, а не «курсовым» -- все эти «курсы» должны выстраиваться в какую-то длинную цепочку, или граф. Начинаться должно в начальной школе (или даже раньше) и дальше задачи должны решаться все годы подряд, без перерывов. Ну, или если был перерыв – то чтобы можно было продолжать с прерванного места.

Там тоже успеха добиваются «сержантским методом»: отработкой навыков на большом числе мелких задач, а не выполнением сразу каких-то "рабочих проектов". Мыслительный навык сначала честно моделируется (в смысле нейролингвистического моделирования) из деятельности профессионалов, выражается как-то в явном виде, а потом оформляется для учебных целей как задачи по тренировке навыка. Потом задачи попарно комбинируют эти навыки, потом в задачах комбинируется по множеству навыков -- и на выходе появляется искомая интуиция, учебная метанойя.

Задач – сотни, а не единицы (ибо «единицы» -- это «проходить мимо»). Проблем здесь две: а) понять, что нужно тренировать, из чего состоит целевое мышление, и б) сочинить автоматически проверяемые задачи, которыми можно эти элементы мышления тренировать. После чего – налёт часов тренинга решает всё. И некоторый налёт казарменности есть: сержант следит, чтобы слишком не расслаблялись. Этот путь только для тех, у кого есть не только "ген таланта", но и "ген усидчивости" (http://www.economist.com/news/science-and-technology/21606259-musical-ability-dna-practice-may-not-make-perfect?fsrc=scn/tw/te/pe/practicemanynotmakeperfect) -- чемпион мира по программированию, определённо, таким геном обладал, судя по замечаниям: "Как-то при обсуждении в форуме вопроса о том, кто сколько времени тратит на занятия, Гена ответил – примерно 20 часов в неделю. В то же время подавляющее большинство ребят занимается максимум 6 часов в неделю." (http://dl.gsu.by/NForum/posts/topicshow/76.dl?postid=59214#59214).

Часов на дисциплину нужно много, каждый день. Профильная дисциплина в этом плане сравнима с иностранным языком, там есть метафора ледяной горки: ежедневно сползаешь на час-полтора. То есть если тратишь на язык час-полтора в день, то удерживаешь текущий уровень языка, а если хочешь карабкаться – то нужно два-три часа в день для его освоения. Каждый день: речь идёт о свойствах нейронной сетки человека, которая учится на повторениях и имеет свойство забывчивости. Я когда-то писал об этом в "как зажечь мастерство": http://ailev.livejournal.com/1130190.html -- в силу устройства нейронной сетки это применимо к любым курсам, не только языковым.

Ключевой вопрос в таком подходе, что при домашнем образовании, что при школьном -- это автоматизация:
а) репозиторий огромного числа задач, в том числе задач на всяческие «ментальные затыки». Так, для математики и физики никаких "репозиториев" нет, все задачи раскиданы по очень и очень разным задачникам и рабочим тетрадям. Большинство "курсов" программирования опираются на очень маленькое количество задач в каждой теме. А ведь есть ещё и задачи на сочетание разных тем!
б) приёмка задач должна быть автоматизирована, online judge (погуглите, в программировании таких систем ой-ой-ой сколько).
в) выдача задач должна быть автоматизирована, но с учётом концепции адаптивного обучения – если обнаружен ментальный затык, то задачи на данный мыслительный приём добавляются, пока затык не исчезнет, а если всё и так понятно, то задачи на данный приём сокращаются,
г) образовательная среда не должна ограничиваться границами одного курса, она должна сопровождать учащегося несколько лет, я считаю главным достижением Гомельской школы обучения программирования именно это
д) дальше можно думать об edutainment – мотивационные бантики (игрофикация всех мастей), которые очень важны. Но эти бантики должны навешиваться на крепкое содержательное мясо, просто «интереснейшие игрушки, детей не оторвать» не нужны. Сержантский метод только для тех, кто готов служить по контракту. Он, конечно, не для всех. Никто не хочет играть не только на скрипке Энгельбарта, но и просто на скрипке. Программировать никто не хочет "учить", Гомельская школа делает упор на олимпиады -- там программирование "тренируют" для "победы". Это и есть edutainment, социализация нудной работы.

Но вот далее начинаются различия в позициях моей и гомельчан:

1. Совершенствование против развития: можно, конечно, говорить что чемпион мира по пользьбе (до этого освоивший в совершенстве умение держать головку, переворачиваться на животик и т.д.) легко потом осваивает ходьбу, бег и танцы – ибо «талантлив в одном, значит талантлив во всём -- а заодно он и усидчив». Но я это усомневаю. Я считаю, что задерживаться на ступеньках совершенствования не стоит: http://ailev.livejournal.com/1032133.html. Развитие -- это рост спектра возможных адекватных ответов на самые разные жизненные ситуации. Развитие -- это когда всё реже и реже выдаются неадекватные реакции в незнакомых ситуациях из-за незнания и неумения. Совершенствование -- это когда всё реже и реже проявляются неуместные в знакомой ситуации поведенческие стереотипы. Развитие -- это шаги вперёд, в новые ситуации. Совершенствование -- это занятие круговой обороны в знакомой ситуации, и выигрыш за счёт этого. Я думаю, торчать на какой-то одной способности нужно в тяжёлых ситуациях, когда все остальные способности почти на нуле -- Кен Уилбер назвал это "принцип резинки". Посколько развиваться нужно сразу по многим линиям, он предложил сосредотачиваться не на выправлении многих и многих "отстающих" навыков, а опережающим развитием какого-то одного. И тогда этот навык понятет за собой и остальные, они оказываются как на резиночке привязанными. Но вот дальше уже проблема: гипертрофированный один навык (если он не является именно профессиональным) вовсе необязательно будет уже подтягивать другие. Является ли кодирование в объеме олимпиадного программирования навыком, достойным гипертрофирования, или упираться нужно во что-то другое (математику, физику, плавание, игру на фортепьяно) я не знаю. Но я думаю, что и в рамках программирования-информатики есть много куда поразвиваться, чтобы развитие было хоть как-то гармоничным. А потом взрослый человек уже сознательно выберет, куда его тянет, и гипертрофируется туда по собственному разумению и хотению -- а не по желанию педагогов, как это происходит с олимпиадной алгоритмикой.

2. Конечно, можно учить совершенству алгоритмического мышления в части структурного программирования им.Дейкстры, немножко разбавленному знанием избранных мест из томиков Кнута. И дальше считать, что выпускник будет программистом (что обычно оказывается правдой). Но мне кажется, что программирование немного больше, и учить нужно самому разному, и для этого необязательно дожидаться окончания средней школы. Быдлокодер, который кодирует очень быстро, всё одно быдлокодер. Кодер от программиста отличается разительно. Информатика и алгоритмика существенно разнятся, алгоритмика в информатике лишь маленькая часть. Я думаю, что учащимся нужно как можно раньше осваивать мышление не только алгоритмическое, и не только для олимпиадных ситуаций -- при всём соблазне использования олимпиад в качестве средства независимого тестирования своего уровня и мотивационной мегамашинки. Хотя я согласен, что владение алгоритмикой на уровне мыслительных автоматизмов структурного программирования и десятка алгоритмов (чтобы понять само понятие алгоритма) нужно, но его нужно вовремя положить в базу других умений, а не тренировать до блеска. Легко представить олимпиаду ползунов по-пластунски и программу обучения ползунков на достижение олимпийских успехов в этом виде спорта. Но всё-таки спорт – это как-то слишком легко, даже если спортсмены оказываются потом в жизни надёжно пристроены.

3. У меня довольно много разных работ в попытках определить предмет информатики и составляющие его подпредметы, найти там образовательные дырки (увы, этих дыр больше, чем мне хотелось бы). Мой текущий взгляд на образование по computer science для начинающих я совсем недавно описал тут: http://ailev.livejournal.com/1274596.html (вполне возможно, что этот текст нужно бы переписать с учётом достижений Гомельской школы – я просто не был знаком на момент написания этого текста с существованием дистантных тамошних ресурсов, увы).

4. На мой взгляд, computer science (куда входит алгоритмика, но не только она) должна лечь в основу и разных других предметов – поддержки курсов по численным методам, например (скажем, вычислительная линейная алгебра, которая лежит в основе современных коннекционистских подходов к искусственному интеллекту). Информатика, конечно, при этом определяется как наддисциплина к computer science и даже software engineering (http://ailev.livejournal.com/1008054.html), а сейчас к этим дисциплинам прибавляется и инженерия нейронных сеток как коннекционистский вариант моделирования мира: http://ailev.livejournal.com/1205999.html.

5. Образовывать нужно IMHO прежде всего в моделирующем мышлении в целом, а также рефлексирующем мышлении про средства этого моделирования: формализация описаний окружающего мира на языках программирования, моделирования, онтологических языках (см., например, мой заход на системную информатику: http://ailev.livejournal.com/1272169.html и http://ailev.livejournal.com/1274210.html, а также http://ailev.livejournal.com/1273208.html). Проектирование и конструирование -- это просто моделирование тех систем, которые "будут".

6. Это означает, что сэкономленные от подготовки на соревнования по программированию часы (совершенствование в рамках одной дисциплины) должны уйти на освоение новых приёмов мышления (развитие, прихват других типов мышления). Не нужно учить и учить и учить иностранный язык. Нужно использовать его для общения, чтения, письма -- иначе зачем учить?! Нужно класть умение программирования в основу развития, и развиваться дальше. Поэтому выбор языков программирования/моделирования зависит и от того, в какую сторону пойдёт развитие мышления дальше, за пределами олимпиадного программирования с его структурным программиованием и двумерным массивом как самой сложной структурой данных. В частности, я бы сразу делал ставку на расширяемые языки, и в существенной мере тренировал бы аспекты «мета» в мышлении -- http://ailev.livejournal.com/1263511.html. Отсюда моя любовь к Julia, в которой есть аспекты расширяемости, полученные от Forth и LISP (http://ailev.livejournal.com/1140646.html). Ну, и из Julia выходы в математику-физику уж всяко получше, чем у Паскаля. При развитии в сторону тренинга математического и физического мышления, Julia может оказаться полезной.

7. Увы, вся заявленная мной программа обучения мышлению в информатике в целом, а не только олимпиадно-программной её части, проиграет любой онлайн-системе, которая поддеживает автоматизацию обучения – ибо масштабирование тут определяющий фактор, затраты времени родителя или учителя на одного ученика становятся запретительными для всего, что выходит за границы олимпиадного программирования! Такие уж реалии сегодняшней жизни. О спорт, ты -- мир! Недостаток ресурсов на создание "неолимпиадного" online judge (например, поддержание языков программирования, не часто встречающегося на олимпиадах) – это только маленькая часть проблемы, ибо много бОльшая часть тут выявление необходимых к тренингу паттернов мышления и затем формулирование достаточного количества задач, решение которых потом можно автоматически проверить. И это создание масштабируемого учебного курса для "сержантского метода" не автоматизируешь, увы. Так что всё мной написанное -- это пока по большей части благие пожелания. А олимпиадное программирование -- наличествующая суровая правда жизни.

Но материалы гомельской школы вы всё-таки посмотрите, там очень много любопытного и полезного. Напомню ссылку из начала поста: http://dl.gsu.by/NForum/posts/topicshow/76.dl?postid=59214#59214
2019

Об проекты по созданию технологий

Самый ужас, это когда на вопрос: "какую систему вы создаёте в вашем проекте?" отвечают -- "технологию того-сего". После этого обычно следует сессия игры в буллшит-бинго (http://bullshit-bingo.ru/card/465), из которой выясняется, что слово "технология" обозначает множество самых разных вещей, порознь и одновременно:
-- способ (метод) достижения успеха в составе какой-то другой технологии (ага, тут рекурсия). Системой тут не пахнет, ибо "способ" не занимает пространства-времени, с трудом удаётся для его обозначения заставить говорить, например, know-how.
-- фирма (стартап!), которая будет делать что-то (непонятно что) по способу достижения успеха в составе клиентской технологии (см. предыдущее замечание про способ). Фирма занимает пространство-время, но чем фирма торговать-то будет? Know-how, советы раздавать? Часто выясняется, что не только!
-- какое-то хитрое оборудование или софт, которое будет использоваться нашей фирмой (см. предыдущий пункт) для выработки продукта или сервиса, а уж торговать фирма будет этим продуктом или сервисом (которые не технология, и которые как бы мы не говорим, сейчас что будем именно их делать).
-- какое-то хитрое оборудование или софт, которое дадим клиенту, и уже он для себя будет вырабатывать продукт или сервис, а мы получим деньги разово за поставку и может быть ещё за обслуживание.
-- простое или сложное техническое устройство (гвоздь) или софт, которые много дороже оцениваются собеседниками, если их назвать "технология" -- например, "технология гвоздя". Нет никаких "инструментов", или "способов". Просто вместо "создаём гвоздь" говорят "создаём технологию гвоздя". Примерно так же добавляют часто слово "система", для солидности ("создаём систему гвоздя"), не имея задней мысли про использование системного подхода. С "технологией" так же.
-- всё вышеперечисленное сразу, потому что на момент говорения о "создании технологии" ничего ещё нет, потому как ещё нет того инженера, который придумает что же это за такая "технология" и нет того "предпринимателя", который скажет, что же с этой "технологией" потом можно делать, чем можно будет торговать.

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

Горе мне, пытающемуся вернуть этим словам их изначальное терминологическое значение! Когда у меня на занятиях студенты выходят к доске и вдруг поминают в ответ на вопрос "что будете создавать" эту "технологию" как целевую систему, я сразу мысленно удваиваю время их стояния у доски. Хуже только ситуация, когда на вопрос про "систему" отвечают словом "проект" -- и только потом заменяют слово "проект" словом "технология".

В жизни под словом "технология" обычно скрывается плотный клубок неструктурированной мысли, и нужно некоторое время для его распутывания. У меня самого слово "технология" обозначает часть практики (практика=дисциплина+технология, т.е. теория+поддерживающий инструментарий). Но я понимаю, что моё терминологическое использование слова "технология", которое я взял главным образом из стандарта OMG Essence -- это исключение из правила, оно практически нигде в жизни не используется.

Ужас в том, что во многих и многих "проектах" в результате выполнения должна быть создана технология, это в целях проекта и прописано. И такие цели почему-то считают вполне конкретными. Но что в результате такого проекта будет создано? Какая именно целевая система? Разобраться обычно невозможно, пока не будет выкинуто слово "технология" или это слово не начнёт использоваться терминологически (для обозначения какого-то инструментария, поддерживающего дисциплину в составе практики).

Это я просто начитался по службе на ночь глядя разных описаний "проектов по созданию технологий" -- и мало что смог из этих описаний понять. Вроде, все слова на месте, и удовлетворяются всевозможные хотелки (т.е. в проекте делается всё сразу, много, масштабируемо, значимо и весомо, всех ловят и не отпускают обиженными), но что же будет результатом инженерной работы, а не просто бумажно-административного её обрамления в "проект" -- вот этого не понять. И я при этом осознаю, что никакого намеренного тумана не напускается, миром ведь правит не тайная ложа, а явная лажа.
* * *
Меня иногда спрашивают, откуда такая форма построения заголовков в моих постах. А вот откуда: http://harms.ouc.ru/pushkin-i-gogol.html
2019

Современная скрипка -- отаматон

Современная скрипка японского изготовления выглядит и звучит так: http://thenextweb.com/shareables/2016/07/06/otamatone-weird-instrument/

Называется это отаматон (otamatone), вместо смычка нужно нажимать на корпус, что проще, и с одной предполагаемой струной -- но гриф по-честному без ладов:


Но и тут возможны упрощения! Вот новое поколение отaматонов, гриф уже не нужен: https://www.youtube.com/watch?v=CF2sM6pVUt8

Но всегда найдутся гики и нерды, желающие повозиться с более сложным вариантом: https://www.youtube.com/watch?v=VCZvcP4_X7E

Там много всего: http://www.otamatone.com/

Это я всё продолжаю страдать на тему "скрипки Энгельбарта", никто ведь не хочет учиться играть на XYZ -- http://ailev.livejournal.com/1158826.html