That's part of the point of Worse is Better, too. https://www.jwz.org/doc/worse-is-better.html

I have a hard time accepting the premise that a language is better because you have to hope that it does what you want instead of telling it, and for that reason it has become successful.

In fact, the ANSI C spec even states from your link that "Undefined behavior gives the implementer license not to catch certain program errors that are difficult to diagnose." That's just not an acceptable tradeoff anymore -- in fact I don't know it ever was. That's akin to shipping your org chart because you can't make your program do what everyone agrees it should do. You know, catch programming errors, in this case.

The paper argues that some behaviors being undefined let compilers target the widely varying architectures of the early microcomputer era, while still using a language that remains at least somewhat portable between them.

Yes, but your program isn't doing what you think you told it to, which is worse, because the compiler tells you that it will, know what I mean? A false guarantee of safety is kind of the worst.

> Yes, but your program isn't doing what you think you told it to,

Your program is still doing what you told it to if you weren't relying on any undefined behavior (Which, obviously, you shouldn't be). That's the point - if you write C that doesn't rely on any UB, then it can run on a large variety of architectures, work exactly the same on each one, and still get close to the maximum speed for each architecture because they can take the fastest possible option for any of the UB cases (And your program shouldn't care what they do in that situation).

The problem I generally have with C is that the scope of UB is really wide. Languages like Common Lisp have UB too, but it’s generally easier to avoid in “normal” code.

In CL case the "is an error" wording generally covers all of C's "implementation-defined", "unspecified" and "undefined". And surprising amount of normal looking constructs are in the implementation-defined category.

When you add type declarations and (optimize (safety 0)) into the mix you get similar scope of UB as in C (another thing is that in reality nobody actually writes code like that)

I’m thinking of things like it being UB to modify a reader literal because the reader is allowed to do things like tail sharing.

I think that modifiing reader literal is an error mostly to allow implementations to store such pairs in read-only pages (eg. in .rodata section when you build standalone executables) and to allow simple implementation of CDR-coding for reader literals (dfsch has three distinct implementations of abstract <pair> class for exactly this reason and to be able to actually signal meaningful error condition when you violate this restriction).

But it’s not an error: for some of these cases the standard doesn’t specify the consequences and most implementations don’t throw an error if you modify a reader literal, even if you end up modifying the interned list.

"Is an error" is wording used by the standard for things that are left undefined. For things that should signal some kind of error condition the standard uses wording "an error is signalled", the set of such cases is surprisingly small.

If you are hitting UB, then you haven't really told the compiler anything. Do what I mean is not really a thing yet. The compiler can't read the programmer head.