No Subject

[Andreas Kostyrka]

Am Freitag, den 01.07.2005, 18:55 +0200 schrieb Harry George: 
> 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.

In my personal opinion, one can often do lowlevel performance code in a
Python-ese way by using Pyrex. And it gets the additional benefit, that
you pay the "higher line count per feature" that C forces on the
developer only for the part that does this lowlevel manipulation.

> 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.

In some ways namespaces are even less flexible as Python modules.

> 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.

Actually C++ templates are a fix. They are one way to avoid the type
system in C++. A template that takes a class argument takes any class
that has all needed "features and methods". Just as in Python. So it's a
crazy kind of compile-time late-binding. And guess, this static typing
in C++ is so sucessful, that many people consider modern C++ to be a
generics oriented language, and not an OO language.

> 
> > 
> > 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
Well, Java got a VM. And multiple interface "inheritance". And a huge
"standard" library. 

M3 OTOH does have partial type revealing, which allows for more levels
than private, protected and public.
And even more important, M3 has the concept of safe and unsafe
modules/interfaces. Safety in M3-like sense is one of the more important
things in Python. If something goes wrong, in Python you usually just
have to read a traceback. In C/C++ you'll get a core file if you are
lucky. (Or just corrupted data) And if you are even luckier, the stack
in the core file uncorrupted, and you get a sensible backtrace.

In Python OTOH hand, when the traceback is not enough, one can always
work with settrace and other introspection tools.

IMHO languages like Python (or even Java) are a much better approach for
90% of the commercial development. There is just no rational explanation
why an application developer should have to deal with memory allocation
and freeing, dangling pointers, corrupted heaps, and all the other
benefits that C/C++ provide. ;)

> 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.

Yes and no. The problem is that static typing addresses certain
problems, and provides a 90-98% solution. But that makes the remaining
bugs much nastier, because nobody expects them in a "static type
checked" program. Especially the type system of C++ is not powerful
enough to express certain things. On the other hand it provides for
really obscure features. How many C++ developers do know that casting
can change the pointer value? (Hint: Multiple inheritence)

So static typing gives in practice:

a) more lines of code (because variables have to type declared)

b) catches most errors of type errors.

c) forces one sometimes to hack around the type system. (AFAIK void *
hasn't been removed from C++, nor all that ugly casts ;) )

d) makes it harder to find type errors when you get them, because nobody
expects them anymore.

> 
> > > - 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:

Actually, Python provides even more "data hiding" than say C++. In C++
if you look at the class definition you see a memory layout of the
member variables. Not really much protection.

Python on the other hand provides properties, __getattr__,
__getattribute__ and other mechanism that can hide the real place some
piece of data is coming from quite well.

> 
> 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.
That's not data hiding, you mean compiling. The data layout of any C++
class is known to the client. Which makes, BTW writing backwards
compatible C++ shared libraries a pain in the ass ;)
> 
> 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.

Actually the real live suggests the contrary. Using a C++ library isn't
trivial. And the joys of name clashes on the name "string". I guess
namespaces have been added mostly for the one id "string" in C++ ;)


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

Actually, using a library "directly" is mostly a nonbrainer in Python.
What sometimes takes some work is to write a binding that is Pythonic
and safe. Because many C/C++ libraries aren't safe.

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

Well, my C/C++/Python is all basically at the same level. emacs
(sometimes vi *g*). Using anything "higher" just suggests that there are
defecits in the language. And I guess no editor will tell me, that I
call free twice for the same pointer ;)

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.python.org/pipermail/python-list/attachments/20050702/c5f513d6/attachment.sig>