Список дел в MR-е коллеги. Последний пункт:

* Дока (и его внук Жока)

#трудовыебудни

Не забывай

#music

youtube.com/watch?v=YanwyGP0Li4

#prog #meme

https://twitter.com/aussiastronomer/status/1449845046522511364

#prog #cpp

Данила снова пишет интересное. На этот раз — про то, как можно оптимизировать работу приложений, подогнав под конкретную нагрузку реализации mem{cpy, set, cmp}.

P. S.: насчёт того, что всё написано на C++, авторы немного лукавят: __builtin_memcpy_inline и __restrict не являются частью стандарта C++. Но это уже, по большому счёту, придирки

#prog #rust

Вышла версия Rust 1.56! На этот раз Вафель меня опередил, так что читайте его о нововведениях этой версии.

Только что ко мне в БК подошёл чел и предложил мне тысячу рублей, если я установлю TikTok 😐

#prog #article

В последние годы в употребление вошло словосочетание software engineer. Само это словосочетание подразумевает, что работа разработчиков программного обеспечения сравнима с деятельностью инженеров из более традиционных областей индустрии. Много копий было сломано на тему того, можно ли разработчиков и впрямь называть инженерами. К сожалению, эти умствования были малополезны, поскольку все из них были написаны разработчиками без опыта работы в традиционном инженерном деле. Как следствие, их авторы исходили не из реальных представлений о работе инженеров, а из своих стереотипов, которые имели к практике весьма опосредованное отношение.

Hillel Wayne избрал более надёжный подход: признав, что он не в состоянии самостоятельно рассуждать на эту тему, он провёл на эту тему интервью с полутора десятком людей, которые сейчас работают разработчиками, но были ранее инженерами (в их число с неожиданностью для автора вошёл Nick Coghlan, который сейчас больше известен, как один из разработчиков CPython, но до этого работал инженером системной интеграции в Boeing). Этих людей автор в дальнейшем называет "crossovers". Информацию их интервью с этими людьми автор в итоге суммировал в трёх эссе. Если вы спешите, то вот заключение из последнего из них:

To summarize my ultimate conclusions:

First of all, We software engineers are “really” engineers. All the differences people give between software and “real” engineering don’t accurately reflect what “real” engineering looks like. And the biggest difference, licensure, is a political construct, not a technical one. At the same time, there is a difference between the different ways people make software, and it makes sense to think of software developers and software engineers as distinct concepts. But even then, it’s very easy for a software developer to become a software engineer and vice versa.

Second, we are not special. There are some aspects of software engineering that are unique to software, such as the speed of iteration, loose constraints, and the consistency of our material. But software engineering has far more in common with the other forms of engineering than it has differences. The same ideas that engineers use to advance their craft are equally useful in our own domain.

Finally, there is a lot we can both teach and learn. Engineering processes are more sophisticated than ours in ways that we can extract lessons from. Traditional engineers have a stronger sense of professionalism and responsibility than we tend to. In contrast, our culture is much more open and our communities much stronger than what exists in trad engineering. And our developments in version control have the potential to revolutionize traditional engineering.

Тем не менее, сами эссе, разумеется, раскрывают тему более развёрнуто, так что всячески рекомендую их к прочтению:

Are We Really Engineers?
We Are Not Special
What engineering can teach (and learn from) us

#rust

Почему-то не выкладывал. Коллега сделал давно

Хотите добавить знание Rust в своё резюме, но у вас нет даже свободной минутки? Тогда курс «59 seconds to learn Rust» для вас!

#math

Коллекция простых визуальных иллюстраций математических принципов.

(thanks @oleg_log)

@mersinvald спасибище 🙏

#prog #article

Статья, показывающая, как можно при помощи инструмента спецификации ловить баги в многопоточном коде. Конкретно используется подход model checking.

про игры как модель мира: в амазоновской MMO New World дефляция, которая противоположность инфляции, стала настолько серьёзной проблемой, что основным способом торговли в игре стал бартер

This type of regression becomes a severe disincentive to players: what’s the point of leveling a profession if you can’t make any money from it? What’s the point of farming for items if they’re not worth any money, and you can’t afford to repair them?

https://blog.playerauctions.com/mmorpg/currency-crisis-in-new-world/

#prog #scala
Для меня это стало серьёзным доводом в пользу того, чтобы тайпклассы были в самом языке, а не прикручены сбоку в виде имплиситов

Длинный блогпост с подробным объяснением тайп констрейнтов в скале. От паттернов использования до собственной реализации.

Как работают эти магические <:<, =:=, и почему недостаточно обычных тайп баундов. Для меня при изучении скалы это долгое время был один из самых непонятных вопросов.

https://blog.bruchez.name/posts/generalized-type-constraints-in-scala/

Я плохой?

Почему у std::function есть конструкторы для "пустого" объекта?

#prog

На три вещи можно смотреть бесконечно: на горящий огонь, на текущую воду и на то, как у #python-истов горит с match.