[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dynamic vs. static typing
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
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?