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.
evolution is a wrong concept to approach it. cancer is not a separate life form, but a bug in the regeneration system of a complicated life form. it doesn’t exist outside of it, it cannot propagate.
Excuse me, but I think zig grows ever better from driving away users who are driven away by flashy headlines and whatever is the opposite of this “activism” you suggest.
bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams?
zig is on its way to improving compilation times in its own pace and does so for the benefit of the project and everyone involved, so what is left to care for about bun by anthropic’s past?
the “(super) efficient” is not there yet. Io is still dynamic dispatch with multiple layers of indirection. afaik it’s slower than before.
the upcoming releases are expected to provide a solution to this “dispatch is comptime-known, but still dynamic” problem, and drop the loses in efficiency.
scheme is great, but the dx of some implementations is not. i’m on guile scheme due to guix, and frankly, i’m hating it a quite bit.
stack traces are esoteric and error messages entirely unhelpful,
documentation masquerades as deep but is indeed inconsistent and prosaic, mixing styles of reference, explanation, and how-to willy-nilly, (compare with Dybvig’s The Scheme Programming Language, which is focused and consistent, and it takes no time to get your answers; there’s just no method to guile and guix manuals), i hate it big time,
there’s big gaps in documentation (especially with Guix – there’s literally zero information about `define-record-type*` which is used everywhere in its codebase; admittedly, not scheme related, but still),
the cli requires too much memorization,
most modules are not named, but numbered, ie, instead of something like `(base list)`, you get `(srfi srfi-1)`, so you need to either memorize, or go through the info pages for each procedure you need to import, which means you also need to know the exact names for the procedures you need beforehand,
there’s like 4 ways to define a record, each with a different feature set and incompatibilities,
etc.
these are the reasons i find it hard to use.
to respond to the content of the article, the different neurotype idea is off, because scheme allows you very well to express sequences of operations; the ecosystem of APIs may not cater to this tho. although if it was rephrased into “scheme emphasizes symbolic manipulations, as opposed to operating a machine”, i would agree
that’s why we say that with such discoveries we receive a new way – of looking, of doing, of thinking… these new paths preexist in the abstract, but they can be taken only when they’ve been opened. and that is as good as anything “new” gets.
(and such discoveries are often also inventions, for to open them, a ruse is needed to be applied in a specific way for the way to open).
it can’t really be a way to think about it when the recommendation is to not think about it and just do it. experience, observe, reach opinion. all in accordance with you and not some number that’s abstract to your perception.
IDEs made the mistake of locking the user into desktop-traditional keybinding paradigm instead of using a more flexible one which would allow for implementation of both vim and desktop paradigms.
(don’t respond with “well they have vim mode plugins”. no they don’t. they’re hacky and unreliable)