yozzeff thinks

musings about programming

Montag, März 13, 2006

static typing vs. dynamic typing

that debate about strongly typed languages vs weakly (or dynamicly) typed languages will probaly never end.


the reason being that both camps usually present their arguments as a XOR relation. meaning you either use a strongly typed language or you dont use any types at all.

the problem thou is that both are wrong even thou i admit that the dynamic camp is usually more open minded - certainly due the fact, that proponents of dynamic languages often have switched sides from for example java to ruby or python so they usually _know_ about the attributes of typed as well as of untyped languages. the camp of typed language diehards on the other hand (especially java guys) have often never used any dynamic language in earnest - but nevertheless claim superiority. which bags the question on which facts.

No Value on Its On

now if you ask me ... being typed or untyped is no value in itself. other attributes define if typed is a postive trait or if it is a negative trait.

a big system might be much better off if its typed whereas small and medium systems might be better off if untyped.

2type || !2type

now of course the question remains when is a system
big and when is system small?
let me give you 2 measures (which are of course incomplete):

- lines of code (LOC)
- number of developers

problem nobody would argue if i say that any system that is a million lines of code is pretty big - regardless of language used; whereas a team of 3 developers is rather small.

now the problem with small projects is that they tend to grow. especially the successful ones grow and grow and suddenly your system is 250k LOC and 15 developers and you realize that the informal ways of communication you have used do not scale. especially the communication between the subteams breaks all the time.


its time to start formalizing communication paths between devlopment groups. the easiest way on formalizing communication between teams is to add type information to your external interfaces.
now before all you java guys start to shout: "we knew it all the way" please reread the last sentence. i am talking about explicit external interfaces that a team and group publishes to the outside world for consumption. that usually includes services and facades and classes used for data exchange.
your internals can stay untyped and often it is far better if they do. especially if that module is still under heavy development or refactoring.
but then the same advices goes to your dynamic typers - especially you python guys opposing any addition of optional type information into python 3000.
please! documentation is NO substitue for enforced type checking. you are kidding yourself if you belive that.


now good thing with some of the dynamic languages is that you can overcome that point where you should start adding type annotations. all languages that offer decent meta facilities can very well create their own optional static typing system. ruby and python 2.4+ fall into this camp whereas javascript is not capable of such a feat.

the problem with java on the other hand is that it can not "scale down".
it is simply not possible to have parts of your program "untyped" - you can hack around it with reflection and xml and the like but ist
ugly - ugly - UGLY!


so what can we do about all of this? well, basically nothing. there are a few languages out there that do optional typing (boo for example - a python clone). some languages like scala or nemerle are at least trying to do type interference which spares you at least the pains of java generics. but most of these languages are even more obscure than ruby had been 3 years ago (meaning that almost nobody knows them).
i wish for a optional typed ruby or a java where i could drop type infos. that would be nice.