"Strong typing vs. strong testing"

[Pascal J. Bourguignon]

"BartC" <bc at freeuk.com> writes:

> "Pascal J. Bourguignon" <pjb at informatimago.com> wrote in message
> news:87sk0qkzhz.fsf at kuiper.lan.informatimago.com...
>
>> Nothing extraordinary here.  Common Lisp is more efficient than C.
>> http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf
>> http://portal.acm.org/citation.cfm?id=1144168
>>
>> Actually, it's hard to find a language that has no compiler generating
>> faster code than C...
>
> I had a quick look at Lisp to see if your claims had any basis. I
> tried this program:
>
> (defun fib (n)
>   (if (< n 2)
>       n
>       (+ n (fib (- n 1)) (fib (- n 2)) )
> ))
>
> But it gave the wrong results and it took ages to figure out why. Even
> after downloading a working version for comparison, it's was difficult
> to spot the extraneous 'n' (I think I was concentrating on getting the
> round brackets all in the right places).
>
> I thought you were saying that Lisp (and dynamic typing in general)
> was better for pointing out errors? The above error in C would have
> been picked up more easily I think (due to less parentheses clutter,
> and more obvious separators between terms).

There are more parentheses in C (you must take into account {} and []
too, and <> in C++), and the additionnal separators in C are clutter.


> As for speed, executing fib(38) took about 60 seconds on my machine
> (gnu clisp with no switches set). 

Yes, you choosed the ONLY CL implementation having an interpreter by
default, and which when compiling, compiles to a virtual machine.  This
happens also to be my favorite CL implementation, which tells you how
much I care about those silly time benchmarks.

If you want to try a CL implementation generating faster code, try SBCL.


> (Compared with 3.5 seconds, for my
> own interpreted, dynamic language, and 0.6 seconds for C.)

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/