Comment by zamadatix
1 day ago
This change + the existing packed struct logic will be great for working with bit packed binary headers w/o having to manually twiddle so much about the bit handling along the way.
1 day ago
This change + the existing packed struct logic will be great for working with bit packed binary headers w/o having to manually twiddle so much about the bit handling along the way.
It's so interesting to read comments like this and contrast them with the "don't read the code" type of vibes out right now. It feels like half of the developer world is optimizing low-level struct packing and the other half is YOLO'ing 300 KLOC Electron apps. Very confusing.
Same as it ever was.
yeah, remember those newfangled fancy Node.js guys who would just copy/paste from Stackoverflow without any understanding?
Or the Java guys who wrote bloated apps that wasted CPU cycles on garbage collection instead of writing in C++, like God intended?
Or the Fortran / Cobol guys who wrote in those God-damned, wasteful, useless high-level languages, instead of using assembly, like a proper programmer should?
2 replies →
Here's a description of a "real programmer" from all the way back in 1983:
https://users.cs.utah.edu/~elb/folklore/mel.html
I know which kind I want to be.
i think it's perfect: AI allows you to go incredibly deep (you have unlimited access to context to make incredibly impactful surgical changes), or you can go incredibly broad (you have unlimited access to context to tie a mind numbing amount of components together). what shakes out is the middle layer: "infra" between "algorithms" and "product".
though, to be fair, the middle layer itself is composed of this same work. so it's fractal, or turtles all the way down.
And why do you mention AI here at all? These statements are ridiculous, world didn't start last year.
I think it makes sense, if one sees that LLMs exposed various pre-existing splits in the developer world.
Those who viewed code as a means to build something else, are happy to switch to LLMs if they can build that something faster/cheaper.
Whereas, those who liked coding for its own sake, don't want to use LLMs, and fear for their jobs and their happiness.
Unfortunately for the latter group, we're moving to a world where most development is done by LLMs, and only cutting-edge or hobbyist work is done manually. E.g., Japanese artisanal wood-working and joinery is beautiful and elegant... but modern carpentry doesn't build that way.
I used to be paid to go in and fix messes of code, created by juniors who were forced to build things they didn't understand.
Now I get to fix things created by managers who enjoyed building things they still don't understand.
Zig is already great for this with ‘packed struct’ and arbitrary size ints. Allows for very clean protocol creation between systems with known properties. This is another great step in that direction.
you need different packed structs for little- and big-endian data. and casting with little-endian data is a nightmare - you need to reverse-cascade your struct fields to be in accordance with the little-endian bit-pattern. (or have a comptime function that does it for you, of course. but then you lose all declarations for the struct). what should be a simple writing down of a protocol is now a pedantic and error-prone ordeal.
Or you just go ahead and forget that big endian ever existed. It's not coming back.
1 reply →
This has been largely solved by everyone agreeing to use little endian. There aren't really use cases for wanting to convert between them.
13 replies →