Touché. Using RTTI would certainly fill the bill (I'd opt for function pointers, but hey, that's just me). But a manually built if/else construct that requires me to add one more case for each additional subclass doesn't constitute polymorphism in my books. Whether I'm wrong about that is just semantics.

If fact, arguing about whether any particular language is OO, or procedural, or (name your methodology here), pretty much comes down to semantics. One could argue that the Intel instruction set encompasses all of these methodologies, because after all, you can accomplish all of those things with it, can't you? I'm going to agree to disagree on what sort paradigm any particular language follows, because we're not all going to agree on what the requirements are. We've reached the "Oh yeah?" "Yeah!" "Oh yeah?" "Yeah!" stage of the argument, and it's not interesting anymore.

Definitely agree with Shawn, his voice is probably one of the more sane in this particular thread, his love of C# notwithstanding . I've made the same point a number of times here - don't like a language feature? Then don't use it. Which is still my chief argument for using C++ over C. You get all the features of C, plus a bunch of other optional ones. Choice is good.

Java and C# (and lots of others, I'm sure) definitely "lock things down" a little more, although even some of those safe-guards can be short circuited. Dogma surrounding a language doesn't make it capable or incapable of anything; if you want to use return values to report errors in Java, there's nothing really stopping you. I've seen people write code that amounts to something like:

public static void main(String argv[])
{
    try
    {
        // entire program here
    }
    catch(Throwable t){}
}

(No, I've never seen anything quite that blatant, but if all of your catch blocks use Exception and are empty, then it amounts to roughly the same thing.)

This runs into the fuzzy line between technology and culture.

People don't often think of culture as an important part of a language, but really it is. That affects things like naming conventions and code layout, but also larger scale design patterns, where you go to find reusable code, who will help you when you get stuck, and so on.

In the same way as it doesn't force a single technological style, C++ doesn't have a single cuture either. Hence the endless holy wars over where to put your braces, but also this tends to make third party code feel very alien and often unnatural if you sit it alongside your own.

More modern languages (in which I would include Perl, Python, Ruby, etc, as well as Java and C#) tend to have much stronger and more unified cultures. Partly that's just because they haven't had so much time to diverge, but also I think there is some deliberateness on the part of the language designers. Since the rise of the internet, community is seen as very important, so languages are much more likely to have a few centralized hub sites, more in the way of tutorials and FAQ's and example code, and this all points people toward a more unified way of using the language.

That's certainly something Microsoft are very aware of. In addition to the technical decision that all the .NET framework will use exceptions rather than error codes, they put a lot of energy into making sure that the documentation and samples are aligned with that, and finding ways to encourage the whole community to adopt a more unified approach.

Is that a good thing? It's like the programmer version of globalization, and the same arguments apply as out in the wider world. In a way it is a shame to loose all the colorful local flavor and unique ways of doing things, but in practical terms, it is seriously useful to have a common language and be able to communicate and share with people from all over the world...

HAHAHAHA! [Laughing my *** off]
For some reason that had me hysterically laughing!
This thread is fun to read.

I think you're missing the point. A good framework really shouldn't care whether or not the author had a beard. The important issue is how easy it is for users to customize, extend, or replace the facial hair. This is where functional techniques really come into their own. Have you ever tried using a disfunctional razer? No fun at all, trust me on that.

I lean towards simplicity where my grooming interface is concerned - Wilkinson Sword is a fairly robust implementation, and it does what I need it to do. That being said, I think it's flexible enough for most facial hair paradigms, whether it be hairless, goatee, or full facial coverage (but clean below the neckline).

Beards can be nice but just add bloat to mustache ride functionality. Using beards increases the computational complexity of such a vehicle and turns an O(1) ride time into an O(nlogn) ride time. The additional workload can be increased so much that in some cases thick beards are not even tractable.

I have tried a barber interface on a couple of occasions, but found it to be too expensive an operation for my tastes. My current interface serves me well, mostly because it's a legacy platform, and I have no plans to upgrade. I've considered a going with a simple mustache or hairless paradigm, but my Nookie Provider claims some sort of incompatibility and has threatened to cancel my account, or even switch to an entirely different platform.

Sometimes you just gotta go with what works.

Some/Most times the Nookie interface itself incurs huge costs all by itself.

Can't argue with that. However, the overhead associated with creating a new object is a lot more expensive than the maintenance of a currently existing one.

It's not just the constructor overhead you have to worry about when switching provider, though. There are also a bunch of resource management issues when it comes to disposing of the previous instance.

The simplest approach is just to let the garbage collector to deal with this for you, but that can lead to unpredictable resource consumption while a potentially unbounded number of previous relationships are awaiting finalization.

Reference counts are simple and seem to work ok in practice, but don't deal well with cyclic structures so are best avoided unless you are strictly monogamous.

Old skool coders will argue in favor of manual cleanup, which is incredibly efficient but also very dangerous because it is so easy to accidentally leak resources like your house, car, kids...

I've never really been into the whole boost::shared_ptr<> scene, but each to his own I suppose...

One of our interns is a Python freak, and he claims it uses them all over the place. I don't recall what precisely the usage is (he's not here today), but Pygame does seem pretty nifty.

Shawn, quit being so funny, I'm not getting any work done.