среда, 1 марта 2023 г.

[prog.c++] Продолжение экспериментов с шаблонами для улучшения tagged_value_t

Данный пост продолжает тему, начатую на прошлой неделе. В комментариях к первой заметке ув.тов.Константин подал идею об использовании операторов сравнения в виде свободных функций. Что показалось интересным и многообещающим.

Давеча удалось эту идею проверить. Результат мне понравился. ИМХО, так можно гораздо проще расширять функциональность шаблона tagged_value_t, чем в случае наследования от вспомогательных классов.

Получившееся решение показано под катом. Поиграться с ним можно на wandbox.

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

[life.cinema] Очередной кинообзор (2023/02)

Внезапно закончился очередной месяц и подошло время очитываться о просмотренных фильмах. Хотя отчитываться особо не о чем, да и смотреть особо нечего. Из всего нижеперечисленного внимания может заслуживать разве что сериал "Парижская полиция 1905", да и то с оговорками :(

Фильмы

Подставной город (Jojakdoen dosi, 2017). Динамичная корейская фантастика. Если корейское кино очень нравится, то можно и глянуть. Если же не нравится, то лучше не тратить время.

Хранитель тайн (Objetos, 2022). Первые 2/3 фильма казались вполне себе ничего и смотрелись интересно, но вот финал все испортил.

Сериалы

Парижская полиция 1905 (Paris Police 1905, 2022). Это продолжение сериала Парижская полиция 1901. Кому зашел первый сезон, тот может глянуть и второй. Но мне показалось, что второй сезон слабее, следить за происходящим не так интересно.

Расследование (Efterforskningen, 2020). Неплохо, но скучновато. Сократили бы на две серии, хотя бы, и смотреть было бы интереснее.

Ланцет (первый сезон, 2019). Вплоть до последней серии смотреть было интересно и даже не хотелось придираться к косякам, которые то тут, то там проскакивали. Но в финальной серии создатели так развязали все протянутые через сериал ниточки, что мне лично это сильно испортило все впечатление от просмотра.

понедельник, 27 февраля 2023 г.

[prog.thoughts] ИМХО, не есть хорошо, когда приходится выбирать между "быстрым" и "удобным" языками

Около месяца назад статью "Performance of Kafka Consumers: 1 Billion messages". Ничего интересного или полезного для себя там не нашел.

Но одна мысль засела в голову после прочтения и не отпускает до сих пор. Попробую эту мысль озвучить.

В конце статьи есть абзац:

Maybe Go’s performance overshadows Python, but Python is developer friendly. Of course, I can choose Python in these scenarios. If I don't need a performance or need to develop minimized consumer or I need to one-time run/remove console app. But when I need performance or huge numbers, I would rather Go without question.

Т.е. автор говорит, что когда нужна производительность, то Go его выбор без вопросов. Но когда важно удобство (да и скорость написания кода, пожалуй), то Python.

А вот мне сама необходимость делать такой выбор кажется не то, чтобы странной (хотя да, и странной в том числе), сколько ненормальной.

Ведь одно дело, когда мы выбираем между условными Ada/C++/Rust и не менее условными Java/C#/Scala/Kotlin. Тогда понятно, что небезопасные нативные языки берутся в рассмотрение не просто так, а потому что либо нужно опускаться на весьма низкий уровень, либо нужно выжимать последние крупицы производительности (объективности ради нужно сказать, что есть и другие факторы в пользу группы небезопасных нативных языков, но это уже совсем другая история).

Но вот когда речь идет о языках, которые изначально создавались для удобства программиста, а не для скорости исполнения или тотального контроля за всем и вся... То откуда берется эта ложная дихотомия?

Казалось бы, бери себе Kotlin или C# и не парь мозги. Будет и достаточно удобно, и достаточно быстро. Но нет, зачем-то нужно делать выбор между Go и Python. Нипанятна :)


Еще одно впечатление от упомянутой выше статьи: никакого интереса к задаче извлечения большого объема данных из Kafka не возникло. Хотя могу предположить, что это и нужная, и интересная задача, сопровождающаяся сложными техническими моментами. Однако нет, не торкает. А вот сделать что-то вроде Kafka -- вот это уже совсем другое дело... Ну а чего еще ожидать от хронического велосипедостроителя? ;)