"Strong typing vs. strong testing"
Scott L. Burson
Scott at ergy.com
Thu Sep 30 20:06:18 CEST 2010
Pascal J. Bourguignon wrote:
> Squeamizh<squeamz at hotmail.com> writes:
>> In short, static typing doesn't solve all conceivable problems.
>> We are all aware that there is no perfect software development process
>> or tool set. I'm interested in minimizing the number of problems I
>> run into during development, and the number of bugs that are in the
>> finished product. My opinion is that static typed languages are
>> better at this for large projects, for the reasons I stated in my
>> previous post.
Here's a post I wrote earlier, before the conversation got cross-posted.
To me, this is the essence of the matter.
> OK, but sometimes it is handy to have the possibility to make
> assertions which prevent you from committing easily avoidable simple
Agreed. I actually don't see this issue in black and white terms; I've
written lots of Lisp, and I've written lots of code in statically typed
languages, and they all have advantages and disadvantages. In the end
it all comes back to my time: how much time does it take me to ship a
debugged system? Working in Lisp, sometimes I don't get immediate
feedback from the compiler that I've done something stupid, but this is
generally counterbalanced by the ease of interactive testing, that
frequently allows me to run a new piece of code several times in the
time it would have taken me to do a compile-and-link in, say, C++.
So while I agree with you that compiler warnings are sometimes handy,
and there are occasions, working in Lisp, that I would like to have more
of them(*), it really doesn't happen to me very often that the lack of
one is more than a minor problem.
(*) Lisp compilers generally do warn about some things, like passing the
wrong number of arguments to a function, or inconsistent spelling of the
name of a local variable. In my experience, these warnings cover a
substantial fraction of the stupid mistakes I actually make.
More information about the Python-list