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.

XOR

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.

Formalizing

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.

Workarounds

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!

Solutions?

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.

2 Comments:

At 1:53 nachm., Blogger Reinier Zwitserloot said...

I don't know if dynamic typing is itself ever neccessary. I've used it, and I've never found myself wishing I could do this:

a = "foobar"
a = 3

for the simple reason that I want to re-cycle the 'a' name. However, sometimes I do wish to actually stuff strings OR integers (or whatever) in a single variable... but this can still be typed. a's type is just 'object' or some such in that case.

The only problem with typing is all the explicit casts and vartypes that have to be explicitly typed in.

A good friend of mine has been toying with the idea of 'source views'. The idea being that there is one ridiculously verbose language which requires that you specify absolutely everything, in relatively rigid syntax...

but that's not usually the language you type in. You type in something else, possibly not even something purely text. ie: Your IDE automatically keeps track of the type of all identifiers and automatically waters them down as needed to fit all uses. At any time, just hover over that identifier, anywhere, and you get the type. Some keyboard combo will allow you to redefine and lock a variable's type.

That some concept can be carried out to always enforcing listing whether or not you are overriding a method or creating a brand new branch (this makes that whole CameraGun thing on my blog extremely simple) but your 'source viewer' keeps track of this info behind the scenes, only bringing it forward if you need it to be explicit, or if you want to know.

 
At 7:26 nachm., Anonymous Anonym said...

Surely EIFFEL does dynamic typing and automatically optimises those cases that can be done with static typing. Checks are performed at compile-time without need for global-program analysis (i.e. it supports the separate compilation of modules like CLU did). It won't let the same identifier in the same scope take on two different types though (like a = 3 and a = "fubar") but it makes sense to allow it across module boundaries (i.e. during parameter passing) as that involves a change of scope/activation record... I don't like the vagueness of it though - i.e. what are the capabilities of V when it can be an instance of a class C or any of its descendants. Hmm.

- Nick

 

Kommentar veröffentlichen

Links to this post:

Link erstellen

<< Home