Never trust a statistics you didn't forge yourself

[ke.han]

I have to agree that not only Java, but many languages (if you count 
their library support) provide for concurrency via thread locks around 
shared data.  I have built extremely scalable and efficient application 
and system frameworks in Java that encapsulate concurrency for the 
application programmer.  And now that I don't have to support Java 
anymore, I looked for a different solution and found erlang was the best 
go forward solution (most notably for its concurrency model).
I suppose we get used to the far more useful concurrency paradigm in 
erlang that the mainstream model appears low level and not a first class 
language feature.

I'm sorry to see such a tirade about this parallel language report.
I think the report speaks only two things:
1 - The report didn't have a large enough response to provide meaningful 
statistics.
2 - The only meaningfully statistic I can produce from the report and 
its fall out is that when other language communities were asked to fill 
out the questionnaire, they didn't show as much support as the erlang 
community.  This statistic only holds if you think it was the community 
on the erlang maillist that were the bulk of the pro-erlang responses. 
What this implies is obviously subjective..but I know where I stand ;-)

BTW, I remember the post which Joe wrote referencing the questionnaire. 
I did not fill it out.
The reason I remember this post is because I read every post on this 
maillist regardless of the sender.  One the many reasons I chose to use 
erlang is because I really like the maillist community...responsive, 
friendly, professional and not too much useless traffic (although this 
post may qualify ;-).

thanks again to this maillist for making erlang a great choice!!!
ke han




Ulf Wiger (AL/EAB) wrote:
>  
> (I've trimmed the receiver list a bit.)
> 
> Joe wrote:
>>> To be fair, Java does support concurrency at the language level. It 
>>> just happens to do it poorly.
>> No it doesn't java thread map to OS threads - see for example 
> 
> Well, yes, but mapping to OS threads shouldn't in itself
> disqualify a language from being called concurrency-oriented
> (Erlang/OTP R11 will probably support the option of making 
> use of OS threads, at least for running multiple schedulers.)
> 
> Java does support concurrency at the language level. It 
> happens to do it poorly. Leaving the issue of preemptiveness
> open to each occasion is perhaps the worst mistake, but 
> relying on a shared-object model is not that great either.
> 
> The fact remains: Java _was_ designed with concurrency in
> mind.
> 
> This is also the common perception. Quoting from "Java in
> a Nutshell" ((c) O'Reilly 1997):
> 
> "Java makes programming with threads much easier, by 
> providing built-in language support for threads. The 
> java.lang package provides a Thread class that supports
> methods to start and stop threads and set thread 
> priorities, among other things. The Java language 
> syntax also supports threads directly with the 
> 'synchronized' keyword. This keyword makes it 
> extremely easy to mark sections of code or entire
> methods that should only be run by a single thread
> at a time." (Page 8)
> 
> /Ulf W
>