Bart Demoen <[EMAIL PROTECTED]> wrote,
> Manuel M. T. Chakravarty wrote
>
> > I get
> >
> > C++ (your program) : 0.31s
> > Haskell (above prgm): 2.63s
>
> That's really besides the point - I have a Prolog program (no
> cheating !) that solves it in 80 ms with Yap (a Prolog interpreter)
> on a Linux Pentium 166MHz.
Whether it is besides the point or not depends somewhat on
where you perceive the point to be, I think. My point was
to demonstrate to the original poster that by simply
removing the _most_obvious_ glitches in his experiment, he
arrives at a completely different result.
> Solving the generic problem is what you
> want to compete with C on. And feasability, not speed.
My point was _neither_ to educate him in the glorious ways
of good declarative programming nor in any details of fine
tuning Haskell code.
Bart Demoen <[EMAIL PROTECTED]> (in a second message) wrote,
> The problem with these small problems is that once written in a
> declarative way - even the generic cryptarithm solver - (be it Haskell,
> Mercury, Clean or Prolog) it is usually very easy to rewrite them in
> C(++) and get better speed. Actually, the best way to get the fastest
> program to solve any given cryptarithm solver, would probably be to
> write a compiler from cryptarithm problems to C - writing that
> compiler would be a piece of cake in a declarative language and a can
> of worms in C(++).
With all due respect, I think it is exactly this attitude,
which often keeps experienced programmers from trying
"declarative languages". I think, we are better off
focusing on the problems that people asking us to solve
instead of telling them that if they would solve a different
(or more general) problem everything would be different
anyway.
In other words, the goal should be to get reasonable
performance and clarity of code on problems which are also
easy to solve in imperative languages, and then, to excel on
the difficult problems. Otherwise, people might not listen
long enough to ever try a declarative language on a
non-trivial problem.
> Speed is not the only issue - feasability is an issue as well.
I completely agree, but the original poster did not complain
about a slight discrepancy in speed, he was puzzled about an
unacceptable large gap of several orders of magnitude.
Speed is not the only issue, but it definitely is _an_ issue.
Cheers,
Manuel
