

The E programming language - lisperforlife
http://www.erights.org/

======
lisperforlife
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?

~~~
jerf
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.

~~~
evgen
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.)

~~~
jerf
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.

~~~
evgen
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.

