Haskell vs. Lisp vs Erlang for Concurrency Oriented Programming?
5 comments
On the contrary, it is simply saying I've already rejected that strategy since it doesn't actually solve the problem. You cannot grow a shared memory system efficiently.
Since someone has actually solved the problem, I'm going with that solution... but was asking if there was an even better solution.
Since someone has actually solved the problem, I'm going with that solution... but was asking if there was an even better solution.
History- Learned Lisp in High School in the 1980s. Since then, procedural (Pascal & C) and then about 17 years of object oriented development.. C++, Java, Ruby, Objective-C.
I am interested in concurrency oriented programming now... and have been directed to Erlang. Others seem to talk about Lisp alot. (I remember enjoying it, but feeling that it wasn't too practical.. but it was only the 3rd or 4th language I learned and I was 17 at the time.)
What seems to be the natural parallelism in Erlang really appeals to me. The 1960s era syntax does not. (I still think in objects.) I haven't investigated Haskell much, or Lisp recently.
If one wants to solve a problem that is naturally highly parallel (like raytracing) what language would you recommend?
I'm open to hearing about other languages than the ones I mentioned.
I'm not interested in careful programming to be thread safe, or mutexes, etc.
Also, I don't really want to start a flame war... but haven't seen many opinions, or specifically an argument for Lisp from a concurrency viewpoint. And if there's a much better language than Erlang out there, I'd love to find out about it now.
And of course, meta arguments by posting links to others advocacy of particular language also appreciated.
I am interested in concurrency oriented programming now... and have been directed to Erlang. Others seem to talk about Lisp alot. (I remember enjoying it, but feeling that it wasn't too practical.. but it was only the 3rd or 4th language I learned and I was 17 at the time.)
What seems to be the natural parallelism in Erlang really appeals to me. The 1960s era syntax does not. (I still think in objects.) I haven't investigated Haskell much, or Lisp recently.
If one wants to solve a problem that is naturally highly parallel (like raytracing) what language would you recommend?
I'm open to hearing about other languages than the ones I mentioned.
I'm not interested in careful programming to be thread safe, or mutexes, etc.
Also, I don't really want to start a flame war... but haven't seen many opinions, or specifically an argument for Lisp from a concurrency viewpoint. And if there's a much better language than Erlang out there, I'd love to find out about it now.
And of course, meta arguments by posting links to others advocacy of particular language also appreciated.
Scheme is cleaner than common lisp. I think Gambit-C has an implementation of Erlang's message passing and mailbox idea for each process and in addition to that it doesn't use OS threads for individual processes it uses first class continuations. In one test it performed similar to Erlang running as many as 900K processes on a 1GB ram P4.
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03309.html
Having said this. I'm really interested in Erlang because of mnesia. I'm not sure if I want to spend a bit of my life writing a database in Gambit.
Here are thoughts from someone who choose Erlang over Scheme. http://theschemeway.blogspot.com/
I don't really agree with his point of view. I think if your problem doesn't really have a strong concurrency element in it which you would solve by using shared data then it probably doesn't make sense to use the message passing model. Having said that if you are writing for the web one day it definitely will have a strong need for concurrency.
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03309.html
Having said this. I'm really interested in Erlang because of mnesia. I'm not sure if I want to spend a bit of my life writing a database in Gambit.
Here are thoughts from someone who choose Erlang over Scheme. http://theschemeway.blogspot.com/
I don't really agree with his point of view. I think if your problem doesn't really have a strong concurrency element in it which you would solve by using shared data then it probably doesn't make sense to use the message passing model. Having said that if you are writing for the web one day it definitely will have a strong need for concurrency.
Thanks very much for the pointers! I followed up on them and they led to some interesting reading... still leaning toward erlang.
This is like saying I am not interested in solving any real problem, just in concurrency for the sake of it.