Python from Wise Guy's Viewpoint

[Marshall Spight]

"Pascal Costanza" <costanza at web.de> wrote in message news:bnc4bg$r6s$1 at f1node01.rhrz.uni-bonn.de...
> Marshall Spight wrote:
> >
> >>In a statically typed language, when I write a test case that calls a
> >>specific method, I need to write at least one class that implements at
> >>least that method, otherwise the code won't compile.
> >>
> >>In a dynamically typed language I can concentrate on writing the test
> >>cases first and don't need to write dummy code to make some arbitrary
> >>static checker happy.
> >
> > This is a non-issue. In both cases, you need the implementing code
> > if you want to be able to run the testcase, and you don't need the
> > implementing code if you don't.
>
> No, in a dynamically typed language, I don't need the implementation to
> be able to run the testcase.

You need it to be able to run the testcase and have it succeed.
If you just want to fail with undefined method, that's exactly
the same as the compile error.


> Among other things:
>
> - the test cases can serve as a kind of todo-list. I run the testsuite,
> and it gives me an exception. This shows what portion of code I can work
> on next.

The compile errors also serve as a kind of todo list. I run the compiler,
and it gives me an error. This shows what portion of the code
I have to write next.


> - when a test case gives me an exception, I can inspect the runtime
> environment and analyze how far the test case got, what it already
> successfully did, what is missing, and maybe even why it is missing.
> With a statically typed language, I wouldn't be able to get that far.

Okay, so if you want to write testcases for two methods without
writing either, you have to stub in *both* methods and write
one before you can execute the testcases for one successfully.
You'd have to do this eventually anyway; the static compiler
will impose the requirement that you write stubs for the second
one before you execute the first. So I'd admit that the statically
typed language would put a tiny ordering on trivial tasks that
wouldn't otherwise be there.

(Aren't you supposed to write the method right after you
write the testcases, though?)

All those other things you've mentioned are also possible
for statically typed languages as well. (Inspect the runtime
environment, analyze how far, etc.)


> Furthermore, when I am still in the exceptional situation, I can change
> variable settings, define a function on the fly, return some value from
> a yet undefined method by hand to see if it can make the rest of the
> code work, and so on.

I'll acknowledge dynamic languages have an advantage in interactive
execution, which may be considerable.


Marshall