[Tutor] Dynamic/Weak Types and large projects

[alan.gauld@bt.com]

> 1) Dynamic vs. Weak Types 

Weak typing is where the environment doesn't much care 
about type or where there are relatively few types existing.

For example in the early versions of Tcl everything was 
a string. You could pass anything into a function and 
Tcl just saw it as a string, it was only when you tried 
to use it that it fell over because it didn't know how 
to take the square root of "spam" for instance.

Python is similar because everything is a reference so 
the type checking gets done when you try to use it

Example:
>>>def f(a,b):
...   if a < b: print "smaller"
...   return b
...
>>>f(1,2)   # works OK
>>>f('a',2)  # errrm, what happens here?
>>>f([1,2,3],3+4j)  # even more so!

Python doesn't object to the function calls, rather any 
complaints come inside the function where the comparison 
is made. That's weak typing.

> 2) General consensus is that for large projects 
> strongly typed languages are better. Is there any 
> statistical proof of this beside hearsay? 

Yes. The reason strong typing(usually static typing) 
is important for large projects is that they tend to 
be built by large teams of people, often in different 
geographic locations working to paper specifications. 
It is important that interface definitions are 
rigorously adhered to and strong typing checks that
by raising the error early - usually at compile time.

Because errors are cheaper to fix the earlier you catch 
them its much better to find these inconsistencies 
before shipping rather than during integration testing.

You might think it would be caught during component 
test but the people who write the code normally do 
component test and they will use the code as they 
expect it to be used, which may not be how the 
client programmers(located elsewhere) expect to use 
it. By having the interface explicitly stated in 
a header file(C or C++) or an IDL file
(DCOM/DCE/CORBA/RMI etc) the code will fail to compile 
for whoever is not using the interface correctly.
(That's the benefit of static typing)

That's the theory. Unfortunately there's a lot that 
can still go wrong. 

int f(int, int);

defines a func that takes two integers but says nothing 
about the semantics of those integers, so the order 
could be interpreted differently at each end of the 
interface. Languages like ADA, Pascal, C++ allow us to 
define very strict types so that we can reduce that 
problem by using enums or sets which restrict the range 
of valid values(one reason the C #define approach 
discussed recently is a "Bad Thing")(This is obviously
a more "strict" typing) However that only reduces the 
problem not overcome it.

Nonetheless studies have shown that incompatible 
type usage is a significant problem on large projects 
and static/strict typing does help ameliorate it.

What is important to realize however is that this is 
a cost saving feature it is NOT a reliability issue. 
With a decent exception handling system (like Pythons)
the code either way will be equally reliable, its 
just a matter of when/how you catch the bug.

Alan g.
Author of the 'Learning to Program' web site
http://www.freenetpages.co.uk/hp/alan.gauld