[mercury-users] Mercury in academic teaching?

[Richard A. O'Keefe]

Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
	The Mercury debugger isn't that much less friendly than your standard
	Prolog debugger.
	
But then the entire argument against an interpreter disappears.
Just because a language (like C, for example) is compiled, that
has never stopped students typing in test cases without putting
them in a file.

If there is any difference between a compiled language with
a fix-and-continue debugger and an interpreted language, for
the purposes of this discussion, I don't know what it might be.
And if the Mercury debugger doesn't have fix-and-continue debugging
yet, then it *IS* "much less friendly than your standard Prolog debugger".

NB: fix-and-continue doesn't mean "hacking" and it doesn't mean "typing
clauses into an interpreter".  It can mean typing changes into an IDE and
having them checked to some degree and recompiled, like in PLT Scheme or
any good Prolog.

	>     While Mercury is simple in some ways compared with some languages,
	>     it is complex in other ways compared with other languages, and it is
	>     complex in the service of letting you build reliable high level
	>     abstractions.
	
	My position is that while Prolog is definitely a simpler, more forgiving
	language, in order to write reliable programs you still have to
	understand modes and unification and determinism.

Agreed, but "writing reliable programs" and "learning about logic programming"
are different things.  My younger daughter asked me to remove the training
wheels from her bike last week.  For "learning to ride a bike", they were
really good.  For "riding a bike to get some place", not so good.

	Mercury has a much steeper learning curve, but in many cases the
	compiler tells you when your program is not going to do what you
	thought it would.
	
That's not a "but", it's really a "because".

    Mercury has a much steeper learning curve,
    BECAUSE in many cases the compiler tells you when your program
    is not going to do what you thought it would,
    and you never get to find out what would have happened,
    so you don't understand what the compiler is trying to tell you.

Over the years, one of the top complaints that I have heard from people
who have taken programming courses and found them very hard going is
"I could never make sense of the compiler error messages."

Come to think of it, one of the things that drives me up the wall is
3rd year students handing in C programs with obvious problems that the
C compiler DID tell them about, but they weren't EXPECTING to understand
anything the compiler said, so they didn't bother looking at what it did
say or even the particular lines it was talking about.

What I am saying here has been said before, at greater length, with a
wealth of supporting evidence, by my elders and betters:

    A programming system meant to be used by people learning a new kind
    of programming language had better have really good error reports.

I think of Alan Creak's STUBOL compiler, which hallucinated the missing
bits of students' COBOL programs and showed in the listing what the
program should have been.  I think of Peter Fenwick's STUFOR compiler,
which went to great lengths to display exactly where in Fortran formatted
I/O a problem was:  the input or output record and where conversion had
reached, exactly how much of the format had been processed, exactly where
in the I/O list the statement had got to, ...  I think of PLT Scheme with
its graded series of levels so that you can't accidentally use a language
feature or function you haven't been exposed to yet and the soft typing
system it uses to try to diagnose faults before they occur.  I think of
the "classic" systems like PL/C where the compiler did spelling correction
and took other steps to try to avoid cascades of messages resulting from
little typos.

I think of a certain Prolog system I once used whose author had gone to
a lot of trouble to produce diagnostic messages with a lot of explanation
about what he thought had caused the error and what you might do about it,
and how annoying I found it because it was usually wrong.  (Rather like the
grammar checker in Microsoft word.)

I don't want to be misunderstood as saying one word against Mercury.
Mercury is the way it is for good reason.  And there are many things
that we would like to have in a superb language environment that are
hard to support in Mercury's funding and staffing model: "really good
error reporting" is not the kind of thing that attracts research funding,
and open source hackers who are comfortable working on the system tend
to treat such things as low priority too.  (The only noticeable change in
GCC error messages of late has been that they have become unreadable in
an ISO Latin 1 environment.)  What I DO want to say is that if there
were resources for anyone to produce a really good educational environment
(and what ever did happen to the Open University work?) for a logic
programming language, it would be easier to do this for a simple language
than a complex one.

I sometimes wonder whether something like Aditi might make a better
introduction to logic programming.  But Aditi's dead, isn't it?

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------