Luckily the read heads only have one degree of freedom, so the "elevator algorithm" is sufficient: https://en.wikipedia.org/wiki/Elevator_algorithm

If you are interested in Terence Tao's personal mathematical inner world, he touches on that during his interview with Lex Friedman, which I think you might find interesting. Interviews with Kevin Buzzard sometimes touch on these themes too.

Not if you're an enterprise that wants or requires on-prem inference.

  > d = trunc(x/y);     // floor works for unsigned
  >
  > // NOTE: if only want 'd' and it's being converted to an
  > // integer then the truncate or floor operation is
  > // free in the float to integer conversion.

I've never become used to it. My impression is that the constant churn has accelerated. Plausible drivers are (1) normalize novelty as desirable (like fast fashion), (2) product developer/designer incentive structures that reward revolutionary change over progressive refinement. The global switch to subscription models and continuous deployment didn't help.

> more like services and less like physical tools that never change.

I'm not sure that constant change is a characteristic feature of services, especially not professional services.

It used to be that you bought a piece of software and used that version until you decided it was worth upgrading, like a particular physical tool. The software still evolved, just like the design of physical tools can, in principle, evolve.

All that said, agentic AI tooling is evolving so rapidly I'm not sure an expectation of stability is realistic.

https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Statement-Attr...

I don't think the article is well founded. Before you can discuss usage you need to establish the semantics for assert(). The author touches on this in the introduction but then leaves the details unexamined. In particular I'd need to know: can assertions be disabled (as with C/C++ NDEBUG)? does the project have a policy of leaving asserts in production builds? or are asserts only ever enabled for development and testing. if used in production, do you care about the overhead of checking assertions in performance critical code? if an assertion is hit does it always log and panic/terminate? or does it throw a catchable exception? What is the runtime context of the code: is it a server process with a supervision tree? is the failure paradigm "let it crash"? is it an interactive program where the only supervisor is the user? is it a use-case where a program crash is undesirable and/or safety critical? is it a library with unknown use-cases? Are the developers in full control of the program inputs and outputs that trigger asserts?

As a general principle for layered systems, when there is a policy decision to be made, lower-level code should delegate upwards to higher levels, which should implement the policy. Throwing an exception or returning an error code is frequently better than terminating (if you squint, crashing out to the supervision tree is more like throwing an exception than it is like terminating.)

> Correctness - All possible function input and output values which do not have full value coverage should have assertions covering them.

Only if you control all of the callers. Library users would prefer an invalid parameters error/exception.

> Safety - When performing operations that can have unwanted, known, or unknown side effects, assertions should be used to prevent those conditions from happening.

Why assertions? If it is safety critical, shouldn't these checks be mandatory?

> Development - Use an assertion to enforce assumptions on values and state. These assertions can optionally be compiled out of code when coupled with proper testing.

This is where preconditions/postconditions/invariants come in. If safety is important you probably want to leave them in place. A runtime contract violation should enter a fail-safe state.

> Documentation - When writing code, use assertions as self documenting guardrails around your logic. Use assertions to enforce values and state which might be unclear from documentation or hard to decipher from reading code.

I do this, but in this case you either need to be 100% sure that the exception won't get hit, 100% sure that the exception won't make it into production builds, or okay with production crashes.

  > var error = system_call(...);
  > assert(!error);