"Strong typing vs. strong testing"
BartC
bc at freeuk.com
Fri Oct 1 19:50:53 EDT 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