Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!gatech!purdue!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.misc
Subject: RE: Formal definitions (Re: ada-c++ productivity)
Message-ID: <17APR91.00283166@uc780.umd.edu>
Date: 17 Apr 91 00:28:31 GMT
References: <1954@optima.cs.arizona.edu> <1991Apr16.130341.27345@kodak.kodak.com>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 28

David Cok writes:

>It is my gut feel that for computations which are somewhat close to
>mathematics (e.g. sorting), the statement of a predicate giving a
>specification for a function can usually be considerably simpler than
>the statement of an algorithm for computing the result.

Using gut feelings with mathematics is a good way to learn, but not a
good way to be correct.  As I have found many times, from personal
experience :-/

As for this specific example:  in a dynamically typed language, you
can have a generic sort (which is presumably some hand-crafted marvel
with beautiful performance characteristics for both general case and
common specific cases).  So you could say  'sort blarg'.  And if you
have to give it any additional data, besides what you want sorted, it
would be to indicate some non-default sorting order (sort blarg by
date).

As for predicates being easier to specify than algorithms whose
results satisfy the predicate:  both can be implemented in a
programming language.  If implemented in executable form, the results
are tangible, and can be tested in the strictest sense of the word.

Sadly, many computer languages are considered inadequate for this kind
of development.

Raul Rockwell