[Haskell-cafe] In-place modification

Andrew Coppin andrewcoppin at btinternet.com
Wed Jul 11 13:37:06 EDT 2007


Jon Harrop wrote:
> On Tuesday 10 July 2007 21:19:42 Andrew Coppin wrote:
>   
>> Hugh Perkins wrote:
>>     
>>> Yeah I agree with this.  C# totally rocks, but threading is an
>>> unsolved problem.
>>>       
>> I have repeatedly attempted to discover what C# actually is...
>>     
>
> Take Java. Make it Windows only. Fix some mistakes. Tweak performance. Add a 
> little functionality (e.g. operator overloading). That is C#.
>
> Both are designed for GUI and web programming, so they don't fare well for 
> massive concurrency, high-performance numerics or allocation-intensive 
> algorithms (e.g. idiomatic functional programming).
>   

Really? I thought Java was designed to take over the world! LOL.

There are certainly *a lot* of mistakes to fix. OTOH, this is Micro$oft 
we're talking about... how good can it possibly be?

(Windoze-only, you say? Perhaps I misunderstood - I thought this is what 
Mono is all about...)

>> Hint: If you can get readable/maintainable Haskell to run on more than
>> one core "automatically", you're onto something pretty special. ;-)
>>     
>
> If you're using a Unix, just fork the process and pass messages via a pipe.
>   

Yeah, but it's hardly trivial to decide which things are "big enough" to 
be worth forking for, and which aren't.

(Take, for example, a quicksort. You could run the recursions in 
parallel - but once you get down to small enough lists, it isn't worth 
the overhead. But how to know when to stop? You end up adding more 
processing overhead analysing whether to fork than you actually gain by 
forking...)



More information about the Haskell-Cafe mailing list