![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Некоторые философские размышления насчёт программирования
Мы тут на работе организовали доморощенный курс по С++ и вообще программированию для людей без всякого компьютерного образования, которые хотят продвигаться.
Я подвизался его вести.
15 занятий уже прошло, всё более-менее нормально, и вот дошли до multithreading. И тут их прямо замкнуло. То есть, они понимают, что всё происходит одновременно, тут проблем нет. Но вот дошли до места, где один thread передает другому данные через BlockingQueue. Сначала они никак не могли понять, что функции одного и того же класса, могут бежать в разных threads. Наконец, после долгих раздумий, одна девушка говорит: а зачем вообще нужна эта очередь? Почему нам просто не бросить данные из одного thread в другой?
И это меня прямо-таки ввело в просветление. Это же просто коан, если задуматься. Хлопок одной ладони. Думал-думал, и говорю — но мы же ровно это и делаем с помощью очереди — передаём данные из одного thread другому! Но она этот ответ не приняла (и я сильно подозреваю, что и все остальные тоже). Зачем нужен промежуточный этап (очередь какая-то), если можно просто послать вот эту штуку (instance) вот оттуда вот сюда?
Тут я совсем надолго задумался, и в принципе, думаю до сих пор. По всей видимости, проблема в том, что люди, далёкие от этого дела, не понимают разницы между data и execution. Я попробовал объяснить это так: вот смотрите, thread — это инструкции, которые не то чтобы живут в CPU, а исполняются там одна за другой, а данные — это то, что живет в памяти, и не исполняется, а просто существует. Дело усложняется тем, что инструкции работают не просто так, а с этими самыми данным, при этом сами инструкции (не процесс их исполнения, а их материальное воплощение, запись о них, тоже живёт в памяти, просто в другом месте — ну, это ладно).
Кстати, пока писал, подумал: дело ещё усложняется и тем, что если смотреть на source code, то там действительно и переменные, и код функций, всё перепутано — какие-то функции в одном классе, какие-то в другом, при этом всё это может быть в разных threads без всякой системы. Какие-то переменные — члены одного класса, но изменяются из разных threads, другие принадлежат разным классам, но изменяются из одного; какие-то функции запускают новые threads — и так далее, до бесконечности.
В общем, вопрос получился чисто философский. В обычном мире вроде бы нет такой проблемы: все более или менее понимают разницу между объектами мира и процессами, которые выполняются во времени и работают с этими объектами. А в компьютере почему-то у людей случился сбой — тот же принцип оказался непонятным. Почему так, не знаю (хотя подозреваю, что правильный ответ в последней мысли предыдущего абзаца).
no subject
Ну а чо, Эрланг, мессаджи, вот это все. Blocking queue это же implementation detail
no subject
А посмотри на его имплементацию на С++, и мы опять возвращаемся ко всяким очередям. И опять ступор...а...а...а почему бы не бросить этот мессадж прямо в этот процесс?
no subject
Знаешь эту картинку ?
https://images.app.goo.gl/C5hfmeS8FdKrhQq38
no subject
no subject
no subject
no subject
В итоге человек сразу въезжает в функции, классы и ООП и даже что-то там понимает, потому что эти концепции логичны и отражают наше мышление. Но при этом в голове у человека создаётся искажённая картина того что на самом деле происходит в компьютере. Тем тяжелее потом перестроить своё понимание в свете новой информации. Пример с классами и тредами очень показательный. Я заметил что часто люди представляют себе классы (даже не объекты классов, а классы) как некие живые сущности со свойствами, методами и пр. Даже тот факт, что объектов класса может быть много часто удивляет. Потому что обычно-то как раз их не много, и зачастую вообще один, особенно при обучении.
По моему опыту с этим можно бороться только одним способом: объяснить как работает компьютер. Как процессор молотит числа, как работает стэк, доступ к памяти и пр. И уже на этих кирпичах строить более высокие абстракции. Как только люди это уясняют, то сразу пропадает вся мистика ООП и "сложность" мультитреда, например. Часто людям помогают аналогии из жизни. Можно представить треды как поваров, которые работают в одной кухне. Код это рецепт на стене, который все читают. А изменяемые данные это продукты в холодильнике. Повара не могут одновременно взять какой-то продукт и начать его резать, должны договориться кто берёт первым, кто вторым и т.д.
no subject
Вы не поверите, насколько точно у нас совпадают мысли. Я тоже считаю, что это огромное зло, что людям часто преподают какие-то языки и при этом вообще ничего не объясняют, как это всё работает внутри. Особенно бессмысленно преподавать С++ и не показывать, что происходит в памяти.
Я встречал людей, которые программируют на С++ (и в общем, хорошо его знают), но не понимают, чем 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
Ну, это вопрос философский. Если статический - не повлияет, я если локальный, да еще и проинициализирован, то надо же страницы виртуальной памяти выделять и заполнять их чем-то. Если ОЧЕНЬ большой - это займет время. А если ОЧЕНЬ-ОЧЕНЬ большой, то тупо стек кончится и время выполнения функции станет очень маленьким :)
no subject
Я им показывал пример именно static, так что с этой точки зрения всё чисто.
Не думаю, что им вообще нужно знать про виртуальную память.
no subject
no subject
У меня вообще сложилось такое убеждение, что языки стоит преподавать где-то в самом конце обучения на CS. Как у врачей специализация. А до этого то, что общее между всеми языками.
no subject
no subject
Преподаешь Питон - начинай с переменных, строк, циклов, функций и т.п. Память никого не волнует.
Преподаешь Эрланг - начинай с multithreading и pattern matching.
Преподаешь Лисп - начинай с рекурсии.
Преподаешь С++ - начинай с памяти, поинтеров, стека, хипа и т.п. Потому что первый же шаг - что такое operator new? почему нельзя вернуть референс на локальную переменную? почему моя переменная ещё жива, если я вызвал десять тысяч функций из этого места? - и всё пропало. В этом случае никого не волнует электричество и как устроен процессор, так что с этого начинать не надо.
no subject
То есть, наверное, так: есть языки, где можно начинать не с глубины, а с поверхности. И есть языки, где никакой поверхности нет, начинать нужно сразу с глубины. Но рано или поздно до глубины всё равно придётся дойти. Ну или остановиться на каком-то промежуточном уровне - как ты пишешь, править заголовки, писать документацию.
no subject
Но это уже зависит от целей учеников. Кстати, ученики подобрались очень усердные, делают домашние задания, честно стараются!
no subject
no subject
Телефонная линия, провода вроде как общие.
А без протокола (типа "да", "ты меня слышишь?" и.т.д - или "перехожу на прием".) ничего не получится - они либо будут говорить одновременно - и не слушать друг друга, или оба молчать: слушать.
no subject
Да и вообще, будьте проще. 90% задач решаются без параллельности. У начинающего часто создается ощущение, что если че медленно, надо распараллелить, вместо того, чтобы сначала подумать о другом подходе.
Да и вообще, ну зачем рядовому необученному C++? Зачем это людям без компьютерного образовния?
no subject
А параллельность и в частности очередь возникла только потому, что мы там разбираем реальную программу, которая нужна по работе.
no subject
no subject
no subject
no subject
no subject
С++ решает те проблемы, о которых эти люди вообще не понимают, что такие проблемы существуют и как/где/откуда могут возникнуть. Т.е. эти люди могут "вызубрить" правила языка, но для глубокого понимания нужен реальный серьёзный опыт разработки.
> на работе организовали доморощенный курс по для людей без всякого компьютерного образования, которые хотят продвигаться.
А зачем, если не секрет ?
no subject
А выбор языка обусловлен исключительно рабочей необходимостью. У нас 90% проектов на С++.
no subject
Почему не хотят профильных специалистов нанять ?
Почему им не продвигаться там где у них уже есть опыт и знания ?
no subject
no subject
Так то данные и "бросaть" не надо: доступ то к ним у обоих есть.
no subject
no subject
Но всё равно, одно дело понимать в чём тут проблема - а другое дело суметь аккуратно проблемы синхронизации решать не имея хорошего базового CS-образования. В последних версиях STL есть поддержка параллельности, что может несколько облегчать это пряча детали реализации, но всё равно я не уверен насколько новички-неспециалисты могут тут справиться.
no subject
no subject
Это, на мой неискушённый взгляд, некоторая утопия - взять человека без компьютерного образования, и попытаться обьяснить ему проблемы распараллеливания.
Или как написали выше - начинать с азов строения компьютера. Или такой язык, который прячет все детали от программиста, включая проблемы распараллеливания.
Но "короткий курс по С++" для последующей профессиональной работы - фу-фу-фу.
no subject
Собственно, оба предсказания сбылись: кое-кто уже изменил две строчки в одном проекте, а кое-кто отконфигурировал файлы :)
Но иметь общее представление о происходящем совсем неплохо.
no subject
Про то, что общее представление - неплохо, это как "не бывает лишних знаний". Вроде, оно и правда, но какая-то не очень полезная :)
no subject