I especially like this one:

https://news.ycombinator.com/item?id=45549017

Wilson’s Algorithm gives the most pleasing visual results for me.

Added above - thanks!

The article goes over my head by building too many arguments to sustain its case.

For me it's much simpler to articulate:

Human relationships are build on trust and mutual respect. Once that is gone, the relationship goes out the window as well and it's not coming back.

Counter intuitively, relationships between countries seem to function mostly the same way, instead of being based strictly on interest and practicality as one might expect.

Once trust is strained until it breaks, it's not going to be the same from then on.

Looks pretty amazing, especially a bit zoomed out!

The 3D/street view version is an obvious and natural progression from here, but from what I've read in your dev log, it's also probably a lot of extra work.

I'm not sure how this is accomplished, but I like the "poetic" translation a lot more than the "optimal" one.

Which reminds me, do you think it's possible that the stories in the Bible are actually mystic symbolism and "veiled truth" (like the sort of stories that you might get in a dream) and people have mistaken it for actual physical history (with which it's obviously incompatible)?

The parables of Jesus come to mind. They weren't meant to be taken literally but to teach, to get a point across.

There are a great many views about this depending on who you talk to. In Christian circles, it’s essentially the infallibility vs inerrancy topic, with fundamentalist denominations leaning toward inerrancy (which is the view that original manuscripts have complete historical accuracy).

Obviously, you have to take a strong “religion first” lens to everything about the world from there.

But of course, there were ancient cultures that pre-date Judaism (and by extension Judeo-Christian sources), which share many similar stories but with different details and descriptions. Large scale flood myths and arks are common in history. You can read the Mesopotamian version in the Epic of Gilgamesh, which is strikingly similar to Noah’s ark.

Yes, the main churches can only stick to the traditional interpretation. What else could they do? Anything else would be pretty much well, blasphemy.

But I think my favourite interpretation that I've heard so far is that the stories in the Bible are like the protective husk that preserves the kernel of truth. The stories are catchy and have stuck, unwittingly allowing the truth to be carried across the centuries, safely hidden in the minds of men who did not understand it, until the day comes when people grow up enough, to the point where they could crack the shell and eat the fruit.

I really like how that sounds like, but of course, there are probably not many others who see it in that light. Luckily for me, these days they don't burn heretics any more (at least where I live :)).

You present the Bible as one text composed at one time, but I’ve never known anyone to take that view. The Bible can’t “take itself incredibly seriously” because it spans millennia in time, including at least a hundred years after Jesus. Hundreds of years after that is when “The Bible” as we know it today was even assembled from pieces during unification. Before that, early Christians had hundreds of religious texts and through a process of negotiable, brought them together under the Roman state. I’m sure if you read something like the infancy gospels which are not included in the Bible, you could probably also find similar themes.

Of course the stories remained culturally relevant through oral traditions and Jewish law. The common thread is culture and the stories of a people.

Optimize for sweeping efficiently: NP-hard

Optimize for human satisfaction: NP-hardest

That's amusing. I remember there is this site where you can read 40 year old "news", as discussed here:

https://news.ycombinator.com/item?id=46017175

But I couldn't say how many people it cured of reading the news so far.

My controversial opinion:

If Rust were to "borrow" something from the C/C++ spirit, then disabling the borrow checker should be available as a compiler option.

As in, you're an adult: if you want it, you can have it, instead of "we know better".

If you could disable the borrow checker globally, projects would do it, and it would become impossible to compile anything with it enabled.

You can already disable it locally: the unsafe keyword is for that.

The unsafe keyword doesn't disable the borrow checker... it lets you interact with different pointer types that aren't borrow checked, but if you're using the normal reference types in rust the same guardrails are still in place.

That's not the spirit Rust wants to have. You can already disable borrow checker selectively by using "raw" pointers in places where you think you know better, and this is used very commonly. Every String in Rust has such raw pointer inside.

It doesn't make much sense to globally relax restrictions of Rust's references to be like C/C++ pointers, because the reference types imply a set of guarantees: must be non-null (affects struct layout), always initialized, and have strict shared/immutable vs exclusive access distinction. If you relax these guarantees, you'll break existing code that relies on having them, and make the `--yolo` flag code incompatible with the rest. OTOH if you don't remove them, then you still have almost all of borrow checker's restrictions with none of the help of upholding them. It'd be like a flag that disables the sign bit of signed integers. It just makes an existing type mean something else.

Doesn’t work - you need the borrow checker guarantees to implement downstream compilation steps. You can just turn off assumptions

> you need the borrow checker guarantees to implement downstream compilation steps.

You don't technically. The borrow checker doesn't effect the semantics of the program (like, for example, type inference does) and the rest of the compiler doesn't need to (and in fact, doesn't) use its analysis to figure out how to compile the code.

The downstream compiler does assume that the code followed the rules for accessing references - i.e. didn't violating aliasing rules. The borrow checker guarantees this, but it's fundamentally a conservative check. It rejects programs it can't guarantee are correct, and rice's theorem proves that there are always correct programs that it can't guarantee are correct.

That said if you just treat rust-references like C-pointers you will run into issues. The aliasing rules for rust references are stricter. Also not fully agreed upon yet - the currently closest to accepted definition is in the "tree borrows" paper but it has yet to be adopted as the official one by the rust team.

Is rust simple aesthetics to you? Why use rust, or any language at all really, at all then? The whole point of formal languages is to point a gun at the people who refuse to be adults.

If we can't have this, C itself offers zero benefit over assembly.

I think it's more in the spirit of playfulness, like in "don't take yourself too seriously". It's why people want to mod Minecraft and Doom for example.

Because it's fun.

I can totally understand why you wouldn't want to do this though - the plethora of incompatible lisp dialects come to mind. That's why I said it was controversial.

You don't think assembly is more tedious to write than C? I don't think that's because of what C does/doesn't "allow" you to do.

Of course it is. C does allow named functions and variables. C doesn’t allow arbitrary jumps.

Those are two reasons why C is less tedious than assembly.

> C doesn’t allow arbitrary jumps.

Have you heard of longjmp?

That's good to know, but I've noticed it was added in C++26 and seems to be supported in GCC 15 and Clang 19, but not MSVC.

I think in a few (3-4?) years it will be safe to use, but in any case not now.

Still, good to know that it exists.

I would assume that this is easy enough to implement that it will likely appear in a minor update to the upcoming Visual Studio version. MS kept updating the compiler since VS 2022, too.

I certainly hope so, but we'll see. To give an example, std::chrono::current_zone (C++20) still doesn't work on Android even to this day.

So as long as #embed isn't supported by all the 3 major compilers, I am sticking with my current embedding setup. I guess that's what I was thinking of.

It's kind of ironic since AI can only grow by feeding on data and open source with its good intentions of sharing knowledge is absolutely perfect for this.

But AI is also the ultimate meat grinder, there's no yours or theirs in the final dish, it's just meat.

And open source licenses are practically unenforceable for an AI system, unless you can maybe get it to cough up verbatim code from its training data.

At the same time, we all know they're not going anywhere, they're here to stay.

I'm personally not against them, they're very useful obviously, but I do have mixed or mostly negative feelings on how they got their training data.

Getting an email from an AI praising you for your contributions to humanity and for enlarging its training data must rank among the finest mockery possible to man or machine.

Still, I'm a bit surprised he overreacted and didn't manage to keep his cool.