I recently bought Linux Format which featured an article on the E programming language. It is written in java and is an interpreted language. If you don’t like java, there is also one based on common lisp. Just make sure that you don’t use gcj to try and get it up and running, I experienced quite a few problems when attempting to use this JRE.
E is a programming language that removes deadlocks for multi-threaded applications by using promises. I have coffee and am waiting on sugar, you have sugar and are waiting on coffee. Deadlock. Normally, this is overcome by stating you must get coffee before trying to get sugar, and thus you remove the deadlock. What E does, is it says I promise to give you the coffee if you give me the sugar. Not only is this pretty powerful, but here is the kicker: the computation for each thread doesn’t have to be on the same machine. Imagine that the coffee thread is on machine A, and that sugar is on machine B connected over a network. Once machine A promises to give the coffee to machine B, machine B acts as though it has a value until it needs the value. So machine B can go and … buy snacks from the vending machine while machine A makes his coffee. When A is done making coffee, it hands over the coffee and the sugar to B for him to make his coffee: automagically. If machine B got his snacks from the vending machine and now wants to drink his coffee, but doesn’t have it yet, it will patiently wait until machine A is done making coffee before continuing.
I imagine that the types of applications that would get the most use out of this would be SETI @ home and Folding@Home. Although these probably have a robust and flexible model for doing this, I’d imagine that it was pretty difficult to create and could have been done more quickly when E matures.
Hey that is pretty nifty. Deadlock-bucking promises seems like a slightly insignificant feature to base a language around though. Most languages boast new paradigms or a whole set of new features such as this. In fact, they are working on adding stuff like this into C++ IIRC.
Regardless, it’s an interesting idea and makes a lot of sense. Have some code watch over your threads and make them play nice and share =)
I think that it’s not only deadlock-bucking, but allowing it to go seemlessly over a connection is what makes it neat. It takes about 4 lines of code to run a remote function, although I’m not sure of any benchmarking.
Slightly insignificant? No way. For mission critical applications it is a must have. I’ve not really heard of E before but Erlang has been in the news a lot lately. It is praised for that same reasons, and that is why it is being used in systems that need to be highly fault tolerant. Erlang as well as many others
use message passing and actor model for concurrency. It’s pretty interesting also.
Erlang goes way above and beyond E. Erlang not only concentrates on local concurrency (which they did 20 years ago!), but multi-node concurrency! That is why it is so popular lately.
So yes, a new language with only deadlock-bucking is nothing significant. Erlang’s had it for 20 years along with many other breakthroughs.