Lambda the Ultimate

Generic programming is great (partly) beacuse generic programs provide better abstraction and more reusable code. Languages that don't support generic programming facilities are problematic.

Of course, it really depends on the type of the language.

In dynamically typed languages, you don't need GP in order to write polymorphic routines. Same is true with languages that support polymorphic types.

In OOPLs, you often rely on the fact that all object have a common ancestor, so your routines and data structures can use Object*. In static compiled languages (think Java) this is no more than a disgusting hack used to bypass type checking at compile time.

Languages with first class functions can often simulate GP, simply by passing routines around. Notice however that GP often (as in the Ada case for example) allows instantiation and composition to be done at compile time (and enjoy all the advantages of compile time checking, and reduced runtime overhead).

GP is primarily used for polymorphic data types and as a technique to connect and compose abstractions. Even if we dismiss the first use as something that can be handled better using polymorphic data types, and even by using dynamic typing, we should realize the the second use is more fundamental to the way we think about software. In this sense GP adds important expressiveness to programming languages.

By the way, the C++ model and the STL allow for template specialization, which can be seen as adding another level of abstraction. This feature is, of course, a way to achive things usually done with (the more problematic) help of inheritance.

STL's main success is teaching many programmers about the basics of GP.

I'm a great fan of STL and would not consider doing a substantial C++ project without using it. Actually I'm referring to the whole C++ Standard Library, of which STL is a subset. Whatever you think about the C++ generics syntax, it allowed Stepanov to do quit an amazing job of providing both usability and performance (Microsoft, for example, tends to do such things by adding keywords to the language.)

I did not find the slashdot thread very informative. Some points, also mentioned by Chris did resonate however:

1. Lack of standardization – this is always a problem, and I find that it’s a problem with C++ generics in general not just STL. OTOH the situation is definitely getting better.
2. Indecipherable error messages – Again a general problem with C++ generics compounded by STL.
3. Debugging is a bitch because it’s very difficult to view the contents of an STL container in a debugger.

Note that all these problems are the "fault" of the C++ compiler and debugger, not of the STL itself. For example, it shouldn't be too difficult for a particular vendor to build a debugger with intrinsic support for STL container types (at least for the implementation he ships).

I disagree with the point about code bloat. STL actually does a fair job of including support only for the features you need. I think any complaint about bloat goes away when you use a compiler with proper support for specialization.