> The language specs is 700-page long, I wouldn't call that tiny

To be fair, that now includes a substantial standard library. The language + preprocessor spec ends on page 197 and starts on page 19, for a total of 178 pages.

Language spec length is meaningless unless it's in some sort of quantifiable format.

None of the specifications you cite contains a formal semantics of the language in question; that ought to be the basis on which arguments about simplicity should be founded.

(Why the lack of formal semantics? My guess is that all of these languages, to varying degree, are too complex to easily formalize...)

Means nothing if you aren't talking about what that documentation actually includes. I currently work in a language that has like 10 pages of documentation, much of which is "TODO".

The length of the spec isn't really relevant is it? Or are you implying that C is about as complex as Java?

C is significantly more complex than Java. The memory model of Java is simple (multithreading notwithstanding), because it's memory-safe and garbage collected. Not so for C, which has very subtle rules, which result in undefined behavior if broken.

The rules for java memory management could probably fill 200 pages just by itself and it's not easy to debug issues with leaks, excessive overhead and the several layers and variants of garbage collectors.

C's memory model is trivial by comparison.

The question here isn't whether it's easier to write correct C programs than Java programs, it's whether C is a simple language.

Subtle UB, as much of a headache as it can be to a programmer using the language, in this case leads to simpler implementation of a compiler.

No, it doesn't. Maybe it did in 1978, but modern C compilers have to go to heroic lengths to do things like alias analysis that would be easier if the aliasing rules of C weren't so subtle. In Java the question of "can pointer A alias pointer B" is simple (unless typeof A derives typeof B or vice versa, the answer is no). In C, due to TBAA, it's hideously complex.

If you look at software engineering and static analysis papers for a language like Java, there's often a discussion about using stuff like 2-object, 3-call site context sensitive alias analyses built on more or less fairly standardized Datalog rules. If you look at C or C++, the response is generally "you want a precise alias analysis? fall down in riotous laughter".

The rules for TBAA are complex, and many C/C++ programs violate those rules because it's so hard to actually make sure you're not violating them, and half of the purpose of using C/C++ is actually to be able to do the kind of type-punning that TBAA prohibits.

I mean writing a compiler that fulfills the specification. Whether a design complicates the implementation of alias analysis doesn't really change whether it is simple.

I think you've pointed out the distinction many miss when talking about simplicity, which results in talking past each other:

simplicity for the user and simplicity for the compiler writer are totally different things. Java is simpler for the user but more complex for the implementer, and C is more complex for the user but simpler for the implementer.