No subject

[Andreas Kostyrka]

Am Freitag, den 01.07.2005, 13:50 +0100 schrieb Tom Anderson:
> 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.
> 
> Hmm. I don't know C++, but here goes ...
> 
> > - namespaces
> 
> Aren't namespaces basically the same as packages/modules in python?
Basically. And one could probably argue that their are superior to C++
namespaces.

> 
> > - templates
> 
> These would be meaningless in python - they're part of typefulness, which ...
Worse than that. C++ templates are hack which has grown quite powerful
with time. 

And they are a kind of "compile-time" late binding. You get the worst
from both worlds. All the complication of a static typing system, and at
the same time no safety.

One of the more popular arguments pro C++ typing has been that
x.write doesn't have a semantics in Python, while in C++ x->write can
have an expected semantics, because x is restrained to a given type or
subtype. So it's not some random method called write that get's
selected. Problem: This is not valid as such for templates, as templates
will luckily accept any type for a class argument.


> > - strong type checking
> 
> ... python eschews.
> 
> 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.

This is a good thing. Because static typing as such catches a big
percentage of certain classes of errors, it makes it harder to catch the
surviving errors. But the type system doesn't know if an integer
represents a temperature, in fahrenheit, kelvin or celsius, or a pixel
row or column. For an ironclad "type checking" the type system, and
especially the type system of C++ doesn't give enough information.

      * Combined with automatic conversion between types this can lead
        to many bugs going undetected.

And compared to Python, C++ does have the additional drawback, that it
offers

      * an unsafe environment -> anything can kill your runtime. And
        your crash happens sometime later ;) If you are lucky it happens
        when your application goes live with clients ;)
      * quote a highlevel view. With STL you can write quite a bit of
        code in one liners. But because C++ as such is unsafe, and the
        type system of C++ is far from perfect, this can lead to subtle
        bugs that crash your system or just corrupt data.

Contrast this to Python. It's safe. So the worst what usually happens is
that you get an exception. Much easier to debug than a subtle STL bug
that surfaces only if one uses the wrong kind of argument. But which is
not caught by the type system.

Basically the mix of high expressivness, the lowlevel runtime access and
a non-perfect type system gives something that is quite explosive,
especially when employed in an huge enterprise system.

So basically no matter if you program in C/C++/Python whatever you need
tests of all kinds. And here again the static typing of C++ makes it
harder to fake interfaces for unit tests. So to summarize:

      * It makes testing harder
      * It "claims" to catch many error classes.

The reader is invited to think if more C++ programs or more Python
programs have unit tests.

> 
> > - data hiding
> 
> Surely you can hide data in python?
Basically the same way as in C++. Although one needs a cast to overcome
private: declarations in C++ ;)


> 
> > - more available libraries and more advanced developement tools.
> 
> 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.

Difficult to measure. So it's almost always either just a personal
observation, or a study with a methodology that is suspect :(

But I'm quite sure that even the best IDE cannot solve memory bugs in
C++. Ok, one can program almost without pointers and new/delete, but
this leads "almost" automatically to slower programs. And not all
problems are solvable with "simple" vector arrays and other trivially
wrapped containers. 

So anyone who tells you it's easy to program C++ is either doing only
very limited C++ work (say huge C++ programs that are 99% template
generated code) or doesn't know how buggy his programs in reality are ;)



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

And here the crux lies. Software development scales badly. And higher
productivity languages like Python allow smaller teams to develop more
functionality. And compared with other "dynamic" languages like Tcl,
Perl, Ruby, Python does have the benefit that it got a syntax that
enforces better readable code. This can manifest itself in many ways. Be
it that Python/Pyrex code beats C++ code at tasks like huge data
manipulation. (Personal experience: The C++ guys gave up after 12-18
months, and they've just managed to read the data somehow. I've been
able to read the data after one month, another month I've spent
interfacing with the existing C++ app, and afterwards I've optimized for
4 months. And actually did a number of feature requests the C++ team
never ever contemplated to do.)

To put it bluntly for most cases where today C/C++ is used, it's used
unneccessarily and causes pain and costs for all involved. You know this
projects, where even with a strong dislike for Perl, one prays "Couldn't
they do it in Perl, anything, not C?". *g*

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/20050701/81602e18/attachment.sig>