Re: dynamic vs. static typing

[Dave Hudson <address@hidden>]

As someone who predominantly programs in a statically typed language and 
who finds that at least 10% of my functions have to resort to tricks to 
implement dynamically typed behaviour I find I have very little sympathy 
with the extremes of arguments in favour of STL or DTL.

Much as I would dearly like a DTL at times my software is designed to 
run embedded in millions of different types of devices and must not 
break, nor must it be large.  The efficiencies that are possible with an 
STL make my systems possible, while the pedantic warnings of my compiler 
prevent bad things from happening when I mistakenly try to do something 
that I shouldn't.  Wherever I do switch to using dynamic behaviour I end 
up with functions full of runtime assertions to catch things that might 
go wrong as the result of some programming error since there is at least 
a hope that such dynamic errors can be found during testing.

What I do find is that more and more often I find myself wanting static 
analysis of the dynamic parts of my system.  Testing is often not enough 
to guarantee what I want and is somewhat tricky anyway (knowing what may 
go wrong is quite an art :-)).  Worse still I know that very large parts 
of my program probably don't get exercised during testing because much 
of the code is only triggered when error conditions (non-fatal ones) 
occur, such as temporarily running out of memory.

I've toyed with writing a language to express the sorts of problems I 
want to solve but have always stopped because of endless indecision 
about efficiency vs flexibility.  It does occur to me now though that I 
may finally have seen a solution.  If I start with a DTL as my basic 
language design (e.g. say something like scheme) but then rather than 
relying on type inferencing alone, actually add an explicit assertion 
concept then I can start to meet both requirements.

The assertions would fulfil two roles - in a purely dynamic (e.g. 
interpretted) environment they would act as dynamic runtime traps to 
detect bad things happening.  In a static environment they can 
explicitly guide my compiler to more efficient implementations of my 
code and also to annotate to the compiler when things are statically 
correct or not.  This suggests that I can have a very lightweight system 
to explore a problem backed up by a heavyweight one that will help 
enforce the correct use of the solution, while also helping it become 
more streamlined.

It seems that this middle ground is a much better place to play :-) 
Perhaps I've missed something but it seems that the simple addition of 
type assertions mean that I can code either fully dynamically, fully 
statically (e.g. if I constrain each parameter to a function with a type 
assertion) or anywhere inbetween?  Is there any reason why such an 
approach would preclude the use of type inferencing say?


Regards,
Dave