Static typing

[Bruno Desthuilliers]

Michael Muller wrote:
> In article <3f23ae06$0$21093$626a54ce at news.free.fr>, "Bruno Desthuilliers"
> <bdesth.nospam at removeme.free.fr> wrote:
> 
>>Michael Muller wrote:
>>Interface documentation may be obtained in others ways (docstring for
>>exemple).
> 
> 
> Yes, and that's the way that I do it now.  But the problem with this is
> that it's "non-binding": it doesn't impose any programmatic constraints.
> Because of this:
> 
> -   it's hard to enforce automatically (if you want to make sure that all
> programmers in your team are using the prescribed argument definition
> conventions, you have to parse all the docstrings)

It's a management problem, not a programming language issue.

> -  there is no global standard (I might use "name: type info" in my
> docstring, you might use "type name")

Idem.

> -  it is hard to guarantee that the documentation is in sync with the code
> (if you change the type expectations of a function, you can do so without
> changing the documented expectations)

Idem. If your programmers don't care about keeping doc in sync, you're 
in trouble whatever the language.

> -  it makes type errors less obvious (you end up getting an attribute
> error when you perform an operation on the value instead of a type error
> when you initially abuse the interface)  Although, I must say that this is
> surprisingly less of a problem in Python than one might expect.

Yep. Type errors are not the most common nor the most annoying bugs. If 
only declaring types three times was enough to get bug-free programs...

> 
>>And I'm not sure static typing would optimize anything, but not being a
>>Python (nor anything else) guru, I would not bet my hand on this... my 2
>>cents...
> 
> 
> In and of itself, static typing does not optimize anything.  In fact, it
> could slow things down because you suddenly have to do typechecks all over
> the place.
> 
> Static typing can be /used/  for optimizations because it allows for
> optimized forms of attribute access - 

Right.

> without it you must do dynamic name
> resolution at runtime.

Which is a Good Thing IMHO.

> For example, if you want to resolve a method name, you currently have to
> look up the method name in the object and its classes.  With static
> typing, since you know the type of the object at compile time, you can
> just reference it in a "vtable" (a virtual function table) associated with
> the object.
> 
> In short, static typing brings us one step closer to "python compiled to
> machine code".

Well... Objective C is compiled to machine code, and still has dynamic 
binding (not late binding as in C++), so static typing does not seem 
mandatory here.

Anyway, I personnally don't have a compelling need for Python being 
compiled into machine code, and just don't want to here about it if it 
implies static typing !-)

The only thing that could make sens to me would be a protocol-checking 
mechanism, and there are already some.

Bruno