[mercury-users] Re: Re: Some remarks and questions

[Dominique de Waleffe]

  >>> "Fergus" == Fergus Henderson <fjh at cs.mu.OZ.AU> writes:

Fergus> On 03-May-2003, lucsmorf at xs4all.nl <lucsmorf at xs4all.nl> wrote:
>> Do you know of any studies on defect rates and software reliability for
>> projects using Mercury instead of common OO languages?

Fergus> I'm pretty sure no such studies have been carried out.

So am I...

Fergus> In general, such studies tend to be expensive to carry out,
Fergus> and very difficult to do in a meaningful way, due to difficulties
Fergus> controlling for things such as programmer expertise.

That's even more difficult when there is only a handful of projects
being done using said technology.

What I can say for sure however is that, in Mission Critical's case,
we see that the major application we've written is very reliable. It
has been in continuous operations since September 2000 and we've not
seen more than a a few crashes (mostly due to improperly handled
exceptions, but the server still stops properly with a message from
the Mercury runtine). The system is being used daily by around 60
persons.

There are several factors that make it reliable, it is quite
difficult to quantify how much the use of Mercury accounts for in the
quality. I would however say that so many errors are trapped at
compile time that this alone is an important factor in the observed
product quality. 

Mercury cannot however replace thinking or cannot force you to write
nice and clean code. It just enforces so many constraints that many
errors have to go away.

Another important aspect where Mercury is very helpful is for the
maintenance portion of the lifecycle. Once updates are to be done in
the application and that the implementation starts, the compiler
forces the programmer to do the updates properly at all spots where
changes are needed. This has allowed us to implement a number of
updates in the server which have been put in production quite rapidly
and without problems.

I have never taken the time to study our cvs logs but it has been on
my mind for a while. 

In my view the most annoying thing if one does not go with the
parallel grades, is that one cannot easily declare and maintain state
information local to a given portion of the application. One has to
export the state to the top level and pass it around all over. This
goes against the modularity of your application.

If one goes to the parallel grade and thinks in the Erlang way, then
one can encapsulate the state in the module definition and have the
local state of a module maintained by a loop running in parallel to
the application. The processes then can interact by exchanging
messages, which, in Mercury, can be strongly typed.

Of course, going in that direction implies that one really starts
thinking in terms of concurrency for designing the application/server
and that is known to be difficult. 

D. 

-- 
Dominique de Waleffe   Email: ddw a-t missioncriticalit d-o-t com
Mission Critical, Drève Richelle 161 Bât N, B-1410 Waterloo, Belgium  
Phone: +32 2 757 10 15  Fax: +32 2 759 27 60

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