> which produces primes.cpp, containing your program translated to idiomatic, readable C++ code:

As a C++ enjoyer I can confirm this is some excellent idiomatic, readable C++ code.

Most of it yes, but what about:

    typedef I<((I<((n::val (p::val))>::val) != (I<0>::val))> res;
    };

There is some top class wizardry going on there! I don’t think I’ve ever used conditions in a type definition in C++ :)

Update:

Ah, alright - so that evaluation logic is part of the template, not the code that eventually compiles.

It’s basically offloading some of the higher level language compiler logic to the templating engine. Honestly might be a better time investment than spending more time writing this in the parser.

Now I’m sort of intrigued and inspired to use C++ as a lowering target for elevate (a compiler framework I’ve been working on).

Do you really disagree that it’s advancing science? Surely actually testing hardware, building knowledge on how to run this type of mission, learning to use lunar resources, figuring out how to keep people alive, etc. will teach us things we couldn’t learn any other way.

Fwiw do share your concerns about the methods (sending humans on this specific mission is questionable, SLS is questionable compared to SpaceX approach).

Do you think we will learn more from Artemis or the Asteroid Redirect Mission? Because that's a concrete example of how funding this mission caused other experiments to be cancelled.

Fair point, but that’s an argument about prioritization within NASA’s budget (and its size relative to other spending), not the scientific value of the mission.

There's never non-zero value to any challenging engineering problem. The question is whether the finite resources spent to solve it are best spent on it versus other projects.

And in this mission in particular, you can't divorce science from politics. NASA's budget was reined in by Trump 45 and his admin picked Artemis because a manned mission to the moon invokes a particular feeling and memory, not because it benefits science. The moon is a known quantity, and going there is not more valuable than the other projects the government could have spent $100 billion on.

Keep in mind, this is one of the most expensive single launches in history while there is a partial government shutdown and the rest of the federal government that does real research has been gutted by this same administration. So it's tough to talk about "scientific value" when it's obvious that this mission is doing little science at the same time the government has decreed it won't be in the business of paying for science.

The moon isn’t a known quantity, we sent a handful of people there for a combined few days half a century ago. There’s immense scientific and engineering value in keeping a generation of engineers fluent in deep space operations.

If you’re angry about this dumpster fire of an administration wasting money and gutting research (I am too), the answer is to fight for better funding across the board, not to tear down one of the few ambitious programs left that’s actually pushing the boundaries on what we can do. NASA’s budget amounts to a rounding error and isn’t zero sum with the rest of federal science funding, these are separate appropriations.

I'm going to tear down spending $2.5 billion to test the toilets on a space ship every chance I get. It is a massive waste of resources and depletion of human capital that would be better spent on other projects that could advance science and human understanding.

It's not science, it's engineering. I don't think it's advancing science in a way that wouldn't be possible with a fraction of the cost without sending humans there.

The distinction is kind of meaningless, advancing our engineering capabilities in space is advancing the science.

And as I said, agreed on the concerns about cost and sending humans.

> The distinction is kind of meaningless

Only if it helps you to call this "science", I would say.

> advancing our engineering capabilities in space is advancing the science

In this case, we are advancing our engineering capabilities to make humans survive in space, which is arguably completely useless.

Not only that, but we keep focusing on the easier and fun part for engineers. A real problem for surviving in space is life support, see e.g. this: https://mceglowski.substack.com/p/a-primer-on-long-duration-....

But it is a lot less fun than sending humans around the moon in a ship that doesn't need them at all, isn't it?

> The habit takes seconds. No database. No server. No app.

> It wasn't the specialized components. It wasn't the sensors I had so many of.

> These aren't the exciting parts. They're the infrastructure that every project shares.

Apparently there’s no economic pressure toward brevity in LLM generated slop comments either.

And no, they’re not flat subscriptions. Use more tokens and your quota is gone faster.

Not true with github copilot. Cost is per prompt no matter how many tokens the prompt uses. Which can vary by 2 or 3 orders of magnitude...

Speak for yourself, I used my freedom to disable it.

A signed executable isn't for trusting the app. It's for knowing the provenance of the app. Sure, there are some application checks that happen before listing a store app, but those checks are minimal.

Signing proves someone pays Apple $100/yr. The "provenance" you're getting is literally just the billing info.

You forgot closed source. It’s a closed source dropdown menu.

If I had a nickle for every time a Mac user paid for the privilege of using a proprietary toolbar app...

The typical Apple sales pitch. Forgive me for assuming it’s only surface level.

It feels like a leaky abstraction, and similarly implies there should be some way to drop down a layer and work directly with what’s beneath. Something in between C and non-portable assembly.

Asserting retroactively that compilers produce the correct assemvbly feels like just plain giving up on everything in between. Surely the best we can do isn’t a bunch of flaky weirdly interacting optimizations, UB footguns everywhere, things changing when updating the toolchain, etc?

I have written a compiler for a language at more or less this abstraction level. It provides access to 16 general purpose registers and a set of virtual instructions that operate on these registers. I program on an intel mac so the virtual instructions all map directly to x86_64 instructions, but it would be very straightforward to write an arm backend that may compose multiple arm instructions for the equivalent x86_64 behavior. I also could support virtual registers for platforms with fewer than 16 registers.

Having this compiler, which is extremely fast (it is self hosted and self compiles its own 9750K line source file in 15ms on my 2019 macbook pro and I've seen throughout ranging from 500K to 10M lines per second for other programs), I have little interest in ever using LLVM again. I would rather just write optimal code than pray that LLVM does a good job for me. For equivalent programs, I find LLVM can be anywhere from 50-10000x slower than my compiler and doesn't necessarily produce better code. I can produce examples of LLVM code becoming significantly worse at -O2 than at -O0.

The only real utility LLVM offers me at this point is that I could use it to figure out what an optimal solution to a small subprogram might be by compiling a small c program and inspecting the output. Then I can just directly write the optimal solution instead of being perpetually bogged down by llvm's bloat as well as also being exposed to unexpected regressions in the optimizer and/or having to learn its strange incantations to get desired performance.

> Something in between C and non-portable assembly.

Writing your own LLVM passes?

Not really if you look at the prior context. It’s ruling after ruling in the favor of powerful interests (aka rights holders) when it comes to copyright enforcement. A simple correct ruling feels like a miracle.