I think the issue here is not "Don't Repeat Yourself", but "Don't Reinvent the Wheel". If your wheel is just a circle of wood, you're better off building it yourself than hiring a skilled (or sometimes not so skilled) laborer. Too much overhead and risk.

If Linux does that, I really hope it can be done in a standardized way that doesn't make porting to *BSD more difficult than it already might be. Standards are a good thing.

But it already has a name; this noble art is called "programming", or better yet: "hacking".

I think the old Lisp tradition of using lists for everything is related to this somehow. On the other hand, in Common Lisp programmers can define custom types that have to fulfill a predicate function. Then, if they declare the types of their functions, most implementations will generate type-checking code unless instructed not to. So in Common Lisp you can use lists for everything but still have type-checking, at some cost to efficiency. :D

Heh, I can especially tell the first code example is LLM-generated. Humans don't usually write comments like:

   // There are a few ways to let API callers bring their own 
   // memory, as they would in a no-malloc environment and this
   // stack-friendly c'tor is a stand-in for that. 

There's just something about this comment that doesn't feel right. I've seen these kinds of phrasings in LLM output before but I'm not sure exactly how to describe them.

Maybe the solution is to cull the bad, cliché writing from the training data.

You can just instruct the LLM not to write like an LLM.

Ugh, you're making me remember the last time I listened to NPR. It's so bad.

I listen to NPR daily and I don't think I've ever heard any of them use that phrasing.

Personally, I prefer mailing lists. The tooling is there, it's consistent, and it's powerful. And if it adds a higher bar of entry, in this day and age that seems like a plus to me.

Immutable commits seem like a pretty good base for a decentralized VCS for me. In fact, Git was designed for this use case in the first place.

The snapshot-based system requires that the patch order matters which Darcs/Pijul don’t require so long as the patches apply since they commute. This means you can pull in patches from other users at an time in any order & still get the same stable reference. If you apply patches in a different order in Git, you will get a different reference hash & some entity ends up needing to be the centralized source of truth when doing deployments & stuff—which is probably why everyone ends up having some code forge for their code base on a centralized server to “sync” the state.

And with rebase, how are the commits immutable? Seems like MS GitHub found a way to mutably drop commits recently…

Where? Just searched the entire thread for both the word "refund" and the word "credit" and I'm seeing nothing about credit being issued.

Also what's with @sasha-id talking to himself? Looks weird as all get out.

See also: https://news.ycombinator.com/item?id=47954655

Looks like he copy pasted responses he got from their support agents.