You raise good points! Ultimately the technical distinction between a specification and programming language comes down to the existence or not of a compiler. I

You raise good points! Ultimately the technical distinction between a specification and programming language comes down to the existence or not of a compiler. Imagine if Python came out in 1960, but without anybody building a Python interpreter. People would consider it a spec language. (Also, lots of spec languages are weaker than programming languages, to make verifying them easier. IIRC mcrl2, FDR, and Promela all fall under this category.) I still think there are practical differences, though, between a language designed for the purposes of specification and one designed for implementing programs. TLA+ has temporal predicates and cross-state nondeterminism because it makes modeling at a high-level easier, even though it makes programmatic implementation harder. That leads to different design decisions through the language. More importantly to the OP, thinking of them as fundamentally different is useful because they draw on different inspirations. It could be that PLs and SLs converge later, but their origins and lineages are still different. And that's interesting and worth studying. I don't think talking about ur-languages is as useful as talking about archetypes: "ur-" to me implies "the original", and that's a hard thing to do. TFA has some ur-s like self that aren't the original, but still are useful as archetypes. Off the top of my head, the archetypes of formal speciifcation would be * Temporal Logic (LTL, CTL, TLA) * Relational algebra (Z, B, Alloy) * Guarded Command Language (Promela, SPIN) * Process Calculi (CSP, FDR) * Labelled Transition Systems (Petri Nets, mclr2) * Just drawing a diagram and figuring out the semantics later (UML) * Abstraction over an existing programming language This is all real messy, and I see lots of overlapping concepts and unclear cases. Are state machines their own thing, part of LTS, or an implementation detail of the specification approach? Should we be distinguishing between the mathematical formalisms and the languages themselves? What about the vaster world of specifying code and not designs? etc etc etc