[erlang-questions] Why is Erlang what it is?

[Bruce Fitzsimons]

Serge Aleynikov wrote:
>
> Frankly, where I think static typing is advantageous is in code 
> refactoring.  The compiler with static checking helps a lot at fixing 
> all inter-dependencies when types are being modified.
I think this has been litigated ad nauseum on other languages. The other 
perspective is that static typing is a strait-jacket -- you're forced 
into naming/namespaces to be able to differentiate the types properly 
(and you are doing it "properly" right, making new types where 
required?). You get rigid interfaces and you *have* to change all your 
code. You start getting version dependencies and/or misleading variable 
names if you don't change the type name, and if you change the type name 
all your code needs to be recompiled. Lose/lose in my book.

I've used the (c++) compiler to detect these changes before, which I 
think is the approach you're referring to. It depends on the language, 
but just make sure you don't do anything dirty anywhere, and watch out 
for the implicit conversions and C legacy (int/pointer equiv, 
signed/unsigned ignorance, et al).

Being able to add a new element to a tuple being thrown around the place 
is quite nice. It makes the coupling looser and allows less rigidly 
defined interfaces. You risk your code dying, but then that is where 
your definition and change-control over the interfaces becomes 
important. Static typing doesn't take away the need to do this, and I 
think it becomes a crutch to avoid doing it in a lot of circumstances 
("Hey the compiler will take care of it").

For my part I think the difference between static and dynamic typing is 
a personality thing, do you want to have the (I think false) sense of 
security that all your code clicks together like Lego and enjoy the 
overhead of maintaining types everywhere, or do you want to focus on the 
job at hand and rely on skill and post-analysis to deflect errors. 
Relying on skill is a hard thing to justify if you come from the "it is 
a computer, and therefore we should make things provably correct" 
mindset, but if you come from the craftsman/engineering side it makes 
more sense. I'm starting the programming is art/craft/science flamewar 
again too...

Your mileage will inevitably vary. Refactoring with the cool new tools 
that update all type info at once probably is easier, but I'm not 
convinced that they encourage people to think about the consequences of 
their actions -- they appear much like global search&replace and 
copy/paste which I find to be the beginning of the slippery slope to 
sloppy errors.

Bruce