Interesting thought. One can argue that the ability to write better OO code is already present in modules, functions, processes, and asynchronous message passin

Interesting thought. One can argue that the ability to write better OO code is already present in modules, functions, processes, and asynchronous message passing. Threads are needed in Ruby and Java to handle the asynchronous piece. Consider also Erlang's pattern matching style of defining functions, which reminds me a bit of generics in CLOS. Lisp like atoms are also a very useful device in Erlang. So it strikes me that this proposal is sort of re-inventing in Erlang something that already exists. Moreover when one throws in OTP and it's frameworks for structuring collections of processes, I'm not quite sold on the benefits of doing this beyond making Erlang accessible to the larger audience steeped in the OO way. Corrado Santoro has done a little bit with this in his agent technology http://www.diit.unict.it/users/csanto/exat http://www.diit.unict.it/users/csanto/exat