ErlCee++

[Joe Armstrong]

 ... cut ...
 
> I'm wondering if anyone else on this list who loves Erlang as much as
> I do but has been forced to work in pure C++ has attempted this?  I'm
> looking at bringing over:
> 
> 	- one mailbox per concurrent activity
> 
> 	- selective receive
> 
> 	- send/receive as the only synchronization primitive allowed
> 	  (we'll just have to enforce this one through development processes
> 	   and code reviews)
> 
> 	- no program globals (only registered processes; also will need to
> 	  be enforced through development processes and code reviews)
> 
> 	- "lightweight" processes. 

... cut ...

  Some comments:

	YES

  This philosophy  is if you like one  of the key ideas  in Erlang (the
others have to do with error  handling) - Interestingly we are not the
only people to like this approach.

  Ask Mr. Google about "indigo" and "longhorn" - and you'll see what I
mean IYSWIM.

  <<incidentally if you  want to "motivate" your approach  tell 'em about
Indigo - and call what  you're doing "service oriented programming" --
then you'll  be buzz word  compatible and hopefully  get a MAR  [1] of
8.2>>

  A well-tried method of program development is to spend the odd 
5 minutes over and some of your valuable evening time hacking
time on an Erlang prototype that does everything that the C++ program
will eventually do (at some indeterminate point in the future) -
this can then be "demonstrated" to management.

  Something like: 

  "I hacked up  this little thing at home just  to clarify some design
issues -- we can use it as a bench mark/reference implementation/...
... look at this, I've got 100,000 sessions going, course the Java system
that we're building will only handle 2000 sessions but that's a limitation
of Java ....  

  Good luck

  /Joe

   


[1] Management Acceptance Rating.