[mercury-users] Mercury in academic teaching?

[Jonathan Morgan]

On 09/10/06, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> On Mon, Oct 09, 2006 at 10:09:09AM +1000, Ralph Becket wrote:
> > Jonathan Morgan, Saturday,  7 October 2006:
> > > As a student who is just studying Prolog, I do not believe that
> > > Mercury is likely to be a good introductory logic programming language
> > > for several reasons.
>
> I've thought several times about switching from Prolog to Mercury for
> this subject, but at the moment, I don't think Mercury is ready to use
> in second year teaching.  Mercury has too many sharp edges on which
> students can nick (or impale!) themselves.  Prolog certainly has its
> share of quirks, but it is a much simpler language.  And just as
> importantly in the age of instant gratification, with Prolog you get a
> payoff sooner than you do with Mercury, even if ultimately the payoff
> is a lot greater with Mercury.  If there were, to badly mix my
> metaphors, a version of Mercury with training wheels, that let you
> learn the language a bit at a time, hiding the parts you haven't
> gotten to yet, and making it easier to understand the part you are
> trying to learn, I'd love to switch to Mercury.

I think that you would be better teaching Mercury after Prolog, so you
can exhibit various features that fix the problems encountered in
Prolog and motivate the language (dare I say that you have six spare
lectures that could be better employed than in Q&A?)  I do not think
that students are likely to use Mercury sufficiently to really realise
the advantages over Prolog.

> mode of each predicate,
> and then makes sure the code has the expected determinism.  But the
> cost of this is that you have to explain modes and determinism before
> you can do anything.  And that forces you to explain Mercury's switch
> detection algorithm, because some students are sure to run into cases
> where Mercury fails to detect determinism.  Student:  "Why is this
> definition of min/3 nondeterministic?"  Me:  "Because both clauses can
> succeed."  "But in that case, the results are the same.  No matter
> what, there's only one solution."  "But Mercury counts it as two."
> "Oh...  OK, I fixed it; now why does it think it's nondeterministic?"
> "Because Mercury doesn't know that X=<Y and X>Y can't both succeed."
> "I see....  Alright, why doesn't this one work?"  "No, sorry, Mercury
> can't tell that X<Y and not(X<Y) can't both succeed."  "Pthft."

That last one doesn't seem very nice.  In general, I like Mercury's
determinism detection, but I think most students would prefer not to
worry (after all, if in doubt we could just change that det to a
nondet and see what happens).

> In Prolog, the first definition would have compiled and run just fine,
> although it would leave a useless choicepoint.  Later in the semester,
> we explain efficiency concerns and how to get rid of unnecessary
> choicepoints, but in Mercury it has to be explained just to get code
> to compile.  And in many cases, they can get away without fixing it
> at all in Prolog (it is just performance, after all).

Think like a computer scientist - so long as we get the same
asymptotic efficiency, who cares about these minor constant factor
differences?

> Another problem with Mercury for teaching is the flip side of one of
> its great features:  once you get your code through the compiler, it
> probably works.  The unspoken catch is that you better have set aside
> a lot of time, a lot of coffee, and a good set of manuals (and having
> access to the Mercury developers is *very* helpful, too) to *get* your
> code to compile.  As frustrating as it is to try to figure out why
> your Prolog code is failing or looping, it's much more frustrating to
> be faced with dozens of error messages from the Mercury compiler, and
> worse still to see the number of errors drop to 8, then to 3, then 1,
> only to see it leap back up to dozens as the Mercury compiler gets to
> the next stage.  I expect if we used Mercury for undergraduate
> teaching, we'd be finding large tufts of hair around the labs.

I have experienced both these things, and neither of them are
particularly nice.  In general, I do not think students are ready for
wierd type and mode errors, that can initially seem extremely random.
At least if you are in Prolog you can start with the debugger on an
(incorrectly) working program.  Most students are unlikely to spend
sufficient time with Mercury to get the hang of even its simple error
messages.  I can see many undergraduates having a mostly working
program shortly before submission, starting to change something, and
then being unable to get it to even compile before submission (which
automatically translates to zero on any runtime testing requirements).
 I think version control is the answer to this problem, but my feeling
is that most students don't use it.

> > 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.
>
> Whoa, I strongly disagree there!  The Prolog top level is very useful
> in lectures to show how Prolog works.  Having to type in, compile, and
> run a 10 line program to do a one line test is very unweildy.
> Similarly when developing:  I find it *much* easier to test code
> bottom-up in Prolog than in Mercury, since you don't have to build a
> test scaffolding.  Nor do I see how the lack of a top level in any way
> discourages "change something and try again" development.  Once you've
> built the scaffolding to test your Mercury code, if it doesn't work,
> why would you be any less likely to just change something and try
> again?  I know I've done that in Mercury when I couldn't figure out
> what the compiler's error messages were trying to tell me.

I'm inclined to agree.  However, my main problem with testing by
interpreter is that tests are often not written down, but just typed
in randomly, which means that they can never be used again.

> > I don't think that many subtle issues have to be mastered by Mercury
> > beginners.
>
> When you're explaining things, I agree you can gloss over details.
> But as soon as you turn students loose in the lab, they will quickly
> run into some of the huge body of subtleties you have to understand to
> develop code in Mercury.

They can also run into the subtleties you need to understand to
develop code in Prolog (especially things working in one mode but
refusing to work in a different mode).

However, I'm glad to see that someone agrees with me about the
disadvantages of Mercury for education (despite being a great language
for real software development).

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