Pascal Costanza <[EMAIL PROTECTED]> writes: > Andreas Rossberg 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'm confused. Are you telling that you just write a+b in your >> programs without trying to ensure that a and b are in fact numbers?? > > Basically, yes. > > Note that this is a simplistic example. Consider, instead, sending a > message to an object, or calling a generic function, without ensuring > that there will be applicable methods for all possible cases. When I > get a "message not understood" exception, I can then decide whether > that kind of object shouldn't be a receiver in the first place, or > else whether I should define an appropriate method. I don't want to be > forced to decide this upfront, because either I don't want to be > bothered, or maybe I simply can't because I don't understand the > domain well enough yet, or maybe I want to keep a hook to be able to > update the program appropriately while it is running.
Moreover, a good proportion of the program and a good number of algorithms don't even need to know the type of the objects they manipulate. For example, sort doesn't need to know what type the objects it sorts are. It only needs to be given a function that is able to compare the objects. Only a few "primitive" functions need specific types. So basically, you've got a big black box of applicaition code in the middle that doesn't care what type of value they get, and you've got a few input values of a specific type, a few processing functions needing a specific type and returning a specific type, and a few output values that are expected to be of a specific type. At anytime, you may change the type of the input values, and ensure that the needed processing functions will be able to handle this new input type, and the output gets mapped to the expected type. Why should adding a few functions or methods, and providing input values of a new type be rejected from a statically checked point of view by a compiled program that would be mostly bit-for-bit the same with or without this new type? Of course, in the process of so modifying the program, we may get some dynamically detected type errors that we would correct as Pascal indicated. -- __Pascal Bourguignon__ http://www.informatimago.com/ "Specifications are for the weak and timid!" -- http://mail.python.org/mailman/listinfo/python-list
