[Haskell-cafe] Shootout favoring imperative code

[Brent Fulgham]

--- Sebastian Sylvan <sebastian.sylvan at gmail.com>
wrote:
> Some of the problems seem to be heavily geared
> towards an imperative *implementation*, meaning that
a Haskell
> version is hardly idiomatic Haskell (and as such I ,
and I 
> suspect otehrs, really have no inclination to work
on it).

I agree that several benchmarks suffer from this
problem, but
we have been trying to change this where possible.

> Take the fannuch benchmark for instance. Part of it
> is to generate input data (all permutations of a
sequence). It
> would be better to not require the program to print
out the 
> first 30 lists from the input data, since that
places 
> additional (completely unneeded) restrictions
> on how to implement the program (and leads to an
> unnecessarily ugly implementation if you generate
the input in 
> a non-imperative fashion).

I must disagree.  We based this benchmark on a very
standard
benchmark studied by Lisp implementors (and others,
see e.g.,
http://citeseer.ist.psu.edu/315141.html)in an effort
to address
the problems of the original array access benchmark
(which was
extremely imperative in nature).  I don't think asking
Haskell
to handle this simple program is unfair; Ken Anderson
and others
dealt with this for Lisp many years ago.

> I assume it's no coincidence that this sequence
> exactly matches the "straightforward" way to
generate 
> permutations in C.

But I think Haskell may face real-world cases where
data must
be produced in some known order.  For Haskell to be a
contender
in "real world" use, it sometimes has to confront ugly
requirements.

> I should also note that I don't think these
benchmarks mean 
> anything at all. It would be better to test, say,
the best
> possible solutions for some of the ICFP programming
contests, 
> for example. They say a lot more about real-world
speed.

Agreed.  However, it's a lot easier to get volunteers
to
implement small benchmarks (therefore, providing the
ability to
compare many languages) rather than large ICFP
entries.

-Brent