Python evangelists unite!
Milliken, Peter
Peter.Milliken at GTECH.COM
Thu Nov 29 22:46:40 EST 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 :-))
Peter
> -----Original Message-----
> From: Jonathan Gardner [mailto:jgardn at alumni.washington.edu]
> Sent: Friday, November 30, 2001 1:04 PM
> To: Peter Milliken; python-list at python.org
> 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