"Strong typing vs. strong testing"

BartC bc at freeuk.com
Sat Oct 2 01:50:53 CEST 2010


"Pascal J. Bourguignon" <pjb at informatimago.com> wrote in message
news:877hi1iq2o.fsf at kuiper.lan.informatimago.com...
> "BartC" <bc at freeuk.com> writes:

>> (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

>> 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.

I mentioned 'C' because it's one of the cross-posted languages; I normally
use my own language. Nevertheless, both of these (as well as Python and
probably many others) require no more than 4 parentheses in the line in
question; the Lisp line above uses 12 (including the 2 I moved to the next
line for clarity).

And needing an extra "+" when you want to add 3 things instead of 2, sort of
makes it obvious that you do have 3 things instead of 2... In fact the error
would never have got so far. Sometimes redundancy in syntax is useful.

>> 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.

Well, 60 seconds is pretty slow even for an interpreter; even plain CPython
took only 30 seconds.

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

OK.


-- 
Bartc 




More information about the Python-list mailing list