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