[e-lang] Re: Comments on Lex's "Object as Capabilities in
Squeak"
Mark S. Miller
markm at caplet.com
Thu Jan 30 19:36:43 UTC 2003
At 11:27 PM 1/29/2003 Wednesday, Robert Withers wrote:
>Mark, I would like to thank you for this significant commitment you
>have made in engaging us with your ideas.
Hey, no commitment! Just a strong desire. I'll do what I can. ;) ;)
>My goals have been to learn some of E's infrastructure, and to start
>building towards multi-user squeak and mobile-code. It looks like
>this fits at your second level of ambition. It would not surprise me
>if this is the level Croquet is reaching for.
>
>However, I like the challenge and reward of your fourth level of
>ambition. It requires several orders of magnitude greater of a
>community commitment.
Perhaps, but I don't think so. I think the tradeoff is instead how similar
SafeSqueak is to Squeak, and how much Squeak is ported to SafeSqueak rather
than tamed or rewritten. I think what is simply unachievable, no matter what
level of community involvement, is to achieve the forth level with a
language that is only painlessly different than existing Squeak.
As for effort, I think the tradeoff is the other way around.
"Simplicity is the unavoidable price which we must pay for reliability."
-- Tony Hoare.
Doubly so for security. Given a change of basic architectural principles, it
is often easier to start over than it is to retrofit. Again, doubly so for
security. E was born at Electric Communities under the same "The E
Extensions to Java" http://www.erights.org/history/original-e/ . (That E is
now known as "Original-E".) Java, like Squeak and Scheme, was already close
to being a perfect pure capability language. (This is, in all three cases,
ignoring the libraries.) So we thought we could define E as a capability
secure variant of Java that would be close enough to port much old Java code.
Three years and $10M later, I think we understood the problem well enough
that we could succeed at it, but even after that investment it would have
been a much harder effort than what we did do: take those insights and build
a new language from scratch a) on top of Java, b) designed to seem familiar
to Java programmers, and c) inheriting the Java libraries via a taming
mechanism so that E would start with a large endowment of working libraries.
OTOH, Jonathan Rees, in a one-man thesis-sized project, turned Scheme into
W7. W7 is as fully capability secure as is E (actually, E without auditors),
and is a minor an almost perfectly upwards compatible variant of Scheme. So
it can go either way.
I can't say for certain which of these two cases is the better analogy to
the task we face with Squeak, but I sadly suspect it's much more like the Java
situation.
> If I understand correctly, with the benefit of
>having read on your site about financial capabilities, privileged
>security abstractions allows for trusted "arbitrage" objects (my
>terminology), which people could *really* trust.
"trust" is tricky. I think this statement is too strong in any case.
>As you ask in your mail, what would we lose from Squeak, or be willing
>to lose, to do these things?
Good questions. More later... Probably not till Monday.
----------------------------------------
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
More information about the Squeak-dev
mailing list
|