February 4, 2006 at 3:42 pm · tags: E
I started reading E in a Walnut and E feels great. I just want to point out some advantages and disadvantages of the language:
Why E
E’s promise-pipelining architecture ensures that deadlock cannot occur.
Excluding user interface code, a simple but effective peer-to-peer secure chat system has been written in less than 30 lines of code; no more lines of code were required to write a basic digital-money bank server despite the severe security issues involved.
E can even enable the fearless yet powerful use of multi-party limited-trust mobile code. “Mobile code” is just about anything executable on your computer that you get from somewhere else. Every time you turn on a word processor, play a game of Solitaire, or double click on an email attachment, you are executing mobile code written by someone you probably don’t know and should not trust. Yet we give Solitaire, Barbie Fashion Designer, and Christmas Elf Bowling the full power to read our most private documents, sell them on EBay to the highest bidder, and then delete all your files. Our grandchildren will laugh at how silly this was, yet today there is no choice. If Microsoft used E instead of Visual Basic for its application language, Word and Excel would not be vectors for attacks like the original Love Letter virus. If all software were written in E, Klez and BackOrifice could never have existed: indeed, the term “virus”, so loved by the press because it implies incurability, would never have been applied to computing.
E has C/Java syntax, is built with objects at core design, has powerful string handling and is dynamically typed…
Why not E
The current implementation of E runs on top of the java virtual machine. As such, it is not a good language for low level machine manipulation.
And E’s performance is quite unfavorable compared to raw C, so do not write the real time kernel of a missile guidance system with it, either.
Actually, most arguments over performance miss the most important points about software development. One of the few time-tested truths of software development is, “first get it to work, then get it to work fast”. E is an excellent language for getting a system to work. Once it is working, you can gain the performance rewards by profiling to see which portions of the code actually affect performance, then rewriting those (typically small) portions in Java, or C, or assembler, depending on your needs.
So… learn E 
February 3, 2006 at 4:28 pm · tags: E
Just gone through another bit of documentation about E language. Now about remote objects.
E is secure by default and that’s is great. Enough said.
The thing that makes it so secure it’s the core of his RPC mechanism. Every object is remotable (no need of mixin classes or awful scaffolding). What it takes to remote an object? Two lines of code:
[code lang="javascript"]
def sr := makeSturdyRef.temp(your_object)
def uri := introducer.sturdyToURI(sr)
[/code]
Now you have an encrypted uri to share (securely, use PGP or something like that) with your peers to gain access to the remote object.
To the other side now you have to get the remote object and call the method you want. Again… very easily:
[code lang="javascript"]
def remote := sr.getRcvr()
def val := remote <- call_the_method_you_want()
[/code]
val is a promise as I explained earlier
Great, isn’t it?
Here the full details of the examples: Introducing Remote Objects
February 2, 2006 at 5:10 pm · tags: E
This is my first glance on E.
It’s a very intuitive language. This is a non-commented copy of the Finding Text online tutorial, check there if you want to know more.
Let the code itself speak.
[code lang="javascript"]
def find(file, substring) :void {
for num => line in file {
if (line.includes(substring)) {
print(file.getPath() + “:” + num + “: ” + line)
}
}
}
def findall(path, ext, substring) :void {
if (path.isDirectory()) {
for file in path {
findall(file, ext, substring)
}
} else if (path.getName().endsWith(ext)) {
find(path, substring)
}
}
def args := interp.getArgs()
if (args.size() != 3) {
throw(”usage: findall.e rootname extension substring”)
}
def root :=
findall(root, args[1], args[2])
[/code]
January 28, 2006 at 3:52 pm · tags: E
Yesterday I took a look at E. It’s a special language.
The things that make it so special are his security-by-design and the concept of promise. A promise is somewhat like a deferred in Twisted domain. The language assures you that it will call the remote method in an asynchronous manner and tell you when data is ready (see Dataflow concurrency, lazy evaluation and Oz)
See what the documentation of E says:
The promise architecture described here is the heart of what makes E different. There are no multiple threads, no synchronize statements, no critical objects, no deadlocks. Yet the promise architecture allows the construction of all the different distributed programming behaviors that more conventional architectures allow. The consequence is that distributed systems written in E are more robust and easier to work with– once you have grasped the implications of promises.
The current implementation sits on top Java (it won’t work on 1.5 but on 1.4 runs fine) and seems quite slow. There is another on-going implementation on top of Common Lisp and by now it’s slower because uses parts of the Java one.
If you are somehow interested in concurrency it’s worth a look.
« Previous entries
