– Шутковал вчера про пропаганду, а сегодня Rutube забанил мой канал про ZX Spectrum за радугу на логотипе.

Думаю, ну бот, наверное, какой-то автоматический, написал в поддержку "Товарищ Сталин, произошла чудовищная ошибка!", что радуга на логотипе с начала 1980-х годов, и что это символ того, что компьютер цвета может отображать. Ответили: убирай радугу – Радиолюбители Санкт-Петербурга и Ленобласти.

#suckassstory, пожалуй

Я обычно: 😐
Я, когда рядом котик: 😍

Возможно, сегодня или завтра таки допишу и опубликую текст про property

#science

Нептун гораздо менее синий, чем многие считают.

ras.ac.uk/news-and-press/news/new-images-reveal-what-neptune-and-uranus-really-look

А вот так волшебно цветёт персик в горной деревне на острове Сикоку в долине реки Ниёдо. Фотографы называют эту локацию «Шангри-ла», но непонятно, насколько это официально.

#prog #article

Ни разу не пользовался Figma (не мой род деятельности), но читать про их технические детали, как правило, интересно.

В блоге Фигмы (это гугл-документы от мира графического дизайна) вышла отличная статья (https://clck.ru/JsUmz) о том, как они делали многопользовательский редактор макетов.

Там почти нет программистских подробностей, интересно скорее то, как они максимально упрощали решение очень сложной на первой взгляд задачи. Заявленный принцип «no more complex than necessary to get the job done» применялся и к технической реализации, и к продуктовым требованиям.

Ещё в статье есть про то, почему они не стали применять Operational Transformation и честный CRDT, как они реализовали многопользовательский undo-redo и совместное редактирование древовидных документов. Всё написано простым языком и с наглядной анимацией.

А вот ещё одна статья (https://clck.ru/JsUnC) из их блога про то, как они решали проблему совместного редактирования упорядоченных последовательностей.

Ну, допустим, #meme про бабушку

#prog #cpp #article

An informal comparison of the three major implementations of std::string

(GCC, MSVC и clang)

Все три варианта поддерживают SSO, но по разному этого достигают.

(thanks @itpgchannel)

#prog #article

#llvmweekly

https://c3.handmade.network/blog/p/8852-how_bad_is_llvm_really

TL;DR - медленно, семантика промежуточного представления (над которым производятся оптимизации) заточены на С/С++, и сделать иначе - невозможно. Ну, например, деление на 0 в LLVM - UB, а какой-то "другой" язык хочет уметь это обрабатывать. В итоге, LLVM навязывает некоторую семантику любому языку, которые хочет его использовать. Например, бесконечный цикл в rust, который некорретно оптимизировался llvm - https://github.com/rust-lang/rust/issues/28728

Зато много готовых оптимизаций из коробки.

Так же автор (очень справедливо!) вопрошает, какого хрена в коде LLVM не используются арены и пулы, везде, налево, и направо, потому что основные причины тормозов LLVM - это деревянные структуры без data locality.

У автора замена аллокатора для LLVM на mimalloc дает хороший буст в скорости (+10%).

Я систематически бенчил clang с разными аллокаторами, и остановился на tcmalloc от Google, по скорости тот же mim, но в пике жрет прямо существенно меньше памяти.

Неутешительный вывод такой - начинать разработку компилятора стоит с LLVM, а вот дальше есть варианты.

#prog #моё #article #outoflinestorage

В этот раз я написал слишком крупный для телеги пост — тут он занял бы семь сообщений. Поэтому держите ссылку на cold storage репозиторий для подобных текстов Блог*а:

Почему свойства (property) в языках программирования — это плохая идея

Pleeeease

#meme
Это правда!

#prog #cpp #article

Fun with flat_map’s non-explicit constructors

TL;DR: в коде ниже вызываются три разных конструктора flat_map:

void print_map(std::flat_map<int, int>);

print_map({ {1, 2, 3}, {10, 20, 30} });
print_map({ {1, 2}, {10, 20} });
print_map({ {1}, {10} });
print_map({ {}, {} })