Re: RAD vs. performance

Robbert Haarman wrote:
On Tue, Jun 20, 2006 at 10:53:11AM +0100, Jon Harrop wrote:
You're beating a straw man. I am not assuming that my code is correct
because it passes the static type checker.

You did say that "it's not uncommon to have code that passes the type
checker run correctly the first time. No need to waste time unit
testing.", IIRC. When I questioned the wisdom of not doing actual
testing (how do you even know your code is correct if you haven't tested
it?),

Actual testing or unit testing? I tend not to unit test OCaml code
unless I have reason to believe it may be buggy (e.g. it uses dynamic
typing) because experience suggests that OCaml code that compiles tends
to pass unit tests, i.e. static checking is often a substitute for unit
testing. I beta test all code, of course.

you said you think static typing can eliminate the need for some testing.

Yes.

To me, it really looks like you are assuming correctness based
on the results of the type checker.

Yes.

I am saying that code which
passes a static type checker tends to pass unit tests, whereas code written
in dynamically typed languages like Lisp tends to fail lots of unit tests
and require a lot more work before you have something that you can have
faith in.

Doesn't that just mean your tests are wrong?

No, it means that dynamically typed code that compiles is more error
prone that statically checked code.
Of course, but only because of the definition of dynamic typing. If one
extends the term "dynamic typing" to allow for compile-time errors when
errors are guaranteed to occur, it becomes a whole other matter
entirely. With such a type system, the amount of errors that are
detected at compile time will be about the same as a static type system
given a decent editor with good warnings for the edge cases and a
responsible programmer.

If your types are wrong, you will get wrong results, so your
tests will catch that.

Hopefully, after enough testing. Or you could use static checking and
find most of the bugs immediately.
Testing code is not what a type system is for; a good type system will
catch invalid values which violate type specifications, but comparing
said values and validating them against the function at hand is
practically the definition of unit testing.

This may or may not be true, depending on a number
of things, e.g. the amount of code you have to write in your statically
typed language vs. your dynamically typed language,

OCaml tends to be significantly more concise than Lisp.
This might be true (/might/), although (common) lisp isn't the best
language to compare to when talking about verbosity, or lack thereof. I
find python and ruby tend to be very concise depending on what you're
doing. In any event, this is all circumstantial unless you have some
evidence to back that up.

.