1.94K subscribers
3.53K photos
136 videos
15 files
3.76K links
Блог со звёздочкой.

Много репостов, немножко программирования.

Небольшое прикольное комьюнити: @decltype_chat_ptr_t
Автор: @insert_reference_here
Download Telegram
"Cloud-native" is a catch-all term for widely adopted shitty technology, such as Go and YAML
💯14🌚3👍1
#prog #c #article

You (probably) don’t need to learn C

I’m all for learning C if it will be useful for the job at hand, but you can write lots of great software without knowing C. [выделение моё]

A few people repeated the idea that C teaches you how code “really” executes. But C is an abstract model of a computer, and modern CPUs do all kinds of things that C doesn’t show you or explain. Pipelining, cache misses, branch prediction, speculative execution, multiple cores, even virtual memory are all completely invisible to C programs.

C is an abstraction of how a computer works, and chip makers work hard to implement that abstraction, but they do it on top of much more complicated machinery.
5💩3👍2😁1
Блог*
В этом случае достаточно поменять тип поля irrelevant на UnconditionallyEqual<String> — и можно будет использовать стандартный #[derive(PartialEq)] для достижения требуемого функционала.
#prog #rust

Кое-что я при написании этого поста упустил. Именно, к хэшированию предъявляется логичное требование: если два значения равны, то их хэши также равны. UnconditionallyEqual в том виде, как я написал, не реализовывает Hash, поэтому #[derive(Hash)] работать не будет. Тем не менее, заставлять программиста вручную писать реализацию Hash из-за наличия одного такого поля — не лучший UX. Поэтому стоит написать реализацию Hash для UnconditionallyEqual. Из-за изложенного выше требования и того факта, что UnconditionallyEqual не влияет на операцию равенства, корректной реализацией будет noop:

impl<T> Hash for UnconditionallyEqual<T> {
fn hash<H: Hasher>(&self, _state: &mut H) {}
}
🍌2
#math #article

Hobby’s algorithm for aesthetic Bézier splines

Разновидность сплайнов для "гладкой" интерполяции точек, которая быстро работает (пропорционально числу точек) и зачастую даёт эстетически приятные результаты. Из недостатков: передвижение опорных точек меняет форму всей кривой, и малое передвижение опорной точки может привести к радикальной смене формы кривой в районе этой точки.

В самом начале есть интерактивная демонстрация.
🤔2
#prog #rust

Одна из клёвых вещей, которые есть в #zig — это синтаксис для многострочных строковых литералов:

const hello_world_in_c =
\\#include <stdio.h>
\\
\\int main(int argc, char **argv) {
\\ printf("hello world\n");
\\ return 0;
\\}
;


Большим преимуществом этого синтаксиса является тот факт, что он позволяет с лёгкостью сделать отступ для литерала целиком и при этом не добавлять этот отступ в сам литерал, а также требует минимального экранирования (всё до перевода строки — содержимое строки). Аналогичный код в, скажем, Rust, требует такой неприятной вещи:

    let hello_world_in_c = "\
#include <stdio.h>\
\n\
\nint main(int argc, char **argv) {\
\n printf(\"hello world\\n\");\
\n return 0;\
\n}";


и поддержки со стороны компилятора для того, чтобы экранирование перевода строки убирало не только сам перевод строки, но и предшествующие пробельные символы. Обратите внимание на то, что мне также пришлось экранировать кавычки и \n в коде. Сырые строковые литералы позволяют убрать экранирование, но не лишние отступы:

    let hello_world_in_c = r#"#include <stdio.h>

int main(int argc, char **argv) {
printf("hello world\n");
return 0;
}"#;


Именно по этой причине есть аж два RFC (раз, два), которые добавляют новые виды строковых литералов для подобных целей (включения многострочного кода на другом языке). Тем не менее, в обсуждении второго один человек заметил (и тут дела приобретают #abnormalprogramming оборот), что имитировать многострочные литералы из Zig в Rust в некоторой мере можно уже сейчас. Именно, doc-комментарии уже на этапе лексирования заменяются на #[doc]-атрибуты, а потому можно макросом извлечь эти литералы из атрибутов и сконкатенировать:

macro_rules! text {
(#[doc=$first_line:literal] $(#[doc=$lines:literal])*) => {
concat!($first_line, $("\n", $lines),*)
};
}
let hello_world_in_c = text! {
///#include <stdio.h>
///
///int main(int argc, char **argv) {
/// printf("hello world\n");
/// return 0;
///}
};
🥴192🤔2
Я тут с оказией фаззил один из npm-модулей, который парсит YAML и узнал, что в YAML есть конструкция в виде трёх точек - ...

... doc-end Explicit marker for the end of a document.
https://github.com/eemeli/yaml/blob/main/docs/07_parsing_yaml.md#lexsource-string-string

И реально в спеке такое есть (было бы удивительно, если бы не было, конечно 🌝)

Three dots ( “...”) indicate the end of a document without starting a new one, for use in communication channels.
https://yaml.org/spec/1.2.2/

---
time: 20:03:20
player: Sammy Sosa
action: strike (miss)
...
---
time: 20:03:47
player: Sammy Sosa
action: grand slam
...


Я просмотрел и написал какое-то бесчисленное количество YAML-файлов и не видел ни в одном из них этой конструкции.
🤷4🤔2👍1
👍8❤‍🔥1😁1
Кинь, пожалуйста, проверку интеллекта. Только для себя, а не для персонажа


#quotes
😁153🌚2
POSIX позволяет создать и использовать хэш-таблицу!

Но только одну

Source

#prog #suckassstory
🤡19🤯8😱3
Было бы #трудовыебудни, если бы не тот факт, что это было вчера
🤔4🌚3😭1
AGI так-то существует уже 75 лет
🤩8