C++ can/does do anonymous functions (for example, see boost lambda), and can even give you most of what you want from first-class functions and closures (using functors). The parts that you don't get are due mostly to the fact that C++ doesn't have built-in garbage collection. It's a speed limitation, not a type-safety limitation.

Now for my rant: there seems to be a backlash against type safety in this forum that I don't understand. Granted, if all you ever do is develop dinky webapps with your best friends, permissive languages allow for rapid development (mostly because they let you get away with murder). However, once you have more than a few developers and a few tens of thousand lines of code, the benefits of strict typing become rapidly apparent. The chaotic, free-for-all mentality of languages like Ruby is great for rapid prototyping, but it kinda sucks for developing in more formal scenarios.

It may be "harder" to develop with strongly typed languages, but that's usually an indication that you're having to think a bit before you act. That's rarely a bad thing!

You've said what I've been thinking for many months now.

We've also got a strong contingent of anti-MS ranters.

As to the merits of the article -- there are none. Oddly enough, I can't make a case against his argument because he doesn't have one, save his ultimate realization that it was the language itself. "It came to me in a dream" is a very difficult thing to take issue with.

I've been having to work in MFC recently for a client, and boy...

If you ever needed a reminder why some people dislike C++ so much, just work with MFC. It's one of the worst bastardizations of C++ I've ever seen (of course, to be fair, one has to admit that much of the really sucky stuff in MFC was done before the C++ standards were very good, and long before the compilers caught up).

Writing C++ using std:: and boost:: and other libraries written in "Modern C++" is pure bliss compared to doing it the "Microsoft Way".

Last time I wrote in MFC was about five years ago. As I recall, I got up to speed by reading a couple books which went over basic application design stuff in Win32.

Didn't seem too bad to me -- I even did some COM stuff and some hooks and such. But like I said, that was a while ago. I wasn't a crazy fan or anything, but the tools did the work I wanted to do.

Talk about a black hole of tool-chain hell...

You can go with a lightweight (?!?!) framework around your API, a la MFC, or more of a true framework, like OWL. But in either case, comparing a what? 12-year old framework system with something more recent isn't exactly apples and apples.

I'm not trying to make excuses but heck, the whole reason we grow new frameworks is because old ones get too bloated and brittle.

Rock on with Boost, but don't compare apples and oranges. Maybe it's me, but professionals are supposed to know the hard-to-use crap and should be able to swim around in that stuff like a fish in water.

Hey -- just my two cents. No matter how you cut it, C++ is a killer language when it comes to complexity -- and that's without the freaking frameworks!

Modern C++ done "the boost way" is a great language. I have rewritten perl prototypes in modern C++ with hardly any code expansion, but with huge performance and deployability gains.

Your claim that you can achieve everything in C++ misses the point. Sure, I can write lots of function objects every time I want to apply a function to a data structure (and I do), but I also have to write a lot of tedious code to do it. That tedious code increases the size of my code base, which increases the likelihood of errors and its cognitive load. You can write object-oriented programs using ANSI C, but your code base is going to be much larger than if you did it in a language with actual OO support.

When a programming concept has first-class support in a language, programs that use that concept are going to be shorter, clearer, and less likely to have bugs related to that concept's implementation.

Luckily, true anonymous function support will be a part of C++0x.

Well, no. I was responding to a comment that implied that it was impossible to do things like anonymous functions and closures in C++, due to the restrictions of the type system. That's wrong.

You'll get no argument from me that C++ is verbose.

I've not found static typing to be a big productivity win. I think it disallows a small subset of bugs. Like most people I've been a C++ programmer because it was the highest performance language with the best support for operating and window systems. I'm gleefully looking forward to it playing a smaller and smaller part of my programming work.

Anyone who experienced the C->C++ transition can tell horror stories about problems due to the (ab)use of C's type system in real code...and C wasn't even that weak! Even Perl coders have learned this lesson the hard way (hence the introduction of "use strict"). But I digress.

Maybe you're right, and strong typing doesn't matter that much for the new generation of apps. My instinct however, is that the current hipness of dynamic typing is a (somewhat justified) over-reaction to the ugliness of C++. Meanwhile, a lot of babies are being thrown out with a little bit of bathwater....

I think what really makes programming in a "dynamic" language significantly more pleasant is not having to type (on the keyboard) type (int, Object, etc.) declarations. A strictly, statically typed language with a good type inferencing engine, like Scala or Haskell, makes a lot of this go away.

I understand (though don't have enough experience to verify) that there are times that the type inferencing occasionally makes things harder when you get a type error and can't identify its source. But certainly a win overall compared to explicit types everywhere.

The argument is that comprehensive test suites can substitute for strict typing. I don't buy it as practical, but that's the argument, and I can at least see the reasoning.

The other point is that you can avoid tens of thousands of lines of code and lots of developers in dynamic languages. You're way more likely to keep the thing in a form where two or three guys have it all in their heads and can keep it small and well factored. Strict typing is critical when you're making changes to code you don't understand really well. But you're more likely to understand all the code really well when it's small and you're on a small team.

With great respect, I suggest: If you know what a closure is, you may have trouble understanding how OO is difficult to understand for many other people. The kind of people who have never heard of a closure, and whose eyes glaze over as you try to explain that a closure is an inside-out object and an objct is an inside-out closure.

I can't even fathom what would be difficult to understand about OOP, unless, like I suspect, he is forcing the Kingdom of Nouns onto a problem that isn't well suited for it.