Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!pacbell!lll-tis!lll-winken!arisia!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: The meaning of "declarative"
Message-ID: <602@quintus.UUCP>
Date: 30 Oct 88 00:44:11 GMT
References: <ALF.88Oct2184429@hathor.sics.se> <818@etive.ed.ac.uk> <590@dcl-csvax.comp.lancs.ac.uk> <859@etive.ed.ac.uk> <256@aipna.ed.ac.uk> <41315@linus.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 43

In article <41315@linus.UUCP> bwk@mbunix (Kort) writes:
>In Bratko's book, the Monkey and Bananas problem handily demonstrates
>the both the power and weakness of declarative languagues.

I have never recommended this book.  I think you have misunderstood what
the example should be teaching about the power of declarative languages.
If I may be permitted to quote myself:

	The nice thing about declarative programming is that
	you can write a specification and run it as a program.

	The nasty thing about declarative programming is that
	some clear specifications make incredibly bad programs.

	The hope of declarative programming is that
	you can move from a specification to a reasonable program
	without leaving the language.

[My example wasn't as high-tech as monkey-and-bananas.  Just boring old
transitive closure.  Unimaginative, that's me.]

I say that this is what the example _should_ be teaching.
Having put together a nice clean specification, the next step is to
play with the algebra for a bit.  For example, a useful thing to do
might be to have the program start by looking for macro-operators.
(This is where Explanation-Based Learning comes in, and it turns out
to be beautifully easy to do with a modified pure-Horn-clause interpreter.)
Or you might even try bounded depth-first search:  trivially easy to do in
Prolog.

>After spending an hour or two with this problem, it is easy to understand
>why Prolog programs are hard to debug.

Eh?  If you'd said *C* programs were hard to debug, or Lisp programs were
hard to debug...  Chances are you're trying to debug at the wrong level.

One of the biggest things to grasp about declarative programming (and this
means pure Lisp, ML, Miranda, Prolog, NAIL!, you name it) is the importance
of keeping it clean and obvious so that you can play with it at a high
level, looking for transformations of the problem (leading to transformations
of the program).  The big gains are almost always to be found at the upper
levels (eliminating some operation entirely by transforming the problem
space, for example) rather than by hacking at the low levels (coding the
operation a few microseconds faster).