April 2nd, 2018

2019

Какой математике учить программистов

Меня спросил Борис Штейнберг, какой математике нужно было бы учить программистов. Я очень на скорую руку написал ему ответ -- но, возможно, помощь зала тоже поможет Борису (он университетский профессор, и ему эти ответы на вопрос нужны для дела, он не абстрактно интересуется -- он пишет учебные планы). Так что комментируйте, не стесняйтесь.

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

2. Логика в количестве, но не старинная, а современная. То, что иногда называют "формальная философия": когда говоришь текстом, а потом вдруг формулами пишешь формальную структуру, которая проговаривалась текстом. Фишка в том, что эта логика оказывается не булевской, а как показано E.T.Jaynes, она извод байесовщины. Вот курс, который затрагивает самые азы этого всего, но без тяжёлой математики. По факту его по моим намёткам сделала Пион Гайбарян, и вот его онтика: https://thpectrum.livejournal.com/8785.html и отдельно развёрнут онтический минимум про байесовщину: https://thpectrum.livejournal.com/9338.html. Книжку E.T.Jaynes про байесовскую вероятность как логику науки смотри тут: http://b-ok.org/book/539703/d8b66c

Вот и нужно учить "по тяжёлой" математике и рассуждениям из этой книжки E.T.Jaynes, а ещё нужно добавить сюда понимание математики, достаточное для уверенной ориентации в вероятностных языках программирования (это я тоже отношу к логике): http://probabilistic-programming.org/

3. Программы = алгоритмы + данные. С этими "данными" завал: работа с типами почти нигде не обсуждается, алгебры данных как-то ускользают от внимания. Когда я показал книжку по моделированию данных Криса Партриджа А.Г.Кушниренко, он заметил, что "в другой терминологии это известно любому третьекурснику мехмата". Что ставит задачу: основы алгоритмики выучиваются к третьему классу начальной школы, а основы работы с данными -- вообще не трогаются, а как-то проходят мимо. Все эти выводимые типы, связь типов и операций с ними. Я не очень понимаю, какой раздел математики должен это обслуживать.

Сюда же я отнёс бы обсуждение собственно математики в программировании при дизайне каких-то DSL или даже языков программирования. Например, вот обсуждение дизайна работы с линейной алгеброй в Julia: https://www.slideshare.net/acidflask/designing-linear-algebra-into-julia (видео рассказа -- https://www.youtube.com/watch?v=C2RO34b_oPM). Очень поучительная презентация, там три тезиса (на примере работы с векторами и матрицами -- и не только в Julia): Claim 1. Julia's generic function system (multimethods/ multiple dispatch) is ergonomically designed to capture mathematical abstraction. Claim 2. We're only just learning how to explain abstractions clearly to a computer. Claim 3. The future of high performance lies in composable abstraction.

Что из математики нужно, чтобы программисты могли разобраться, о чём идёт речь в подобных работах? Им же нужно постоянно работать с сочинением разных языков! И опять мы упираемся в современную логику и онтологию ("онтологику" -- где онтологии могут быть представлены, например, наборами многомерных векторов -- как в word embeddings, а не только логиками первого порядка), формальную прагматику (и, замечу, что в последнее время идёт сильнейший уход от семантики в прагматику и по факту игнорирование синтаксиса. Поэтому sic! формальная прагматика).

3. Численные методы в количестве: линейная алгебра, матан и обязательно линейная и нелинейная оптимизация. Без этого трудно будет с современными изводами глубокого обучения в частности и машинного обучения в целом (все эти Autodiff, дифференцируемые алгоритмы и т.д.). Дженсен Хуанг говорит, что современный исходный код -- это данные, а вот "компиляторами" для него служат разные нейронные сетки, автоэнкодеры, эволюционные оптимизации и т.д.. Вот с этими алгоритмами нужно разбираться. Математика эволюции (а она там есть в количестве) -- этому нужно тоже учить, без эволюционных алгоритмов сегодня никуда.

4. А ещё люди массово пытаются понять теорию категорий -- и огромные флеймы на тему "это не нужно для программирования, только мешает" против "это и есть суть программирования, это просто удобный мат.язык для размышлений о программировании". При этом баланс в дискуссии стремительно съезжает в ту сторону, что не просто теория категорий нужна, но и какие-то основы гомотопической теории типов (как они сами там говорят -- того места, откуда выросла когда-то и сама теория категорий, и которое затем породит много чего ещё подобного. Заодно там сразу ещё и выход на всякие coq, agda и прочие "автоматические доказательства").

5. Я совершенно не уверен, что нужно требовать от студентов знания доказательств, тем более что в условиях современного прагматистского поворота мы уже не истину ищем и её доказываем, а полезность определяем (и все рассуждения другие -- можно отдельно пообсуждать, что там в связи с этим происходит в математике).

Вместо знания доказательств нужно требовать умения решать задачи по изучаемой теме. Но даже и тут по-другому: не собственно решать задачи в голове, а с соответствующими современными инструментами -- с использованием какой-то алгебраической/логической системы (типа Mathematica или аналогичной), системы вероятностного программирования, системы численного программирования и т.д.. Математика изменилась, и инструмент математика сегодня -- компьютер, а не ручка-бумажка. Идея может быть от человека, а рутинные вычисления должны быть переданы компьютеру. Я знаю, это предмет отчаянных споров сегодня, но добывать огонь трением не комильфо, делать математику руками неправильно в 21 веке. Да, множество листочков, где нужно решать множество задач (4тысячи задач Демидовича -- хороший ориентир), и можно (и нужно) использовать компьютерные системы для рутинной работы, а голову для нерутинной. Да, эта мысль тяжело заходит классическим людям, и очень мало опыта того, как делать подобные курсы. Но это нужно делать. Доказывать должны компьютеры, а вот что именно доказывать -- это нужно придумывать, вот этому нужно учить. Да, холивар тут неизбежен, я понимаю.

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

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

Вот ещё ответ Сергея Абрамова на этот вопрос Бориса Штейнберга -- и он совершенно другой: https://www.facebook.com/sergei.abramov.96/posts/10215640452860742 (а ещё мне там не нравится военная метафора про "спецназ". Ага, "научная рота", "программистская гвардия", "генерал-программисты". Как будто других метафор нет в милитаризующейся стремительно стране).

Ну, и ещё можно пообсуждать то, что "вопрос бессмысленный, ибо нет уже просто программистов -- все они абсолютно разные, и всех поэтому нужно учить по-разному, а ещё есть data scientists, data engineers и что мы с ними будем в плане математики делать?". Но я это обсуждать не буду: на не очень внятный вопрос я даю не очень внятный ответ, так что в этом плане мы с Борисом квиты.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10212670723377046
2019

Практикум по системному мышлению: уже в это воскресенье

Практикум -- это про "налёт часов". Учебник по системному мышлению помогает примерно так же, как учебник по полётам на авиалайнере: будешь знать названия приборов в кабине, но летать не будешь. Для полёта нужен "налёт часов", практикум. Практикум по системному мышлению раньше был доступен только в моих вузовских курсах (все писали эссе и получали обратную связь), а также в виде менторства в Школе системного менеджмента.

После выхода видеокурса с учебником и задачами (http://www.systemsthinkingcourse.ru/) я избавился от необходимости рассказывать содержание на тренингах и появилась возможность сделать практикум.

Вчера я закончил последний (девятый!) поток "Системного менеджмента и стратегирования", а уже в это воскресенье 8 апреля 2018 уже начну четырёхдневный практикум по системному мышлению -- http://system-school.ru/event/praktikum-sistemnoe-mshlenie-08-04-2018/.

На практикуме мы будем три дня разговаривать о самых разных проектах участников на системном языке, а в четвёртый день поговорим про личное развитие участников. Так что это будет что-то типа "группового менторинга". В курсе будет только один установочный лекционный кусок по личному развитию в начале четвёртого дня (ибо учебника-видео-задач на эту тему пока нет). Один из видов отзывов на наши курсы -- это "помогли выбраться из колеи". А хотелось бы заранее помогать не попадать в колею, из которой потом придётся выбираться. В школе и вузе этому, увы, не учат. Вот, мы учим.

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

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

У меня большой соблазн также воткнуть в тренинг пару упражнений из тренинга онтологики, прежде всего работу со стейкхолдерскими онтиками. Я-то считал, что это не требует особого тренинга. Но когда я увидел, какие трудности вызывали упражнения по определению стейкхолдерской позиции по речи стейкхолдеров, как тяжело давалось практическое освоение работы с онтиками (а ведь это и есть view+viewpoints!), я понял, что с системным мышлением без какого-то дополнительного тренинга в этой области ничего не получится. Так что я добавлю в разбирательство с проектом ещё и эти кусочки. Будем играть в ролевые игры, изображать стейкхолдеров. Да, безо всякого стейкхолдерского мастерства, уж как умеем. Главное -- эту работу с материалом курса на проектах из жизни нужно практиковать, щупать самому руками, смотреть глазами, привыкать улавливать на слух. Практикум. Делать. Глаза боятся, руки делают. С мозгами то же самое: глаза боятся, мозги думают.

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

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