Lambda the Ultimate

inactiveTopic While on the topic of generic programming
started 1/8/2001; 12:33:02 PM - last post 1/14/2001; 6:31:34 PM
Ehud Lamm - While on the topic of generic programming  blueArrow
1/8/2001; 12:33:02 PM (reads: 746, responses: 3)
While on the topic of generic programming
I thought that to complement the discussion of generic programming, I point to this page too.

This is an interview with Alexander Stepanov, and gives some views that explain how generic programming evolved in C++ (and some Ada history). Things are a bit different than they are in Haskell...

You might also enjoy this paper by Stepanov and David Musser. The FTP site has some other interesting papers as well.
Posted to Software-Eng by Ehud Lamm on 1/8/01; 12:33:25 PM

Ehud Lamm - Re: While on the topic of generic programming  blueArrow
1/11/2001; 12:18:26 PM (reads: 770, responses: 0)
To add some spice: What do you prefer, automatic instantiation as in C++, or explicit instantiation as in Ada? [or in general, which language captures the essence of generic programming better?]

Chris Rathman - Re: While on the topic of generic programming  blueArrow
1/14/2001; 6:13:19 PM (reads: 740, responses: 0)
Just to mix it up a little.... :-)

I ran across some criticism of C++ templates by Robert Martin in 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.

Chris Rathman - Re: While on the topic of generic programming  blueArrow
1/14/2001; 6:31:34 PM (reads: 740, responses: 0)
I guess as long as I'm giving the criticisms of C++ templates, I might as well mention the criticism from the other end of the spectrum - namely the Smalltalk community. From a Smalltalk standpoint, genericity is a built in feature of the loose coupling provided by relying on the loose coupling of messages.

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.