Date: Thu, 7 Oct 1999 11:46:42 +0100
From: William Chesters <firstname.lastname@example.org>
Subject: Re: speed versus C
Gerd Stolpmann writes:
> The basis of your argumentation is that the array solution works
> better with current hardware and typical problem sizes. For
> example, memcpy is very fast because it is specially supported by
> the hardware, much faster than initializing the same number of
> elements of a list. This is absolutely true, but I think that it
> only demonstrates that my example was too simple.
... whereas I believe that it is merely part of a much more general
point. You almost sound like you think the efficiency of arrays
should be discounted because it only applies "with current hardware
and typical problem sizes". It's dangerous to get so carried away by
abstraction that you consider exploiting well-known facts about the
way the computer really is to be cheating.
ocaml is a great language precisely because it doesn't disdain to
get its hands dirty---it knows very well what you have to do to solve
real problems on real computers. For me, the kind of elegance and
beauty you want in a language comes not from constructing castles in
the air, but from using abstract ideas to understand the real world
better. ocaml says "look, this is what you really mean when you write
Incidentally the example you give of C strings is another case
where on reflection you find that the "unsophisticated" way is not so
> My first example looks now far better, because you have forgotten
> to count the function calls to hide the array implementation. In
> Caml, they are not necessary.
Er, what function calls? In most Cs I can explicitly mark them
"inline" (which I can't in ocaml (hint!!!)). Let's try and bear in
mind that good C can be surprisingly readable.
> Caml is simply not good at arrays.
No, it's fine actually, that's one of the reasons why it's so great.
> I think it is not a good idea to adopt too much imperative style.
Equally, it's not a good idea to adopt too much ref-trans style, and
ocaml, thank heavens, supports both very well. Imperative programming
is either better from an efficiency point of view, or stylistically
closer to the best way of thinking about the problem, or both.
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:26 MET