Блог*

#prog #meme Незаменимая вещь

Некоторое время назад у меня перед глазами проскочил сайт для генерации красивых картинок с кодом https://carbon.now.sh/ Мне понравилось, расстроила только необходимость использовать интернет и браузер для такой мелочи. И тут мне буквально сейчас попалась вот эта консольная тулза https://github.com/Aloxaf/silicon Она генерит отличные иллюстрации и умеет работать с буфером обмена Вот эта командаа теперь висит у меня в алиасе silicon --from-clipboard --to-clipboard -l $LANGUAGE

Ахаха, в поиск в телеге можно вставить текст вместе со стилями

#prog #article 10 Most(ly dead) Influential Programming Languages

Простите

#prog #meme с привкусом анимэ

#prog #article Why Does "=" Mean Assignment? The usual answer is “because of C”. But that’s just passing the buck: why does C do it that way? Let’s find out!

#prog #meme 🌚

#prog #article Alan Kay Did Not Invent Objects tl;dr Interviews done 30 years later are not good primary sources.

#prog #article Maybe Comments SHOULD Explain 'What' Please don’t use this as justification to write bad code, okay? Okay.

Блестящая карьера. Глянцевая карьера. Матовая карьера. Карьера софт-тач.

#prog #rust #meme

#meme

https://t.me/yashin_russia/661 Товарищ майор — это публика, усекли?

#prog #article #performancetrap The 'premature optimization is evil' myth I have heard the “premature optimization is the root of all evil” statement used by programmers of varying experience at every stage of the software lifecycle, to defend all sorts of choices, ranging from poor architectures, to gratuitous memory allocations, to inappropriate choices of data structures and algorithms, to complete disregard for variable latency in latency-sensitive situations, among others. Mostly this quip is used defend sloppy decision-making, or to justify the indefinite deferral of decision-making. In other words, laziness. It is safe to say that the very mention of this oft-misquoted phrase causes an immediate visceral reaction to commence within me… and it’s not a pleasant one. In this short article, we’ll look at some important principles that are counter to what many people erroneously believe this statement to be saying. To save you time and suspense, I will summarize the main conclusions: I do not advocate contorting oneself in order to achieve a perceived minor performance gain. <...> What I do advocate is thoughtful and intentional performance tradeoffs being made as every line of code is written. Always understand the order of magnitude that matters, why it matters, and where it matters. And measure regularly! <...> Given the choice between two ways of writing a line of code, both with similar readability, writability, and maintainability properties, and yet interestingly different performance profiles, don’t be a bozo: choose the performant approach. Eschew redundant work, and poorly written code. And lastly, avoid gratuitously abstract, generalized, and allocation-heavy code, when slimmer, more precise code will do the trick. <...> These kinds of “peanut butter” problems add up in a hard to identify way. Your performance profiler may not obviously point out the effect of such a bad choice so that it’s staring you in your face. Rather than making one routine 1000% slower, you may have made your entire program 3% slower. Make enough of these sorts of decisions, and you will have dug yourself a hole deep enough to take a considerable percentage of the original development time just digging out. <...> There aren’t many ways to introduce a multisecond delay into your program at a moment’s notice. But I/O can do just that. Code with highly variable latency is dangerous, because it can have dramatically different performance characteristics depending on numerous variables, many of which are driven by environmental conditions outside of your program’s control. As such it is immensely important to document where such variable latency can occur, and to program defensively against it happening. <...> I can’t tell you how many times I’ve seen programmers employ unsafe pointer arithmetic to avoid the automatic bounds checking generated by the CLR JIT compiler. It is true that in some circumstances this can be a win. But it is also true that most programmers who do this never bothered to crack open the resulting assembly to see that the JIT compiler does a fairly decent job at automatic bounds check hoisting. This is an example where the cost of the optimization outweighs the benefits in most circumstances. The cost to pin memory, the risk of heap corruption due to a failure to properly pin memory or an offset error, and the complication in the code, are all just not worth it. Unless you really have actually measured and found the routine to be a problem. <...> I’m not saying Knuth didn’t have a good point. He did. But the “premature optimization is the root of all evil” pop-culture and witty statement is not a license to ignore performance altogether. It’s not justification to be sloppy about writing code.