C++ bad-mouthing (was: Why learn Python ??)
peter at engcorp.com
Tue Jan 13 20:28:21 CET 2004
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.
More information about the Python-list