It seems James has come under fire for his dogged persistence that static typing gets in the way of solving real world problems.
The comments are right in that whether a language is dynamic or static doesn't directly affect whether the types have limits or not.
What Dare fails to understand is that specifying a type specifies a limit. Lets take some examples:
int a;
float b;
char foo[128];
In the above three examples we have limits. Some are obvious and known up front, some are not so obvious and depend on the platform your program runs.
Now, it's very easy for a dynamic language to fall in to the non-obvious limits trap as well. But, lets presume we have a smart language that knows when its limit has reached and overflows.
In the case of Smalltalk, it overflows from SmallInteger in to LargeInteger or from NativeFloat in to LargeFloat. The situation here is changing the type and memory layout of the object involved.
At runtime, changing the type and memory layout of an object in a statically typed language is not possible - the code has been compiled to assume shape and method calls that are possible on the statically defined type.
So, while James was a bit over eager to attribute this problem solely on static typing, it is clear that the solution to this problem is not as straight forward as it is in a dynamic language as it can be in a static language.
In fact, in a static language, you could define a type that dynamically changes itself at runtime, lets call this DynInt. The problem is that then you have to change all your code to use and make DynInt's instead of int's. Again, another disadvantage of static typing. it's just the nature of the beast.
Previous Topic
