As the C++ Standards committee is about midway through formulating the next official version of C++, Chuck ponders the relationship between power and complexity.

http://www.artima.com/cppsource/simple.html

I think templates cause a headache in C++ because we are using the same language feature to address two different paradigms. Generic Programming is programming by static interfaces. This is the traditional use of templates as witnessed by Ada and the new Generics in Java. The other paradigm is Generative programming. People often relate the two because of the C++ template connection, but they are two different paradigms. For instance, Template Haskell uses a completely different mechanism for Generative Programming, one that is more orthogonal with the language. C++ Generative Programming with templates was more on accident than by intention; therefore, it is fraught with peril and exception. If the language would separate out its Generic programming facilities from its Generative programming facilities, I believe it would be a much cleaner and simpler language. Note that this also explains why languages with Generics (e.g., Java) are looked upon as less powerful than C++. This is because they only support Generic programming, not Generative. However, it could be that when they do add in Generative support, they do so in a much cleaner manner; giving a more powerful langauge that is simple as well.

I agree for the most part, but take issue on whether Java really supports generic programming. Type erasure just wrecks genericity in Java for me. But your point on the orthogonality of generic and generative programming is well taken. I wonder if anyone has proposed separate syntaxes for these?

I think the line "The first time _incr executes, the try block fails, since _count has not yet been made an attribute of the class object ..." is incorrect and confuses class attributes with instance (data) attributes. Class attributes can be accessed before an instance of the class is created.

I don't see the need to check for AttributeError when you have already initialised _count to 0.

You can simply use:

class Shape(object):
    _count = 0	# A shared value for Shape classes with no current objects

    @classmethod
    def _incr(cls):
        cls._count += 1

    @classmethod
    def showCount(cls):
        print 'Class %s has count = %s' % (cls.__name__, cls._count)

    def __init__(self):		# A constructor
        self._incr()

Or even simpler:

class Shape(object):
    _count = 0	# A shared value for Shape classes with no current objects

    @classmethod
    def showCount(cls):
        print 'Class %s has count = %s' % (cls.__name__, cls._count)

    def __init__(self):		# A constructor
        self.__class__._count += 1

I would be interested to find out more about the concept ideas that have been put forth for C++. This may address some of the issues. Do you (or anyone) have any good links discussing concepts in C++? I have my own ideas about how they should work, but I'm definitely interested in the thoughts of others.

It seems to me that we have a raw mechanism in templates. I like to relate it to function pointers. Virtual functions are nothing more than function pointers, but they represent a more abstract idea. I think there will be a Generic mechanism, such as concepts, that will be that abstract layer over templates. Templates will still be there if you need them, but in the common case, we need a better notation.

Tanton Gibbs wrote: "Do you (or anyone) have any good links discussing concepts in C++?"

The most "authoritative" place to start is probably
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/

The most recent relevant entry there looks to be Peter Dimov's "Language Support for Restricted Templates" at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1696.html - that's narrower in scope, but there are some links to older and more general papers (in PDF, alas) in the "Concepts" section near the end.

HTH,
Mike

> I think the line "The first time _incr executes, the try
> block fails, since _count has not yet been made an
> attribute of the class object ..." is incorrect and
> confuses class attributes with instance (data) attributes.
> Class attributes can be accessed before an instance of the
> class is created.

Yes, but that's not the point. There is no _count attribute for the derived classes Point or Line until they are bound dynamically.

> I don't see the need to check for AttributeError when you
> have already initialised _count to 0.
>
> You can simply use:
>

> class Shape(object):
> _count = 0	# A shared value for Shape classes with no
> h no current objects
> 
>     @classmethod
>     def _incr(cls):
>         cls._count += 1

But I haven't initialized Point._count to 0! You will get an AttributeError because Point._count does not exist. I am not incrementing Shape_count, but rather Point._count (which is created in the exception handler), and then Line._count, etc., through the cls variable. I wonder if you get my point. There are three variables named _count by the time the code snippet in the article runs. Your "simplification" does not solve the same problem I did - it is only keeping a single count for the whole hierarchy. I am keeping a separate count for each subclass. And there are no instance attributes anywhere in this example. If you trace through the C++ version, you will see what is being accomplished here.

On page 2 you have written:

"When efficiency is an issue, and you need ultimate flexibility, C++ is the only object-oriented (multi-paradigm, even) game in town."

I do not agree. Look at Ocaml: http://caml.inria.fr

I _could_ agree if you had inserted "mainstream", "popular", "large community", etc.. somewhere in that sentence.

So there _is_ alternative for C++ which satisfies all of your issues above. It's just not popular and widely-known. Unfortunately.

I enjoyed this article. C++ is definitely the 128-shaft loom of computer programming.

To answer your question: "Which version do you find easier to grok?" -- the Python one! The curiously recurring template pattern still looks like sleight of hand to me (I prefer to use object factories to keep track of instances).

You say that you use Python when you can and C++ when you have to, and mention Boost.Python for connecting the two. What are your thoughts on mixed-language systems?

Also, regarding your statement:

"When efficiency is an issue, and you need ultimate flexibility, C++ is the only object-oriented (multi-paradigm, even) game in town."

I would argue that a mixed language system is a contender -- for example, Python for the main body of the code, C++ for the bits which need to be heavily optimised. (And we do still see some mixed language systems which embed assembler into C/C++ for reasons of efficiency).

I also claim that C is efficient and flexible. In my opinion its simplicity leaves it less open to abuse than C++.

> But I haven't initialized Point._count to 0!
You don't need to, its inherited from Shape!

> You will get an AttributeError because Point._count does not exist.
No you won't. Try this code:

class Shape(object):
    _count = 0

    @classmethod
    def showCount(cls):
        print 'Class %s has count = %s' % (cls.__name__, cls._count)

    def __init__(self):
        self.__class__._count += 1

class Point(Shape): pass
class Line(Shape): pass

if __name__ == '__main__':
    print Shape._count, Point._count, Line._count
    p1 = Point()
    print Shape._count, Point._count, Line._count
    l1 = Line()
    l2 = Line()
    print Shape._count, Point._count, Line._count

I get the output:
0 0 0
0 1 0
0 1 2

Demonstrating that it is not keeping a single count for the whole hierarchy, there are three independent _count values.
Can you see my point?

> Can you see my point?

Ah, yes, I see it now! Very good. Which makes the point all the clearer that Python is way cool! Thanks. I think I'll update the article when I get a chance (and acknowledge your help). Grooviness. Sorry I was slow on the uptake.

From the article: “My current leaning is to use Python when I can, C++ when I must (which is still often and usually enjoyable) [6], and to be ever on the lookout for a language that gives most of the power and flexibility of C++ but loses most of the headaches.”

You might want to take a look at Objective C, which to my mind fits the bill quite nicely. Just for fun, I decided to code an example solution in Objective C paralleling your examples, (I'm a bit rusty, having spent most of the past five years working with Java, but it's probably not too far off target). I posted it here:

http://jroller.com/page/JonathanLehr?anchor=a_simpler_programming_language

Jonathan

> You might want to take a look at Objective C, which to my
> mind fits the bill quite nicely.

I like Objective-C. I used it in the 80s when it was on the Next platform, and later when it became downloadable for DOS. But there is power in C++ I would miss too much if I went back to OC. Thanks.

A couple of Java centric comments on your well written article:

1. The Java world is about to tackel the issue of how to teach Java with the introduction of generics. I would suggest that they should take your advice and stop teaching arrays and primitives and instead stick to Objects and generics for beginners.

2. Java provides an ideal language that is easy to use like Python and runs as well as C++. Therefore one language can be both your beginners/testers language and your powerful developers language.