Python from Wise Guy's Viewpoint

John Atwood jatwood at cvpjaws03.dhcp.cv.hp.com
Tue Oct 28 13:52:08 EST 2003


Matthew Danish  <mdanish at andrew.cmu.edu> wrote:
>On Sat, Oct 25, 2003 at 12:37:38AM +0000, John Atwood wrote:
>> Pascal Costanza  <costanza at web.de> wrote:
>> 
>> >- 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.
>> >
>> >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.
>> 
>> That's because you're in an interpreted environemt, not because you're 
>> using a dynamically typed language.  Interpreters for statically typed 
>> languages allow the same.
>
>Wrong on all counts.
>
>* Most Common Lisp environments compile to native code, even when
>  working interactively.
>  SBCL, for example, has no interpreter whatsoever.  The interpreter is
>  simulated by calling the compiler and evaluating the resulting
>  function immediately.

If the code is executed in the environment, and one can execute
arbitrary snippets of code, it's an interpreted environment, 
regardless of whether the code executed is native, bytecode,
or other.

>* There exists statically typed language implementations which do the
>  same (SML/NJ)

Yes, these are among those I have in mind when I say "Interpreters for 
statically typed languages allow the same."

>* The behavior of redefinition in a statically typed environment
>  is far different from the behavior in a dynamically typed environment.
>  For one thing, generativity of names kicks in, which makes it
>  basically impossible to redefine types and functions without
>  recompiling all uses (and thus restarting your program), in a static
>  environment.

Yes, and that's a good thing. It prevents the program form getting in an 
unreachable/inconsistent state, and secondly, in an FP, especially a pure 
FP, with explicit state, one need not run the program from the start to 
test whatever code is of interest at the moment, because the state can be 
created via test cases.


John




More information about the Python-list mailing list