&gt; Now, &quot;simplicity&quot; is a mental construct, a language UX construct.<p>My take on “simplicity” is very computational. To me, a programming language is a system of rules of inference, whose judgments are of the form “program is well-formed” (which covers syntax and type checking) and “program does this at runtime” (a reduction relation, a predicate transformer semantics, or whatever fits your language&#x27;s dynamics best). Then, simplicity is just some measure of the language&#x27;s size as a collection of rules of inference. Also:<p>0. Undecidable rules of inference (e.g., type reconstruction for a Curry-style System F-omega) are considered cheating. Undefined behavior (e.g., C and C++) is also considered cheating. Cheating is penalized by considering the entire language infinitely complex.<p>1. Languages (e.g., ML&#x27;s module system) are allowed to be defined by elaboration into other languages (e.g., System F-omega). Elaboration into a language that cheats is considered cheating, though.<p>&gt; To handle this, I think of &quot;unwieldy&quot; as a bit of a technical term. What does it mean to be unwieldy? It means that there is significant non-ignorable complexity.<p>I don&#x27;t see any complexity as ignorable at all. I just see some complexity as worth the price - but you, the programmer, need to be aware that you&#x27;re paying a price. For instance, the ease with which one can reason about Haskell programs (without the totally crazy GHC extensions) justifies the increased complexity w.r.t., say, Scheme.<p>&gt; Significant here must be defined almost probabilistically, too. If there is significant complexity which is ignorable across 99&#x2F;100 real-world uses of a language then it really should win some significant points.<p>This is ease of use, which is subject to statistical analysis; not simplicity, which is not.