April 23, 2010
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.


April 23, 2010
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.
April 23, 2010
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
April 24, 2010
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
April 24, 2010
"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.


April 24, 2010
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/
April 24, 2010
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
April 24, 2010
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><



April 24, 2010
"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.


April 24, 2010
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!