<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: codeflo</title><link>https://news.ycombinator.com/user?id=codeflo</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 11 Oct 2026 03:42:58 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=codeflo" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by codeflo in "Why is the liver so weirdly regenerative?"]]></title><description><![CDATA[
<p>> our ancestors insisting on eating toxic things like mushrooms and spoiled food<p>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?</p>
]]></description><pubDate>Fri, 25 Sep 2026 12:50:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=49843927</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=49843927</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49843927</guid></item><item><title><![CDATA[New comment by codeflo in "Bug Blindness"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Sun, 30 Aug 2026 07:39:44 +0000</pubDate><link>https://news.ycombinator.com/item?id=49496566</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=49496566</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49496566</guid></item><item><title><![CDATA[New comment by codeflo in "Nebula Sans"]]></title><description><![CDATA[
<p>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?</p>
]]></description><pubDate>Thu, 27 Aug 2026 13:11:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=49464374</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=49464374</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49464374</guid></item><item><title><![CDATA[New comment by codeflo in "Pnpm 12.0"]]></title><description><![CDATA[
<p>> unaware of the bun AI-rewrite-to-rust saga<p>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.</p>
]]></description><pubDate>Thu, 27 Aug 2026 07:49:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=49461327</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=49461327</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49461327</guid></item><item><title><![CDATA[New comment by codeflo in "To save C, we must save ABI (2022)"]]></title><description><![CDATA[
<p>Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)</p>
]]></description><pubDate>Tue, 11 Aug 2026 08:59:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=49255170</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=49255170</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49255170</guid></item><item><title><![CDATA[New comment by codeflo in "Why is it all in the kernel?"]]></title><description><![CDATA[
<p>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.<p>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.<p>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.</p>
]]></description><pubDate>Wed, 05 Aug 2026 07:04:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=49179508</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=49179508</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49179508</guid></item><item><title><![CDATA[New comment by codeflo in "Zigbee vs. Matter over Thread:Understanding IoT Protocol Performance in Practice"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Wed, 05 Aug 2026 06:25:00 +0000</pubDate><link>https://news.ycombinator.com/item?id=49179251</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=49179251</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49179251</guid></item><item><title><![CDATA[New comment by codeflo in "Log is non-monotonic in PHP and Lua"]]></title><description><![CDATA[
<p>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 <i>precisely</i> specified to produce the closest representable value to the mathematically exact result.<p>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.<p>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:<p><pre><code>    pub fn log(self, base: f64) -> f64 {
        self.ln() / base.ln()
    }
</code></pre>
I'm sure other math libraries aren't better. But this is <i>not</i> 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.</p>
]]></description><pubDate>Wed, 29 Jul 2026 07:38:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=49094475</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=49094475</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49094475</guid></item><item><title><![CDATA[New comment by codeflo in "HackerRank open sourced its ATS. My resume scored 90/100. Oh wait 74. No – 88"]]></title><description><![CDATA[
<p>It can be useful for pure translation tasks and stuff like that where you explicitly don't want creativity of any kind.</p>
]]></description><pubDate>Mon, 29 Jun 2026 08:58:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=48716640</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=48716640</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48716640</guid></item><item><title><![CDATA[New comment by codeflo in "Claude: Elevated errors across many models [resolved]"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Tue, 16 Jun 2026 18:39:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=48559972</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=48559972</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48559972</guid></item><item><title><![CDATA[New comment by codeflo in "They’re made out of weights"]]></title><description><![CDATA[
<p>> These theories are flawed in the sense that they cannot account for subjective experience and agency, amongst other things.<p>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.</p>
]]></description><pubDate>Thu, 04 Jun 2026 09:37:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=48396255</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=48396255</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48396255</guid></item><item><title><![CDATA[New comment by codeflo in "YouTube to automatically label AI-generated videos"]]></title><description><![CDATA[
<p>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.<p>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.</p>
]]></description><pubDate>Thu, 28 May 2026 07:27:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=48305782</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=48305782</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48305782</guid></item><item><title><![CDATA[New comment by codeflo in "YouTube to automatically label AI-generated videos"]]></title><description><![CDATA[
<p>> 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.<p>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.<p>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.</p>
]]></description><pubDate>Thu, 28 May 2026 07:19:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=48305721</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=48305721</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48305721</guid></item><item><title><![CDATA[New comment by codeflo in "Everything in C is undefined behavior"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Wed, 20 May 2026 16:03:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=48209932</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=48209932</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48209932</guid></item><item><title><![CDATA[New comment by codeflo in "Everything in C is undefined behavior"]]></title><description><![CDATA[
<p>> You can't load an integer from an unaligned address.<p>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.</p>
]]></description><pubDate>Wed, 20 May 2026 08:54:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=48204899</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=48204899</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48204899</guid></item><item><title><![CDATA[New comment by codeflo in "Everything in C is undefined behavior"]]></title><description><![CDATA[
<p>> The compiler, and really the underlying hardware too, is playing a game of telephone with your UB intentions.<p>The part about hardware is wrong BTW. In all the cases about null pointers and out-of-bounds access and integer overflow and whatnot, the hardware semantics are clearly defined, and the assembler code does exactly what is written. The way modern compilers act on your code makes C less safe than assembler in that sense.</p>
]]></description><pubDate>Wed, 20 May 2026 08:50:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=48204850</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=48204850</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48204850</guid></item><item><title><![CDATA[New comment by codeflo in "The Zig project's rationale for their anti-AI contribution policy"]]></title><description><![CDATA[
<p>I don't get that impression at all. LLMs would have avoided the stylistic repetition of "live". Asking an LLM to reformulate the sentences you quoted yields this slop:<p>> There are a lot of people who go through life by vibing. And honestly: that’s not automatically “bad.” Sometimes it’s even the only workable way to get through things. The issue is that “vibe-first” people tend to have a pretty loose relationship with truth, rigor, and being pinned down by specifics. They’ll confidently move forward on what <i>sounds</i> right instead of what they can verify.<p>I'll finish this post with a sentence containing an em-dash -- just to confuse people -- and by remarking on how sad I find it that people latch onto dashes and complete sentences as the signifiers of LLM use, instead of the inconsistent logic and general sloppiness that's the actual problem.</p>
]]></description><pubDate>Thu, 30 Apr 2026 10:51:32 +0000</pubDate><link>https://news.ycombinator.com/item?id=47960658</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=47960658</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47960658</guid></item><item><title><![CDATA[New comment by codeflo in "Framework Laptop 13 Pro"]]></title><description><![CDATA[
<p>Last I checked, one kidney might not even suffice to pay for 256GB anymore.</p>
]]></description><pubDate>Tue, 21 Apr 2026 20:04:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=47853825</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=47853825</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47853825</guid></item><item><title><![CDATA[New comment by codeflo in "A communist Apple II and fourteen years of not knowing what you're testing"]]></title><description><![CDATA[
<p>I don't disagree with that, but that's not what was discussed. The person I was replying to was asserting that the Soviet union couldn't have developed semiconductors because unlike the US, it didn't have "a vast civilian customer base that let it recoup R&D expenses". My argument is that "recouping" anything doesn't matter in a planned economy.</p>
]]></description><pubDate>Wed, 15 Apr 2026 18:21:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=47783076</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=47783076</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47783076</guid></item><item><title><![CDATA[New comment by codeflo in "A communist Apple II and fourteen years of not knowing what you're testing"]]></title><description><![CDATA[
<p>Of course in any economy, there are scarce resources, and skilled labor is certainly one of them. What I'm specifically arguing against is the assertion that in a planned economy, the existence or lack of a <i>customer base</i> would in any real way impact the allocation of those resources. That's not a helpful way to analyze the decisions of the communist planning committee.</p>
]]></description><pubDate>Wed, 15 Apr 2026 15:18:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=47780335</link><dc:creator>codeflo</dc:creator><comments>https://news.ycombinator.com/item?id=47780335</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47780335</guid></item></channel></rss>