[cap-talk] GC versus RAII

[David Barbour]

On Fri, May 20, 2011 at 12:54 AM, Ben Kloosterman <bklooste at gmail.com>wrote:

> abstractions will leak anyway especially around resources
> eg  out of memory , floating point overflows , network errors

( especially distributed objects!)  , HD errors etc  hence its

better handling these resources more carefully .


I disagree with this conclusion. It is entirely feasible to develop
languages for composition of real-time and embedded (fixed-memory)
processes. For distributed programs, our abstractions may account for the
possibility of disruption - i.e. translucent distribution rather than
transparent. HDD errors can be escalated to a sub-program failure, similar
to someone powering down their laptop or a machine experiencing a sudden
case of 'all blown up'.

That said, I would agree that our programming models should be robust and
resilient even to most conditions of partial failure that we failed to
anticipate or detect.


> I had to  build a new mechanism in so the caller to the service

knew  exactly the internals of the issue which ended up as a

quick fix eg pretty ugly string parsing on a Soap exception.
>

State of the art languages fail us with respect to modeling
the distribution, configuration, and installation of applications. However,
this failure isn't necessary. Gilad Bracha describes another possibility
with his vision for Serviced Objects [1]. My vision differs from his... but
I should probably blog it rather than discuss it here. Anyhow, such things
as remote code diagnosis (using mirror capabilities for reflection),
maintenance, and live upgrade (or even live distributed programming) are
possible, though perhaps infeasible in current languages.

[1] http://gbracha.blogspot.com/2007/03/sobs.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20110520/b9b15426/attachment.html