No subject


Fri Jul 1 12:55:02 EDT 2005


#! rnews 4560
Newsgroups: comp.lang.python
Path: news.xs4all.nl!newsspool.news.xs4all.nl!transit.news.xs4all.nl!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!attws2!ip.att.net!NetNews1!xyzzy!nntp
From: Harry George <harry.g.george at boeing.com>
Subject: Re: 
X-Nntp-Posting-Host: cola2.ca.boeing.com
Content-Type: text/plain; charset=us-ascii
Message-ID: <xqxfyuyh43p.fsf at cola2.ca.boeing.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
Lines: 115
Sender: hgg9140 at cola2.ca.boeing.com
Organization: The Boeing Company
References: <mailman.1179.1120208053.10512.python-list at python.org> <Pine.LNX.4.62.0507011340580.24395 at urchin.earth.li>
Mime-Version: 1.0
Date: Fri, 1 Jul 2005 16:40:26 GMT
Xref: news.xs4all.nl comp.lang.python:384402

Tom Anderson <twic at urchin.earth.li> writes:

> On Fri, 1 Jul 2005, Adriaan Renting wrote:
> 
> > I'm not a very experienced Python programmer yet, so I might be
> > mistaken, but there are a few things that would make me prefer C++
> > over Python for large (over 500.000 LOC) projects.

Strictly in terms of software engineering and language design, Python
may well be better suited to large projects than C++ or Java.  Code
re-use, original coding and prototyping, unittests, and peer reviews
are a lot easier with Python than with C++ or Java.

The problem is that large projects tend to have portions which are
performance sensitive.  So a project might be 100K LOC of C with 200K
LOC of Python.

> 
> Hmm. I don't know C++, but here goes ...
> 
> > - namespaces
> 
> Aren't namespaces basically the same as packages/modules in python?
> 

They serve the same purpose but are not 1:1 with a file.  I personally
can't think of a situation where I'd want 2 or more namespaces in a
physical file, or 2 or more files per namespace.  Therefore I don't
see any advantage in the C++ approach.

> > - templates
> 
> These would be meaningless in python - they're part of typefulness, which ...
> 
> > - strong type checking
> 
> ... python eschews.

Templates address (I hesitate to say "solve") static typing by adding
back the polymorphism that static typing eliminates.

Python avoids the fix-on-a-fix by doing dynamic strong typing in the
first place.

> 
> Not that this is necessarily a good thing. I have to say that my Java
> roots do lead me to think that strong typing is a plus for big
> projects, since it's a way of defining and enforcing interfaces
> between bits of code written by different people (or by one person at
> different times!). Optional static typing in python would be nice for
> this.
> 

Java has nothing on Modula-3.  Talk about strong static typing... It
used to take me 3 days to get the first compile to run on a new
project.

Yet after years of Modula-3 (and repeatedly seeing strong static typing
pay off) I found python quite comfortable.  Somehow the problems
strong static typing addresses aren't a problem.

> > - data hiding
> 
> Surely you can hide data in python?
> 

You can't genuinely hide data in Python.  The best you can do is the
"_" idiom.  

The question is why was data hiding invented in the first place.  It
prevents attempts to get at the underlying mechanisms instead of
sticking with the external API.  There are two reasons for this:

a) Protection of the algorithms (e.g., trade secrets).  Python doesn't
solve that.  Neither do C++ or Java, or assembler.  If you have access
to the binary, you can reverse engineer the functionality.

b) Prevent ill-considered attempts at optimization through use of the
lower layers.  Those layers are there for a reason, usually to protect
the external API from changes in the underlying library.  Python
solves that by attracting programmers intelligent enough to understand
this.:-)

> > - more available libraries and more advanced developement tools.

If the library is in C, C++, or FORTRAN, Python can use it.  Worst
case you have to write your own bindings.

As for "advanced development tools"... That's a flameware waiting to happen.

> 
> True. The more advanced development tools are offset to a large degree
> by the advanced crappiness of C++ as a language, though; i'd be
> surprised if a C++ programmer borged up with all the latest tools was
> actually more productive than a python programmer with a
> syntax-colouring, auto-indenting text editor. It'd be very interesting
> to get some real numbers on that.
> 
> >> Ultimately, manageability of a project is far and away more about the
> >> people involved and the techniques used than it is about any single
> >> technology involved.
> >
> > Agreed.
> 
> +1 getting to the crux of it.
> 
> tom
> 
> -- 
> In-jokes for out-casts

-- 
harry.g.george at boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: (425) 294-4718



More information about the Python-list mailing list