Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.prolog
Subject: Re: Prolog's Pitfalls?
Message-ID: <2952@skye.ed.ac.uk>
Date: 9 Jul 90 20:09:52 GMT
References: <1990Jun18.221058.11331@chaos.cs.brandeis.edu> <3305@goanna.cs.rmit.oz.au>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 163

In article <3305@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>>     Isn't Prolog an awkward, often obscure programming 
>>     language useful for just a few application domains?

[Richard goes on to defend Prolog at length.]

There would be a lot fewer disagreements of this sort if it were not
for the difference between what certain advocates of Prolog promise
and what the language actually delivers, and if not for the attitude
certain advocates of Prolog take towards other languages.  Some
skepticism about Prolog is, I think, a natural result.

I think Richard's defense is, on the whole, a fair one.  Nonetheless,
he is too quick to dismiss certain points and he uses a bit too much
rhetoric along the lines of "Gods below, but I'm sick of this.  When
will these people grow up?".

>There are several points that can be made even without knowing anything
>about Prolog.
>
> -- obscurity as a property of a programming language has much to do
>    with the person making the claim and the instructional material
>    that person has been exposed to.

This sort of observation is all very well, but it's far from the whole
story.  If something's hard to understand, maybe it really *is* hard
to understand.  If instructional material tends to be confusing, maybe
that says something about the language.  You happen to be very good
at explaining Prolog, but maybe it says something about the language
that many other people meet with less success.

Another thing to bear in mind is that different people are good at
different things, and it's not surprising that some people find that
Prolog suits them very well.  However, we can't ignore the problems
of the rest.

For example, I happen to like the syntax of Lisp and to find it very
readable.  Moreover, I have found that many people who find Lisp's
syntax difficult have not been taught the effective techniques for
dealing with it or have been using editors which fail to help them.
Nonetheless, this does not mean that everyone will come to like
the syntax if only they are taught the right ways of thinking and
given appropriate tools.  And even if everyone could come to like
Lisp, the fact remains that the syntax often works against it in
practice.

> -- the awkwardness of a language is best assessed by someone who has
>    made a determined effort to become fluent in it.  Pascal is more
>    awkward than a zooful of mules.  C is as awkward as a greased hammer.
>
>    A *very* good way to experience a language X as awkward is to try
>    to use it as if it were language Y which you already know.

This is true in some cases but not in others.  It is often very
effective to use one language in the style of another.  To pick a
fairly extreme example, I have used Basic as if it were Lisp with
good results.

> -- I myself don't see Prolog as a general-purpose language.  So what?

>    If Prolog is useful for a few application domains, that's all the
>    justification it needs.

Maybe so, but that's not all the justification it gets.

>What has quicksort to do with Prolog?

The large number of times it is used to show how easy and natural it
is to express things in Prolog.  [To be fair, the functional language
folk often do the same.]

>Prolog has never failed any one of *my* expectations.

Surprise!  Remember that you understand Prolog very well.  A number
of other people aren't in the same position.

>> 1. Notwithstanding Peter van Roy's admirable benchmark results, Prolog 
>> implementations tend to be slow for many programs.  (e.g., quicksort
>> in Prolog vs. in C).

[Lots about performance on quick and other sorts deleted]

But Richard, do you deny that Prolog implementations tend to be slow
for many applications as compared to, say, C?  Are all the people who
have experience that would suggest this just mistaken?

>> 2. I have yet to see an elegant marriage of logic and functional 
>> programming.  It seems clear that functional syntax is needed.
>
>I thought we disposed of that just a little while ago.

Yes, you think a little syntactic sugar is enough; others don't.
If enough is added to prolog so that one can write higher-order
functions and anonymous functions (lambda expressions), though,
I suppose *I'd* be satisfied.  Having most things curried, as in
SML, would be nice too.

>> 3. Prolog's fixed depth-first search order and left-to-right computation
>> rule are too inflexible (e.g., for AI and expert system applications). 

>Gods below, but I'm sick of this.  When will these people grow up?
>Prolog is a *PROGRAMMING* *LANGUAGE*.  Ada, C, Lisp, Scheme, they all
>have exactly the same depth-first left-to-right computation rule as
>Prolog.  This makes them useless for AI and expert systems applications?
>Get real!

Yes, but again and again one is told that Prolog *has* search or that
it *has* backtracking or that it *has* pattern-matching -- they don't
have to be *added* like they do in other (inferior) languages.  The
expectation is created that Prolog will do a lot of things as-is, when
the reality is that one often has to write code to do them, just as
one has to when using other languages.

>- You have to pass all needed parameters to procedures.

>  This really is not a big deal in practice if you will only try to write
>  *Prolog* code instead of trying to write Pascal code in Prolog.  If you
>  want to know how to do that, my services as a teacher of advanced Prolog
>  courses _are_ for hire...

Maybe it's not a big deal for *you*, but quite a few people, some of
whom haven't learned any language other than Prolog (and so haven't
been influenced by Pascal directly), and others who are very
experienced Prolog programmers (and so should have learned better
if it's as easy as you say), write procedures with unreasonable
numbers of parameters.

>- Adding new parameters is a pain.
>
>  (a) Design your program right in the first place.  I'm serious.
>  (b) This is a property of programming environments, not of languages.
>      Ever use Masterscope?  (.EDIT WHERE ANY CALLS FRED)  Great tool.

Given tools that do enough of the work for you, all problems go away.
Thus, we can remove all the problems of COBOL, FORTRAN, etc, and all
languages are perfect.  So?

>There is an ambiguity in "uses lots of memory".  It could mean "turns over
>a lot of cells" (true).  It could mean "needs a lot of storage at any one
>time" (false).

A good point, and one that needs to be made.

>It's worth noting that the single-assignment property is precisely what
>makes functional languages like ML and logic-based languages attractive
>for parallelism.  (It's getting late or I'd elaborate on this.)

Ditto, although it's made rather too often.  

>About cuts and assert, I will only say that competent Prolog programmers
>know that the fewer of them they use, the faster their programs are likely
>to be.

One wonders how they become competent Prolog programmers when so many
Prolog texts give the opposite impression about the role of cut.

>At this late date, do I need to say once again that Prolog is not the
>only logic programming language?

This is another way in which all problems can be made to disappear.
Let's deal with one language at a time.

-- Jeff