Lambda the Ultimate

I ran across some criticism of C++ templates by Robert Martin in comp.software-eng. His complaints are two-fold.

1. Templates take too long to compile
2. Templates don't provide run-time polymorphic behavior

Here's the relevant quotes:

here: One of C++'s greatest weaknesses is compile time. Compile time goes up in rough proportion to the square of the code size -- especially when templates are used. On the other hand, abstract types create compiler firewalls that can greatly reduce compile time. A well organized C++ application that uses abstract types to reduce compile time dependencies can lower its compile time to roughly NlogN.

Generics are a wonderful features of C++. I wish Java had them. But they have been over-used of late IMHO. I anticipate that the excitement over generic programming will abate and a more balanced view will survive.

here: I have a customer who's core library requires two hours to compile on a four processor Sparc-20 -- mostly because of the heavy use of templates, but also because there is no way to compile less than the whole thing. This means that very time they make a tiny change to anything, it's two hours before they can test. Ouch! It's tough to get anything done when you are limitted to three or four turnarounds per day.

here: For example, I would have appreciated a polymorphic iterator class. Though I think the template based iterators are cool because of their speed and simplicity; I also find it annoying that I must know the container type every time I want to iterate.

here: It would be nice to pass iterators around, at run time, without having to know what type they are. It would also be nice to pass containers around without having to know their type.

I don't wan't the *compiler* to know the type. I want to have a single function that can take an iterator. I don't want that function to be a template.

void f(iterator& i)
{
//...
}

I then wan't to put this function into a shared library and never have to compile it again. No matter how many different container types are used, I want *one* copy of this function in the runtime executable environment.

Don't kid yourself into thinking that the costs of templates are low. The cost in compile time, memory overhead, and executable footprint are non-tri[v]ial. Also don't kid yourself into thinking that the cost of polymorphism is high. In most situations the cost is negligible.

As long as an object responds to a message, it is effectively type compliant and can be used generically in place of any other object that responds to the same messages. No static type checking to get in the way of writing classes that handle genericity.

Of course, this really boils down to whether one believes that static type checking is a necessity. If you believe that static type checking is necessary for a project, then Templates are the only way to get around the type system. If, however, you believe that static type checking causes more trouble than it's worth, then you get a form of genericity with little effort required.

This loose coupling is one of the reasons that I think that Smalltalk has the most mature collections classes of any standard library. The libraries don't have to work through a special filter or bypass the type system to get the desired effect. From the Smalltalkers I've talked to, they seem to be unimpressed with the STL exactly for this reason.