[Haskell-cafe] In-place modification

Sebastian Sylvan sebastian.sylvan at gmail.com
Sun Jul 15 13:05:14 EDT 2007

On 15/07/07, Hugh Perkins <hughperkins at gmail.com> wrote:
> On 7/15/07, Donald Bruce Stewart <dons at cse.unsw.edu.au> wrote:
> > However, if you're keen, and agreeing to implement the same algorithm on
> > both systems,
> Sorry, the rule is you use what's available in your chosen language,
> otherwise I have to restrict myself only to use things available in Haskell,
> which is kindof silly dont you think?

Nobody is saying anything different. We're just saying that you have
to implement the same thing in both languages. Don't compare insertion
sort with merge sort, for example, compare insertion sort with
insertion sort and merge sort with merge sort. If you don't, any
differences you detect have nothing to do with the language itself,
and is as such completely useless!

If you have a neat way of doing something due to some language
feature, then do use it (see lazy lists in Haskell, compared to the
awkward lazy streams in C#, or imperative array updates in C# compared
to the somewhat awkward readArray/writeArray etc.)! But use the same
algorithm if you want to draw any valid conclusions!

As we've demonstrated there's nothing stopping you from writing
imperative "C-like" algorithms in Haskell (just like C#), and there
certainly wasn't any major performance difference (did you even
benchmark Dons latest entry? Not the template haskell one, but the one
before that? If you want you can replace the unsafeRead/unsafeWrite in
the same way I did in mine -- I'd still like to see how it fares with
the better cache performance and the other optimizations that you had
in the C# version).

If you want to compare two languages, then implement the same
algorithm in each. Don't implement a naive and elegant, or a flexible
and general algorithm in one of the languages, and then compare it
with a completely different algorithm in the other language (written
specifically for the benchmark itself, rather than as a
general/flexible algorithm). It just doesn't give you any useful data,
and you'd be wasting your time, and we wouldn't want that would we?

I think dons summed it up nicely. We tried both approaches,
lazy/general, and imperative/fast. In the former verion C# was
horrible compared to Haskell, in the latter the performance was about
the same (again, please benchmark Dons latest entry if you haven't).
Hardly a resounding victory for C#!

> The issue with the shootout is there's no room for creativity, it's like
> working for a manager who micro-manages.

I thought the point wasn't to compare programmer's creativity, but to
compare languages?

Sebastian Sylvan
UIN: 44640862

More information about the Haskell-Cafe mailing list