[Haskell-cafe] In-place modification

Sebastian Sylvan sebastian.sylvan at gmail.com
Sun Jul 15 16:26:49 EDT 2007

On 15/07/07, Hugh Perkins <hughperkins at gmail.com> wrote:
> On 7/15/07, Sebastian Sylvan <sebastian.sylvan at gmail.com> wrote:
> Hi Sebastian,
> There are literally thousands of problems at http://topcoder.com.  I'm
> totally fine with using any of these as a benchmark.
> Can you find one that shows off the strengths of Haskell?

Can you find me a list of the contests? I find that site impossible to
navigate efficiently.

Roughly speaking the strenths of Haskell are mainly increased
productivity, safety, and realiability. Not something you can test for
by meassuring performance of finished solutions (who knows how long
the C version took to create?). However, in terms of performance
Haskell is pretty good at laziness, algebraic manipulations of
(possibly infinite) data structures, and concurrency (especially if
you require atomic operations on shared data - since you can use STM
rather than locks, which also gives you exception safety for free).

Also, I believe you already have two suggested benchmarks that you
could try, so why not start with those since they already have
implementations in lots of languages, including Haskell and C#?

> > You don't think that multiple agents interacting in a concurrent
> setting is representative for real programs? It is, and by simplifying
> it down to the core problem, you can test the "difficult bit" far more
> easily than if you were to require everyone to write a full-on telecom
> operatings sytem, or any other application that's concurrent in the
> same style, for each language you want to compare.
> Yes, actually that's exactly the problem I have at work that I'm looking for
> a solution for.

Okay, so what's the problem then?
Why not implement this one very simple application that tests just
this thing and see what happens? In fact, there already is a C#
implementation for it, if you can't find anything wrong with it, then
don't you have the information you need? If you can find something
wrong with it, fix it (and submit the fix!), and see how the improved
version fares (remember, you can't change the algorithm as it would
void the comparison!).

Point is, you have at least two suggested problems that you could try
out, and you now say that one of them is even a great fit for your
specific problem domain, so get cracking and you'll have your answer

Sebastian Sylvan
UIN: 44640862

More information about the Haskell-Cafe mailing list