A specification language is desirable. (Test cases are special cases of
specifications. Test-driven development is a revival of the waterfall
process.) For specifying interactions (computer-computer or
computer-human), I recommend "live sequence charts" of David Harel, or
generally any one based on temporal logics.
The problems with natural languages or sublanguages for anything from
specification to implementation are:
0. You have to transit to formal languages at some point (the
implementation is formal). The later you transit, the later you can use
a computer to analyze and/or simulate for catching mistakes. You catch
fewer mistakes, and later.
1. To re-gain the benefit of formality above, some people settle for
restrictive sublanguages. Thus naturalness is lost anyway. The problems
below, however, are still preserved.
2. Natural languages and sublanguages lack diagrams. For some
specifications, formal diagrammatic languages are more suitable (e.g.,
live sequence charts).
3. Natural languages and sublanguages lack scoping and parenthesizing
such as in mathematical notation and formal languages:
sqrt (sin (x^2 + y) - 2) * z
(forall r. (Int -> M r) -> M r) -> M Int
forall r. ((Int -> M r) -> M r) -> M Int
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
