🚀 go-pugleaf

In article <93022.184813U35395@uicvm.uic.edu>, C. M. Sperberg-McQueen
<U35395@uicvm.uic.edu> wrote:
> 
> > Because some of us do write large Prolog programs that depend on efficiency,
> > and it's better to instill good programming habits from the beginning than to
> > overcome bad programming practice later on.
> 
> Proof, I guess, that using a logic programming language does not make us
> logical.  If I were willing to accept your equation of 'good programming
> habits' with fast code, I wouldn't have posted my note about writing
> Prolog as though it were Pascal with commas.  If you want to make anyone
> believe it, you should provide an argument or two in favor of it, not
> just say it again.

Ok, so here are some reasons.  The most important one is that the code I
posted follows a regular and common pattern that Prolog programmers the
world over will quickly recognise and understand.  If you want to
communicate, you must speak the language (and I don't mean syntax).  As a
bonus, the introduced relation max/3 is useful in its own right, such as
when you wish to take the maximum over a second list.  As for you
(apparent) claim that Heiner's code is more "declarative", I count 3 cuts
(one is redundant) vrs. one (local) cut in my version.  Who are you trying
to kid???

> The real problem for me in your note, however, is your assertion that
> relying on Prolog's declarative semantics is 'bad programming practice'.
> The relative clarity of its declarative interpretation is one of the
> most appealing things about Prolog -- God forbid we should begin to
> think of it as a 'bad habit' if we take advantage of one of the best
> features of the language!
>
> If you write big systems that have to be optimized to be fast, you have
> a right to worry about writing fast code.  You do not have the right to
> spread the pernicious falsehood that speed is the only criterion of good
> code.
> 

There is nothing particularly optimised about my code; it was written to
take best advantage of Prolog's strengths (esp. pattern matching), while
avoiding obvious non-declarative inelegancies (the cut).  It just happens
to be fast.  This is the daily experience of the proficient Prolog
programmer -- write your code as cleanly as you can, and performance will
come naturally.

-- John Hamer                           Email: J_Hamer@cs.aukuni.ac.nz
-- Department of Computer Science
-- University of Auckland, New Zealand.