Static/Dynamic? Why not both?

So.. it's been quiet here. I decided, a bit more than a week ago to learn LISP. I have been hearing things about LISP every so often, how great it was, so I got this feeling that I should give it a look. Somehow, in the middle of this project I decided to study Ruby as well. To add to all this I'm trying to compare both of them to C# 3.0.

It's been an interesting journey (which is not done yet). Both languages are of the dynamic variety, which I have a personal bent against. I see the value of dynamic typing for some situations, and it certainly made a number of interesting features of both languages easier.

For example, dynamic typing is very useful for interpreters (like IRB or REPL), and it is easier to include metaprogramming, or LISP style macro capabilities in a dynamic language.

On the other hand, static typing has immense benefits too. The obvious one is the ability of the compiler to protect you from yourself. Most dynamic typing advocates tend to dismiss this as the argument of a "newbie", but the truth is that it is not as simple even as protecting you from yourself, but perhaps protecting you from your neighbor, etc.

It is naive to assume that experienced developers don't make mistakes. In fact, the most experienced developers probably make more mistakes than average because unless they are lazy they are working on harder problems.

But.. I am starting to rehash a common debate, which is totally unnecessary. It is unnecessary because I don't believe that dynamic and static typing are wholly incompatible. Maybe if the two camps would bury the hatchet we'd see better alternatives.

Dynamic languages for example, can easily include psuedo-static typing, and quite a few do to a very limited degree. But why is it so limited? Take LISP as an example. LISP includes support for declaration of types, but it is very rarely used, except for performance gains. I could be wrong here, but I think the main reason is LISP implementations never included type checking. Most dynamic languages actually tend to eschew the concept of compilation entirely.

I think it is great to be able to quickly test your code in an interpreter (or JIT as is the general case), but why aren’t there systems to check your code when preparing a release? Actually, preparing a release is too late. Really, it should be like Visual Studio, where it is checking your code as you write it, but I see how this might be a bit difficult, so I would settle for having basic code validation tools.

However, good validation tools require support from within the language, and from the developers. It is obvious that with runtime metaprogramming you can break things a validation tool would think was ok, or vice versa, so languages would need a way for you to suppress validation on specific sections, or the false positives could be a big problem.

On the static side, I actually see the trend developing already. C# 3.0 (and C# 2.0) are excellent examples of how static languages are working to bring features traditionally associated with dynamic languages to the static world. C# 3.0 also introduces some pseudo-dynamic capabilities. “var” is an example of this. Technically everything is still static, but it does not always feel that way, and when combined with anonymous types, methods, and lambdas it does more than just feel different.

There is still plenty left to do here though. I think it might be very interesting to introduce an almost totally dynamic option to C#. I was thinking of the ability to take a try/catch block and append mode options to the try. For example:

try runtime
{
  x.IHopeThisMethodExists();
} catch (RuntimeCompileException e)

Of course code like above would be treated with about the same level of regard as unsafe {} but it could be very useful for testing some changes quickly, or for building mini-languages into applications.

Duck typing is another option, approachable from either side. Dynamic languages can do some duck-type code validation, and static languages can use it as well with the proper restrictions. I static language should have little difficulty in generating “anonymous” interfaces at compile time if that is how the developer designs things. You could just as well reuse the try runtime metaphor as try ducktime… or maybe something a little less silly.

Anyhow, that is about my limit for the night.