Попробую чуть более полно раскрыть свой взгляд на то, что получилось с докладом. И еще на несколько связанных с этим вещей.
Итак, Иван Пузыревский сделал толковый доклад, в котором провел слушателя от возникновения необходимости использования асинхронного программирования на примере работы с операциями ввода-вывода, до идей promise/future и перехода к сопрограммам. Хотя в самом докладе для меня ничего нового не было, для большинства слушателей, думаю, доклад был более чем интересен. Возможно, для многих доклад Ивана открыл новый мир, про который они были не в курсе.
А раз многие люди не знают про то, что такое асинхронное программирование вообще и как оно может быть реализовано, то вполне уместным мог бы быть доклад, вроде "Actors for fun and profit" с CoreHard Autumn 2017. Но не в чистом виде, а разбавленный большим количеством примеров кода.
Это навело меня на мысль, что имеет смысл подготовить доклад на тему "Actors vs CSP vs Tasks vs ...", в котором будет рассматриваться решение какой-то одной (или не одной) несложной задачки с помощью нескольких подходов. Мол, вот у нас есть акторных подход, который характеризуется тем-т и тем-то. Есть CSP-подход, который почти как акторный, но отличается тем-то и тем-то. Есть еще вот такой подход... И вот есть у нас такая задача. С помощью акторов мы ее решаем вот так, а с помощью CSP вот так, а с помощью task-ов вообще не решаем, ибо забабахаемся...
Надо будет подумать на эту тему. Если кто-то хотел бы услышать такого плана доклад, то дайте знать. А если у вас есть интересная задачка, которую можно было бы разобрать, то дайте знать тем более. Ну не на обедающих же философах подобный доклад базировать.
Теперь о том, о чем я рассказывал на C++ Russia 2018. С одной стороны, мне показалось, что примеров кода с какими-то пояснениями не хватило. Скажем, когда я говорил, что наличие хорошей поддержки ООП в C++ -- это достоинство, то можно было бы это на примере проиллюстрировать. Но, с другой стороны, при тестовых прогонах я едва укладывался в 40 минут даже с тем материалом, который был. Добавлять еще 1-2 слайда и 3-5 минут дополнительного рассказа было очень стремно. Так что этот недостаток я постараюсь исправить при подготовке текстовой версии доклада.
Однако, чем больше я думаю о том, как можно больше и лучше привлекать внимание к SObjectizer-у, тем больше прихожу вот к чему:
Есть определенный класс библиотек/фреймворков, надобность которых не вызывает больших вопросов. Например, работа с регулярными выражениями. Или работа с TCP-сокетами. Или работа с файловой системой.
Ведь всем же очевидно, какие задачи решаются такими библиотеками/фреймворками. Кроме того, такие библиотеки широко востребованы. Ведь практически каждому программисту рано или поздно потребуется иметь дело с регуляркой или чтением содержимого каталога на диске.
Но есть и другие библиотеки/фреймворки. Использование которых вызывает определенные вопросы само по себе или же в сочетании с конкретным языком программирования.
Например, библиотека для поддержки software transaction memory для C. Или библиотека lock-free структур данных для Ruby или Perl-а. Или библиотека для реактивной обработки потоков данных для C++. Ну или вот, как в случае SObjectizer-а, библиотека акторов для C++.
Проблема здесь заключается в том, что a) люди далеко не всегда знают, о чем вообще идет речь, и b) не всегда очевидно, зачем это все для конкретного языка программирования. Вряд ли многие Ruby-программисты имеют представление о lock-free структурах данных вообще. И, даже если часть из них в должной степени просветить, то следом встанет вопрос -- а имеет ли смысл применять оные структуры в программах на Ruby? И даже если смысл в этом есть, то для какого процента Ruby-новых программ это будет иметь смысл?
Предположу, что похожая ситуация есть и в отношении STM и, скажем, plain old C.
Вот мне кажется, что с акторами и C++ что-то очень похожее. Хотя тут все-таки получше, чем с STM :) Но все равно не просто.
И, кстати говоря, для меня лично сложность с рассказом про модель акторов и ее применимость в том, что, с моей точки зрения, акторы -- это такой же инструмент, как и нити/потоки (они же threads). Поэтому объяснять, где и когда выгодно применять акторов, почти то же самое, как объяснять где и когда применять многопоточность. Ведь, в общем-то тривиальная вещь. Многие сами разбираются, где им нужен многопоточный код, а где однопоточный, даже не сильно об этом задумываясь. Тоже самое происходит и с акторами.
Похоже, что единственный выход тут -- это брать какую-то несложную задачу и разбирать ее на пальцах. Только вот какую именно? Мы не можем сослаться на то, что мы делали в прошлом. Это уже не наш код, нам никто не разрешал разглашать информацию о том, что мы делали. К сожалению. Поэтому нужно будет выдумать какую-то подходящую задачу самостоятельно. Либо же кто-то из читателей поделится своей задачей. Но направление движения становится понятнее.
Комментариев нет:
Отправить комментарий