[mercury-users] Mercury in academic teaching?

[Ralph Becket]

Richard A. O'Keefe, Monday,  9 October 2006:
>     Someone (was it Ralph Beckett?) wrote:

(`Becket'.)

> 	> In favour of Mercury as a pragmatic teaching choice is the lack of an
> 	> interpreter: having strict, static checking by the compiler means that
> 	> users are far less able to "debug" code by making random changes.
> 
> (1) The presence of strict static checking has little or nothing to do
>     with the absence of an interpreter.  Hugs is regarded as an interpreter,
>     so are gchi and hbi, despite having strict static checking.

Sorry, there I did conflate two orthogonal issues.

> (2) The presence of strict static type checking does little or nothing to
>     stop students "debugging" code by making apparently random changes.

I agree there will always be a certain section of a class who take this
approach.  However, it is harder to get wobbly code past the Mercury
compiler: it isn't a language for the hack-and-hope types.  But I would
assume that a computer science course would seek to dissuade that coding
style and encourage thinking before typing.

>     I am not at all sure that simply chaining students to the wall to
>     stop them doing this is the right thing; it means that there is something
>     important they don't understand and we want them to seek help about it,
>     rather than simply trapping them "in traps of treacle" (Pratchett ref.).

Fair enough, but without decent checking by the compiler students often
think they have achieved success (their programs pass some test cases)
when in fact their programs are very broken.

>     Mercury's mode checking and determinism checking place strong limits of
>     the kinds of hacking that *make sense*, but if you understand what's
>     going on well enough to be helped by the compiler's messages, you
>     probably don't have much of a problem in the first place.

Mercury's mode and determinism checking aren't that hard to explain at a
level sufficient to write non-trivial programs.  The main issue is
understanding how unification works, which is just as much a problem in
other logic programming langauges, and how disjunction can introduce 
non-determinism.

> (3) Above all, I like to think that I understand Prolog fairly well.
>     And for me, stepping through in the debugger seeing what actually
>     *happened* was a major, repeat ***MAJOR*** part of learning to
>     understand Prolog.

The Mercury debugger isn't that much less friendly than your standard
Prolog debugger.

>     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.  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.

-- Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------