[cap-talk] Horton at HotSec '07: How broadly object/capability?

[Stiegler, Marc D]

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Ivan Krstic
> Sent: Monday, July 09, 2007 1:53 AM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Horton at HotSec '07: How broadly 
> object/capability?
> 
> On Aug 9, 2007, at 4:13 AM, Jed Donnelley wrote:
> > that the issues regarding the costs for implementing 
> > object/capabilities are quite distinct at the different levels 
> > (language, OS, network).
> 
> Capsys people tend to say things like "capabilities are easy, 
> just use our language!" or "capabilities are easy, just use 
> our OS!", and this is clearly out of touch with reality. As a 
> developer, I'm not going to pick my language based on 
> security features; you need to bring your security features 
> to my language. This is why I regard e.g. Brett Cannon's work 
> on capabilities in Python as important.  

I have noticed a two-step common pattern for getting better ideas into
the world. The first step is the remarkably difficult problem of
inventing/discovering/rediscovering a vision of the future that really
is better. The second step is the comparably difficult problem of
figuring out how to retrofit that vision onto the horrific mess that
already exists. Each of these two steps requires different, yet crucial,
insights. Both steps are required to build a future that is actually
better. Both the work on things like E and the work on things like Pythy
are necessary. Neither is sufficient by itself: trying to build a more
secure Python without first having the insights that come from something
like E merely makes another hack, while having insights from something
like E without then figuring out how to retrofit them on something like
Python merely makes another academic exercise. The same pattern
(Python+E -> Pythy) is present in the evolution C+Smalltalk -> Java,
Windows+CapDesk -> Polaris, and FTP+Xanadu -> World Wide Web.

The trick, when claiming that non-legacy solutions are "out of touch
with reality", is to avoid concluding that the only thing "real" is more
pointless hack jobs that look more like a drunkard's walk than a trip to
a better place (a fate avoided by Bitfrost, along with Pythy and Java
and WWW from the above examples).

It is perhaps also worth noting that, every once in a while, against all
odds, something new that actually requires learning actually does
succeed. This reality should be "out of touch" if legacy were the only
thing that mattered. I find it comic (in the tragic sense) that so many
people feel that the world will not, sometime in the next thousand
years, shift to a new and better programming language. In 1995,
according to the common logic, it would have been correctly claimed that
only C++ and FORTRAN could ever be used as programming languages, that
as-yet-undeployed languages like Java, JavaScript, and Python were "out
of touch" and a waste of time. Hmmmm....

Ironically, of course, JavaScript caught on specifically because it
addressed not only ease-of-programming but also security concerns.
Everyone was turning off ActiveX in their browsers because it was the
cybersecurity equivalent of a nuclear bomb. JavaScript actually let you
get some work done without the detonations. The problem, as everyone has
finally learned in the last decade, is that JavaScript only lets you get
a little work done. Which is why all this object-cap stuff is at all
interesting in the first place :-)  

--marcs