It is also nice to know that Erlang has been used for desktp software (and not just parallel computing, servers...). The open-source wings3d modeller is written in Erlang. www.wings3d.com

Bruno Medeiros Wrote:
> Brad Anderson wrote:
> > Bruno Medeiros wrote:
> >> I read in a recent article (I think it came from Slashdot, but not sure) that a new programming paradigm is needed to make concurrency easier, just in the same way as OO (and class encapsulation) improved on the previous data abstraction paradigm to make code cleaner and easier to write. Just in the same way as structured programming (ie, using functions/scopes/modules) improved on the previous paradigm of sequential/global/goto-using code, so to speak.
> > 
> > http://www.pragmaticprogrammer.com/articles/erlang.html
> > 
> > search for "Concurrency Oriented Programming"
> > 
> > BA
> 
> 
> Hum, again Erlang, interesting. I had heard a bit about it before, on an
> article (again don't remember where) about a comparison between Apache
> and a web server built in Erlang. On a multicore machine Erlang did much
> because of it's massively parallel capabilities, etc..
> This makes Erlang very interesting, but one must then ask questions
> like: What restrictions does Erlang's approach have? Does it have
> disadvantages in other areas or aspects of programming? Is it good as a
> general purpose programming language, or is it best only when doing
> concurrent applications? Can any of it's ideas be applied to imperative
> languages like D, Java, C#, etc.?
> I personally am not looking deep into this (never had the use to study
> concurrency in-depth so far), I'm just pointing out that a lot of things
> have to be considered, and I have a feeling that there must be some
> downside to Erlang, or otherwise everyone else would be trying to bring
> Erlang aspects into their languages. Or maybe Erlang is just taking
> momentum. Time will tell.
> 
> 
> -- 
> Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

BCS wrote:
> Reply to Pragma,
> 
>> There are moments where I wish I could think *like* Rain Man,
>> especially when it comes to concurrency.
>>
> [...]
>> If nothing else, it illustrates that there's something
>> extraordinary about such abilities that may be permanently
>> out-of-reach for normal people, despite the fact that some people are
>> just born that way.
>>
> 
> I have wondered if this is something like incomputableity with regards to a Turing machine. Might the normal brain be like a Turing machine and the autistic brain be something like a brain not limited in the same way? Given that some people can, for instance, identify large primes in near constant time, I'd say this is a distinct possibility.

I agree.  There's a whole range of "brain temperments" that give rise to all kinds of "ab-normal" behaviors like this. Autism is one.  Synesthesia is another.

I saw this one program about a savant (of the non-idiot variety) that was a "visual-numerical synesthete": he could read a number and would see it's "shape" in his mind's eye.  By focusing on various facets of the shape and color, he could determine all kinds of things without using math: odd/even, prime, factors, etc.  When asked to use clay to model these shapes, it was found to not be a hoax, and that his reckoning of these numbers was highly regular and uniform. Fascinating stuff.

So the real question becomes: If the real top-tier* insights are permanently out of reach for us "mere mortals", how do we teach a program to garner these kinds of insights (for parallelism and optimization) for us instead?

(*I think we can all agree that parallelism is not inherently difficult to grasp. But for sizable programs, where to split things up can be a very tough problem to sovle correctly.)

-- 
- EricAnderton at yahoo

Bruno Medeiros wrote:
> Hum, again Erlang, interesting. I had heard a bit about it before, on an article (again don't remember where) about a comparison between Apache and a web server built in Erlang. On a multicore machine Erlang did much because of it's massively parallel capabilities, etc..

Probably this one: http://www.sics.se/~joe/apachevsyaws.html


> This makes Erlang very interesting, but one must then ask questions like: What restrictions does Erlang's approach have? Does it have disadvantages in other areas or aspects of programming? Is it good as a general purpose programming language, or is it best only when doing concurrent applications? Can any of it's ideas be applied to imperative languages like D, Java, C#, etc.?

My (very limited) experience with Erlang on a (very small) pet project is that you can't just transliterate a Java or C# app to Erlang. The paradigm is too different, you have to redesign the entire app to benefit from Erlang's features; but, once you start to get comfortable with it you get several times more productive with Erlang.


> I personally am not looking deep into this (never had the use to study concurrency in-depth so far), I'm just pointing out that a lot of things have to be considered, and I have a feeling that there must be some downside to Erlang, or otherwise everyone else would be trying to bring Erlang aspects into their languages. Or maybe Erlang is just taking momentum. Time will tell.

Some of it's concurrency features could be implemented as a library. gen_server and family is a Template Method using callbacks + Green threads + error recovery on steroids.

What I'd really like to see on D is the bit syntax and pattern matching. It is very useful to implement binary protocols and parsers. But I'm not holding my breath.

Bruno Medeiros wrote:
> BCS wrote:
> 
>> Reply to Pragma,
>>
>>> There are moments where I wish I could think *like* Rain Man,
>>> especially when it comes to concurrency.
>>>
>> [...]
>>
>>> If nothing else, it illustrates that there's something
>>> extraordinary about such abilities that may be permanently
>>> out-of-reach for normal people, despite the fact that some people are
>>> just born that way.
>>>
>>
>> I have wondered if this is something like incomputableity with regards to a Turing machine. Might the normal brain be like a Turing machine and the autistic brain be something like a brain not limited in the same way? Given that some people can, for instance, identify large primes in near constant time, I'd say this is a distinct possibility.
>>
>> At risk of sounding politically incorrect; does anyone known of an autistic person who might be interested in learning programming?
>>
>>
> 
> Autism is not synonymous with savantism, which is what you where thinking of.
> 

No, I was not necessary thinking of savantism. More generally I was thinking about people whose brains function abnormally. This covers autism, savantism, insanity, Psychopathy and genius[*] among others. Autism just happens to be (if I understand correctly) the more profound and general (savantism seems to be a subset) abnormality with regards to the type of intellect associated with CS style tasks.

* If you ask me, insanity is where the brain works differently and it get in the way, genius is where the brain works differently and it helps. They are not mutually exclusive and if fact probably correlate quite well.

But green threads don't take advantage of multi-core processors, neh?

Julio César Carrascal Urquijo Wrote:

> Bruno Medeiros wrote:
> > Hum, again Erlang, interesting. I had heard a bit about it before, on an article (again don't remember where) about a comparison between Apache and a web server built in Erlang. On a multicore machine Erlang did much because of it's massively parallel capabilities, etc..
> 
> Probably this one: http://www.sics.se/~joe/apachevsyaws.html
> 
> 
> > This makes Erlang very interesting, but one must then ask questions like: What restrictions does Erlang's approach have? Does it have disadvantages in other areas or aspects of programming? Is it good as a general purpose programming language, or is it best only when doing concurrent applications? Can any of it's ideas be applied to imperative languages like D, Java, C#, etc.?
> 
> My (very limited) experience with Erlang on a (very small) pet project is that you can't just transliterate a Java or C# app to Erlang. The paradigm is too different, you have to redesign the entire app to benefit from Erlang's features; but, once you start to get comfortable with it you get several times more productive with Erlang.
> 
> 
> > I personally am not looking deep into this (never had the use to study concurrency in-depth so far), I'm just pointing out that a lot of things have to be considered, and I have a feeling that there must be some downside to Erlang, or otherwise everyone else would be trying to bring Erlang aspects into their languages. Or maybe Erlang is just taking momentum. Time will tell.
> 
> Some of it's concurrency features could be implemented as a library. gen_server and family is a Template Method using callbacks + Green threads + error recovery on steroids.
> 
> What I'd really like to see on D is the bit syntax and pattern matching. It is very useful to implement binary protocols and parsers. But I'm not holding my breath.

Robert Fraser wrote:
> 
> Julio César Carrascal Urquijo Wrote:
> 
>> Bruno Medeiros wrote:
>>> Hum, again Erlang, interesting. I had heard a bit about it before, on an article (again don't remember where) about a comparison between Apache and a web server built in Erlang. On a multicore machine Erlang did much because of it's massively parallel capabilities, etc..
>> Probably this one: http://www.sics.se/~joe/apachevsyaws.html
>>
>>
>>> This makes Erlang very interesting, but one must then ask questions like: What restrictions does Erlang's approach have? Does it have disadvantages in other areas or aspects of programming? Is it good as a general purpose programming language, or is it best only when doing concurrent applications? Can any of it's ideas be applied to imperative languages like D, Java, C#, etc.?
>> My (very limited) experience with Erlang on a (very small) pet project is that you can't just transliterate a Java or C# app to Erlang. The paradigm is too different, you have to redesign the entire app to benefit from Erlang's features; but, once you start to get comfortable with it you get several times more productive with Erlang.
>>
>>
>>> I personally am not looking deep into this (never had the use to study concurrency in-depth so far), I'm just pointing out that a lot of things have to be considered, and I have a feeling that there must be some downside to Erlang, or otherwise everyone else would be trying to bring Erlang aspects into their languages. Or maybe Erlang is just taking momentum. Time will tell.
>> Some of it's concurrency features could be implemented as a library. gen_server and family is a Template Method using callbacks + Green threads + error recovery on steroids.
>>
>> What I'd really like to see on D is the bit syntax and pattern matching. It is very useful to implement binary protocols and parsers. But I'm not holding my breath.
> 
> But green threads don't take advantage of multi-core processors, neh?

http://www.erlang.org/ml-archive/erlang-questions/200606/msg00187.html

BA



 --
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Robert Fraser wrote:
> But green threads don't take advantage of multi-core processors, neh?

Perhaps not, but Erlang now supports SMP.  From the wiki: "Erlang has supported symmetric multiprocessing since release R11B of May 2006." This blog entry is also informative:

http://www.franklinmint.fm/blog/archives/000792.html


Sean

Robert Fraser wrote:
> But green threads don't take advantage of multi-core processors, neh?

There's very little that's black and white when it comes to the lines between processes and threads (both kernel and user space).  I worked with a thread library that allows migration of individual threads between _processes_.  It's the only one like that I've ever seen, but it worked, and quite elegantly (and unfortunately proprietary).  It's relatively easy to produce of a M:N model that's a combination of kernel level threads combined with user space threads.

Erlang is indeed a very interesting system if for no other reason that it's fairly unique.  I wish I could find 3-6 months to really get my hands dirty with it, but alas, that's behind another dozen or so projects.  Anyone wanna be my lackey, I mean research assistant?  The pay would be crappy, the housing not free, and the hours sucky.. but it'd be fun, honest!

Later,
Brad

Brad Roberts wrote:
> 
> Erlang is indeed a very interesting system if for no other reason that it's fairly unique.  I wish I could find 3-6 months to really get my hands dirty with it, but alas, that's behind another dozen or so projects.  Anyone wanna be my lackey, I mean research assistant?  The pay would be crappy, the housing not free, and the hours sucky.. but it'd be fun, honest!

Now that I'm learning about Erlang I'm discovering that it seems to work a lot like how I wanted to approach concurrency in D, so I'm definitely going to try and find some time to play with it.


Sean

Robert Fraser wrote:
> But green threads don't take advantage of multi-core processors, neh?

Actually they do if they are executed by a pool of OS threads (At least one per core, for example).