"Strong typing vs. strong testing"

[Tim Rowe]

On 27 September 2010 18:46, namekuseijin <namekuseijin at gmail.com> wrote:

> Fact is:  almost all user data from the external words comes into
> programs as strings.

Sorry, sent this to the individual, not the group.

I'd be very surprised if that were true. I suspect the majority of
programs are in embedded systems, and they will get their "user data"
come straight from the hardware. I doubt the engine controller in your
car or the computer inside your TV pass much data around as strings.
Of course, Python probably isn't the ideal language for real-time
embedded systems (I expect an advocate will be along in a moment to
tell me I'm wrong) but it's important to remember that the desktop
isn't the be-all and end-all of computing.

For what it's worth, all the research I've seen has found that
compile-time checking and testing tend to catch different bugs, so if
correctness is really important to you then you'll want both. The
truth of the matter is that correctness is only one factor in the
equation, and cost is another. Python tilts the balance in favour of
cost -- it's really fast to develop in Python compared to some other
languages, but you lose compiler checks. That's the right balance for
a lot of applications, but not for all. If it's really critical that
the program be correct then you'll want a bondage-and-discipline
language that does masses of check, you might even do separate static
analysis, and you'll *still* do all the dynamic testing you would have
in Python.


-- 
Tim Rowe