Hi,
IMHO there is a problem with the choice of the example: As a newcomer to
a programming language you start with simple examples, of course. And
how do you judge the simplicity of an example? By your programming
experience with other languages. So you will use examples that are
simple in, say, C++.
In fact this sort of generate-and-test cryptarithm solvers is
particularly simple in C++ because:
- It does not require any memory management.
- A library function for permutations happens to be available.
- The computational complexity of the example is still small enough for
a brute-force generate-and-test approach. A more intelligent solution
is not needed.
The example is also easy to program in Haskell. But in contrast to C++,
Haskell has not much chance to use its particular strengths here. The
strength of C++ is of course its ability to do in-place updates of
memory cells.
Let's compare this situation to medicine. Consider a new medicine B for
a certain illness is to be tested. You might say: "Let's test it with
persons that are not too seriously ill." When you select such persons
(without explicitly thinking about their current treatment), you will of
course get the group over-represented for which the old medicine A does
help. And when you compare A and B on your group of persons, it is
likely that A appears better than B. Researchers in medicine can tell
you that such an approach leads to misleading results.
>From a Haskeller's point of view, there are other examples that can be
considered as relatively simple. These typically involve recursive data
structures. Already just with lists and numbers there are nice examples.
To give just one, the list of prime numbers can be defined in 2 lines
using Eratosthenes' sieve:
> primes = sieve [2..] where
> sieve (p:xs) = p : sieve [x | x <- xs, x `mod` p /= 0]
How many lines of C++ code do you need to implement this?
For really complex tasks you sometimes cannot afford to include some
algorithmic optimization into C++ code because it is already so complex.
The corresponding Haskell code might still be simple enough so that
including the algorithmic optimization is feasible. That way you might
get Haskell programs that are more efficient than their C++
counterparts.
Just my 2 cents,
Heribert.
