View mode: basic / threaded / horizontal-split · Log in · Help
April 23, 2010
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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
Re: Things I Learned from ACCU 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!
1 2 3 4 5 6
Top | Discussion index | About this forum | D home