Walter Bright" <newshound1@digitalmars.com> wrote in message
news:hqsuac$29rh$2@digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message
>> news:hqsn2j$1s29$1@digitalmars.com...
>>> bearophile wrote:
>>>> Being Haskell not easy, it's even possible for me to not understand the
>>>> explanation if some Haskell expert eventually explains me why that
>>>> Haskell
>>>> program was slow :-)
>>> It's statements like this (and I've heard this repeatedly) that makes me
>>> wonder what the value of Haskell actually is to conventional programming
>>> tasks and regular programmers.
>>
>> Not that I have an opinion either way, but FWIW, very similar things
>> could probably be said for C++.
>
> I know, and that creates an opportunity for other languages!
Definitely :)
Although, I guess what I meant by that was that if there were someone
unexperienced in imperative systems languages, C++ would probably have a few
things to teach them, even though it may present them in a
much-less-than-ideal form.
-------------------------------
Not sent from an iPhone.

Fri, 23 Apr 2010 06:23:22 -0700, Walter Bright wrote:
> bearophile wrote:
>> Walter Bright:
>>> OCaml has a global interpreter lock which explains its behavior.
>>> Russell didn't know why the Haskell behavior was so bad. He allowed
>>> that it was possible he was misusing it.
>>
>> You have just the illusion to have learned something about this. Trying
>> to read too much from this single example is very wrong. A single
>> benchmark, written by a person not expert in the language, means nearly
>> nothing. You need at least a suite of good benchmarks, written by
>> people that know the respective languages. And even then, you have just
>> an idea of the situation.
>
>
> Fair enough, but in order to dismiss the results I'd need to know *why*
> the Haskell version failed so badly, and why such a straightforward
> attempt at parallelism is the wrong solution for Haskell.
>
> You shouldn't have to be an expert in a language that is supposedly good
> at parallelism in order to get good results from it.
Why not? Do you think parallelism is simple to manage (efficiently)? No
offence but a total novice has zero understanding of e.g. threads or 3rd
party libraries. The best he can do is to come up with something using
the stdlib Thread classes. Usually it fails miserably due to deadlocks or
other synchronization issues with locks.

On 04/23/2010 10:10 AM, Walter Bright wrote:
> Michael Rynn wrote:
>> OK where's the naive version of the D Pi program that scales up with
>> 1,2,4 cores? How far off are we? Is the concurrency module working
>> with it yet?
>
> Nobody's written a library function to parallelize a map/reduce yet.
Funny you mention that. I actually started a map/reduce library that I
was planning on having run in parallel on a single machine. I didn't
get very far as I had to divert my attention elsewhere. I really need
to get back to it because it was an interesting little problem to work on.
Casey

On Fri, 23 Apr 2010 19:09:55 -0400, retard <re@tard.com.invalid> wrote:
> Fri, 23 Apr 2010 06:23:22 -0700, Walter Bright wrote:
>
>> You shouldn't have to be an expert in a language that is supposedly good
>> at parallelism in order to get good results from it.
>
> Why not? Do you think parallelism is simple to manage (efficiently)? No
> offence but a total novice has zero understanding of e.g. threads or 3rd
> party libraries. The best he can do is to come up with something using
> the stdlib Thread classes. Usually it fails miserably due to deadlocks or
> other synchronization issues with locks.
I think his point was that a person who *does* understand parallelism and
threading couldn't get it right. Not being an expert in the *language*
does not make you a novice at threading.
Of course someone who does not understand threading/parallelism is bound
to have troubles no matter what the language until he/she gains more
experience. You almost have to experience a deadlock-after-2-weeks
problem to really get how important threading issues are (I did).
-Steve

"retard" <re@tard.com.invalid> wrote in message
news:hqt94i$2sgv$2@digitalmars.com...
> Fri, 23 Apr 2010 08:57:54 -0500, Andrei Alexandrescu wrote:
>
>> On 04/23/2010 07:00 AM, Clemens wrote:
>>> (As an aside, I'm generally a bit put off by the hostility towards
>>> programming language research and theory in the D community. "We don't
>>> need no stinking theory, we'll just roll our own ad-hoc solution which
>>> will work much better because ivory-tower academics are completely out
>>> of touch with reality anyway." Bleh.)
>>
>> I hope that trend has been definitively reversed.
>>
>> Andrei
>
> Instead of hostility we now have blissful ignorance. Maybe I should post
> here more often again..
When the academic researchers keep their work squirreled away in academic
circles and written in such a convoluted style that only other long-term
ivory-tower residents can get far enough past the language to see the actual
meaning, it's a wonder that *anyone* finds it surprising that programmers
are ignorant of it.
And that's just the researchers that actually *do* know what they're doing.
Let's not fool ourselves into thinking that the *majority* of academia
actually knows it's head from it's ass (yea, that's right - I've brought it
back to hostility).
-------------------------------
Not sent from an iPhone.

On Fri, 23 Apr 2010 16:00:32 +0400, Clemens <eriatarka84@gmail.com> wrote:
> Walter Bright Wrote:
>
>> * Not all functional programming languages do concurrency well. Haskell
>> and
>> OCaml in particular have severe fundamental problems with it such that
>> parallelizing your code makes it slower.
>
> Do you have a reference on that? I'll produce one to the contrary:
> http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking-4core
Haskell is cool but I am puzzled with that Haskell vs C example.
What is he comparing? Parallel Haskell vs what?
Also he is right by using the argument "naive",
but more likely "naive use of the language" for a given algorithm, the
very thing you arguing against?
I'd like to see the comparisons of a "non-naive" implementations too :)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On 04/23/2010 10:40 PM, Nick Sabalausky wrote:
> "retard"<re@tard.com.invalid> wrote in message
>> Instead of hostility we now have blissful ignorance. Maybe I should post
>> here more often again..
>
> When the academic researchers keep their work squirreled away in academic
> circles and written in such a convoluted style that only other long-term
> ivory-tower residents can get far enough past the language to see the actual
> meaning, it's a wonder that *anyone* finds it surprising that programmers
> are ignorant of it.
The style of academic papers is not convoluted on purpose. The good
papers discuss new solutions to difficult problems and therefore must be
very precise so as to convey a trove of information in a short space.
Preparing a good academic paper may take six months or more. A magazine
article of the same length may take an afternoon.
> And that's just the researchers that actually *do* know what they're doing.
> Let's not fool ourselves into thinking that the *majority* of academia
> actually knows it's head from it's ass (yea, that's right - I've brought it
> back to hostility).
That's a truism. Clearly there will be many foot soldiers and few
generals in any field. The majority of developers can also be considered
to not quite know what they're doing.
I've had an email diatribe with an acquaintance who had the same stance
"academia sucks". He kept on going how pretentious and fake it was, and
I couldn't figure where he was coming from, until one day when he
mentioned he'd been an academist so he has first-hand experience. The
problem was he was in the outer academic circles that go through the
motions of research (author papers, hold conferences, publish
proceedings and journals) but they aren't quite doing research. At that
point I agreed with him.
Andrei

Hello Walter,
> You shouldn't have to be an expert in a language that is supposedly
> good at parallelism in order to get good results from it.
Very good point. If a design with no blatant flaws performs like that with
no easy to spot cause, I'd say there is a problem in the language, even if
the problem is in the program.
--
... <IXOYE><

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message
news:hquqfm$2vse$1@digitalmars.com...
> The majority of developers can also be considered to not quite know what
> they're doing.
>
Heh. I've surprised a lot of laymen, after telling them I'm a programmer, by
my opinions that most programmers are incompetent and most software and
consumer electronics are terrible. Seems hugely ironic to those unfamiliar
with the field, but being around it and (at the risk of narcissism) knowing
what I'm going, I think puts me (along with many of the people on this
board) in a prime position to notice flaws and steps backwards.
-------------------------------
Not sent from an iPhone.

Nick Sabalausky wrote:
> Heh. I've surprised a lot of laymen, after telling them I'm a programmer, by
> my opinions that most programmers are incompetent and most software and
> consumer electronics are terrible. Seems hugely ironic to those unfamiliar
> with the field, but being around it and (at the risk of narcissism) knowing
> what I'm going, I think puts me (along with many of the people on this
> board) in a prime position to notice flaws and steps backwards.
I share your opinion that most software and consumer electronics is terrible. Of
course, I've produced my share of terrible software, but I won't make any
excuses for doing so.
For example, my TV set crashes every once in a while, and must be power cycled :-(
The old analog sets never did that!