[mercury-users] The Mercury Language

[Michel Vanden Bossche]

On 05-Sep-2000, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:

> I think all of this applies as much to Mercury as it does to ML.
> ...

I think that ML, Haskell and Mercury are already "scientific" successes.
What they lack is "industrial" success. ML, the oldest "theoretically
sound" language of the 3, has many available references, several
excellent implementations and is being taught in lots of universities.
In spite of that, the language has not taken off yet. Why? I tend to
share Brian Kernighan's point of view:

> ... is that they're aimed at people who have
> mathematical sophistication, who are able to think in more abstract
> ways, that lots of other folks, and I include myself, have trouble with.

But the fundamental problem is that people have not recognized yet that
such a "mathematical sophistication" is not only required, it's
mandatory. 

Nobody questions today the need to model a bridge using hamiltonian
mechanics. Partial differential equations are hard, but not relying on
"mathematical sophistication" would imply the collapse of the bridge. It
doesn't mean that workers building the bridge have to be mathematically
literate, but the "engineers" must. 

Complex physical systems are conceived and developed by the intimate
association of theory, (i.e. continuous mathematics: Hamilton, Maxwell,
Schrödinger equations, etc.) and practical expertise where reproducible
know-how coexists with standards and adapted tools.

The software technology still currently used today (COBOL, FORTRAN, C,
ADA, C++, Java) is based on languages whose theoretical foundations are
almost non-existent. Their semantics is so poor and muddled that it is
extremely difficult to assess the programs that are written in these
languages. On the whole, software development does not rely on a solid
theoretical foundation. The languages used do not allow the study of the
properties of the program under development by comparing them to the
intentional properties.

It is clear that this pragmatic approach should not necessarily be
discarded when the objective is simple: we have built houses for 7000
years without resorting to Hamiltonian mechanics. When problems grow
more complex, resorting solely to practice has its limits: the collapse
of the nave of the Beauvais cathedral (XIIIth century ;-) could have
been avoided by performing finite element analysis. When problems become
very complex, it is illusory to solve them without a very solid
theoretical arsenal: if we can conceptualize the immaterial transmission
of sound and pictures, it is illusory to develop such a system before
the advent of Maxwell’s equations.

Academia have done their best to explain this to the world. The problem
is that there have been very few demonstrations, at large scale, and in
an industrial context, that this was the way to go (nobody in the
industry really cares about the 8-queens problem or the construction of
the ML compiler in ML, or the Mercury compiler in Mercury). Another
problem is that many "academical" languages lack an extremely good
integration with the current "real-world" (the required "pragmatic" side
of the software problem).

What's really required is the demonstration of the RELEVANCE of such an
approach. This is very hard, because, by definition, the problems to
solve are complex, require a lot of investment in the
requirement/specification phase, don't give a lot of substance to
publish research papers, need a lot of effort at the details level, and
finally need a sponsor and stake-holders that do believe that's the way
to go.

This is what we, modestly, try to achieve with Mercury. But this is a
hell of a job, because you have to deliver a real working system.

Regarding Peter's question:

> So the
> question I have for those interested in seeing Mercury "catch on" is:  is
> the correct solution to this to educate the masses to use more sophisticated
> abstractions, or would we do better trying to simplify some of the concepts
> (while retaining Mercury's declarativeness) to make it easier for the
> average developer or uni student to pick up?  Or is it better to accept
> Mercury's current level of popularity and get on with the research?

Education of the masses is important, but will take time :-) Education
of the decision maker is very important (very few "managers" understand
anything about the complexity of discrete systems, but they know that
there is a problem, see "Software Hell", Business Week, December 6,
1999). The problem is that they cannot relate that "hell" with the
"ontological" issues.

Simplifying the language is not a solution (io__state excepted :-((.

Get on with research is certainly the thing to do (and the team is very
good at that).

What's needed is the demonstration of the relevance, some sound
engineering to improve well identified issues (#1 memory management, #2
richer types à la .Net, #3 speed of the compiler), and the equivalent of
an "Engineering Handbook", the methods and tricks that can help a good
engineer who is not necessarily a genius (this in an old idea from D.L.
Parnas).

As the resources are limited, the real question is to optimize that
combined "scientific-industrial" development.

Regards,

Michel
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------