![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
catpadМы тут на работе организовали доморощенный курс по С++ и вообще программированию для людей без всякого компьютерного образования, которые хотят продвигаться.
Я подвизался его вести.
15 занятий уже прошло, всё более-менее нормально, и вот дошли до multithreading. И тут их прямо замкнуло. То есть, они понимают, что всё происходит одновременно, тут проблем нет. Но вот дошли до места, где один thread передает другому данные через BlockingQueue. Сначала они никак не могли понять, что функции одного и того же класса, могут бежать в разных threads. Наконец, после долгих раздумий, одна девушка говорит: а зачем вообще нужна эта очередь? Почему нам просто не бросить данные из одного thread в другой?
И это меня прямо-таки ввело в просветление. Это же просто коан, если задуматься. Хлопок одной ладони. Думал-думал, и говорю — но мы же ровно это и делаем с помощью очереди — передаём данные из одного thread другому! Но она этот ответ не приняла (и я сильно подозреваю, что и все остальные тоже). Зачем нужен промежуточный этап (очередь какая-то), если можно просто послать вот эту штуку (instance) вот оттуда вот сюда?
Тут я совсем надолго задумался, и в принципе, думаю до сих пор. По всей видимости, проблема в том, что люди, далёкие от этого дела, не понимают разницы между data и execution. Я попробовал объяснить это так: вот смотрите, thread — это инструкции, которые не то чтобы живут в CPU, а исполняются там одна за другой, а данные — это то, что живет в памяти, и не исполняется, а просто существует. Дело усложняется тем, что инструкции работают не просто так, а с этими самыми данным, при этом сами инструкции (не процесс их исполнения, а их материальное воплощение, запись о них, тоже живёт в памяти, просто в другом месте — ну, это ладно).
Кстати, пока писал, подумал: дело ещё усложняется и тем, что если смотреть на source code, то там действительно и переменные, и код функций, всё перепутано — какие-то функции в одном классе, какие-то в другом, при этом всё это может быть в разных threads без всякой системы. Какие-то переменные — члены одного класса, но изменяются из разных threads, другие принадлежат разным классам, но изменяются из одного; какие-то функции запускают новые threads — и так далее, до бесконечности.
В общем, вопрос получился чисто философский. В обычном мире вроде бы нет такой проблемы: все более или менее понимают разницу между объектами мира и процессами, которые выполняются во времени и работают с этими объектами. А в компьютере почему-то у людей случился сбой — тот же принцип оказался непонятным. Почему так, не знаю (хотя подозреваю, что правильный ответ в последней мысли предыдущего абзаца).
no subject
Date: 2020-07-18 11:34 pm (UTC)В итоге человек сразу въезжает в функции, классы и ООП и даже что-то там понимает, потому что эти концепции логичны и отражают наше мышление. Но при этом в голове у человека создаётся искажённая картина того что на самом деле происходит в компьютере. Тем тяжелее потом перестроить своё понимание в свете новой информации. Пример с классами и тредами очень показательный. Я заметил что часто люди представляют себе классы (даже не объекты классов, а классы) как некие живые сущности со свойствами, методами и пр. Даже тот факт, что объектов класса может быть много часто удивляет. Потому что обычно-то как раз их не много, и зачастую вообще один, особенно при обучении.
По моему опыту с этим можно бороться только одним способом: объяснить как работает компьютер. Как процессор молотит числа, как работает стэк, доступ к памяти и пр. И уже на этих кирпичах строить более высокие абстракции. Как только люди это уясняют, то сразу пропадает вся мистика ООП и "сложность" мультитреда, например. Часто людям помогают аналогии из жизни. Можно представить треды как поваров, которые работают в одной кухне. Код это рецепт на стене, который все читают. А изменяемые данные это продукты в холодильнике. Повара не могут одновременно взять какой-то продукт и начать его резать, должны договориться кто берёт первым, кто вторым и т.д.
no subject
Date: 2020-07-19 12:13 am (UTC)Вы не поверите, насколько точно у нас совпадают мысли. Я тоже считаю, что это огромное зло, что людям часто преподают какие-то языки и при этом вообще ничего не объясняют, как это всё работает внутри. Особенно бессмысленно преподавать С++ и не показывать, что происходит в памяти.
Я встречал людей, которые программируют на С++ (и в общем, хорошо его знают), но не понимают, чем heap allocation отличается от stack allocation и что, например, если у тебя очень большой статический (или просто локальный) массив внутри функции, то это не повлияет на быстроту вызова функции. Или если ты хочешь менять поинтер внутри функции, то его надо передавать by reference (аргумент был: ну как - это же уже поинтер, зачем его by reference?)
Поэтому два самых первых занятия (4 часа, между прочим) я посвятил только разбору того, что происходит на стеке при вызове функций с разными типами аргументов (by value, by ref, by pointer); где и сколько живут локальные переменные; где хранятся разные типы данных в памяти; что есть program counter и как это всё связано. Потом ещё дал им домашнее задание нарисовать каждое изменение стека и все вообще все stack frames при работе рекурсивной функции factorial(3).
Но, как видите, всё равно не помогло. Хотя, я понимаю, что без этого всё было бы ещё гораздо хуже. По крайней мере, они теперь свободно оперируют понятиями scope, lifetime, heap и т.п.
no subject
Date: 2020-07-19 04:13 am (UTC)Ну, это вопрос философский. Если статический - не повлияет, я если локальный, да еще и проинициализирован, то надо же страницы виртуальной памяти выделять и заполнять их чем-то. Если ОЧЕНЬ большой - это займет время. А если ОЧЕНЬ-ОЧЕНЬ большой, то тупо стек кончится и время выполнения функции станет очень маленьким :)
no subject
Date: 2020-07-19 04:38 am (UTC)Я им показывал пример именно static, так что с этой точки зрения всё чисто.
Не думаю, что им вообще нужно знать про виртуальную память.
no subject
Date: 2020-07-19 02:20 pm (UTC)no subject
Date: 2020-07-20 08:32 am (UTC)У меня вообще сложилось такое убеждение, что языки стоит преподавать где-то в самом конце обучения на CS. Как у врачей специализация. А до этого то, что общее между всеми языками.
no subject
Date: 2020-07-20 04:20 pm (UTC)no subject
Date: 2020-07-20 09:34 pm (UTC)Преподаешь Питон - начинай с переменных, строк, циклов, функций и т.п. Память никого не волнует.
Преподаешь Эрланг - начинай с multithreading и pattern matching.
Преподаешь Лисп - начинай с рекурсии.
Преподаешь С++ - начинай с памяти, поинтеров, стека, хипа и т.п. Потому что первый же шаг - что такое operator new? почему нельзя вернуть референс на локальную переменную? почему моя переменная ещё жива, если я вызвал десять тысяч функций из этого места? - и всё пропало. В этом случае никого не волнует электричество и как устроен процессор, так что с этого начинать не надо.
no subject
Date: 2020-07-21 08:44 am (UTC)То есть, наверное, так: есть языки, где можно начинать не с глубины, а с поверхности. И есть языки, где никакой поверхности нет, начинать нужно сразу с глубины. Но рано или поздно до глубины всё равно придётся дойти. Ну или остановиться на каком-то промежуточном уровне - как ты пишешь, править заголовки, писать документацию.
no subject
Date: 2020-07-21 08:55 am (UTC)Но это уже зависит от целей учеников. Кстати, ученики подобрались очень усердные, делают домашние задания, честно стараются!
no subject
Date: 2020-07-21 09:34 am (UTC)