🚀 go-pugleaf

In article <602@quintus.UUCP >  ok@quintus.UUCP (Richard A. O'Keefe) writes:
 > 	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.
 > 
 >                            * * * 
 > 
 > 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).

A tip of the hat to Richard for his well-penned remarks.
I am amazed at the power of Prolog to solve a problem in
combinatorial logic without being given an explicit method.
But I am also disheartened by the difficulty of untangling
the effects of reordering the clauses.

When a bright student solves a brain-teaser, the order in which
the clues are stated does not strongly affect the method of
solution.  In Prolog, resequencing the clues can have dramatic
effects on the search order.  I find this phenomenon bewildering.

--Barry Kort