specification

Non-executable specifications provide greater freedom of notation for capturing the essential semantics of a task without commitment to a particular computational model, but require a greater leap in subsequently converting the specification to executable form.
...
... some 'how' specifications do not have a clear 'what' specification because clear static specifications of dynamic processes do not always exist. Programming languages can capture the dynamics of computation more clearly than mathematics and can provide a clearer uniform specification for all dynamic processes than mathematical specifications.
...
Having a non-executable formal specification of a task solves only a small part of the application programmer's problem, even if its clarity is greater than of an executable specification. The complexity of converting a 'clear' non-executable problem specification into a program may well be greater than writing the program in the first place. It has been said by both Wittgenstein and Dijkstra that we should talk about thinks only if they can be said clearly and simply. The complexity of converting non-executable specifications into correct executable programs suggests that they may not be 'natural' for the specification of programs.
...
It has by no means been established that interesting computational problems have non-executable mathematical specifications which are clearer than executable ones. Mathematical specifications may be clearer for mathematical problems such as the gcd for which mathematical notation was specifically designed, but are generally not clearer for for inherently computational problems such as the specification of language interpreters where specification by a relation between inputs and outputs or by some other non-executable notation simply does not exist. Thus the choice of level of abstraction to achieve greatest clarity depends on the problem being solved.

-- Wegner. The Object-Oriented Classification Paradigm. 1987