"Marshall" <[EMAIL PROTECTED]> writes: > There are also what I call "packaging" issues, such as > being able to run partly-wrong programs on purpose so > that one would have the opportunity to do runtime analysis > without having to, say, implement parts of some interface > that one isn't interested in testing yet. These could also > be solved in a statically typed language. (Although > historically it hasn't been done that way.)
I keep hearing this, but I guess I fail to understand it. How "partly-wrong" do you require the program to be? During development, I frequently sprinkle my (Haskell) program with 'undefined' and 'error "implement later"' - which then lets me run the implemented parts until execution hits one of the 'undefined's. The "cost" of static typing for running an incomplete program is thus simply that I have to name entities I refer to. I'd argue that this is good practice anyway, since it's easy to see what remains to be done. (Python doesn't seem to, but presumably a serious dynamically typed system would warn about references to entities not in scope?) -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list