Marshall wrote: > Pascal Costanza wrote: >> Consider a simple expression like 'a + b': In a dynamically typed >> language, all I need to have in mind is that the program will attempt to >> add two numbers. In a statically typed language, I additionally need to >> know that there must a guarantee that a and b will always hold numbers. > > I still don't really see the difference. > > I would not expect that the dynamic programmer will be > thinking that this code will have two numbers most of the > time but sometimes not, and fail. I would expect that in both > static and dynamic, the thought is that that code is adding > two numbers, with the difference being the static context > gives one a proof that this is so.
There is a third option: it may be that at the point where I am writing this code, I simply don't bother yet whether a and b will always be numbers. In case something other than numbers pop up, I can then make a decision how to proceed from there. > In this simple example, > the static case is better, but this is not free, and the cost > of the static case is evident elsewhere, but maybe not > illuminated by this example. Yes, maybe the example is not the best one. This kind of example, however, occurs quite often when programming in an object-oriented style, where you don't know yet what objects will and will not respond to a message / generic function. Even in the example above, it could be that you can give an appropriate definition for + for objects other than numbers. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list