[mercury-users] Mercury in academic teaching?

[Richard A. O'Keefe]

I am not going to offer an opinion on whether Mercury or Prolog is better
as an introduction to logic programming.  (And why confine the discussion
to those to?  What about Mozart/Oz?)  But there is one thing that I cannot
agree with:

    Someone (was it Ralph Beckett?) wrote:
	> 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.  There are
    several C interpreters, including one I have on an old Mac that can
    run time backwards just like a Prolog debugger.  And one of the first
    implementations for the strict statically checked language Ada was
    the well known Ada/Ed interpreter.

(2) The presence of strict static type checking does little or nothing to
    stop students "debugging" code by making apparently random changes.
    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.).
    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.

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

    Some of this was certainly to learn how to cope with control problems 
    which the Mercury compiler wouldn't allow, BUT I very much doubt whether
    I would ever have learned to understand what the Mercury compiler was
    complaining about had I not made the mistakes and seen the symptoms in
    a Prolog context first.

(4) At this University we are seeing the effect of several years of using
    a "remote from the machine" "high level" programming language.  (Note
    the scare quotes on "high level"; I mean Java.)  What is the effect?
    A generation of students who haven't a clue about what's really going
    on inside the computer, or what's likely to be cheap or expensive.
    (Yes, we do teach data structures and algorithms, and yes, we do teach
    C.  But "I learned Java first, so I'll stick with Java" and "it's in
    java.util (or java.io) so it MUST be fast".)  Just this year I had a
    4th year student who insisted on rewriting the program that I had
    given her from C into Java "so that she could understand it", making it
    about 3 times bigger and no less than 150 times slower.  (In order to
    try and get her research done, I had to rewrite a major class from
    java.io, AND rewrite her program.  Feh.  Oh well, it did serve an
    educational purpose:  that student is know convinced that rewriting in
    Java isn't always a good idea, and that studying C a bit more might be
    useful.)

    While I am arguing that a strong grasp of a fairly low level operational
    understanding of what is (or might be) happening is very important for a
    programmer, do not misunderstand me as saying that that is sufficient,
    or that abstraction is not important.  A good programmer has to be able
    to work at SEVERAL levels of abstraction and to move between levels
    comfortably when that's useful.

    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.

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