C++ (was RE: Python suitability)

[Gordon McMillan]

Alex Martelli writes:

[starting with his conclusion]

> I'd rather program in Python -- but if the tasks I'm doing
> are not suited for Python (e.g., developing components
> which need to run EXTREMELY fast), then C++ is what
> I'm happiest with.

It's funny. I agree with that; but I disagree with almost 
everything else.

> Or, to put it another way: you have to DESIGN, rather than
> just start hacking.

Hackers hack, designers design, no matter what the 
language, (you actually come close to saying this later).
 
> Specifically, if you follow the advice of Scott Meyers, in his
> excellent "Effective C++" (CD Edition): never inherit from a
> concrete class.

Never make a rule of thumb into a religeous dogma. There are 
excellent reasons, at times, for violating this "rule". Take a 
look at scxx on my starship pages. While I would *never* give 
that out as an example to someone learning C++, it's a case 
where a single "virtual" would break the entire thing.
 
> One key difference is that, in C++, you _can_ design and
> maintain huge and flexible projects -- the language does not
> hinder, and gives you almost all the tools you need for that

If C++ (or Java) gave you those tools, there would be no 
"need" for UML. UML "works" (for some definition of "works" 
<wink>) because it hides language complexity. It also lacks 
expressiveness.

Look at "Design Patterns". Most of those patterns are directly 
expressible in Python. So much so, that if you translate the 
UML into Python and use that, the result will be needlessly 
complex and stilted. What the UML actually expresses is how 
to get around language barriers.

There are useful diagrams in UML, (eg, the state and 
transition diagrams). Unfortunately, the one most tools use to 
generate code (and draw from reverse engineering) has 
everything to do with language structure, and nothing to do 
with what actually happens at runtime. To put it bluntly: 
people spend most of their time designing the wrong thing.

Worse, they get it wrong, but it's carved in stone now; so the 
final system is either needlessly complex and marginally 
functional, or bears no resemblance to the "design".

The secret to good performance is to prototype and prototype, 
then code the bottlenecks in a faster language. The secret to 
large systems is to prototype and prototype, until you've got 
clean separation of the system into managable pieces, then 
code in whatever language most suits the need of each piece.

This is contrary to the advice of a lot of the gurus you mention; 
but they have a large vested interest in the process.

- Gordon