From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA15847 for caml-redistribution; Thu, 7 Oct 1999 14:20:17 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA12667 for ; Thu, 7 Oct 1999 12:52:29 +0200 (MET DST) Received: from mail5.svr.pol.co.uk (mail5.svr.pol.co.uk [195.92.193.20]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id MAA05259 for ; Thu, 7 Oct 1999 12:52:27 +0200 (MET DST) Received: from modem-101.pravachol.dialup.pol.co.uk ([62.136.84.101] helo=toy.william.bogus) by mail5.svr.pol.co.uk with esmtp (Exim 2.12 #2) id 11ZB9s-0000Jd-00 for caml-list@inria.fr; Thu, 7 Oct 1999 11:52:24 +0100 Received: (from williamc@localhost) by toy.william.bogus (8.8.7/8.8.7) id LAA02740; Thu, 7 Oct 1999 11:46:42 +0100 Date: Thu, 7 Oct 1999 11:46:42 +0100 Message-Id: <199910071046.LAA02740@toy.william.bogus> From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: caml-list@inria.fr Subject: Re: speed versus C In-Reply-To: <99100702163301.21475@ice> References: <199910061521.QAA02123@toy.william.bogus> <99100702163301.21475@ice> X-Mailer: VM 6.34 under Emacs 20.2.1 Sender: weis 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 machine code". Incidentally the example you give of C strings is another case where on reflection you find that the "unsophisticated" way is not so bad ... > 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.