[cap-talk] Specs for our 'ideal' language?

[David Barbour]

On Sun, Sep 27, 2009 at 12:39 AM, Matej Kosik <kosik at fiit.stuba.sk> wrote:
> Various tricks (like JIT) may:
> - improve performance
> - decrease the size of the virtual machine
>  (e.g. by elliminating the interpreter)
> but do they elliminate the virtual machine altogether?
>
>
> Perhaps then, `managed code' is then equivalent to `code executed with a
> help of a virtual machine (sometimes called as runtime)'.

Even C code executes on an 'abstract machine'. It's just a rather
'thin' abstract machine when implemented on certain computer
architectures - in particular, when executed on a single-core uniform
memory architectures. C is doing less well today: its virtual machine
does not effectively account for concurrency, GPUs, FPGAs,
event-processing, etc. Most C in use today requires complex,
incomplete, frameworks and much self-discipline to make up for the gap
and mismatch between its virtual machine and the real machine.

The difference between 'abstract machine' and 'virtual machine' is a
rather arbitrary line in the sand regarding thickness of the
implementation, how much mapping is required. I don't consider it to
be a worthy distinction, not nearly so much as considering practical
qualitative and quantifiable concerns such as performance and
optimizations achievable.

> I am not focusing very much on performance. Rather, on elegance of
> object-capability security model in certain contexts. I am experimenting
> with it in kernel-space and there are some nice comparisons with other
> approaches that use other security mechanisms which lead to different
> results. I am interested in all the language properties that are related
> to creation of software systems that are robust.

I'm curious: How do you measure 'elegance'?

Have you considered social language properties, such as support for
distributed multi-user programming (including pair programming),
integration with zero-button unit-testing, etc. Object capability
itself is extremely suitable for testing environments, since it
guarantees the environment can be modeled entirely within software
even for larger integration tests. Certain properties for the language
- especially its namespace design and nominative vs. structural typing
- can determine whether programmers tend to specialize code into tiny
little niches vs. share it.

Have you considered other robustness properties? My own interest in
'robust' computing had much to do with *survivable* computing. That
is, computing that can survive natural disasters, slashdot effect,
military jamming, intermittent stealth-mode, and network attacks.
Hallmarks of such a design are more than mere 'robustness' - one also
needs graceful degradation (partial service while under attack) and
resilience (self-healing and recovery).  Object capability model only
helps for a few of these: one also requires secure models for
distribution, replication (for both disruption resistance and
regeneration), persistence, etc.