[mercury-users] An opinion about Mercury

[Raphael Collet]

Dear all,

Here is a text written by Romain Demeyer, a master student that worked with us 
at Mission Critical IT (Belgium) for his master thesis.  He designed and 
implemented a tool that compiles and evaluates declarative specifications of 
process workflows.  The text gives his view about the language Mercury.

We thought that it was interesting, because it answers a recurring question 
about the learning curve of Mercury.  We always face such a question when we try 
to sell products that are made with Mercury.

Romain should have subscribed to the mailing list, so feel free to comment and 
ask questions.

Cheers,

Raphael Collet
Mission Critical IT
www.missioncriticalit.com

---

For my master thesis at the Facultés Universitaires Notre-Dame de la
Paix (FUNDP) in Namur (Belgium), I had the opportunity to work at
Mission Critical IT as a trainee.  My curriculum covers a deep study
of object- oriented programming languages (Java), imperative languages
(C, Pascal), database languages (SQL), computer networks, operating
systems, together with a few courses on economical sciences, and a
strong mathematical background.  I also attended a 30-hour course on
functional and logic programming, which gave the basics of those
programming languages, in particular the languages Haskell and Prolog.
This kind of languages was only mentioned in that course, and no
substantial exercise was done with them.  My experience in functional
and logic programming was thus limited to a theoretical overview, and
small exercises.

When I was at Mission Critical IT, I had to learn the language
Mercury, because my work involved some implementation.  Note that the
implementation was not the main objective of my job.  Most of my time
was spent on defining a subject for my master thesis (a declarative
approach for defining workflows), reading documentation (theses and
scientific papers on the subject), learning concepts related to the
subject (workflows, temporal logic), theoretical research, and
designing solutions.  I learned programming in Mercury in parallel
with those activities.

The major difficulty when I started using such a language was that I
used to think in an imperative and object-oriented way.  Some time was
necessary to get used to think in terms of «what» instead of «how».
Understanding the basics of Mercury required some effort, too.  My
training naturally followed the needs of the implementation process.
Learning Mercury in parallel with other activities has never been a
problem, notably thanks to the support given by Mission Critical IT
employees, who were always available to help me.

As soon as after a few weeks, I was able to program complex algorithms
without being delayed by my training with Mercury.  After twelve
weeks, programming in Mercury became natural, instinctive, and fast.
I think that my expertise in Mercury grows to the level I had in other
languages (as Java), without even exploiting all the possibilities of
the language.

The project I developed at Mission Critical IT is of a relatively
large size, and contains some complex algorithms and data structures.
Here are my personal conclusions about the language Mercury, given my
experience with it.  Its strength is of course the fact that the
language is declarative.  Mercury makes it easy to write safe and
concise programs.  Debugging is simpler, development is faster, and
program reviewing is much easier than with languages like Java, which
quickly makes the structure of big projects look like a labyrinth.
The latter feature can be illustrated by comparing my program with an
equivalent one written in Java.  The core of my project consists in 5
files and about 1700 lines of code.  The corresponding core in the
Java program was estimated to 150 files and 18000 lines of code.  I
also believe that programs written in Mercury are easier to make
robust.  If I had to choose one of the languages I know for developing
a program with some minimal «logic» complexity, I would definitely
choose Mercury.

The real issues I had with Mercury occurred in the more «imperative»
modules of the project, like a small command-line tool for executing
the program.  It is only in those modules that I found Mercury less
intuitive, or less adequate.  The extra weak points I would mention
are the lack of documentation and libraries, in comparison with
mainstream languages, and the difficulties for programming user
interfaces.  However, my overall impression is very positive.  I would
not use another language if I had to make this project again.

(translated from French by Raphael Collet from Mission Critical IT,
  original text by Romain Demeyer)

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