[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