Seebs <usenet-nos...@seebs.net> writes: > On 2010-10-01, Pascal J. Bourguignon <p...@informatimago.com> wrote: >> Seebs <usenet-nos...@seebs.net> writes: >>> On 2010-10-01, Pascal J. Bourguignon <p...@informatimago.com> wrote: >>>> compiler passes wrong type wrong result fails at run-time >>>> (the programmer (with exception >>>> spends hours explaining this is >>>> finding the the wrong type) >>>> problem) >> >>> I have no clue what exact scenario you're talking about here. I've never >>> seen a bug that could plausibly be described as "compiler passes wrong >>> type" which wasn't picked up quickly by running with more warnings enabled. > >> This is the scenario discussed in this thread, a long is passed to >> maximum without a compiler warning. > > The compiler didn't pass the wrong type, the user did.
And the compiler passed it on without saying anything. >>> And on the other end of things, it is not always obvious or straightforward >>> to figure out *why* the dynamic language has ended up with something of the >>> wrong type, or what's wrong with that type. > >> It is on the contrary rather obvious or easily discoverable, looking at >> the backtrace, and inspecting the data structures referenced from it. > > This is a fascinating assertion, but it is slightly marred by not actually > being generally true. It's often the case that it's pretty obvious, but > sometimes it's not so obvious -- it can take quite a bit of doing to figure > out how or where some hunk of a data structure got set up wrong. It's very > easy to find the call where a nil was passed to something expecting some kind > of integer; it's sometimes not so easy to find the completely unrelated hunk > of code which modified the data structure half an hour earlier. When debugging C program, you are perfectly right. But I don't observe the same when debugging lisp programs. -- __Pascal Bourguignon__ http://www.informatimago.com/ -- http://mail.python.org/mailman/listinfo/python-list
