[mercury-users] Bertrand Meyer's opinion

[Michel Vanden Bossche]

In "Where is Software Headed? A Virtual Roundtable" (Computer, Vol. 28,
No. 8, August 1995), Betrand Meyer says:

> I do not see much future in the next few years for some approaches that
> were recently heralded as promising: functional programming, logic 
> programming, and expert systems (in their application to software). 
> Some of them will find, or have already found, a niche, and all will 
> remain useful as part of every software developer's bag of tricks, but 
> it is hard to see how any of them could fundamentally affect our field 
> over the next 10 years.

The good news is that there is some hope for Mercury after 2005 ;-) 

We do believe that there is a future for a software paradigm that will

1. favor correctness, reliability, evolvability and supportability
2. without compromising performance and scalability,
3. and with a very good integration with more traditional paradigms. 

Mercury is not too far from getting us there (but the journey is still
significant). We have evidence that we have already (1), although the
compilation time and the lack of IDE affect the productivity. Our
current COM integration has already demonstrated that (3) was feasible
without a too big burden in the NT world (but the COM-GC coupling
requires some adjustments, see the unscientific benchmark hereunder) and
the .Net development will improve that considerably (at least in the
.Net world ;-). 

For us, the most critical challenge is (2). In the short term, the
improvement of the GC is an issue but, again, .Net will solve that in
the "devil's" world.  A big issue is that scalability imposes
multi-threading support (this is investigated by Peter Ross). One of our
concern is that in our current PFlow server (a Petri Net engine for
workflow support) the "stack-size" is 40 MB. With HLC, the stack-size
had to be increased to 64 MB. This limits seriously the scalability
(this problem is related to the lack of elimination of trivial
non-terminal recursions). In the long term, we expect that a fundamental
solution will come from destructive updates, but this is still a key
challenge.

The MLDS compiler (HLC) has solved many issues (easier MT, easier
exceptions, much simpler run-time, etc.) and is a step in the right
direction.

And now, my key question. Besides what's being done or identified, what
can help invalidate Bertrand's prediction?

As a business betting on Mercury, we are interested by your comments.

Regards,

Michel

BENCHMARK - This is a simple program that parses a big XML file (8MB)
and count the number of
elements in it by recursively traversing the XML Object Tree (the idea
was to check the Mercury-COM interface using the MS XML parser). 

Here are the preliminary results (on a Dell PIII 733 MHz, 256 MB Rambus,
Windows 2000)

       Language	                      Elapsed Process Working	VMSize
                                       (sec)   (sec)  Set (KB)   (KB)

C# (COM Binding) .................... 15.156  14.453   33,872   30,848
VJ++ (COM Binding) ..................  4.175   4.171   18,616   16,604
Merc (NONE, COM Binding) ............  1.019   1.016   31,244   31,300
Merc (HLC, COM Binding) .............  0.850   0.848   25,056   25,484
Merc (NONE, COM Binding, NewComStd) .  0.697   0.696   31,124   29,952
Mercury (HLC, COM Binding, NewComStd)  0.530   0.527   24,120   22,812
VB (COM Binding) ....................  0.345   0.345   16,612   14,548
Delphi (COM Binding) ................  0.293   0.293   16,040   14,452
C++ (COM Binding) ...................  0.266   0.266   15,628   14,344

VB (.NET) ...........................  0.070   0.069   31,684   29,620
C# (.NET) ...........................  0.066   0.065   30,324   28,328
C++ (.NET) ..........................  0.065   0.065   26,952   24,988
Merc (.NET) .........................   TBD     TBD     TBD      TBD

NewComStd: Improvements done by Renaud Paquay for the COM-GC interface
TBD: To Be Done
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------