Re: Strong Typing, Dynamic Languages, What to do?

[Anton van Straaten <anton@appsolutions.com>]

Brent Fulgham wrote:
> I'm hoping the readers on this list can offer soothing words 
> that will help me end this internal struggle and allow me to 
> make rational language selection choices.

I'll offer a narrow answer to the question - too narrow to be very soothing, I'm sure.  In some circumstances, I think it's possible to get the benefit of both approaches, exploiting the strengths of each.  The cases I'm thinking of involve domain-specific languages and/or data-driven systems.  I'm a big fan of that general approach, since the goal of a good programmer should be to come up with a concise and comprehensible description of the task to be performed, and the more high-level that description, the better.  To come up with really concise and high-level descriptions, you need to invent some kind of language, which often - in programs which lend themselves to this approach - end up as metadata represented as s-expressions, XML, or whatever.

Given such metadata, you need a program to translate that metadata into action.  Scheme and some of the other dynamic languages are enormously well-suited to this kind of thing, because... well, they're dynamic, they have macros, etc. etc.  Doing meta-things in statically typed languages is much more time-consuming to write, and less "natural" (subjective I suppose - but hopefully I'm preaching to the choir).

But despite the benefits of dynamic languages for interpreting metadata, it's often useful to "compile" the metadata into some other language form.  Here's where there's an opportunity for the static languages.  It can make a lot of sense to have a program written in a dynamic language translate that metadata into a static language.

The driving factor for me to do this on a few occasions has simply been that the rest of a system is in a static language (esp. Java), and so there really isn't much choice.  But other reasons are possible.  One of them might simply be that you want to be able to "prove" the type behavior of the resulting system, to satisfy yourself or others about its correctness in that respect.  Another reason could be to achieve better performance than you might get from interpreting metadata directly in the final program.

Compiling a program through an ordinary Scheme compiler to machine code or even C or Java doesn't address this.  A compiled Scheme program knows nothing special about the types in your system, except at runtime.  However, if you're generating your own statically-typed code from your metadata, the resulting generated program *does* contain static type information, which will be appropriately checked by whatever statically-typed language compiler you're using.

Now you can deliver a statically-typed program, secure in the knowledge that it's as typesafe as anything can be (without running a PLT soft typing analysis on it, that is :)  The benefit is that you didn't have to laboriously key in all the extra keywords, template-ish repetition, and other cruft that goes along with conventional static languages.  

A canonical example of this approach is a system that generates database persistence code from a schema specification. In the Java world and elsewhere, this is quite a common approach.  Of course, mostly the code to do this is written in Java itself, and it works just fine.  But as a personal preference, I'd much rather write such code in Scheme, which is born to do such things. The Scheme version will be perhaps 10 times smaller than the equivalent Java code, more fun to write, and easier to maintain.

Anton