Except that code isn't really that far from what you might type. I've spent a lot of time working with code that uses templates heavily (including "well designed" libraries like Boost) and it's just a god-awful mess. Make an error in instantiating a template class and you get an error message that refers to code deep in an STL header. Want to make your container class iterable? Get read to write dozens of lines of inscrutable boiler-plate code. Even something simple as iterating over a container is braindamaged. Before the auto keyword you had:

    for(vector<some_really_complex_type>::iterator itr = something.begin(); itr != something.end(); ++itr)

Then you need to use "itr." It's a pointer-like thing that isn't quite a pointer, and when you hold pointers in your container, which you often (usually) want to do you have to deal with a pointer-to-a-pointer which is almost never pleasant. And when you deal with keyed containers you have to remember the iterator actually points to a pair so you have to do .first and .second (why not .key and .value?)

Braindamage doesn't even begin to describe it.

I rarely use the "for" or "while" keywords. I use the algorithms instead.

The containers have been designed with this is mind.

If you don't use the algorithms, indeed, the STL can be cumbersome to use.

The algorithms are a PITA without lambdas, and are not easily composable or extensible to express more complex iteration. None of them can work with multiple containers, which makes writing even something as simple as a "zip" function using the algorithms an exercise in futility.

But then you have to define the loop internal logic elsewhere because C++ has no lambda (yet, at least in most places where it's used in production). God help you if you have a lot of variables that need to be compared or referenced inside the loop.

Without lambdas you use functors.

> then you have to define the loop internal logic elsewhere

The loop is performed by the algorithms.

See std::for_each, std::transform, std::accumulate, std::partition, etc., etc.

But then you have to define the loop internal logic elsewhere because C++ has no lambda (yet, at least in most places where it's used in production).

And predictably you were downvoted...

First of all, like you've mentioned, his C++ example code is bogus. Second of all he says "modern funkiness of dynamic languages" only to continue with lambda, map/reduce and type independence. The first two are unrelated to dynamic/static typing, the latter is incorrect or badly phrased. You don't get "type independence" in dynamic typed languages, the types are still there. Thirdly, he greatly exagerates the complexity of templates (thousands of incorrect syntax options for smart pointers, all you have is a hammer, etc)

It's a classic case of fishing for arguments to support an idea.

I agree, the STL is a great resource and I miss it in other languages. However, the long type declarations clutter up code. Type inference would make STL code much, much, much, much, much easier to read. Mentioning a container's type once improves readability. It is nice to know that you're dealing with a vector<map<string, set<int> > > if someone has written some crazy code that uses one. Having to repeat the type over and over again, for example, needing to declare that your iterator variable is of type vector<map<string, set<int> > >::const_iterator, makes STL code unnecessarily painful to write and to read. The STL's consistency and feature set certainly makes other language's collection libraries look amateurish by comparison, but the lack of type inference in C++ makes the STL a mixed blessing.

C++0x has type inference via the "auto" keyword: http://en.wikipedia.org/wiki/C%2B%2B0x#Type_inference

It is available in compilers today -- for example, Visual C++ 2010 supports "auto".