/ e	E Language Original Design Goals

The E language is designed to start as a scripting / rapid prototyping / command language, sacrificing performance and support for programming in-the-large (like static type checking) in exchange for simplicity and ease of use. Not sacrificed even a smidgen is security. Like Original-E, E is a capability-secure persistent distributed pure-object language (it inherits most of these features from our ELib platform).

As a simple one-at-a-time command language, The E language is quickly learnable by non-programmers. As a programming language, E is immediately accessible to programmers schooled in C-tradition languages: C, C++, Java, Python, Perl, Tcl, csh. It should also be accessible to (fingers crossed) Visual Basic programmers. Speaking loosely, Python is to C++ as E is to Java.

Intended Uses at Communities.com:

• Internal poking. The difference between the Smalltalk / Lisp / scripting language experience and the C / C++ / Java experience is striking. In the former, "what would happen if?" questions are answered interactively during that moment of curiosity. This supports learning and debugging. (This difference is often thought to be associated with compiled vs interpreted languages, but this is mistaken, as Smalltalk is as fully compiled as C, and until recently Java was only interpreted.)

  E can already invoke any public method of any Java object. Once E is available, I expect most of us will keep a live E read-eval-print loop at our side while programming.

• Internal Testing. E should be a good language for writing replayable test scripts. Initially for unit testing of internal programming abstractions. Once also made a scripting language for Microcosm, we should be able to easily write replayable scripts of user actions. Which brings us to:

• A Microcosm Command Language. E's message dispatch mechanism is designed to also include calculated verbs, such as appear on our pop-up menus. Once this interfacing is done and scoping issues have been figured out, E is intended to replace our current command line interface.

• A Secure Hub Administration Language. This was actually the motivating case for creating the language.

• User Creation / Extension of World-Object Behaviors. This could range from simply adding new World-Object verbs defined in terms of existing ones, to piecemeal programming interactions like Hypercard's ability to "dive into" a button and edit its script. MOO experiences show this to be a compelling source of richness of the world. See E World Scripting Examples.

Long term, assuming it can eventually be compiled as well as Scheme (as it was designed to be), E could give us a migration path away from Java. E is sort of Original-E without the Java (which ironically is different from Joule, even though Original-E is sort of Joule + Java). We have already spent at least ten times as much effort working around flaws in Java as it takes to invent, build, and support a good simple programming language (like Scheme, Joule, or E). So much for saving effort by leveraging a supported platform!

Oh yeah,

• Making Distributed Secure Programming easy!