Just waterfall harder

No, a spec is not code. It's possible to describe simple behavior that's nevertheless difficult to implement. Consider, say,

  fn sin(x: f16) -> f16

There are only 64k different f16s. Easy enough to test them all. A given sin() is either correct or it's not.

Yet sin() here can have a large number of different implementations. The spec alone under-determines the actual code.

good read. thanks for sharing

I agree with the overall structure of the argument but I like to think of specifications like polynomial equations defining some set of zeroes. Specifications are not really code but a good specification will cut out a definable subset of expected behaviors that can then be further refined with an executable implementation. For example, if a specification calls for a lock-free queue then there are any number of potential implementations w/ different trade-offs that I would not expect to be in the specification.

I’d say it differently - that without code the spec is insufficient. Maybe you don’t need a full program as the spec but without some code, you’re left trying to be precise in natural language and that’s not what they are good for.

Meh, it's the age old distinction between Formal vs Informal language.

Simply put: Formal language = No ambiguities.

Once you remove all ambiguous information from an informal spec, that, whatever remains, automatically becomes a formal description.

Kind of, that is why non-functional requirements exist, because not everything is code.

just like what djikstra said

Called tests yeah