here is the quote (<a href="http://www.stlport.org/resources/StepanovUSA.html" rel="nofollow">http://www.stlport.org/resources/StepanovUSA.html</a>) from one of the original auhors of stl:
'While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other words, I realized that a parallel reduction algorithm is associated with a semigroup structure type. That is the fundamental point: algorithms are defined on algebraic structures. It took me another couple of years to realize that you have to extend the notion of structure by adding complexity requirements to regular axioms. And than it took 15 years to make it work. (I am still not sure that I have been successful in getting the point across to anybody outside the small circle of my friends.) I believe that iterator theories are as central to Computer Science as theories of rings or Banach spaces are central to Mathematics. Every time I would look at an algorithm I would try to find a structure on which it is defined. So what I wanted to do was to describe algorithms generically. That's what I like to do. I can spend a month working on a well known algorithm trying to find its generic representation. So far, I have been singularly unsuccessful in explaining to people that this is an important activity. But, somehow, the result of the activity - STL - became quite successful.'
Stroustrup wrote a couple of books and papers about the history of C++, which discuss how it got the way it did. Its basically by being very pragmatic, focussed on speed, with a requirement to be C source compatible as much as possible.<p>Very worthwhile: <a href="http://www.stroustrup.com/dne.html" rel="nofollow">http://www.stroustrup.com/dne.html</a> and <a href="http://lambda-the-ultimate.org/node/2283" rel="nofollow">http://lambda-the-ultimate.org/node/2283</a><p>Unfortunately, C++ is a language that fills a niche no-other does - the ability to write genericized systems programming code. For large systems (gcc-sized) it offers a lot of advantages over C (obviously, simplicity is not one of them). I say unfortunately because nobody can argue that C++ is beautiful, but until that niche goes away, C++ will always have a place.
<i>"OOP is not the holy grail. It's a cute idea, and it was quite an improvement over procedural languages back in the 70's when it was invented. But it's honestly not all it's cracked up to be. In many cases it is clumsy and verbose and it doesn't really promote reusable code or modularity.<p>That is why the C++ community is today far more interested in generic programming, and why everyone are finally starting to realize that functional programming is quite clever as well. OOP on its own just isn't a pretty sight."</i><p>Smalltalk has had anonymous functions in the form of block objects since 1972! And they are so fundamental to the language that all control structures and iteration constructs are implemented using them! Look at the following if/else code in smalltalk:<p>(...boolean expression...)
ifTrue: [...true block...]
ifFalse: [...false block...]<p>That sends an ifTrue:ifFalse: message with two arguments, a true block and a false block (lambdas), and if the receiver, a Boolean expression that should yield either the True or False object, is true, then the first block gets evaluated and the second ignored, and if it's false, than the second is evaluated and the first ignored.<p>Anonymous functions are a core part of OOP, because OOP is supposed to be a streamlined subset of Lisp, preferably with specialized message-passing syntax. The idea that anonymous functions are some recent, novel addition to OOP, or that functional programming constructs are at odds with "pure" OOP, or that by peppering your C++/Java/C# code with lambdas, your "object-oriented" code has suddenly become multi-paradigm, shows just how distorted an understanding of OOP and functional programming the average programmer, and even language designer, has.<p>Stroustrup clearly didn't understand OOP or Smalltalk when he bolted classes on to his wretched mess of a language, and that's why C++ looks the way it does, instead of like Objective-C, a language that was a faithful, somewhat successful attempt to add Smalltalk-style OOP to C.
So, if I get this, the "party line" was that C++ is great because it's OOP -- never mind if it actually does not provide encapsulation or modularity. Or garbage collection. Or reflection. But now it is that C++ is great because it's not OOP, it's generic. It still does not provide encapsulation or modularity.<p>And all of this is derived from the design choice of making it not-even-compatible with C. To me, that's ideology.<p>That the compiler doesn't load a bunch of .o files does not mean there's no dependency graph. There is, it's just on header files, which makes things worse. You just moved the "modularity" from the linker/loader stage to the <i>compilation</i> stage. Which is the opposite of modularity. You can't modify a template with LD_PRELOAD. You can't have pluggable templates. If you modify a template, you have to recompile everything that uses it.<p>The STL never had to be efficient. It just had to be convenient. Anyway, you won't get efficiency from generic code, because <i>real efficiency</i> requires knowing <i>what's the problem you're trying to solve</i>.<p>I think Go got generics much better. Pass an interface{LessOrEqual} to a Sort and you're golden.
Actually, Bruce Eckel goes over this in "Thinking in C++". Stroustrup chose not to use an object-based hierarchy, where everything inherits from one base class (like in Java and Smalltalk). This presents a problem when making generic containers (that is, a container that can hold any type of object). To solve this, generics (in the form of templates) were added to C++.