Sam Gentile's blog had a reference to a C/C++ Users' Journal article on enforcements in C++, which is a way of using templates to create assert like constructs. For the example that they show, you end up needing two versions, one for const and non-const objects. Then the authors decide to parameterize the enforcer class a bit more and end up with a template class that has a nested templatized operator. The creation of enforcers is so complicate that the authors define a macro which calls another macro and instantiates the template. Ouch. This makes Lisp macros look easy in comparison. That's 2 language mechanisms (template classes and macros -- three if you count the nexted templatized operator) in order to do what one mechanism, macros, can do in Lisp or Dylan.

Next up, a pair of articles from Carlos: In the first, he cites what he sees as disadvantages of dynamically typed languages:

The pros I perceive is not what most would argue. It's actually based on my experience using the Visualage and Eclipse environments. The pros are that it's easier to navigate and search the code base. See the absence of type information makes it difficult to find the dependencies between code. Ask any smalltalker their experience of trying to reduce the size of the smalltalk image, it's an extremely painful process. Just because you're liberated today from type information, doesn't mean that it's not going to strike you back tommorrow.

The question you've got to ask is, should I sacrifice the code completion, quick-fix, search, etc. for a little fewer keystrokes?

I think that the ability to build an intelligent development environment and the ability to build minimal images (for languages that have them) are orthogonal. On the building of intelligent environments, we need only point out that Visual Age and Eclipse have their roots in Smalltalk environments. The environment that I'm using for Python, WingIDE can do code completion and reasonable searching. I think it's a matter of work to some of the features like quick-fix. Here are some screenshots of Apple's Dylan environment from 1994, that give you an idea of the kinds of things that can be done. There's an interesting article about this in CACM.

As far as reducing image, that's possible to do as well. The Dylan folks found an innovative solution to the image problem -- known as the tree-shaking problem in the Lisp community. Instead of starting with a whole world image and trying to strip it down, they started with an empty world and added only what was needed. A Dylan app that was under development ran in a debugger nub that only contained the code needed to run that app. As the app grew, code was added to the code in the nub. When it came time to ship a standalong application, you cut the tether to the nub (an IPC connection) and what was in the nub was your application.

The second of Carlo's posts contains questions:

What if you could remove type information from a static typed language?

What if you could annotate a dynamic language with type information?

Shouldn't languages have more than one mode?

If static type checking is just one kind of analysis, should we not be able to turn it off and on?

If I knew the type of an object is my code, should I have the capability to tell the compiler what type it is?

If tests were so important, shouldn't I be able to ask the compiler to generate some of these tests ?

The right language should not be a choice between static and dynamic checking, it should give you that choice.

The right language allows me to choose how much static analysis I really need.

The right language allows me to give hints to make that analysis possible.

The right language makes creating tests easier.

I'm aware of two languages (at least) that allow you to add type declarations to parts of a program as needed: Common Lisp and Dylan. I'm sure that there are probably more, but I know for sure that this can be done in those two languages.