C++ bad-mouthing (was: Why learn Python ??)

[Peter Hansen]

Donn Cave wrote:
> 
> In article <40041576.D070723E at engcorp.com>,
>  Peter Hansen <peter at engcorp.com> wrote:
> > Basically, as a software engineer ... I find Python to be hands down
> > *the* best language I've encountered for use in serious work.  I can't
> > actually think of another which excels on so many fronts.
> 
> But your list describes the perfect hacker language, at
> least on some counts.  I'm nominally a Software Engineer
> myself, but I have no formal CS education and have never
> worked on a large project, so I feel right at home with
> the hacker culture here.  But help me out here, suppose
> we're going to go in and develop one of those massive
> projects - I don't know, say the IRS needs a new computer
> system - what on that list would we care about?

Never having done a new system for the IRS (yet? ;-) I can't
really say, but I do some pretty hard core stuff and Python
fits the bill for me better than past attempts...

> Maybe vague promises like high productivity and ease of
> testing would be attractive, but anyone can say that for
> some ideal context.  

Perhaps, but it's also pretty easy to quantify, at least in the
non-scientific fashion which I've attempted to use for that.

> Library support is probably not even on the charts.  

Very few systems cannot benefit from good library support.
Presumably the IRS requires networking, some user interface
capabilities, probably a bunch of database interfaces, really
sophisticated testing, and these days maybe even some standardization
in the area of, say, XML or something like that.

> I would think a major consideration at
> the outset of a project like this would be whether the
> code that all these teams is writing will eventually come
> together and work like it's supposed to, and from that
> point of view it's tempting to look for some support for
> architectural consistency, like "interfaces" and that sort
> of thing.

I agree, though I personally find it much more effective to use
good tests for this kind of thing.  Interfaces don't cut it when
there's not a simple caller-callee relationship between things.  I
have lots of components which are separated by various other kinds of
interfaces, such as a particular file format, or XML, or some custom
network protocol.  Need tests to check both sides of those equations.

-Peter