codeflo

> our ancestors insisting on eating toxic things like mushrooms and spoiled food

Presumably this didn't happen because are ancestors were dumb, but rather because the ability to process slightly spoiled food is a significant advantage in an environment where fresh food is sometimes scarce?

It's still a wild logical leap to me that we went from this observation, that maybe the bottom half of users never learn how the software works, to the idea that we should build software that is actively learning-hostile. In the old era, we established consistent UI patterns: this kind of button does X, this kind of button behaves like Y, here are the tools to solve your problem. Maybe not everyone learned the patterns, but those that did became wildly productive. Now: who cares if buttons are recognizable as such, your bottom half of users tap all over the place anyway, so design for them exclusively. It's good to enable more people, but we also lost something in the process.

They say it's a modified version Source Sans, but then don't compare it with Source Sans to show the differences. The only comparison is with their previous, unrelated font (Whitney SSm). Why?

> unaware of the bun AI-rewrite-to-rust saga

I seem to be mostly unaware, at least, it's not self-explanatory to me why a Rust rewrite would be that baffling. What's the verdict on the Bun rewrite, and how does that relate to pnpm's decision? Also, wasn't Bun switching from Zig to Rust instead of from TypeScript to Rust like pnpm? I get the impression that many web infrastructure projects have been switching to more native languages.

Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)

I think in the background of article's premises is an argument about classical vs. intuitionistic logic, rather than only about the merits of putting stuff in the kernel vs. outside.

Isabelle seems to use classical logic and set theory. Classical logic is often simpler, but when you do the "hard toil" (as the article puts it) of building recursive functions on set theory, all you've really done is to nonconstructively prove the existence of a set of pairs with certain properties. Good luck evaluating such an abstract "existence" with any concrete argument. Whereas intuitionistic logic as used by Coq is more complicated, but that's in part because its notion of "function" is an actual procedure in your computer that can accept an argument and produce a result.

At least that's to the best of my understanding; it's been a while since I have looked at any of this, so feel free to make corrections.

A light switch not working for 30 seconds, or a door not opening for 30 seconds, even if only sporadically, is a significant loss of life quality, no qualifiers needed.

There's a widespread misconception (not shared by the article author) that floating point arithmetic is "imprecise" in the sense that the result is off by some amount of random noise. On the contrary, IEEE floating point results are precisely specified to produce the closest representable value to the mathematically exact result.

For efficiency reasons, library functions (and sometimes, sadly, hardware implementations) don't always guarantee this (closest representable) exact result. That's fine if the function is then called "approximate_inverse_square_root" or something. Sometimes being off by some epsilon is a good tradeoff for 10x efficiency. I'm unhappy when such a tradeoff is smuggled into my math library without warning.

I checked Rust's source code to confirm the article's claim that it doesn't have a precise log function, and indeed, here's the implementation:

    pub fn log(self, base: f64) -> f64 {
        self.ln() / base.ln()
    }

I'm sure other math libraries aren't better. But this is not a correct implementation of arbitrary-base logarithm. A function like that perhaps shouldn't even be offered in the standard library at all (since it's so trivial to begin with), or at the very least, not with that name. If a programmer wants to opt-in to a fast but slightly wrong value, they should do so explicitly, in my opinion.

It can be useful for pure translation tasks and stuff like that where you explicitly don't want creativity of any kind.

Regardless of what? Programming is solved, I hear, with all the 100x productivity PhD-level automated coding loops they have going. Don't make excuses for them when they disprove their own bullshit.

> These theories are flawed in the sense that they cannot account for subjective experience and agency, amongst other things.

On the contrary, it's precisely this assumption, that there is a "subjective experience" that requires explanation beyond the material, that is axiomatically assumed without evidence. It falls apart quickly, any "subjective experience" is completely tied to neurons, knock out the neurons and the subjective experience disappears, or stimulate the neurons to cause the experience.

It's clear that YouTube doesn't want you to have much influence over your feed. You can't even ban specific channels from being shown to you, which would be the simplest thing to implement, and other knobs that previously existed were silently removed.

Since Google does nothing that isn't based on metrics, we can deduce that they have data to show that giving people settings to focus the recommendations on what they want reduces total watch time. We'll only get an AI filter if it turns out that AI slop offends people so much that they disengage with YouTube altogether, which outside of HN and similar bubbles, I don't yet see happening.

> If AI music allows someone with less formal musical skills to feel like they are joining in and making something, then maybe it has its value.

An emphatic no. What we need to do is to stop comparing every hobby performance, whether it's music or dancing, with the top 10 artists in their field. We need people to learn, and try, and feel safe to be visible and thus vulnerable in group situations without fear of being mocked on social media for eternity. To achieve this, we need to stop filming people, and we need a societal norm that treats a violation of this ban on par with spitting someone in the face. We need to celebrate amateurs that simply try to improve their raw, honest skills.

What we don't need to do is to give everybody a Fisher Price toy with a "make it sound awesome" button. We need human connections.

It seems like I simply misunderstood the point of the "game of telephone" metaphor. To be honest, even with your added explanation, I don't fully get why you express it that way. But I think we're in agreement on the substance, and I shouldn't have worded my response so harshly.

> You can't load an integer from an unaligned address.

You can, and the results are machine specific, clearly defined and well-documented. Ancient ARM raises an exception, modern ARM and x86 can do it with a performance penalty. It's only the C or C++ layer that is allowed to translate the code into arbitrary garbage, not the CPU.