A look at C++14, part 1

But for those of us who understand it, and want to use it, I can't see the damage of having this pipeline thing in the STL. To me, it's a very simple and nifty concept, and I would get a solid implementation of that done in a couple of hours, from scratch. If you don't like it, it's just syntactic sugar over stuff you could do anyway in another, more verbose, way. Or rolling out your own solution; testing is up to you, then.

After all, even Java has a lot of parts that most college students will never touch. RMI, for instance, and the related naming services. But if you need it, it's there (and it's *incredibly* useful for a nice set of problems). Same applies to most languages out there.

I don't see why languages and their associated standard libraries should keep from evolving. To make life easier for some grumpy programmers stuck in the '80?

We develop more complex systems in 2013 than thirty years ago, and static verification is something a lot of us need in the realm of software engineering, so we build the abstractions that enable us to spend a bit more in coding, and much less in QA (which, incidentally, is where real software development costs go).

The matter would be to explain what a monad is to university students, for instance, not holding back progress. Omniscience isn't required to use a language; C++ has many useful subsets for the issue at hand.