This language claims to be "capabilities-secure", which I assumed meant that it uses capability-based security and is an object-capability language. This got me excited -- my work on Sandstorm.io and Cap'n Proto uses capability-based security heavily, and a high-performance object-capability language would be awesome to have (the existing ones are mostly dynamically-typed and slow, though you can use capability-based design without using a capability-based language, as many programs and most OS's actually do to some extent).
Unfortunately, it turns out they have simply coopted the term to mean something completely different. According to the documentation: "Pony capabilities are completely new, no other language has them."[0]
Please think of a new word for this; don't redefine one (or a pair) that is widely-used already.
Kenton, are you perchance familiar with the E language.
That was (is?) all about capabilities.
http://erights.org/elang/index.html
Yup. Cap'n Proto's RPC layer is based on E's network protocol, CapTP, except sitting on top of Cap'n Proto's serialization layer instead of Java serialization. E's designer, Mark Miller, is a friend and assisted me with the design.
That's great news that you know Mark! We have talked extensively with Mark about the design of Pony, and he agrees that it is indeed a capabilities type system, and that it is capabilities secure.
Hmm well if Mark Miller says Pony is capability-based then it must be. I apologize if I've misunderstood. I'm confused, though, by two things:
1. Your documentation introducing capabilities specifically says: "Pony capabilities are completely new, no other language has them." If you really mean "capability" in Mark Miller's sense of the word, then this statement is incorrect. Many object-capability languages exist.
2. What your documentation describes as "capabilities" looks to me like type qualifiers. The documentation says "A capability is a form of type qualifier and provides a lot more guarantees than const does!" But this doesn't sound anything like capabilities.
Is it possible that Pony is an object-capability language but you are also using the word to refer to a different concept? If Pony is actually an object-cap language then that's excellent, and I even more so encourage you to rename the type qualifier concept to avoid the confusion!
FWIW, Sandstorm is very interested in adopting a high-performance ocap language, but would probably shy away from one which uses the word "capbaility" to mean something else, for fear of confusing developers.
Sandstorm looks extremely interesting. Very very extremely. If Pony could be useful at all to Sandstorm, please get in touch!
Sorry for the docs misunderstanding - I promise, bad docs not withstanding, we are using "capability" to mean exactly what you want us to mean :)
+1 to fixing the docs. It should not be hard to remove the one line, "Pony capabilities are completely new, no other language has them."
The term "capability” is much older than Pony, and the concept was proposed in the 60s. We would have loved to use a different word, but there are not enough different recognisable words in the English language.
We use capabilities in Pony to statically avoid data races - not for security. But we believe that Pony's capabilities can also be developed further to support security - would be great to try and program Sandstorm’s security with them.
> The term "capability” is much older than Pony, and the concept was proposed in the 60s.
Right, capability-based security (my definition) originated in the 60s and has been in continual use ever since. Pony's definition is new, AFAIK (and according to the documentation).
> We would have loved to use a different word, but there are not enough different recognisable words in the English language.
I think "type qualifiers" is the correct term. The Pony docs already describe capabilities as being similar to C++'s "const" and "volatile" type qualifiers, and this term will help people understand that the concept is similar (but more advanced).
The Pony docs spend a whole paragraph explaining that its capabilities are not the same thing as any other "capabilities" I may have heard of, e.g. "You may have heard of capabilities somewhere else, but these are not the same thing." The fact that you need this paragraph suggests that you've heard this objection a number of times, which should be demonstration enough that you really ought to choose a different term. People don't usually need disclaimers like this. English is a language that has entirely too many words -- there are plenty available. Or, consider making one up. :)
> But we believe that Pony's capabilities can also be developed further to support security
Yes, it's very likely that your "capabilities" would compose well with object capabilities in order to effect security. But that's just all the more reason they shouldn't use the same word, since it will be incredibly confusing to anyone who is trying to use both.
The "type qualifiers" you refer to are an extension of the capabilities-secure nature of Pony. They are themselves also a form of capabilities, specifically because the underlying language is itself capabilities-secure.
You may be interested in the type system paper that covers this:
http://ponylang.org/papers/fast-cheap.pdf
OK, then I'm very confused by this documentation:
http://tutorial.ponylang.org/capabilities/introduction/
It seems to state that the type qualifiers are the capabilities, and explicitly claims no existing language support capabilities.
If this is just an issue of misleading documentation then I apologize for raising a false alarm, though the documentation should be corrected. :)
I think you're right, the documentation should DEFINITELY be corrected!
No worries on a false alarm, as I am always eager to discuss capabilities security, in any form :)
The term "capability" is perfectly appropriate here. A capability is something that defines how you can use what it points to. It's often used in the security context, but is also used the way Pony uses them (to define how the holder of a reference can mutate the target object).
A capability is traditionally a noun, or sometimes the combination of a noun and a set of allowable verbs, but not simply a verb.
If Pony were using "capability" to describe the combination of a variable and its qualifiers, then I'd say, yes, that's a capability -- it designates a thing, and the permission to use it. But they are using "capability" to describe specifically the _qualifiers_ on the variable, which is not correct, and is confusing.
Here's a great paper discussing what capabilities are and the confusion around them: http://zesty.ca/capmyths/usenix.pdf
Before you ask: Yes, Linux/POSIX capabilities (as described on the capabilities(7) man page) are similarly misnamed. This is covered in the paper, and has been a source of a lot of confusion.
FWIW, this is a touchy subject for a lot of fans of capability-based security because the story of capabilities goes something like this:
1960s-1970s: Capability-based security invented, popularized, widely used, almost makes it into hardware (Intel 432).
1980s-1990s: People incorrectly redefine capabilities in various ways (e.g. as verbs rather than nouns), then declare "capability-based security doesn't work" based on these misunderstandings (see the paper I linked). Capability systems find they have trouble making headway against these misconceptions, as the difference between the misconceived version and what capabilities really are are just subtle enough to confuse anyone who isn't immersed in it. (Meanwhile, the basic ideas of capabilities live on as object-oriented programming, but aren't enforced strictly enough to be called "security".)
2000s-2010s: People start realizing that capabilities as originally defined do in fact work ridiculously well and they become re-accepted.
We really don't want to go backwards again. :/