Re: Minsky still posting

From: Matthew Huntbach (mmh_at_dcs.qmul.ac.uk)
Date: 03/18/05 

Date: Fri, 18 Mar 2005 13:25:27 +0000

On Fri, 17 Mar 2005 rafe@cs.mu.oz.au wrote:
> Matthew Huntbach wrote:
>> On Wed, 16 Mar 2005 examachine@gmail.com wrote:
>>> Matthew Huntbach wrote:

>>>> If you want to do serious search, you don't want the crude
>>>> depth-first with backtracking that's built into Prolog.

>>> I agree. That's a major problem, we really want a logical language
>>> with better control on how reasoning is done, hmmm. I liked the approach
>>> of mercury but I couldn't even run the tutorial so I gave up.

>> Well, there we go then. Doesn't this suggest it's all just too
>> complex?

> No, it doesn't. examachine did not say when he tried using Mercury,
> what problems he encountered, nor whether he asked for help. And even
> if he had, a single datum does not suggest anything general.

OK, the above was written slightly tongue-in-cheek, actually I've quite
a lot of respect for Mercury. However, I think it's noteworthy that while
a lot of attempts have been made to improve Prolog and develop a
better logic programming language, none seem to have succeeded in
pushing Prolog out of the way as the standard logic programming
language, nor have they managed to stop the decline of interest in
general in logic programming.

>> I think the relatively simple control mechanism of Prolog is the
>> reason for its longevity.

> Prolog's control mechanism is anything but simple (cf. cuts,
> assert, retract, var/nonvar, variable identity etc.) The
> correspondence between a Prolog program and a set of logical
> formulae collapses if you use any of these tools and often
> even if you don't (Prolog does not, for instance, reorder
> goals to ensure that the operational semantics of a program
> match the expected denotational semantics).

Yes, I always think of Prolog purely in operational terms, which
is what I've been getting at in this thread. I don't think it works
to try and think of it as "executable logic". But trying to make
programming languages more like executable logic increases the
complexity of them in operational terms. With Prolog, it's knowing
the goals will be executed just in one order that makes it easy
to comprehend.

> Mercury solves these problems and remains purely declarative.
> Mercury programs have an immediate declarative reading.
> What makes Mercury difficult to learn for some people is that
> they have difficulty anyway understanding expressive type
> systems and they have problems with the mode system (which
> specifies operational properties of a program, such as input
> and output arguments of predicates and the corresponding
> bounds on the number of solutions), because that is a fairly
> novel feature. But, judging by the successes of our
> undergraduate summer student programmes, neither of those
> aspects of Mercury is especially taxing once the effort has
> been put in to understand them.

OK, but adding types and modes adds another layer of complexity,
perhaps just another little barrier that stops the casual enquirer
from looking further.

>>> Ok. But we write programs in poor languages like C/C++ or Java. I
>>> don't regard these languages as good OOP languages even.

>> Neither do I, but they must have something going for them for people
>> to use them.

> The programming "market" obviously doesn't select tools on technical
> merit. A whole bunch of reasons could be advanced including similarity
> to familiar tools (C -> C++ -> Java -> C#), that most of the graduates
> we churn out can't get past the imperative model, impressive hype
> machines (e.g. object orientation, Perl, XML are generally asserted as
> being good, without any real evidence), and so forth.

No, the point I've already made is that a lot of these *didn't* have
impressive hype machines. Perl and C++ were both one-man ideas that
grew because they seemed to fill a need. Java did have the hype, but
I think it's a reasonable clean-up of C++. I use C as essentially
a structured assembly language, and I use Java as a practical language
which has a lot of back-up and is a reasonable implementation of some
of the abstract OOP idea - but I have always refused to touch C++ as
it's an ugly mess which falls between the two.

I do think that object-orientation has something serious going for it.
I think the lack of appreciation of that amongst most academics
involved in programming language work was a prime reason why the
languages that academics have put so much work into - the functional
and logic ones - have made so little headway in the world outside
academia. Sorry, I think we academics are guilty of a "not invented
here" mentality when it comes to our attitude towards OOP.

>> Functional and logic languages have had huge amounts of academic
>> backing and have been forced down the throats of generations of
>> Computer Science students. Other languages, which never had that
>> backing, have taken off. C++ was just Stroustrup's little idea
>> originally, wasn't it? I think its success compared to the lack of
>> success of langauge like Prolog indicates that it does have something
>> more useful which is fundamental to it, even if it's not the best
>> way of presenting that useful thing.

> I'd argue that C++' "something useful" is (a) it's percieved similarity
> to what everyone's familiar with, namely C, and (b) it's perceived
> advantages over C. But it's not clear to me that either (a) or (b) is
> true, or at any rate true enough to support C++' uptake on technical
> grounds.

Didn't C itself grow up in general usage at a time when most
university CS programs would have been taught in Pascal? C caught on
because it had something going for it i.e. closeness to the raw
machine.

>> Funny, I never see the sort of people who post homework problems
>> to comp.lang.prolog mentioning classes. Nor do I see anyone else.

> Judging by their postings, 99% of the people who post to c.l.p asking
> for homework help have got to be somewhere near the bottom end of the
> academic bell curve. But...

You may think that, but my experience of teaching programming (in Prolog
as well as Java and years back in Pascal and C) is that most
ordinary joes are about that level. We to whom Prolog and declarative
style programming seems obvious and intuitive are a small minority.

> I'd like to finish by making a point of my own. It seems to me that
> this argument over what makes a good AI programming language is
> premature. Before you can have such a debate, you should have a
> pretty good idea of what it is you want to be able to express. So
> far I've only seen vague statements and hand waving along these lines.

Yes, but that brings me back to one of the points I was making, which
was that the Fifth Generation Project started when the logic-based
approach to AI was at the height of fashion. So it was supposed you
could define intelligent behaviour by logic, and then implement it
with a programming language which was executable logic. Personally
I don't think the idea of what makes a "good AI programming language"
is very useful, because there are so many different sorts of AI which
requires different sorts of programming. AI has been useful in giving us
tricky programming problems, with the languages developed to cope with
these spinning off to more general usage. So I don't think there's really
a distinction between "a good AI programming language" and "a good
general purpose programming language".

Matthew Huntbach

Relevant Pages

  • Re: Minsky still posting
    ... |>> I think the relatively simple control mechanism of Prolog is the ... |> The programming "market" obviously doesn't select tools on technical ... | a structured assembly language, and I use Java as a practical language ... | languages that academics have put so much work into - the functional ...
    (comp.lang.prolog)
  • Re: Code Review - is this code shit
    ... "learning" a programming language is not quite the same as other ... I announced my score, I pointed out that it was meaningless, because ...
    (comp.lang.c)
  • Re: Why We Use C Than C++...
    ... > the level of the programming language. ... the advantage of low level code ... typical example of in-kernel OOP. ...
    (comp.lang.c)
  • Re: compare element in a list prolog
    ... >>for most Prolog newcomers, namely, how, starting with a blank slate, do ... >>of Prolog programming and, as such, only comes from continued practice. ... to designing programs in any programming language, I agree, but AFAIK ... > processing lists. ...
    (comp.lang.prolog)
  • Re: OpenBSD C programming - getting started
    ... You are expected to know about programming language principles, ... You usually let the driver take care of that. ... I'd start with writing programs that don't dig deep into hardware, ...
    (comp.unix.bsd.openbsd.misc)