== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > Personally I'm not as much amazed about the time taken, as about the > fact that many people _today_ don't figure what's good about the STL. My > theory (which I expanded in my article On Iteration) is that STL > requires some unusual and borderline obscure PL features, and because of > that it could only be implemented in C++ using means that were at the > time highly non-idiomatic. The net result was that STL's beautiful > design was difficult to distinguish from the wall of syntax that > surrounded it. As such, most people who weren't C++ programmers didn't > "get" it and only some C++ programmers "got" it (even Bjarne took some > time). In my humble opinion, the design of Java, C#, and Go is proof > that their authors didn't get the STL. Otherwise, those languages would > be very different.
I see at least a few reasons why people (including me before ranges came along and made me see in hindsight what STL was trying to do, but didn't quite get right) miss the underlying beauty of STL: 1. Despite being extremely generic and good at making complicated things possible, STL sucks compared to both std.range/std.algorithm and Python/Ruby/Perl/PHP duck typing at making simple things simple. a. Iterators come in pairs (both horribly verbose and statically uncheckable). Yes, this enables a few things that wouldn't otherwise be possible, but at the expense of making the other ~98% of use cases much more awkward and dangerous. IMHO this is a very bad tradeoff. b. Calling the iteration syntax horrible would be an understatement. Iterating over a container (via iterators/ranges) is something that's done so often that even small improvements in syntactic clarity and terseness are worth reaching for. C++'s way of writing a loop to iterate over a container via iterators looks about the same before and after RSA encryption, and the encrypted message looks really long. 2. Lack of variadic templates. This is a key thing that really makes std.range/std.algorithm tick. Without them, you can't have chain or zip and map and reduce are severely neutered. Breaking outside of standard lib stuff into userland, I've found taking a variable number of generic ranges to be unbelievably useful in my dstats library, and I use it for everything from mutual information to regression to ANOVA to partial correlations. 3. Lack of powerful compile-time reflection/introspection. Pretty much all compile time reflection/introspection in C++ is a massive kludge, which makes it virtually impossible for mere mortals to write their own generic algorithms and containers in all but the simplest cases. They can still use ones written by gurus, but it's a lot easier to appreciate stuff like this when you can actually make your own.
