Python evangelists unite!

Milliken, Peter Peter.Milliken at GTECH.COM
Fri Nov 30 04:46:40 CET 2001

Ah, you said the magic in your opening lines "C++....". A maintainers life
line - job security forever! The number of "large" projects that have used
C++ just make me laugh all the way to the bank :-). 

A more cruddy language for implementing large projects I have never seen.
But, as one manager used to argue, "I can get plenty of C++ programmers...."
- despite the technical arguments for why C++ is a disaster of a language
for large projects. I have no argument that python has probably saved your
bacon many a time on a C++ project - but the base of the argument is
floored. "...several thousand line program that quickly became unmanageable
in C++...." :-). Python is a better language than C++ - I would lay C++
somewhere down the bottom of any list for implementing "largish" projects (I
term "large" projects in millions of lines not thousands - sorry, I can't
resist bragging :-)).

As for the French - "Au contraire..." - I never could deal with the fancy
stuff :-)

In my opinion (:-)), C (and hence it's backward compatible "big brother")
are "old" languages - neither of which I would choose from a software
engineering principle perspective - but here I get onto ground that has been
argued before (see the extensive thread on whether to implement an Air
Traffic Controller in Python [comp.lang.python] - many people who
participated in that thread know my opinions :-)).

As for the poor coding habits of the projects that you have participated,
you have my sympathy many times over :-). People keep making the same
mistakes, that is one of the nice things about the software industry -
nobody (appears) to want to learn from previous pioneers (how many people
reading this have Steve McConnells book, Code Complete on their shelve -
excellent book because if you read and practice that you will save yourself
about 15-20 yrs of blundering around the coding world :-)). It all keeps
people like me in a job (I currently work maintaining a "largish" C product

So, sorry mate, I accept you have a place for Python, but all you are
proving is my original statement. That different languages have different
places. Have you ever seen the purported interview with Stroustrop about
C++? I personally believe it to be true! :-).

So, "Au contaire" to you too (and thanks for taking the bait :-))


> -----Original Message-----
> From: Jonathan Gardner [mailto:jgardn at]
> Sent: Friday, November 30, 2001 1:04 PM
> To: Peter Milliken; python-list at
> Subject: Re: Python evangelists unite!
> On Friday 30 November 2001 08:18 am, Peter Milliken wrote:
> > I use Python as a good, quick and dirty hacking language. 
> For real (read
> > production) stuff that I expect a customer to run or will 
> require more than
> > a single person working for a couple of hours, I look 
> elsewhere :-). Sure
> > there are examples of Python being used for "large" jobs - and very
> > successful they have been too - but these people are 
> masochists  (IMO) :-).
> > They could have been more productive with other languages 
> that provide
> > better support for generic software engineering 
> principles/standards.
> >
> Au contraire...
> I find large projects benefit the most from python. I have a 
> several thousand 
> line program that quickly became unmanageable in C++. In 
> python, everything 
> just blends together seamlessly. When something goes wrong, I 
> don't have to 
> whip out a debugger because it is so easy to read the old 
> code, and I can 
> follow it with my finger better than a debugger could.
> The parts are extremely interchangeable, modifiable, and 
> reworkable. I can go 
> in and change any class, even the design, and it still pretty 
> much works. 
> When it doesn't, it is easy enough to debug. And the function 
> parameters? 
> THANK HEAVENS that someone has the sense to do what python 
> does when you have 
> like 2 million arguments to a function - NAMED PARAMETERS. 
> And one more word: 
> dir()/__doc__. Every time I wonder what something does, I 
> boot up the command 
> line, import it, and start dir'ing it and __doc__'in it. 
> Without even looking 
> at the code, I have figured out the most important parts, 
> because I have 
> documented it as I wrote it.
> With C/C++ you have messy defines and stuff you have to 
> manage in addition to 
> the code. And the code is unreadable, even if you are a 
> professional C++ 
> programmer. You have to remember what members there are, 
> whether they are 
> protected, public, or private, and whether the other guy is a 
> friend, child 
> class, or nobody at all. Not to mention you have to watch the 
> memory and 
> freeing it all the time - but not if someone else is still 
> using it! Keep 
> reference counts on pieces of data that are dynamic and used 
> by more than one 
> pointer; then there is the list/array management that has to 
> go on, the 
> off-by-one errors and the every to inevitable type-casting 
> problems... You 
> get the idea. It's a lot to remember as you debug old code. 
> It feels like 
> building a house with tiny pebbles and little sticks and 
> pieces of string.
> > There, that should bring the 'vangelists out of the 
> woodwork! :-) It's just
> > too easy, they rise like starving trout - each language has 
> it's strengths
> > and weaknesses. Python has some very nice features, I use 
> it a good deal.
> > But it definitely has its place!
> >
> I agree with you that there are limitations to Python; I 
> disagree with you 
> that Python was not meant for large projects. 
> > In the meantime, my advice is don't get "emotionally" 
> hooked into the
> > language. Analyse its strengths and weaknesses, consider 
> other languages
> > and their strengths and weaknesses and then you can hold an 
> intelligent
> > conversation with another programmer! :-)
> >
> Exactly. Why do *you* use a language? The answer should 
> always be something 
> reasonable. It should never be emotional. Well, unless you 
> are a teenager, 
> then everything is emotional. =)
> Jonathan

More information about the Python-list mailing list