[0] https://brevzin.github.io/c++/2025/05/02/soa/

But like modules and concepts the committee has opted for staggered implementation. What we have now is effectively syntax sugar over what could already be done with asserts, well designed types and exceptions.

I agree that they’re not there yet but I don’t want to discredit the benefits of these recent advancements

This is one of the biggest traps I’ve seen in code review. Generally, everyone is coming from a good place of “I’m reviewing this code to maintain codebase quality. This technically could cause problems. Thus I’m obligated to mention it”. Since the line of “could cause problems (important enough to mention)” is subjective, you can (and will, in my experience) get good natured pedants. They’ll block a 100LOC patch for weeks because “well if we name this variable x that COULD cause someone to think of it like y so we can’t name it x” or “this pattern you used has . I would do it with this other pattern (which has its own downsides but i wont say them)”.

This is where the concept of “Correct by construction” comes in. If any of your code has a precondition that a UUID is actually unique then it should be as hard as possible to make one that isn’t. Be it by constructors throwing exceptions, inits returning Err or whatever the idiom is in your language of choice, the only way someone should be able to get a UUID without that invariant being proven is if they really *really* know what they’re doing.

(Sub UUID and the uniqueness invariant for whatever type/invariants you want, it still holds)

``` <~ foo := (a: int) { a - 1 } ```

Then at the import site:

``` ~> foo ```

* some day it’ll totally for real make it off the page and into an interpreter I’m sure :,)

A slightly less bleak example is data analysis. When I am analyzing some dataset for work or home, being able to skip over the “rote” parts of the work is invaluable. Examples off the top of my head being: when the data isn’t in quite the right structure, or I want to add a new element to a plot that’s not trivial. It still has to be done with discipline and in a way that you can be confident in the results. I’ll generally lock down each code generation to only doing small subproblems with clearly defined boundaries. That generally helps reduce hallucinations, makes it easier to write tests if applicable and makes it easier to audit the code myself.

All of that said, I want to make clear that I agree that your vision of software engineering Becoming LLM code review hell sounds like… well, hell. I’m in no way advocating that the software engineering industry should become that. Just wanted to throw in my two cents

Is what I was responding to in the grandparent of your comment

Of course, this kind of thing is easy to do wrong. Programs like D.A.R.E. and THRIVE tried going the way of fear tactics which seems to really not work well. We need to have an open and honest discussion about "yes, this is fun. But it DOES have a bad side" instead.

The last sticking point there is that it assumes people will be rational and come to the conclusion of using with moderation. Hopefully people can be rational... Otherwise I think there's no hope for us in solving the brainrot epidemic.

As for optimizations, I figure evolution-designed languages might come up with things that are hard to pattern match for more complex operations.