Preparing Mozart 1.4.0

[Bob Calco]

> 
> On Sun, Jun 29, 2008 at 01:27:44PM -0400, Bob Calco wrote:
> 
> > > The Fault module has also been redesigned and rewritten completely.
> > > Distribution-related exceptions and fault handlers have been
> discarded,
> > > because of their complexity and lack of modularity.  Fault watchers
> > > have
> > > been reduced to a simpler primitive: a stream of fault state for
> each
> > > entity.  The programmer can also provoke entity failure, which can
> be
> > > helpful for combining fault-tolerant abstractions.
> >
> > This is interesting. How does it compare to Erlang's OTP mechanisms
> for
> > fault-tolerance? Seems at once lower level and more expressive.
> 
> I hope this means oz gets something like erlang's process linking
> (which allows building up abstractions like erlang's supervisors).
> At the moment this makes the system largely unusable for any high
> availability type application.

I never thought Erlang-like process linkage would be a problem in Oz, it is
just that it's not supported yet by a framework + syntax sugar for that
purpose. I have lately been wondering what would happen if the "lessons of
Erlang" from a practical programming perspective were really applied to
building new libraries in Oz.

Mozart armed with an OTP-like framework would be a potent alternative to
existing runtimes--including Erlang's. 

The problem I see with Mozart is that it's ostensibly "too much" for most
people to take in all the different paradigms in one language (more of a
perceived than real problem as programmers are gradually learning NOT to be
one-trick, one-language ponies anymore, and both the JVM and CLR are picking
up some functional programming concepts in their main language
implementations), and I kind of buy into Erlang's critique of shared state
and the benefits of process isolation on principle, esp. if the performance
tradeoff can be mitigated by multi-core religion. 

The Oz syntax is quite foreign to most programmers. On the other hand, there
is more in Mozart for the commodity programmer to relate to than in Erlang
(OO programming, mutable variable via cells, imperative-looking loop syntax,
etc.), for good or ill... I do think syntax is kind of like a UI layer over
a language and if it's pretty people will forgive some pretty ugly or
inadequate internals, and vice versa. (Ruby for example, which was designed
with this sensitivity to the "user experience" -- in this case, developer
experience -- in mind, is only now starting to weed out some early bad
design decisions.)

But Erlang's uptick in popularity with Web 2.0's come-uppance portends good
things for non-standard computing paradigms as the industry grapples with
the real problems of distributed programming in the age of the Internet.
Mozart, like Erlang before, is simply a bit ahead of its time. It will have
its heyday, too, and probably sooner than we think. Things are moving so
quickly now.

I have been, am, and will continue to be optimistic about Mozart as an
evolutionary link to the next generation of computing VMs and I am really
grateful to have had the opportunity to grok Erlang "existentially", which
for mainly practical reasons (OTP support for arbitrarily complex
supervision trees!) I am actually using right now on a real project, wishing
both platforms had a little more of each other in them. 

Like I said I could really use Mozart's (very mature) CPI in Erlang right
now... :)

- Bob


> 
> sRp