The E programming language(erights.org)
erights.org
The E programming language
http://www.erights.org/
1 comments
I discovered this really old programming language. Looks like it has not been touched since 1998 and seems to have been created by Douglas Crockford. Has anybody really used this?
No, it was not created by Crockford. Crock was on the management team at Electric Communities (who built E) but he was mainly building powerpoint decks and helping to pimp the company to investors and tech press (i.e. while people now seem to associate him with coding due to his JavaScript work he was never really a coder and had nothing to do with E other than working at the company that developed the language.) The primary creators of E would be Doug Barnes, Arturo Bejar, Chip Morningstar, and Dan Borenstein, with a lot of help from Jay Fenton, Rob Jellinghouse, Gordie Freeman, and a whole host of other smart folks. Mark Miller later came over to EC from Agorics (where he was one of the creators of Joule, the too-slow-to-work language that was the source for many of the ideas used in E like capability security, an actors model with a message passing architecture, etc.) and took over a lot of the lead dev and architecture work on E. When EC folded E was spun out and continued as a cute research project for quite a while, leading to some neat demos and a variant in Ocaml I think.
Since then MarkM has moved to Google and along with some other security researchers has taken a lot of the E concepts over to JavaScript as the Caja project.
Since then MarkM has moved to Google and along with some other security researchers has taken a lot of the E concepts over to JavaScript as the Caja project.
E was created by Mark Miller and Dan Bornstein. Both are Googlers now. Dan is known as the main creator of the Dalvik VM. Mark is still following the path set by E but in the context of Javascript. He's working on both Caja, an ocaps secure subset of JS and on JS Harmony itself.
* http://en.wikipedia.org/wiki/E_%28programming_language%29
* http://en.wikipedia.org/wiki/Caja_%28programming_language%29
* http://en.wikipedia.org/wiki/E_%28programming_language%29
* http://en.wikipedia.org/wiki/Caja_%28programming_language%29
It's way, way too far ahead of its time. If Functional Programming manages to hit the mainstream, this is one plausible direction that it could move in after that. It will be much easier to start talking people into an approach like this once they've absorbed that stuff, and it will probably be much easier to implement in strong functional programming languages with good type systems than on top of objects.
While a strong type system is one way to achieve the goal (and probably the easiest one from a language design perspective) it is not the only way. The original E design did not rely upon typing at all but used cryptographic security at the message-passing layer to accomplish the capability semantics desired. Strong typing made it easy to apply the core ideas to Ocaml, for example, but it could have been accomplished in a language with weaker types but a more rigidly designed message-passing architecture like Erlang with just a few tweaks to the VM and OTP system (e.g. a lot of the tools that make hot code loading and debugging things on-the-fly possible in Erlang leak too much information about the system and would have to be changed.)
Yes, I think I wasn't clear. What I was getting at was more about the mentality of programmers; if you can get stronger types into the mainstream you will also get many of the same concepts that you need to understand capability based systems into the mainstream. They aren't, strictly speaking, the same by any means, but right now the ideas in the area of provability, meaningful types, capabilities, and that whole complex of ideas around reifying not just what code does but what it doesn't do, just aren't popular enough yet. FP is the most likely vehicle to get that complex at least somewhat out into the mainstream. Once you have that, you might as well exploit it in your capability-based systems, even if they aren't strictly speaking related. Capabilities, on the other hand, don't look to me like they can lead the charge, but they could ride it.
I definitely agree with this. I also think that capability systems that are based on a good type system are probably going to be easier to code with than ones based on message passing security. The type systems make it easier to define and use the basic capabilities and involve a lot less boilerplate code than what one sees in other variants of capability-semantics.
Really old? E comes from the mid to late 90's. In Tiobe's current top 20 only C# and Go are newer than that.
While E seems to be deadish, many of its core ideas around object capability security (ocaps) live on. Others have mention Caja, an attempt to bolt ocaps onto JS, but see also Gilad Bracha's current experiments with a Smalltalk variant called Newspeak which is entirely built around ocaps.
Another interesting take on ocaps is Joe-E, which is basically a verifier that allows a subset of Java. If some Java source passes Joe-E then that source is capability secure.
Another interesting aspect of E, vats, is conceptually not too different from actor style concurrency as exemplified by Erlang, except that where one Erlang actor(process) conceptually is one "object," an E vat may hold many objects. Note: Erlang predates E by quite a bit, and the actor model predates Erlang by even more; I just thought it worth mentioning as one way to think about vats.
In fact, Erlang is itself very nearly an ocaps system. Nearly because actors can mostly only talk to other actors after they receive (or spawn) a PID, thus untrusted actors can be limited in capability by not sending them dangerous PIDs. But not quite because some dangerous primitives (like IO) are globally available. It would be straightforward to produce an Erlang-ish actor based language that was ocaps secure.
While E seems to be deadish, many of its core ideas around object capability security (ocaps) live on. Others have mention Caja, an attempt to bolt ocaps onto JS, but see also Gilad Bracha's current experiments with a Smalltalk variant called Newspeak which is entirely built around ocaps.
Another interesting take on ocaps is Joe-E, which is basically a verifier that allows a subset of Java. If some Java source passes Joe-E then that source is capability secure.
Another interesting aspect of E, vats, is conceptually not too different from actor style concurrency as exemplified by Erlang, except that where one Erlang actor(process) conceptually is one "object," an E vat may hold many objects. Note: Erlang predates E by quite a bit, and the actor model predates Erlang by even more; I just thought it worth mentioning as one way to think about vats.
In fact, Erlang is itself very nearly an ocaps system. Nearly because actors can mostly only talk to other actors after they receive (or spawn) a PID, thus untrusted actors can be limited in capability by not sending them dangerous PIDs. But not quite because some dangerous primitives (like IO) are globally available. It would be straightforward to produce an Erlang-ish actor based language that was ocaps secure.
You would have to rip out a lot of the introspection functionality in erlang to make this work eg
3> [P|_] = erlang:processes().
[<0.0.0>,<0.3.0>,<0.5.0>,<0.6.0>,<0.8.0>,<0.9.0>,<0.10.0>,
<0.11.0>,<0.12.0>,<0.13.0>,<0.14.0>,<0.15.0>,<0.17.0>,
<0.18.0>,<0.19.0>,<0.20.0>,<0.21.0>,<0.22.0>,<0.23.0>,
<0.24.0>,<0.25.0>,<0.26.0>,<0.27.0>,<0.28.0>,<0.36.0>]
4> erlang:process_info(P).
[{registered_name,init},
{current_function,{init,loop,1}},
{initial_call,{otp_ring0,start,2}},
{status,waiting},
{message_queue_len,0},
{messages,[]},
{links,[<0.5.0>,<0.6.0>,<0.3.0>]},
{dictionary,[]},
{trap_exit,true},
{error_handler,error_handler},
{priority,normal},
{group_leader,<0.0.0>},
{total_heap_size,987},
{heap_size,610},
{stack_size,2},
{reductions,2639},
{garbage_collection,[{min_bin_vheap_size,46368},
{min_heap_size,233},
{fullsweep_after,65535},
{minor_gcs,8}]},
{suspending,[]}]