On static typing

Tuesday 10 August 2004

After a small project of mine was converted from Python to C#, I have a new-found admiration for Python’s dynamic typing, and other cool features like named arguments in function calls. I have come to believe this about static typing:

Static typing prevents certain kinds of failures. Unfortunately, it also prevents certain kinds of successes.


Some details might be interesting. What kind of successes?
I agree. Are there any languages that offer both? I know VB sort of does (declare a variable variant and you get 0 static type checking on it), but the type of the object is still firmly set, you can't add new methods and properties to it at runtime.

I'm not sure what such a language would look like, but when writing in static languages I frequently wish I had more dynamicism (is that a word?) for just some parts of the code.

The current fuss about adding function decorators to the Python language suggests that Python is on the way towards adding optional static type declarations to the language...

The question is: with things like Starkiller and Boo (a Python-like language apparently with type inference), would type declarations really offer that much more over and above type inference for programs with low levels of magic? (Where my definition of magic is stuff like metaclasses, messing around with inheritance hierarchies, and so on.)
Whilst I can imagine decorators will help runtime environments more precisely infer how classes and functions should be treated (what type should IronPython tell .Net this argument takes?), and debuggers might well use them to set conditional breakpoints on type assertion failures, I don't think we're sliding into Hell in a static type declaration handbag, here. :)
Oh, forgot to say: I know entirely what you mean by having success prevented. In Python, it's trivial to (say) iterate through a list of classes, instantiating and calling each one. In statically typed VB.Net, it's a nightmare that took me half an hour of wading through documentation to figure out:

for stepclass in [step1, step2]: stepclass().run()

In VB.Net, that's:

Dim NoArgs as Object() = {}
Dim CommitSteps As Type() = {GetType(StepType1), GetType(StepType2)}
For Each StepType As Type In CommitSteps
Dim ThisStep As CommitStep = StepType.GetConstructor(Signature).Invoke(NoArgs)
Damien: Common Lisp offers both. Dylan might too, I'm not sure.
how about boo (http://boo.codehaus.org), the .NET python knockoff? hideously incomplete but sweet with python niceness...
Damien: Objective-C has a generic "id" type that is very convenient. Unfortunately, the memory management is wacky for someone used to more dynamic languages (though I suppose autorelease pools are a step up from doing everything yourself).

Objective-C is often forgotten, but Apple (or NeXt, rather) got it right with Cocoa. Check it out.
Oh, and the PyObj-C bridge seems to work well. best of both worlds (almost).
Anonymous Coward 3:37 PM on 16 Aug 2004
I think checking for syntax errors is an important part of building software. I recently installed Fedora Core 2. The installer is written in python. How do I know? Well after selecting a couple seldom used options, the installer spit out a python compile error. How is this a good thing?
Compiling on demand is a separate concern from dynamic typing. As a Python developer you can pre-compile everything (and test your code). The fact that some developers have done a bad job using Python isn't a fair indictment against the language.
Ok, I'll give you that one. Truthfully they should have used a static analyzer like pyChecker.

Don't get me wrong. I really like python. I'm just not sure I would use it for a really big project.
Try it for a medium sized project. I was pretty bloody skeptical, myself. Once I'd actually done a mid-sized project, though, I was hooked by how easy it all was. Now, *all* my large projects are in Python.
If the points of comparison are Python/Common Lisp/Scheme on the dynamic language side vs. C#/Java/C++/C on the static language side, then I think the conclusion as stated is kind of obvious.

Where it starts to get interesting, though, is when you stack a Python up against a more modern static language with a rich type system and type inferencing: at least an O'Caml or Haskell, but preferably a Nice or a Scala or a Cayenne or an Epigram.

I've spent decades with Common Lisp and Scheme and, to a lesser extent, Smalltalk. Did all of my recreational programming in them until about two years ago, at which point I discovered O'Caml in the process of stumbling across Ensemble. I find O'Caml to strike a really nice balance between being functional and imperative, and between static-typing-with-inference and dynamic checking. And I have to say that I like the safety. For example, there are OpenGL bindings in O'Caml that are type-safe where the native C APIs are not, thanks to the use of phantom types.

I should also add that the thing that I thought I was getting from my dynamic languages, which had a lot to do with interactive, incremental development, I also get from O'Caml: it has an interactive toploop, a bytecode compiler, and a native compiler. It also has an awesome time-travel debugger for the bytecode compiler and a profiler for the native compiler, so it really can take you all the way from type-and-go to tweaking to get those last few CPU cycles out. It's got a goodly number of great libraries (not like Perl or Python, though, admittedly!) and it's quite easy to link C/C++ in (in fact, current O'Caml has great support for loading DLLs on the fly). So if you think that C#/Java/C++/C are the state of the art in statically-typed languages, let me recommend giving O'Caml a try.

"I have come to believe this about static typing"

People believe all kinds of things. It's more interesting to hear about the evidence they use to support those beliefs.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.