Python Productivity over C++
Steve Mullarkey
programmer for the past 3 years. I'm not a genius but would modestly (?)
class myself as reasonably competent.
In the past week I have become aware of Python. I've bought a book and
read this newsgroup every day.
I have read in several places productivity claims of 5 to 10 times over
'C' and "C++". I would like to ask for some feedback from "C++"
programmers who have moved to Python as to whether these estimates are
realistic.
In "C++" I have :-
1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
Profilers, Programmers Editor including Class Browser, etc..
2. I use the STL (Standard Template Library) which gives powerful string
and container classes.
3. I use incremental compiling and linking. This reduces wait times to
very small amounts.
4. I can also use background compiling and linking.
5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
etc..
I don't want to start a flame war but, given the above, I just can't see
where the productivity increase is generated. I am genuinely interested
to ask "C++" programmers :-
1. What productivity increase do you achieve ?
2. How long did you use Python before you achieved increased
productivity ?
Best regards,
Steve Mullarkey.
Tascom Pty Ltd.
Berry, NSW 2535, Australia.
Tel : (61)-(2)-4464-3328
Albert Hofkamp
>I have been a 'C' programmer for the past 15 years and a "C++"
>programmer for the past 3 years. I'm not a genius but would modestly (?)
>class myself as reasonably competent.
I learned C about 11 years ago, and switched to C++ 4-5 years ago.
>I have read in several places productivity claims of 5 to 10 times over
>'C' and "C++". I would like to ask for some feedback from "C++"
>programmers who have moved to Python as to whether these estimates are
>realistic.
Depends on what you define as productivity. With a nice definition, no doubt
you can get these rates. On the other hand, I have way too many advertisements
promising me incredible productivity increasements, so I tend not to believe
any of these claims.
>In "C++" I have :-
>
>1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
>Profilers, Programmers Editor including Class Browser, etc..
>
>2. I use the STL (Standard Template Library) which gives powerful string
>and container classes.
>
>3. I use incremental compiling and linking. This reduces wait times to
>very small amounts.
>
>4. I can also use background compiling and linking.
>
>5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
>etc..
>
>I don't want to start a flame war but, given the above, I just can't see
>where the productivity increase is generated. I am genuinely interested
>to ask "C++" programmers :-
The big question is, are you happy with the above stuff ?
For example, why do you need a memory leak tool ? Are you really interested in
spending your time hunting down memory leaks, is that your goal in life ?
I think not.
I'd rather use a computer to perform tracking of memory usage, and let it
handle memory management for me.
A lot of the tools have an origin from the design ideas of C/C++, which is fast
execution on small machines. The price that you pay is that you have to do a
lot of management around it yourself.
Python starts at the other end. With an easy to learn language, take as much
management away from the programmer as possible. CPU time is extremely cheap
now, much cheaper than a few hours developer-time (you can buy a new PC if you
save 14 days of work !).
>1. What productivity increase do you achieve ?
I am not sure, I don't measure it. My basic problem is that everything I do has
to be multi platform.
Python is a bigger help than C++ in that respect, basically because it provides
an abstraction layer just like Java, while at the same time it is more open,
conceptually cleaner, and freely available.
However, development tools is not the entire story.
The main gain imho is maintainability after the program is `finished' (notice
this is still the main cause of costs for programs). Python is an easy
language, but it scales well. That means that others can read your programs
quite easily without sacrificing (word doesn't look right) the ability to
tackle real-world problems.
Also, since it is interpreted rather than compiled, the source is always
nearby. If necessary, you can even do some bug-hunting in the
production-environment rather than your own development environment (which is
important for me since most of what I do is prototyping).
>2. How long did you use Python before you achieved increased
>productivity ?
Hmm, that's tricky. I'd say -6 months.
I started building Python extensions in C++, before I could program Python. 6
months later, I wrote my first program in Python. Due to the excellent
documentation and books, learning was a matter of hours. After that I only
needed to look up some details on syntax.
Obviously, I picked Python because I had a problem that was suited to use Python
for. If I would have to do the same thing in C++, it would have cost me days
instead of hours. In that respect I had a huge productivity increase in minutes.
As said before, I don't believe these numbers, and I don't understand why
management loves these numbers. Imho, it is not unlike the productivity
increase you experience when you switch from hammer to screw-driver when trying
to insert screws.
Albert
---
Look ma, windows without Windows !!
Wim Lavrijsen
>I have read in several places productivity claims of 5 to 10 times over
>'C' and "C++". I would like to ask for some feedback from "C++"
>programmers who have moved to Python as to whether these estimates are
>realistic.
I'm a C++ programmer (leave out the quotes ;) ).
First off, any claim of an order of magnitude increase in productivity is
pure nonsense. See Brooks for an explanation or Boehms and McConnell for
hard data.
<snip enumeration of tools>
>I don't want to start a flame war but, given the above, I just can't see
>where the productivity increase is generated. I am genuinely interested
>to ask "C++" programmers :-
>1. What productivity increase do you achieve ?
>2. How long did you use Python before you achieved increased
>productivity ?
I want to use Python for scripting tasks. I dislike 'ordinary' scripting
languages as they lack the ability to recover from errors; a problem that
Python, being a real programming language, does not have.
Up to now, I've been using C++ for scripting. I'm not proficient in Python
yet, so writing a Python script takes far longer than writing a C++ utility
and the Python code itself is larger than the equivalent C++ code.
What I expect from Python, is that I can reuse scripting utilities,
something that I do not do for C++ utilities. This could, perhaps, yield
a 10% increase in productivity, but I'm not writing scripts all day, so
my overall productivity increase will be negligible.
Most of all, however, I enjoy the incremental coding (I come originally
from a Smalltalk background). I *like* Python, which is all excuse I need
to use it.
Best regards,
Wim Lavrijsen
Christian Tanzer
stev...@ozemail.com.au (Steve Mullarkey) wrote:
> I have read in several places productivity claims of 5 to 10 times over
> 'C' and "C++". I would like to ask for some feedback from "C++"
> programmers who have moved to Python as to whether these estimates are
> realistic.
>
> In "C++" I have :-
>
> 1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
> Profilers, Programmers Editor including Class Browser, etc..
>
> 2. I use the STL (Standard Template Library) which gives powerful string
> and container classes.
>
> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.
>
> 4. I can also use background compiling and linking.
>
> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..
>
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated.
There are lots of reasons. The ones first springing to my mind are:
- The tools you mention notwithstanding, C++ still forces you to write
lots of low-level code by hand (e.g., memory management, the
`orthodox canonical class form').
- C++ doesn't offer any means of meta-programming. If you want to add
some mechanism (like serialization, introspection, ...) to a class
hierarchy, you'll have to add member functions to every class in the
hierarchy. In Python you can implement the complete mechanism in the
root class of the hierarchy.
- Incremental compiling/linking doesn't help when you need to refactor
your product or want to add a mechanism to a class hierarchy. In
that case, you might have to wait a long time for the product to be
recompiled and linked. In Python, you might be able to pull the
change into the running application.
- I could go on, but I have to leave for work...
> I am genuinely interested to ask "C++" programmers :-
>
> 1. What productivity increase do you achieve ?
At least a factor of five if comparing C++ and Python.
> 2. How long did you use Python before you achieved increased
> productivity ?
Less than two weeks.
Regards,
Christian
--
Christian Tanzer tan...@swing.co.at
Glasauergasse 32 Tel: +43 1 876 62 36
A-1130 Vienna, Austria Fax: +43 1 877 66 92
Frank V. Castellucci
>
> [snip]
>
18 (C) and 10 (C++)
> In "C++" I have :-
>
> 1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
> Profilers, Programmers Editor including Class Browser, etc..
>
> 2. I use the STL (Standard Template Library) which gives powerful string
> and container classes.
>
> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.
>
> 4. I can also use background compiling and linking.
>
> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..
>
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated. I am genuinely interested
> to ask "C++" programmers :-
Don't read that I am foresaking the C++ language, I'm not...I love it
and will continue with it for a long, long, time.
Both languages have a rich set of libraries. It is not apples to apples
when one language is compiled and linked, and the other is interpereted.
With Python you can skip the comp+linkedit step and just code and run
which equates to the potential for more work in less time. I find that
it saves more time than the equivalent task in Java as well.
I don't understand why people put background compiling and linking as
some kind of feature. The only time this has worked for me has been on a
pre-emptive multi-tasking OS (Linux, OS/2, NT, MVS) when what I was
compiling was a separate executable or library whilst I worked on
another body of code. At the speed of todays computers, you can barely
get to the other body of code before the other background compile and
linkedit have finished.
I shall enumerate some Python DIFFERENCES as it relates to the REAL
drudge of development:
0. Platform independent.
1. No waiting for compile and linkedit, just write and run.
2. No need for creating makefiles, just run.
3. Very RICH set of packages (libraries).
4. Idle provides a good source level debugger.
> 1. What productivity increase do you achieve ?
Again, if you are always doing something else during the housekeeping of
C++ than the difference is minimal. I rarely find this to be the case,
we are often sitting like cave men in front of a fire watching the
compilation for errors and warnings. So for me the productivity increase
is the gain from not waiting for compiles, not dealing with make files,
and faster debugging.
> 2. How long did you use Python before you achieved increased
> productivity ?
Generally, the class and object took about a day, the language features
are still being realized. At this point I have been putting together a
project for creating a package of GoF Design Patterns (Gamma et. al) and
Collections (STL-ish) in pure Python.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package
Frank V. Castellucci
>
> stev...@ozemail.com.au (Steve Mullarkey) wrote:
> [snip]
>
> There are lots of reasons. The ones first springing to my mind are:
>
> - The tools you mention notwithstanding, C++ still forces you to write
> lots of low-level code by hand (e.g., memory management, the
> `orthodox canonical class form').
>
> - C++ doesn't offer any means of meta-programming. If you want to add
> some mechanism (like serialization, introspection, ...) to a class
> hierarchy, you'll have to add member functions to every class in the
> hierarchy. In Python you can implement the complete mechanism in the
> root class of the hierarchy.
This is crap:
1. There are gc, SmartPointer, heap management, etc. class libraries out
there.
2. There is the type information in standard conforming compilers.
3. There is, has been, and will be more, C++ class Class libraries which
are powerful, easy to use, and free. I was using NIHs Class class about
5 years ago.
Define 'orthodox canonical class form'
>
> - Incremental compiling/linking doesn't help when you need to refactor
> your product or want to add a mechanism to a class hierarchy. In
> that case, you might have to wait a long time for the product to be
> recompiled and linked. In Python, you might be able to pull the
> change into the running application.
I agree with this truth.
> [snip]
People, we should all be realistic. I have seen so many language
assertions that are unfounded or un-reasearched that the credibility of
the author goes in the toilet with my urine.
Drew Csillag
On Fri, 9 Jun 2000, Steve Mullarkey wrote:
> I have been a 'C' programmer for the past 15 years and a "C++"
> programmer for the past 3 years. I'm not a genius but would modestly (?)
> class myself as reasonably competent.
>
> In the past week I have become aware of Python. I've bought a book and
> read this newsgroup every day.
>
> I have read in several places productivity claims of 5 to 10 times over
> 'C' and "C++". I would like to ask for some feedback from "C++"
> programmers who have moved to Python as to whether these estimates are
> realistic.
>
> In "C++" I have :-
>
> 1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
> Profilers, Programmers Editor including Class Browser, etc..
Python's tools are very good (and don't need them a lot of the time
anyhow). The main thing missing is a GUI builder (but glade and PyGlade
are getting there quickly). Memory leak tools just don't apply (Python
has reference counted garbage collection). Programmers editors are
numerous and one is included (IDLE).
> 2. I use the STL (Standard Template Library) which gives powerful string
> and container classes.
There is no STL library for Python since you don't need them, things like
mappings, lists, strings, etc. are built in.
> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.
Python - minimal compile time (happens automatically, so no fighting with
project defs or makefiles, dependancy tracking, etc.).
> 4. I can also use background compiling and linking.
C++ link time always takes forever, just sometimes forever is shorter
occasionally. There are may stories of people starting a full compile and
going to lunch since it would be that long before the compile finished...
These stories are true (lived it myself) when dealing with a reasonably
large project.
> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..
All available for python too (most included in the standard dist).
Python's standard library is almost a good enough reason in and of itself
to use it. Not to mention that the language rocks.... :)
>
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated. I am genuinely interested
> to ask "C++" programmers :-
>
> 1. What productivity increase do you achieve ?
Better than 10x.
> 2. How long did you use Python before you achieved increased
> productivity ?
Well, since I was doing Python on the side, it was about a month or so. I
was doing C++ for about 3-4 years before that.
IMNSHO, after writing Python for a month, I didn't want to do anything in
C++. Luckily, for my current employer, I program in Python almost
exclusively (some C here and there too). Basically, what I've discovered
is that:
1) I write the application in Python
2) if it's too slow, I try tweaking the slow section in python.
3) if it's still too slow, I write a C extension.
Generally, too slow doesn't happen often and I rarely get to step 3.
My main beefs with C++ are this:
* If you want to write dynamic programs, you spend a lot of time
fighting the compiler, convincing it you are correct.
* Even when not writing dynamic programs, you still spend a lot of
time telling the compiler "I know better than you, bow to me" --
by using casts.
* C++ compilers bite when it commes to debugging templates, some are
better than others, but they all suck.
* Memory management sucks. With Python, it doesn't enter the picture.
* Can you say "buffer overflow"?
* The language is so big that very few people know the *whole*
language and you wind up at any job with 1 or 2 language lawyers who
write code that nobody else understands.
Python makes all of the above much easier.
Just my $.02
Drew Csillag
--
print(lambda(q,p):'pmt:$%0.2f'%(q*p/(p-1)))((lambda(a,r,n),t:(a*r/
t,pow(1+r/t,n*12)))(map(input,('amt:','%rate:','years:')),1200.0))
Michael Hudson
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated. I am genuinely interested
> to ask "C++" programmers :-
>
> 1. What productivity increase do you achieve ?
>
> 2. How long did you use Python before you achieved increased
> productivity ?
One of my habits is answering questions on comp.lang.python with
quotes from the Python Quotation file at
http://starship.python.net/crew/amk/quotations/python-quotes.html
The one for this occasion is:
I never got beyond starting the data-structures in C++, I never got
beyond seeing how it would work in Scheme. I finished it in one
Python-filled afternoon, and discovered the idea sucked big time. I
was glad I did it in Python, because it only cost me one afternoon
to discover the idea sucks. -- Moshe Zadka, 13 May 2000
Cheers,
M.
--
3. Syntactic sugar causes cancer of the semicolon.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Mike Fletcher
track down a memory leak. Yes, memory leak tools would be nice to have in
Python. Hidden memory leaks (cycles) are rare, but when they happen in a
complex project they are often a nightmare to track down. An optional
garbage collector with a debug mode saying "hey, I found a cycle that wasn't
cleaned up, the objects were: object types, object cycle description" would
be really cool. Yes, I'd probably remove it for the final proggy, but as a
development tool it would be very, very, useful, and is currently (to my
memory), not available.
0.02
Mike(y)
-----Original Message-----
From: Drew Csillag [mailto:drew.c...@starmedia.net]
Sent: Friday, June 09, 2000 1:07 PM
To: Steve Mullarkey
Cc: pytho...@python.org
Subject: Re: Python Productivity over C++
On Fri, 9 Jun 2000, Steve Mullarkey wrote:
...
Python's tools are very good (and don't need them a lot of the time
anyhow). The main thing missing is a GUI builder (but glade and PyGlade
are getting there quickly). Memory leak tools just don't apply (Python
has reference counted garbage collection). Programmers editors are
numerous and one is included (IDLE).
...
Bill McClain
> I have read in several places productivity claims of 5 to 10 times over
> 'C' and "C++". I would like to ask for some feedback from "C++"
> programmers who have moved to Python as to whether these estimates are
> realistic.
I've been using C++ for work for several years and use Python at home. I'm
trying to introduce Python at work.
What frustrates me about C++ is the enormous declarative overhead required
to get anything done. Every class requires me to instruct the compiler on
how to copy, assign, compare and reference objects, and how subclasses
are allowed to inherit from the parent. STL works well for data structures,
but the advanced features are very cumbersome.
Much of this burden simply vanishes with Python.
When my coworkers come to me for help, I always warn them: C++ is a
difficult language to use _well_. The types of issues everyone
eventually encounters can be found at Herb Sutter's "Guru of the
Week":
http://www.peerdirect.com/resources/
It's not pretty.
-Bill
Martijn Faassen
> stev...@ozemail.com.au (Steve Mullarkey) writes:
>>I have read in several places productivity claims of 5 to 10 times over
>>'C' and "C++". I would like to ask for some feedback from "C++"
>>programmers who have moved to Python as to whether these estimates are
>>realistic.
> I'm a C++ programmer (leave out the quotes ;) ).
> First off, any claim of an order of magnitude increase in productivity is
> pure nonsense. See Brooks for an explanation or Boehms and McConnell for
> hard data.
That's likely true. I do suspect there are more anecdotal examples of
"I did the same project in Python and I finished in half the time!" compared
to C++ than the other way around, but these aren't very scientific. Usually
the person already had experience with the problem domain before reaching
for Python, for instance. Still, Python is far more dynamic than C++ and
probably fits certain problem domains more naturally. I have a hard
time seeing Zope in C++, for instance.
> <snip enumeration of tools>
>>I don't want to start a flame war but, given the above, I just can't see
>>where the productivity increase is generated. I am genuinely interested
>>to ask "C++" programmers :-
>>1. What productivity increase do you achieve ?
>>2. How long did you use Python before you achieved increased
>>productivity ?
> I want to use Python for scripting tasks. I dislike 'ordinary' scripting
> languages as they lack the ability to recover from errors; a problem that
> Python, being a real programming language, does not have.
> Up to now, I've been using C++ for scripting. I'm not proficient in Python
> yet, so writing a Python script takes far longer than writing a C++ utility
> and the Python code itself is larger than the equivalent C++ code.
But then you must be very good at C++. :) (Hi Wim!) My experience was that I
was faster than C++ after a couple of days already. Note that I haven't had
any real experience with post-STL C++, which may or may not matter.
When you write a class in C++ and you want to do it *well*, you have to
think about a horrible amount of stuff; constructor, destructor, copy
constructor, assignment operator, possibly other operators, public, private,
protected. Without the STL you'll have to do lots of manual memory
management as well; reallocating arrays, etc. If you want to write a
generic class there's a whole set of extra things to consider.
I found that this took a long time in C++, while whipping up a decent
class in Python is a piece of cake in comparison. Even generic Python
classes.
It's perhaps just a difference in philosophies as well; C++ is a statically
typed language and its proponents put a lot of emphasis on this kind of
correctness. In Python you might come up with lots of correctness rules
as well, but people don't, as the whole approach is different. People
rarely care about things like public/private, even. This also means a lack
of getters/setters in many cases; those will only be created if they
are deemed necessary. This means encapsulation can be broken easily,
but Python programmers don't care about this so much -- in practice often
it is more of a problem to strictly preserve encapsulation (and type safety)
than it is to fix any problems when and if they arise.
> What I expect from Python, is that I can reuse scripting utilities,
> something that I do not do for C++ utilities. This could, perhaps, yield
> a 10% increase in productivity, but I'm not writing scripts all day, so
> my overall productivity increase will be negligible.
I think that in quite a few problem domains more increase of productivity
can be seen, but it's extremely hard to measure and probably also
depends on the individual.
> Most of all, however, I enjoy the incremental coding (I come originally
> from a Smalltalk background). I *like* Python, which is all excuse I need
> to use it.
Right -- it's just plain fun. In my opinion, it's more fun than C++, where
the fun is really in dealing with its the dark side. :) So in many cases,
I can have more fun coding in Python than in C++, while my productivity is
at least not adversely affected (and in many cases I believe positively
affected). Since run-time speed often doesn't matter, this means I'd rather
use Python in many cases.
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Drew Csillag
On Fri, 9 Jun 2000, Mike Fletcher wrote:
> Just a minor note, having spent all of last night (unsuccessfully) trying to
> track down a memory leak. Yes, memory leak tools would be nice to have in
> Python. Hidden memory leaks (cycles) are rare, but when they happen in a
> complex project they are often a nightmare to track down. An optional
> garbage collector with a debug mode saying "hey, I found a cycle that wasn't
> cleaned up, the objects were: object types, object cycle description" would
> be really cool. Yes, I'd probably remove it for the final proggy, but as a
> development tool it would be very, very, useful, and is currently (to my
> memory), not available.
Good point. But there are actually two cycle detectors (one may or may
not be derived from the other) that I know of: plumbo and Cyclops (I've
used both). I believe (I may be totally wrong on this) that one of them
will be included with 1.6.
>
> 0.02
> Mike(y)
>
> -----Original Message-----
> From: Drew Csillag [mailto:drew.c...@starmedia.net]
> Sent: Friday, June 09, 2000 1:07 PM
> To: Steve Mullarkey
> Cc: pytho...@python.org
> Subject: Re: Python Productivity over C++
>
>
>
>
> On Fri, 9 Jun 2000, Steve Mullarkey wrote:
> ...
>
> Python's tools are very good (and don't need them a lot of the time
> anyhow). The main thing missing is a GUI builder (but glade and PyGlade
> are getting there quickly). Memory leak tools just don't apply (Python
> has reference counted garbage collection). Programmers editors are
> numerous and one is included (IDLE).
>
> ...
>
--
Christian Tanzer
"Frank V. Castellucci" <fra...@colconsulting.com> wrote:
> > There are lots of reasons. The ones first springing to my mind are:
> >
> > - The tools you mention notwithstanding, C++ still forces you to write
> > lots of low-level code by hand (e.g., memory management, the
> > `orthodox canonical class form').
> >
> > - C++ doesn't offer any means of meta-programming. If you want to add
> > some mechanism (like serialization, introspection, ...) to a class
> > hierarchy, you'll have to add member functions to every class in the
> > hierarchy. In Python you can implement the complete mechanism in the
> > root class of the hierarchy.
>
> This is crap:
>
> 1. There are gc, SmartPointer, heap management, etc. class libraries out
> there.
Guess what. Something like SmartPointer was one of the first classes I
implemented. In C++, that doesn't relieve you of thinking about memory
management, though.
> 2. There is the type information in standard conforming compilers.
Nowadays, there is.
<rant>
If you happen to use a standard conforming compiler. In 1997, there
were still several compilers that didn't even fully conform to the
1990 edition of Stroustrup und Ellis's `The Annotated C++ Reference
Manual'.
</rant>
RTTI doesn't offer any mechanisms remotely approaching Python features
like `__getattr__'/`__setattr__' though. Not to speak of `eval' and
`exec'.
> 3. There is, has been, and will be more, C++ class Class libraries which
> are powerful, easy to use, and free. I was using NIHs Class class about
> 5 years ago.
So what? Your pains start as soon as you want to combine libraries
from different sources which happen to use incompatible idioms (like
overloading global operators, ...).
> Define 'orthodox canonical class form'
J.O. Coplien's `Advanced C++ Programming' will tell you all about it.
> > [snip]
>
> People, we should all be realistic. I have seen so many language
> assertions that are unfounded or un-reasearched that the credibility of
> the author goes in the toilet with my urine.
I've used C++ and Python for projects of comparable size/complexity
and based my statements on that experience.
That's not scientific research, and of course it depends on my style
of using the two languages.
Your experience might be different.
Mark Hammond
news:3940D192...@colconsulting.com...
> Define 'orthodox canonical class form'
I believe this is from "Advanced C++ Programming Styles and Idioms", by
James Coplien (whom Ive actually had the pleasure of dinner with - I was
one of a few - Im sure he wont remember me :-)
Mark.
Andrew M. Kuchling
> I was glad I did it in Python, because it only cost me one afternoon
> to discover the idea sucks.
Indeed. This is a point missed by much of the flamage on the
linux-kernel list about the CML2 kernel configuration system. If CML2
turns out to be a bad idea, or can't be made to work correctly, I'm
sure that ESR would much rather throw out 1000 lines of Python code
than 10,000 of C code that had to be carefully debugged to get it to
run enough to discover that it's a bad idea. If CML2 does turn out to
be a good idea, it can be recoded into C if the Python dependency
really is unacceptable.
--
A.M. Kuchling http://starship.python.net/crew/amk/
I'm willing to accept that someone might just have all the answers. However,
I'm pretty sure he won't be posting them on a GeoCities page.
-- From mathew's October 1999 web.scan
Wim Lavrijsen
>"Frank V. Castellucci" <fra...@colconsulting.com> wrote:
>> 1. There are gc, SmartPointer, heap management, etc. class libraries out
>Guess what. Something like SmartPointer was one of the first classes I
>implemented. In C++, that doesn't relieve you of thinking about memory
>management, though.
As I understand it, Python objects are simply reference counted. So, a
pervasive use of smart pointers in C++ will give the exact same effect
as in Python.
>> 2. There is the type information in standard conforming compilers.
><rant>
>If you happen to use a standard conforming compiler. In 1997, there
If 1997 was the last time you touched C++, it explains a lot about your
arguments.
>were still several compilers that didn't even fully conform to the
>1990 edition of Stroustrup und Ellis's `The Annotated C++ Reference
>Manual'.
></rant>
>RTTI doesn't offer any mechanisms remotely approaching Python features
>like `__getattr__'/`__setattr__' though. Not to speak of `eval' and
>`exec'. =
If you wish to have such in C++, use a C++ interpreter, such as ROOT/CINT.
>> 3. There is, has been, and will be more, C++ class Class libraries which
>> are powerful, easy to use, and free. I was using NIHs Class class about
>> 5 years ago.
>So what? Your pains start as soon as you want to combine libraries
>from different sources which happen to use incompatible idioms (like
>overloading global operators, ...).
If programmers (library vendors in this case) mess up, you will always
have problems, in any language. I've seen several messages on this platform
about problems with modules redefining variables from other modules. Why
is that different than a library vendor who is so erratic to use global
operators?
>> Define 'orthodox canonical class form'
>J.O. Coplien's `Advanced C++ Programming' will tell you all about it.
Also being to only book which advocated the canonical form. Compilers
do a reasonable job by providing the cctor, assignment copy and dtor.
(I worry about efficiency, so I write my own cctor and assignment copy
operators, see: http://www.lavrijsen.net/ctotw/ctotw21.html)
Best regards,
Wim Lavrijsen
Michael Hudson
> Just a minor note, having spent all of last night (unsuccessfully)
> trying to track down a memory leak. Yes, memory leak tools would be
> nice to have in Python. Hidden memory leaks (cycles) are rare, but
> when they happen in a complex project they are often a nightmare to
> track down. An optional garbage collector with a debug mode saying
> "hey, I found a cycle that wasn't cleaned up, the objects were:
> object types, object cycle description" would be really cool. Yes,
> I'd probably remove it for the final proggy, but as a development
> tool it would be very, very, useful, and is currently (to my
> memory), not available.
Have you tried Neil Schemenauer's patch?
http://www.enme.ucalgary.ca/~nascheme/python/gc.html
It can help with some of these things.
There's also cyclops, which I think is somewhere on ftp.python.org.
Cheers,
M.
--
Academic politics is the most vicious and bitter form of politics,
because the stakes are so low. -- Wallace Sayre
Courageous
> > First off, any claim of an order of magnitude increase in productivity is
> > pure nonsense. See Brooks for an explanation or Boehms and McConnell for
> > hard data.
>
> That's likely true. I do suspect there are more anecdotal examples of
> "I did the same project in Python and I finished in half the time!" compared
> to C++ than the other way around, but these aren't very scientific.
I've used C++ since 1985. Recent experiences with C++, Lisp, Java, and
Python all have me favoring Python for productivity. Is there an order
of magnitude increase in producitivity? Well base 2 maybe. :)
> >>2. How long did you use Python before you achieved increased
> >>productivity ?
About 2 weeks.
> > Up to now, I've been using C++ for scripting. I'm not proficient in Python
> > yet, so writing a Python script takes far longer than writing a C++ utility
> > and the Python code itself is larger than the equivalent C++ code.
It only takes about 2 weeks become proficient in Python.
> But then you must be very good at C++. :) (Hi Wim!) My experience was that I
> was faster than C++ after a couple of days already. Note that I haven't had
> any real experience with post-STL C++, which may or may not matter.
Stl? *S*tl? Could it be?!?!?! Satan!!! :^)
> It's perhaps just a difference in philosophies as well; C++ is a statically
> typed language and its proponents put a lot of emphasis on this kind of
> correctness. In Python you might come up with lots of correctness rules
> as well, but people don't, as the whole approach is different. People
> rarely care about things like public/private, even. This also means a lack
> of getters/setters in many cases; those will only be created if they
> are deemed necessary. This means encapsulation can be broken easily,
> but Python programmers don't care about this so much -- in practice often
> it is more of a problem to strictly preserve encapsulation (and type safety)
> than it is to fix any problems when and if they arise.
This flexibility of approach allows someone to concentrate more
on the problem domain and less on their language, IMO.
C/
Eric Lee Green
> I have read in several places productivity claims of 5 to 10 times over
> 'C' and "C++". I would like to ask for some feedback from "C++"
> programmers who have moved to Python as to whether these estimates are
> realistic.
>
[Lots of tools, libraries, and pre-defined classes to ease the process.]
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated.
Sooner or later, no matter how comprehensive your tools and libraries, you
must write code. Python code is much more compact than C++ code. For example,
a netstream class took 3 pages of "C" code (would have taken the same amount
of C++ code, since no STL container class was applicable here). It took half
a page of Python code. The Python code was written in 1 hour. The "C" code was
written in 4 hours. The two classes were functionally equivalent (one lives on
a client where Python is not available, one lives on a server where Python is
available).
Our QuickStart product is written in C++. A product we are currently working
on is written (mostly) in Python (with some "C" modules and programs). So we
do have some experience with both. We would not have even started our current
project if C++ had been a requirement, because there is no way we could
deliver it with the manpower we have. (Even with Python it's a stretch -- Hey,
if anybody out there is looking for a good Python job, leave me email,
especially if you've done any sort of GUI work in the past, you're hired :-).
--
Eric Lee Green er...@estinc.com
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
Frank V. Castellucci
advocating C++ over Python. I am having a tremendously educational and
productive time using Python. My responses are in regards to C++
comments which I feel are either not true, or that the arguments being
presented are based on a subjective desire, or lack thereof, to achieve
the functionality expressed as lacking or inferior.
Christian Tanzer wrote:
>
> "Frank V. Castellucci" <fra...@colconsulting.com> wrote:
>
> > > There are lots of reasons. The ones first springing to my mind are:
> > >
> > > - The tools you mention notwithstanding, C++ still forces you to write
> > > lots of low-level code by hand (e.g., memory management, the
> > > `orthodox canonical class form').
> > >
> > > - C++ doesn't offer any means of meta-programming. If you want to add
> > > some mechanism (like serialization, introspection, ...) to a class
> > > hierarchy, you'll have to add member functions to every class in the
> > > hierarchy. In Python you can implement the complete mechanism in the
> > > root class of the hierarchy.
> >
> > This is crap:
> >
> > 1. There are gc, SmartPointer, heap management, etc. class libraries out
> > there.
>
> Guess what. Something like SmartPointer was one of the first classes I
> implemented. In C++, that doesn't relieve you of thinking about memory
> management, though.
This is kind of funny because in my experience memory management
thinking usually precludes SmartPointer implementation.
>
> > 2. There is the type information in standard conforming compilers.
>
> Nowadays, there is.
Agreed, but the language had the ability for you to write your own, or
use someone else's library which provided the same.
> RTTI doesn't offer any mechanisms remotely approaching Python features
> like `__getattr__'/`__setattr__' though. Not to speak of `eval' and
> `exec'.
>
> > 3. There is, has been, and will be more, C++ class Class libraries which
> > are powerful, easy to use, and free. I was using NIHs Class class about
> > 5 years ago.
>
> So what? Your pains start as soon as you want to combine libraries
> from different sources which happen to use incompatible idioms (like
> overloading global operators, ...).
Every language has a painful aspect to itself. Some take more time to
correct than others.
> I've used C++ and Python for projects of comparable size/complexity
> and based my statements on that experience.
>
> That's not scientific research, and of course it depends on my style
> of using the two languages.
>
> Your experience might be different.
I try not to pick a language for implementation until I am happy that
problem space is adequately defined, a reasonable degree of requirement
specification have been put forth, a sound analysis and design has been
done, and a language is available which satisfies the solution space. As
a contract developer this time alloted to perform these tasks may span
from one weekend by myself to many months with teams of people.
Sometimes the people who hire me decide the language before these steps.
I do the best I can.
Hands down, a interpretive language with a reasonably rich functional
capability will allow someone to "be more productive" than one which
requires intervening steps to get you into the unit test/debug cycle. I
don't go for the "one language cures all" position personally because if
it were true, we wouldn't have so many to choose from.
When any language has been around for awhile and supported through
developers like you and I by ADDING capability that the native grammar
ALLOWS us to, then the language becomes useful. Python is useful.
M.-A. Lemburg
>
> I have been a 'C' programmer for the past 15 years and a "C++"
> programmer for the past 3 years. I'm not a genius but would modestly (?)
> class myself as reasonably competent.
>
> In the past week I have become aware of Python. I've bought a book and
> read this newsgroup every day.
>
> 'C' and "C++". I would like to ask for some feedback from "C++"
> programmers who have moved to Python as to whether these estimates are
> realistic.
Let's see...
> In "C++" I have :-
>
> 1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
> Profilers, Programmers Editor including Class Browser, etc..
IDEs:
* Python comes with an IDLE
* PythonWare sells a brand new product called PythonWorks which
* PythonWin is another Win32 based product
Memory Leaks:
* These can only occur if you are using cyclic references; Python1.6
will probably have cycle GC, so starting with 1.6 leaks are
probably only in C code.
Profilers:
* Python comes with a profiler.
> 2. I use the STL (Standard Template Library) which gives powerful string
> and container classes.
Python doesn't really have a need for these, since coding
polymorphic code which only relies on available interfaces
is no problem at all (Python uses name binding, not
static typing as C++).
> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.
>
> 4. I can also use background compiling and linking.
Python compiles on-the-fly at run-time and only if needed.
You can even program interactively and have the program
compile its own code.
The typical C cycle editor-compiler-linker-debugger boils
down to a editor-run cycle -- Python provides run-time
exceptions which show you exactly where errors occurred.
> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..
Regular Expressions are included in Python. For Date/Time
there is a 3rd party extension called mxDateTime (see my
Python Pages), for other things take a look at the
Parnassus Vaults (via www.python.org).
Best of all: Python comes with batteries included (tm)
Just scan the library documentation at www.python.org to
get an impression of what is there.
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated.
Should be obvious: Python reduces dev-time, enhances
productivity, reduces LOCs, scales well (from 5-100k LOCs
if needed -- which is roughly equivalent to 25-250k LOCs
in C++ from my own experience).
Besides, you can continue programming in C++ and then
glue everything together using Python. It offers great
extension and embedding capabilities. I have turned to
writing all object oriented code in Python and only
resort to C for low-level high performance routines.
Works well :-)
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
nbe...@fred.net
Bill> What frustrates me about C++ is the enormous declarative overhead required
Bill> to get anything done. Every class requires me to instruct the compiler on
Bill> how to copy, assign, compare and reference objects, and how subclasses
Bill> are allowed to inherit from the parent. STL works well for data structures,
Bill> but the advanced features are very cumbersome.
Bill> Much of this burden simply vanishes with Python.
I rarely need to do this for my classes. Using STL heavily is a big
help.
Wim Lavrijsen
>reduces LOCs, scales well (from 5-100k LOCs
>if needed -- which is roughly equivalent to 25-250k LOCs
>in C++ from my own experience).
This is interesting. Could other people confirm this? Ie. that the
trade-off for Python is larger at small projects (factor ~5) than at
medium sized projects (factor ~2.5)?
And what is the cause of the difference?
Best regards,
Wim Lavrijsen
Mike Steed
> Sent: Friday, June 09, 2000 9:38 AM
> To: pytho...@python.org
> Subject: Re: Python Productivity over C++
>
>
This is a surprising thing to say. STL requires that the types used to
instantiate its various templates be well-behaved in certain ways, e.g., for
copying, assigning, and comparing (depending on the "concept" to which the
template conforms). This means you have to implement your own copy
constructor, assignment operator, and/or comparison operators for each
(non-trivial) class. It may not be difficult, but it is overhead that
Python does not impose.
--
M.
Wim Lavrijsen
>> From: nbe...@fred.net [mailto:nbe...@fred.net]
>>
>> I rarely need to do this for my classes. Using STL heavily is a big
>> help.
>This is a surprising thing to say. STL requires that the types used to
>instantiate its various templates be well-behaved in certain ways, e.g., for
>copying, assigning, and comparing (depending on the "concept" to which the
>template conforms).
All that STL containers require is that your dtor and copy assignment
don't throw. The compiler generated members fullfill that requirement.
> This means you have to implement your own copy
>constructor, assignment operator, and/or comparison operators for each
>(non-trivial) class. It may not be difficult, but it is overhead that
>Python does not impose.
Please inform yourself better before making such statements. Blindlessy
drawing conclusions based on the C++ implementation of one particular
vendor from Redmond isn't good for your credability.
Best regards,
Wim Lavrijsen
Mike Steed
> Sent: Friday, June 09, 2000 11:11 AM
> >> From: nbe...@fred.net [mailto:nbe...@fred.net]
> >>
> >> I rarely need to do this for my classes. Using STL heavily is a big
> >> help.
>
> >This is a surprising thing to say. STL requires that the types used to
> >instantiate its various templates be well-behaved in certain ways, e.g.,
for
> >copying, assigning, and comparing (depending on the "concept" to which
the
> >template conforms).
>
> All that STL containers require is that your dtor and copy assignment
> don't throw. The compiler generated members fullfill that requirement.
True. And although it's not required, it *is* a good idea to make sure that
each class's copy constructor and assignment operator behave properly. The
default copy ctor often does not do what you want, e.g., if your class
contains pointers to other objects.
> > This means you have to implement your own copy
> >constructor, assignment operator, and/or comparison operators for each
> >(non-trivial) class. It may not be difficult, but it is overhead that
> >Python does not impose.
>
> Please inform yourself better before making such statements. Blindlessy
> drawing conclusions based on the C++ implementation of one particular
> vendor from Redmond isn't good for your credability.
And assuming that I'm blindlessly drawing conclusions based on Microsoft's
compiler is not good for your credibility. The default copy ctor
(regardless of the compiler) simply does a member-by-member copy, which is
often the wrong thing to do. The point is that, even if the default is
acceptable, the C++ programmer has to (or should) think about it.
This discussion illustrates the original point: these are details that the
Python programmer does not need to deal with.
> Best regards,
> Wim Lavrijsen
--
M.
Tim Peters
> ...
> Good point. But there are actually two cycle detectors (one may or may
> not be derived from the other) that I know of: plumbo and Cyclops (I've
> used both). I believe (I may be totally wrong on this) that one of them
> will be included with 1.6.
Cyclops started as an attempt to give plumbo a serious speed boost, but
quickly diverged. Both require manual setup and some expertise, and
Cyclop's larger set of "features" makes it that much more intimidating at
first.
Neither will be included with 1.6, AFAIK. There's still reason to hope that
NeilS's GC patch will be, albeit perhaps that enabling it will require
setting a compile flag at Python build time.
running-in-circles-ly y'rs - tim
Hung Jung Lu
>Steve Mullarkey wrote:
> > 3. I use incremental compiling and linking. This reduces wait times to
> > very small amounts.
> > > 4. I can also use background compiling and linking.
>
>Python compiles on-the-fly at run-time and only if needed.
>You can even program interactively and have the program
>compile its own code.
I really have to raise my voice here: in Python, running means also
compiling. Steve: sorry to point this out to you, but you really ought to
take a look at dynamical reloading of modern script languages like Python.
To me, that's the biggest advantage of modern script languages. In Python,
there are no separate commands for compiling and running. And you can reload
a Python module on the fly. Do you understand that? For many applications
(like webservers), it is absolutely crucial that the main application keeps
running while you are adding/modifying part of the program. That's an area
where C++ can not do well. In Python, I often have programs running, and
then I need to modify part of the program. I go ahead and modify the module,
and since I have designed the main program to reload the submodules, I never
have to stop the main application, this even if there are compiling/runtime
errors from the submodule. Doing that in C++ is an absolute nightmare.
Python not only does incremental compiling and linking, it does it in REAL
TIME. You can modify your program while it is running. This is absolutely
critical for applications like webservers: you don't want to stop the main
application because you want to change one line of code. This is a
tremendous time saving over the traditional compile-run-debug,
compile-run-debug, compile-run-debug,... cycles. In Python, it was more
like: debug-click, debug-click, debug-click,... cycle. I just can't imagine
how I was going to do the same thing in C++ within the same time frame. I
would say that 10 times shorter development time is probably an
understatement in that particular case. In my case, it was between a
possible project and an impossible project.
The biggest advatages of script languages are that they make dynamic
reloading easier and they offer reflection (or introspection): the language
is capable of looking into itself, and even perform meta-programming. I know
you can make your C++ program to do this kinds of things, but you have to
spend a tremendous amount of development time before you can reach some
minimum features of dynamic reloading and reflection. (I have also used Java
reflection features, but Python's reflection is way simpler and superior.)
When you have dynamic reloading, designing GUI in Python is still not as
comfortable as in Visual Basic, but darn close.
I worked for a multimedia CD-ROM game company before, and it really sucked
to use C++ or Java because of the lack of dynamic reloading. Programmers
waste too much time in the compiling process. With Python, you can have the
application running, find out the bug, fix it, and all while the game is
still running. Too bad I already changed job.
Hung Jung
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Boudewijn Rempt
>>I have read in several places productivity claims of 5 to 10 times over
>>'C' and "C++". I would like to ask for some feedback from "C++"
>>programmers who have moved to Python as to whether these estimates are
>>realistic.
> I'm a C++ programmer (leave out the quotes ;) ).
> First off, any claim of an order of magnitude increase in productivity is
> pure nonsense. See Brooks for an explanation or Boehms and McConnell for
> hard data.
I'm not entirely sure - I would like to see some hard data, but I think
that having a language which assembles all the best practices and
discards all the worst might offer a significant improvement in
productivity. After all, many cents make a dollar, too.
I'm not really sure whether scripting languages aren't as much a leap
as the leap from first to second generation languages was. The results
mentioned in that paper comparing C++, Java, Perl, Python & Tcl by Lutz
Prechelt (http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.ps.gz)
were suggestive. To quote (p. 28) "Designing and writing the program in
Perl, Python, Rexx or Tcl takes only about half as much time as writing
it in C, C++, or Java and the resulting program is about half as long."
Simply put, with Python you need less statements, and the amount of
statements a programmer puts out is constant (be it assembly, C or
Python - I think that's in Brooks, too), so the amount of effort needed
is correspondingly less.
Of course, that doesn't take into account the oft-mentioned variabilty
in programmer prowess - the best can crank out ten times as much code
than the worst. That's why the people developing KDE can push out more
C++ code than I can Python ;-(.
--
Boudewijn Rempt | http://www.valdyas.org
Boudewijn Rempt
> I really have to raise my voice here: in Python, running means also
> compiling. Steve: sorry to point this out to you, but you really ought to
> take a look at dynamical reloading of modern script languages like Python.
> To me, that's the biggest advantage of modern script languages. In Python,
> there are no separate commands for compiling and running. And you can reload
> a Python module on the fly. Do you understand that? For many applications
> (like webservers), it is absolutely crucial that the main application keeps
> running while you are adding/modifying part of the program. That's an area
> where C++ can not do well. In Python, I often have programs running, and
> then I need to modify part of the program. I go ahead and modify the module,
> and since I have designed the main program to reload the submodules, I never
> have to stop the main application, this even if there are compiling/runtime
> errors from the submodule. Doing that in C++ is an absolute nightmare.
Could you post an example of designing the main program to reload
submodules? I'd like to get that working, too, and coming from
languages where that's impossible, I've a bit of trouble coming up
with a solution...
Moshe Zadka
> Could you post an example of designing the main program to reload
> submodules? I'd like to get that working, too, and coming from
> languages where that's impossible, I've a bit of trouble coming up
> with a solution...
You were addressing a different "you", but I would still like to explain how
I did that in a program that didn't see yet the light of day. I had a
main module containing "hooks": lists of functions to execute in different
circumstances. For example:
# File: Hooks.py
on_load_hooks = []
Now, when I started up the program, I looked in a specified directory for
extensions: each of them got read into a string, and then I did
exec s in {}
Now, an extension usually looked like:
#
import Hooks
def foo(params):
do something
Hoos.on_load_hooks.append(foo)
Additionally, the user was able to add extensions at run-time. There was
no provision for de-registering extensions, except for places which had
place for exactly one hook. In those, registering a hook meant de-registering
the previous one. This convinced me that it is possible, but it wasn't needed
for that application. One caveat: when you de-register a function, first
delete it from the globals, otherwise you might get some nasty leaks. Python
1.6 might solve this if the gc patch gets in.
--
Moshe Zadka <mos...@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
Hung Jung Lu
>Could you post an example of designing the main program to reload
>submodules? I'd like to get that working, too, and coming from
>languages where that's impossible, I've a bit of trouble coming up
>with a solution...
This is a very simple reloader, but it gives you an idea. Make two Python
files names M1.py and M2.py:
M1.py
===============================================================
import sys
import thread
import time
def reloader():
while 1:
module_name = raw_input('module to reload: ')
modules = sys.modules
if modules.has_key(module_name):
print 'reloading'
reload(modules[module_name])
else:
print 'importing'
exec 'import %s' % module_name
time.sleep(1.0)
if __name__ == '__main__':
thread.start_new_thread(reloader, ())
while 1:
time.sleep(1.0)
==================================================================
M2.py
=============================
print 'Hello World!'
=============================
Now, run the first file in a shell (or double click on it in Windows
system), and then type in M2 at the prompt, then go to M2 and edit it by
hand (change to something like print 'bye bye World'), and then type in M2
again at the prompt. See the magic.
The thing is, if you modularize your huge python project into small modules,
you can really achieve good reloading and that makes your debugging easier.
This is especially true for large projects where the penalty of setting up
the initial state is very time consuming (like when you are debugging a
computer game module... there might be some error that happens only after
you've played 27 dungeon rooms. Not that I have programmed games in Python,
it's just an analogy.)
regards,
Rainer Deyke
news:8hr8fj$fu$1...@sunnews.cern.ch...
> All that STL containers require is that your dtor and copy assignment
> don't throw. The compiler generated members fullfill that requirement.
This statement is both incorrect and misleading. Incorrect because there
may be other requirements: for example, std::set (along with several others)
requires that operator< and operator== are defined for the object.
Misleading because for many classes the compiler generated functions cause
incorrect behavior.
--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware action/role-playing games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Aahz Maruch
Wim Lavrijsen <wl...@hpatl26.cern.ch> wrote:
>
>First off, any claim of an order of magnitude increase in productivity
>is pure nonsense. See Brooks for an explanation or Boehms and McConnell
>for hard data.
That's half-true. Lines of code per unit time is roughly constant per
programmer (though I think Python breaks even that rule). Of more
interest is the extent to which one language has greater expressiveness
than another for a given domain. So if Python programs are generally
one-tenth the size of C/C++ programs, there *is* an order of magnitude
increase in productivity.
Where I think Python really kicks butt is in maintenance, though.
Reading Python code is significantly easier than any other language I've
seen; rewriting Python code is also significantly easier.
--
--- Aahz (Copyright 2000 by aa...@netcom.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"I love you."
"Duhhhh!" --SFJ
Frank V. Castellucci
>
> In article <8hqbvr$fgr$1...@sunnews.cern.ch>,
> Wim Lavrijsen <wl...@hpatl26.cern.ch> wrote:
> >
> >First off, any claim of an order of magnitude increase in productivity
> >is pure nonsense. See Brooks for an explanation or Boehms and McConnell
> >for hard data.
>
> That's half-true. Lines of code per unit time is roughly constant per
> programmer (though I think Python breaks even that rule). Of more
> interest is the extent to which one language has greater expressiveness
> than another for a given domain. So if Python programs are generally
> one-tenth the size of C/C++ programs, there *is* an order of magnitude
> increase in productivity.
I would be careful with that bat. The more libraries you use, the more
editors that provide expansion and completion, the more generator type
tools available increase the LOC but reduce the time spent at the
keyboard. For any language.
Productivity is not measured by LOC alone, it needs to be measured by
QLOC (Quality lines of code). This is easily tracked with most revision
control systems. If developer A spends ten minutes putting out crap
code, then developer be must come along and spend even more time
debugging and correcting those "productive" lines of code.
> Where I think Python really kicks butt is in maintenance, though.
> Reading Python code is significantly easier than any other language I've
> seen; rewriting Python code is also significantly easier.
Agreed.
--
Frank V. Castellucci
James Logajan
> 1. What productivity increase do you achieve ?
I find it easier and quicker to lay out high level design and in
experimenting with finding the best class/data schema. And I can then run
it. The syntactical constructs of C++ tend to distract from the design
thought processes. All in my humble opinion of course (and I think that is
what you were asking for).
I wouldn't say I am many times faster at this with Python than C++, just
that the Python syntax seems to be more pleasurable to work with and that I
*feel* I make good progress with it. It is subjective I'm afraid.
P.S. Used C for about 20 years, C++ for about 4.
James Logajan
> Could you post an example of designing the main program to reload
> submodules? I'd like to get that working, too, and coming from
> languages where that's impossible, I've a bit of trouble coming up
> with a solution...
Several ways are possible. Here is one way. In the main program you might
have:
# main.py
# Run-time modify of a module.
import sys
import os
import m1
m1.F(1) # Try first version of m1.py
del sys.modules['m1'] # The magic bit.
print "Please edit m1.py; press return when ready."
sys.stdin.readline()
import m1
m1.F(1) # Try second version of m1.py
And the module to be modified looks like:
# m1.py
def F(score):
print "Banana"
#print "Mango"
Now a typical run with commenting out the first pritn and uncommenting the
second print in m1.py should lead to an output like:
Banana
Please edit m1.py; press return when ready.
Mango
Hope this helps!
P.S. If you don't even know the name of the module ahead of time, you can
get creative with the "exec" statement!
Courageous
> I find it easier and quicker to lay out high level design and in
> experimenting with finding the best class/data schema. And I can then run
> it. The syntactical constructs of C++ tend to distract from the design
> thought processes.
I strongly agree. In python, I get to think entirely about the problem,
without worrying about the language/programming environment one bit,
really. Furthermore, and this is a MAJOR win, python programs are *small*,
which makes them easier to maintain, easier to read, and faster to code
in general. Python is also very syntactically lightweight, which has to
me my favorite thing about it.
Right now, I strictly use it as a rapid prototyping environment. It's
great for testing out concepts.
C/
Travis Oliphant
While on the subject of reloading...
I'm not sure if you covered this already, but what if I have an extension
module written in C that is already loaded in memory.
If I change the extension module and recompile it. Is there a way to get
python to reload the new extension module. I've tried to do it but always
get a segmentation fault.
-Travis
Alex
> Could you post an example of designing the main program to reload
> submodules? I'd like to get that working, too, and coming from
> languages where that's impossible, I've a bit of trouble coming up
> with a solution...
I posted something about that recently. I've posted the code again
below. I must admit, I haven't had much occasion to test it yet, as I
haven't been working on anything with complex module dependancies.
Also, if you had many modules, it would probably be a bit slow as it
stands.
import sys, string
from types import ModuleType
class Reloader:
'''Here is my attempt at something that figures out an appropriate
reloading order for you. You create an instance of the class,
call it 'rr', before you have imported any of the modules you'll
be wanting to reload (the .pythonrc file would be a good place.)
Then when you wish to reload the modules in a given namespace, you
run the command
exec (rr (globals ()))
In my case, the namespace would usually be __main__, so this would
just go at the top of the script I'm currently working on in
emacs.
Alex.
'''
def __init__ (self):
self.keepem = sys.modules.copy ()
def get_new_modules (self):
modules = {}
for i, m in sys.modules.items():
if (not self.keepem.has_key (i)) and \
(type(m) == ModuleType):
modules[i] = m
return modules
def clear_sys_modules (self):
for i in self.modules.keys ():
if sys.modules.has_key (i):
del sys.modules[i]
def get_dependancies (self, module_name):
self.clear_sys_modules ()
exec 'import ' + module_name
new_modules = self.get_new_modules ()
del new_modules[module_name]
return new_modules
def determine_reloads (self):
self.return_commands = []
while self.dependancies:
for i, deps in self.dependancies.items ():
if not deps:
break
else:
raise 'Cyclic dependancy(?)'
exec 'import ' + i
reload (eval (i))
if self.namespace.has_key (i) and \
(self.namespace[i] == self.modules[i]):
self.return_commands.append (
'import %s; reload (%s)' % (i, i))
del self.dependancies[i]
for deps in self.dependancies.values ():
while deps.count (i):
deps.remove (i)
def __call__ (self, namespace):
self.namespace = namespace
self.modules = self.get_new_modules ()
self.dependancies = {}
for module_name in self.modules.keys ():
deps = self.get_dependancies (module_name).keys ()
self.dependancies[module_name] = deps
self.determine_reloads ()
return string.join (self.return_commands, ';')
rr = Reloader ()
if __name__ == '__main__':
'''This is a test script, intended to be run with two modules, B.py
and C.py somewhere in the directories in sys.path. Their contents
should be
B.py:
######################################################################
import C
class B (C.C):
def __init__ (self):
C.C.__init__ (self)
C.py:
######################################################################
class C:
def __init__ (self):
pass
'''
import B, C
bid = id (B.B)
cid = id (C.C)
exec (rr (globals ()))
assert (bid != id (B.B)) and (cid != id (C.C))
t = B.B ()
François Pinard
> ["M.-A. Lemburg" <m...@lemburg.com>]
> >reduces LOCs, scales well (from 5-100k LOCs if needed -- which is
> >roughly equivalent to 25-250k LOCs in C++ from my own experience).
> This is interesting. Could other people confirm this? Ie. that the
> trade-off for Python is larger at small projects (factor ~5) than at medium
> sized projects (factor ~2.5)? And what is the cause of the difference?
I would be tempted to say than for big projects, you usually build specific
libraries and tools for your project, kind of another language layer.
One this is done, and if done well, it increases the expressivity of the
language you use, whatever the language is, and so, reduces the difference
between languages. For medium sized projects, the layer of specific
libraries is thinner, and you then observe more directly the expressivity
of the bare programming languages.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Christian Tanzer
"Frank V. Castellucci" <fra...@colconsulting.com> wrote :
> > > 2. There is the type information in standard conforming compilers.
> >
> > Nowadays, there is.
>
> Agreed, but the language had the ability for you to write your own, or
> use someone else's library which provided the same.
Sure it provides it. But you have to implement it. And that costs
time.
The decisive difference is:
- in C++ you have to add RTTI code to every class in the class
hierarchy -- it is simply impossible to factor the behavior into the
root of the hierarchy.
- In Python, you can implement the entire mechanism needed in the root
of the hierarchy.
Of course, nobody forces you to do that, and you might end up with
exactly the same design as in C++.
> Every language has a painful aspect to itself. Some take more time to
> correct than others.
Sure. But you can still compare the total amount of pain and the time
it costs you. And here, Python comes out way ahead.
If the problem mandates it, you might still have to use C++. But you'll
need more development time. And it is less fun to use C++.
> I try not to pick a language for implementation until I am happy that
> problem space is adequately defined, a reasonable degree of requirement
> specification have been put forth, a sound analysis and design has been
> done, and a language is available which satisfies the solution space. As
> a contract developer this time alloted to perform these tasks may span
> from one weekend by myself to many months with teams of people.
> Sometimes the people who hire me decide the language before these steps.
> I do the best I can.
Great. I hope we all do (though I met too many people who don't).
--
Christian Tanzer tan...@swing.co.at
Glasauergasse 32 Tel: +43 1 876 62 36
A-1130 Vienna, Austria Fax: +43 1 877 66 92
Alex Martelli
news:8F4E9C028steve...@139.130.250.4...
> I have been a 'C' programmer for the past 15 years and a "C++"
> programmer for the past 3 years. I'm not a genius but would modestly (?)
> class myself as reasonably competent.
>
> In the past week I have become aware of Python. I've bought a book and
> read this newsgroup every day.
>
> 'C' and "C++". I would like to ask for some feedback from "C++"
> programmers who have moved to Python as to whether these estimates are
> realistic.
I have not "moved" from C++ to Python: most of my professional
development (what I get paid for) is still C++. For personal
programming projects, such as my bridge studies, I've moved most
stuff to Python (everything that used to be in Perl, and a good
fraction of what used to be in C or C++).
> In "C++" I have :-
>
> 1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
> Profilers, Programmers Editor including Class Browser, etc..
My favourite editor has always been vi (now, and since a few years,
in the free gvim version), and it's just as good for Python as it is
for C++. Otherwise, I find PythonWin and IDLE adequate substitutes
for Microsoft Visual Studio. ObWarning: I don't do much GUI's, in
either language, so I have no experience of how the GUI builders
compare; Hammond and Robinson's "Python Programming on Win32" seems
to do an adequate job of presenting a huge variety of different
approaches you can use -- if I did have a huge investment in a GUI
builder I'm sure I could keep it (a GUI shell in VB, Delphi, or
whatever you prefer, with most or all of the real work in Python).
> 2. I use the STL (Standard Template Library) which gives powerful string
> and container classes.
I suspect that here we see the usual confusion between STL (the
prototype experimental research thingy which provided inspiration
for what is now in the C++ standard and has since kept changing)
and the Standard C++ Library. Matters only to pedants like me, I
guess, but one of the little things giving me joy is that I just
barely managed to catch this confusion about to be propagated in
Eckel's otherwise-excellent "Thinking in C++" 2nd edition, and it
was in time to have him correct it (he's such a wonderful writer,
I hope he really gets to grips with the "Thinking in Python" book
he mentions as a possibility!).
Anyway, back to your point 2: Python's dictionaries, lists, and
strings, give you basically all you get from Standard C++'s
containers, and then some. You may have to do some adaptation
for certain constructs (e.g., remap a std::multimap<> in terms
of a dictionary with lists as entries), and some of the best
features of C++'s <algorithm> are missing (std::next_permutation,
for example), but I notice you don't mention those so I guess
you won't miss them (there is sure to be something around the
net usable as a substitute, anyway:-).
> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.
>
> 4. I can also use background compiling and linking.
>
> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..
No compiling and linking at all surely beats even those "very
small amounts", and the good stuff you can find on the net for
Python is a LOT.
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated.
For many people, I suspect a key issue is that they never really
understood _100%_ of C++. It IS a hugely complex language, and
an ENORMOUS investment is needed to fully grasp 90% of it; just
as much effort and expense, to move up to 99%; and as much again,
to get to 99.9%. I'm about at this last level, so I'm RARELY bitten
by things I just didn't understand perfectly, but I'm unwilling
to do it all over again to get to 99.99% (particularly since, at
this level, existing implementations still deviate substantially
from the Standard). But I also do consulting and mentoring, and
see presumably-experienced C++ programmers baffled by issues such
as
MyClass my(5); // declares a variable
MyClass mx(); // declares a function, NOT a variable
or
std::copy(a.begin(), a.end(), b.begin()); // does NOT extend b!
etc, etc, as well as 'deeper' issues such as partial template
specialization, order-of-initialization issues, dominance rules,
the distinctions between overriding, overloading, and hiding, &c.
Judging from my experience, over 90% of "experienced C++ programmers"
have a 90%-or-less grasp of the C++ language. This is quite
understandable given its complexity and difficulty, but surely
explains why such programmers would be much more productive in
a language that is simple enough that they CAN grasp it well with
much more modest effort (and, mostly, carefully designed so that
not-fully-grasped issues don't rear up and bite you when you
least expect it:-).
However, avoiding C++'s traps and pitfalls is not really where the
big gains came for me, since I'm reasonably well-versed in avoiding
them (and have the scars to prove it:-). Rather, for me personally
the key issues have to do with Python's intrinsically-dynamic nature.
Exploratory programming, ease of reuse, very easy refactoring, are
three key issues. In C++, you have to start with a substantially
"right" class structure; you can do minor tweaks, but you can't really
go very far "just playing around with various possibilities"; and when
you see a refactoring would be warranted, it's most often a lot of
work. Plus, to get any substantial reuse value out of your work, you
have to invest a lot in making it _reusable_ in the first place, or
in reworking it with reusability in mind -- very worthwhile investment,
but still hard to do under production deadlines. Python's more fluid,
dynamic style helps on all of these fronts: you play around more, get
more possibilities explored, refactor more frequently and effectively,
and get reuse without huge up-front investments in reusability.
> I am genuinely interested
> to ask "C++" programmers :-
>
> 1. What productivity increase do you achieve ?
I've never measured it precisely, but it does lie somewhere
between a factor of 2 and one of 10. It's probably less for
areas one knows so well (having written a dozen separate programs
or subsystems for them) that one could recode them in one's
sleep, while it tends to the higher end for areas where the
exploratory-programming and refactoring advantages loom large.
> 2. How long did you use Python before you achieved increased
> productivity ?
A couple of weeks (versus a decade of C++, and C before that).
One of the most amazing characteristics of Pythin is how
amazingly FAST one becomes productive with it.
Alex
Gordon McMillan
>gm...@hypernet.com (Gordon McMillan) writes:
>
>[snip]
>
>> One point worth reiterating is that where the app (in a C++ design)
>> calls for lots of related classes, you will probably only have a
>> handful in Python. Of course, this means discarding classical "OOP"
>> thinking, and desinging more in the "component" style. But this can
>> yield an order of magnitude all by itself.
>
>If it's worth reiterating, would you mind elaborating on this
>somewhat?
Simply that in Python, inheritance doesn't necessarily have anything to do
with runtime behavior. (You can, of course, introduce that dependency, but
you'd be well advised not to.)
The classic example would be 2 base classes (say Event and View), and you
want view->process(event) to get to both the right overload and the right
override. In C++ (or Java) that takes spelling out the whole num(View
derived classes) x num(Event derived classes) matrix, and bouncing the
message back and forth (first to get the overload and then to get the
override). In Python, it takes view.process(event).
That is, it's the interface that matters (not the derivation), and you
don't even have to get formal about that.
Not that you should throw out everything you know about pre-condions and
post-conditions and substitutability; but you don't have to spend all week
convincing the compiler you know what you're doing.
- Gordon
Roy Katz
CPU emulator, implementing twelve or so basic instructions (push,
pop, mov, add, interrupt-execute, etc...). The time invested in its
Python build amounted to two hours. Mostly of the time was spent writing
new code.
Then I moved it to C++. In a nutshell, this required re-writing
everything using STL. This took me about twice as long to implement (not
counting nitpicking over the syntax errors).
Then I move to C. The process took about twice as long as the C++
attempt; not counting the time it took for me to write miscellaneous
libraries (stack, memory allocation), I noticed that I was spending far
more time hunting pointer bugs and syntax errors than writing new
code. oThis was the longest port; it took me about four times longer than
it did in Python.
At the same time, C was faster than (straight) Python by a factor of
ten. Whatever, I now have three implementations of a virtual CPU to play
around with :)
Roey Katz
Aahz Maruch
Roy Katz <ka...@Glue.umd.edu> wrote:
>
>I wanted to test this out, so I built a project in Python. It is a small
>CPU emulator, implementing twelve or so basic instructions (push,
>pop, mov, add, interrupt-execute, etc...). The time invested in its
>Python build amounted to two hours. Mostly of the time was spent writing
>new code.
>
>Then I moved it to C++. In a nutshell, this required re-writing
>everything using STL. This took me about twice as long to implement (not
>counting nitpicking over the syntax errors).
>
>Then I move to C. The process took about twice as long as the C++
>attempt; not counting the time it took for me to write miscellaneous
>libraries (stack, memory allocation), I noticed that I was spending far
>more time hunting pointer bugs and syntax errors than writing new
>code. oThis was the longest port; it took me about four times longer than
>it did in Python.
>
>At the same time, C was faster than (straight) Python by a factor of
>ten. Whatever, I now have three implementations of a virtual CPU to play
>around with :)
The real moral is that, had you invested the same amount of time
speeding up your Python code (possibly by writing part of it in straight
C), you almost certainly would have received a speedup of somewhere
between two and a hundred times -- so at worst your C program would have
been five times faster and at best your C program would have been ten
times slower. (Best and worst being relative to the Python program, of
course. ;-)
David Bolen
> Simply that in Python, inheritance doesn't necessarily have anything to do
> with runtime behavior. (You can, of course, introduce that dependency, but
> you'd be well advised not to.)
(...)
> That is, it's the interface that matters (not the derivation), and you
> don't even have to get formal about that.
For me, this hit home in a small but practical case of overriding
sys.stdout with an alternate "file" object. The requirement is that
it satisfy the interface (in this case, just a "write" method) and not
a particular class hierarchy.
This makes it extremely simple, and generally informal, to build a
class that fits the requirement (and/or augment an existing class that
may be deep in your own hierarchy) and use that as a replacement
sys.stdout object. As long as you meet the interface requirements
(dynamically at run time) you're set.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Darrell Gallion
> Whatever, I now have three implementations of a virtual CPU to play
> around with :)
>
Now it's time to refactor. How easy will it be to add features to each?
--Darrell
Roy Katz
My point is that I find Python easier use for roughing out a
quick sketch--like how charcoal is to art. program. I'm hooked on it
as a general-purpose language, please understand; however, now
I have an (working) example for my friends (whom I'm trying to persuade
to pick up Python).
The punchline: coding took two hours in Python and two days in C.
Roey Katz
vu geyt ir?
Courageous
> >Then I move to C. The process took about twice as long as the C++
> >attempt; not counting the time it took for me to write miscellaneous
> >libraries (stack, memory allocation), I noticed that I was spending far
> >more time hunting pointer bugs and syntax errors than writing new
> >code. oThis was the longest port; it took me about four times longer than
> >it did in Python.
Although, to be fair, any seasoned C programmer has his or her
own preferred set of utility functions for doing hashtables,
stacks, lists, and so forth. I have a set of macro-expansion
tools for that that are far more efficient than the standard
template library could ever pray to be (written by a nut who
would meticulously process to assembly and analyze the number
and nature of assembly instructions issued for the equivalent
C... he was really freaky :).
Fair point with the pointer bugs, though.
That's not something that can even happen in Python, really. :)-
C/
Juanjo Álvarez
en fecha: Mon, 12 Jun 2000 06:33:05 GMT
|Python is a simply wonderful prototyping environment, IMO.
|Now only if it had an optimizing compiler...
I think every Python fan dream with that...
It's really so difficult?
Courageous
Frank V. Castellucci
>
> > >Then I move to C. The process took about twice as long as the C++
> > >attempt; not counting the time it took for me to write miscellaneous
> > >libraries (stack, memory allocation), I noticed that I was spending far
> > >more time hunting pointer bugs and syntax errors than writing new
> > >code. oThis was the longest port; it took me about four times longer than
> > >it did in Python.
>
> Although, to be fair, any seasoned C programmer has his or her
> own preferred set of utility functions for doing hashtables,
> stacks, lists, and so forth. I have a set of macro-expansion
> tools for that that are far more efficient than the standard
> template library could ever pray to be (written by a nut who
> would meticulously process to assembly and analyze the number
> and nature of assembly instructions issued for the equivalent
> C... he was really freaky :).
But this is somethings we had to do. I know you've heard the old "When I
was your age I walked to school", which the new cry of us greying and
balding is "When I was your age I had 64k on a mainframe". Now you look
on the sideboard of some pc product$ with requirements of 128 Mb just to
USE the damn things.
--
Frank
Moshe Zadka
> |Python is a simply wonderful prototyping environment, IMO.
> |Now only if it had an optimizing compiler...
>
> I think every Python fan dream with that...
>
> It's really so difficult?
Short answer: yes
Long answer: but it's being worked at nonetheless
Courageous
> > Although, to be fair, any seasoned C programmer has his or her
> > own preferred set of utility functions for doing hashtables,
> > stacks, lists, and so forth. I have a set of macro-expansion
> > tools for that that are far more efficient than the standard
> > template library could ever pray to be (written by a nut who
> > would meticulously process to assembly and analyze the number
> > and nature of assembly instructions issued for the equivalent
> > C... he was really freaky :).
>
> But this is somethings we had to do.
This is doubtful, albeit you would have had to look somewhere to
find what you wanted... that I don't doubt. It wasn't so long ago
that STL was just a glimmer in the C++ standard's eye, and was
nothing more than a yet another template library from yet another
unix vendor. This isn't to argue the genuine usefulness of pythons
generic container classes, of course; obviously I'm sold. :)-
C/
Ken Seehof
> <snip>
> In "C++" I have :-
>
> 1. Good tools, Borland C++ Builder, MS VC++, Memory Leak Tools,
> Profilers, Programmers Editor including Class Browser, etc..
I look forward to some nice tools under development. Right now, I'd say
that overall C++ tools are better than the python tools (aat least in the
Windows environment). On the other hand, imho, python doesn't need the
tools as much.
GUI building tools - C++ wins. Until Boa Constructor arrives. There's also
PythonWorks, which I haven't looked at.
Memory leak tools - Python doesn't need them (except for circular refs which
aren't that tough anyway). Python wins here. The next major release of
python will probably have true garbage collection, which will remove orphan
circular refs.
Profilers - Never looked, so I don't know if python has any good ones. If
I'm concerned with saving a few milliseconds, I code an extension.
> 2. I use the STL (Standard Template Library) which gives powerful string
> and container classes.
Having strings and container classes as built-in types with language syntax
is a big advantage for python. I find that while STL is perhaps as
/powerful/ as python's set built-in types, it still takes me longer to code
with it, and my code is much less readable than it would be in python.
> 3. I use incremental compiling and linking. This reduces wait times to
> very small amounts.
True, but to me this isn't as nice as having an interactive interpreter.
Suppose you write a function to manipulate a list in some way. Now you want
to test it. In python, you call the function from the interpreter, perhaps
expressing the list as a literal. In C++ you write a test function, maybe
complete with some user interface code, debug your test function, compile
(very quickly with your incremental compiler) and run your test function,
and then try to figure out whether your bug is in the function being tested
or your test function. Anyway, I find that the typical write-test-debug
cycle goes much faster in an interpreter, and with less distraction.
BTW, seems to me that in theory one could write a C++ interpreter. The idea
would be to make the compiler available through a library function that
would compile the one-liner into a (very small) shared library, link to it,
and call it. Does anyone know it that has been done?
> 4. I can also use background compiling and linking.
>
> 5. I have 3rd party libraries to handle Regular Expressions, Date/Time,
> etc..
>
> I don't want to start a flame war but, given the above, I just can't see
> where the productivity increase is generated. I am genuinely interested
> to ask "C++" programmers :-
>
> 1. What productivity increase do you achieve ?
Very hard to measure. I think maybe 4 to 1, but I can't prove it.
> 2. How long did you use Python before you achieved increased
> productivity ?
I could match my C++ within a couple weeks. Maybe a couple months to get to
4-1, mostly because I had to look for new libraries.
> Best regards,
>
> Steve Mullarkey.
> Tascom Pty Ltd.
> Berry, NSW 2535, Australia.
> Tel : (61)-(2)-4464-3328
Where does it come from?
The interpreter certainly helps, but that's not really the main thing.
When I code in C++ or python, I spend most of my time testing and debugging,
so the question is: How does python save time on debugging?
In C++ most persistent bugs are related to memory and type issues. Python
handles memory for you, and gives less potential for type related problems
(despite the nonsense about C++ being safer because of static type checking
(oops, I hope I didn't just start a flame war :-) ). So most of these bugs
don't appear in the first place.
I find that the Visual C++ debugger is better than the python debugger
(though eventually someone will write a really awesome python debugger,
which should be relatively easy given python's introspective capabilities).
However, I find that in the two years I've been programming with python, I
use the debugger less often than when I'm programming with C++ (which I've
been doing for about twelve years).
Python bugs are usually much easier than C++ bugs. Write down a brief
description of the next ten significant bugs you encounter in C++ and you
will see what I mean.
Dealing with types in C++ is often very time consuming. C++ has a vast
number of redundant basic types that various people have wrapped and aliased
in various ways. By basic types I mean integers, floats, lists, strings,
and mappings (ok, I'm being python-centered here). In C++ I find myself
spending more time making sure I have the right kind of integer, or
converting from one string type to another, or figuring out how to iterate a
particular kind of list, etc. In python, if someone invents a new sequence
type, or implements a special kind of mapping object, I immediately know how
to use it with no guessing or reading manuals. The STL certainly helps C++
overcome this, but STL was invented long after C++, so you still have to
deal with the multitude of types. Python's containers were there from day
1.
The learning curve for third party libraries is a major factor in
productivity. In python it is often said that there is one obvious way to
do a thing. As a result, it is usually easy to remember (or even guess)
correct usage. You never have to ask, "Is that supposed to be an unsigned
short int or a long int?", or "Is that a const char *, a char const *, or a
MegaWidgetString& ?", or "Am I supposed to delete that?".
I like to write my own custom programming tools (whether in C++ or python),
especially for large projects. Python programming tools are easier to write
because of it's dynamic nature, and because string processing is easier.
Why is string processing easier in python? Python doesn't have more string
processing capability but python can do the same things with much less
syntactical messiness. There is no need for a string class to wrap the
basic type. And then there's the handy slice operators that are
syntactically cleaner than anything you can get in C++. A regex library is
a regex library, but it sure is nice to test your regular expression on the
command line (perhaps 10 seconds per test rather than 20-30 seconds with a
C++ compiler).
I don't have anything against C++, but for me, the role of C++ is changing.
It is becoming what assembly used to be when I was programming with C: a way
to code that inner loop that has to go really fast.
--
Ken Seehof
ke...@sightreader.com
starship.python.net/crew/seehof
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
Ken Seehof
Wim Lavrijsen wrote:
> "M.-A. Lemburg" <m...@lemburg.com> writes:
>
> >reduces LOCs, scales well (from 5-100k LOCs
> >if needed -- which is roughly equivalent to 25-250k LOCs
> >in C++ from my own experience).
>
> This is interesting. Could other people confirm this? Ie. that the
> trade-off for Python is larger at small projects (factor ~5) than at
> medium sized projects (factor ~2.5)?
>
> And what is the cause of the difference?
>
> Best regards,
> Wim Lavrijsen
I'd expect it to be the other way around. The advantages of Python over
C++ for small projects (interactive interpreter, fast unit testing and
debugging, simpler syntax, no declarations) continue to be equally
relevant in large projects. In addition, Python encourages component
oriented programming, which means it scales much better than C++. In a
typical C++ project, it is difficult to make major changes, or even
small modifications, to the design and implementation of components
without having nasty chaos propagating throughout the rest of the
project.
In python, if you have ten different teams independently develop ten
modules after a one hour design meeting, you can figure they will
probably work together seamlessly. Not likely in C++.
Peter Schneider-Kamp
>
[nice anecdotal hint for Python productivity]
> At the same time, C was faster than (straight) Python by a factor of
> around with :)
Would you mind putting the code somewhere (on a site or something).
I'd like to take a look to count number of lines/evaluate
how expressive the languages are, if I can read and extend
the code easily (let's say I add two CPU commands, I measure
how long I need to understand enough of the code to be able to
do it and then how long I need to do it) etc.
of-course-I'd-like-to-play-with-it-too-ly y'rs Peter
--
Peter Schneider-Kamp ++47-7388-7331
Herman Krags veg 51-11 mailto:pe...@schneider-kamp.de
N-7050 Trondheim http://schneider-kamp.de
Ken Seehof
Hung Jung Lu wrote:
> <snip>
> The biggest advatages of script languages are that they make dynamic
> reloading easier and they offer reflection (or introspection): the language
> is capable of looking into itself, and even perform meta-programming. I know
> you can make your C++ program to do this kinds of things, but you have to
> spend a tremendous amount of development time before you can reach some
> minimum features of dynamic reloading and reflection. (I have also used Java
> reflection features, but Python's reflection is way simpler and superior.)
> <snip>
> Hung Jung
I'm developing a python module that will generate C code (translated from a
C-like custom language edited within the python application), invoke the
compiler, and dynamically (re)load the resulting extension module. With a
little help from Python, even C/C++ can be dynamic!
Max Møller Rasmussen
>When I code in C++ or python, I spend most of my time testing and
debugging,
>so the question is: How does python save time on debugging?
I believe that many factors is in play when considering how long time it
takes coding in C/C++ vs. Python.
C/C++ is probably more error prone due to memory managment and pointers this
should make Python faster in itself.
But consider what happens if you find a design flaw in your code and you
have to refactor all of it. Shorter code will be faster to refactor.
Shorter code will probably also have fewer design flaws.
This leads to a quadratic growth in refactoring time for longer code.
Roughly:
Twice as long code -> Twice as many design faults to refactor (Perhaps even
more).
Twice as long code -> Twice as long refactoring time.
I know that this is oversimplification, and that object oriented programming
should make it unnessecary to refactor all the code, but I do believe that
it is very close to the truth. The difference in productivity should be
problem^2 for C/C++ as compared to Python.
The theory can be tested by writing really long programs in both Python and
C/C++.
:-)
There should be a really HUGE difference in productivity for the Python
programmer as Python is a much easier language to design in.
Max M
Thomas Thiele
NO!
I think the more complex the program is the more C++ is the better choice.
It is very easy and fast to write short effective programs with python.
But in larger programs a lot of time is spend for developing and testing the
algorithm.
And I think using C++ is faster because the compilation time is relativly small
compared with the
whole time for program developing. And the the additional time to program the
nice
pythonfeatures (like dictionaries, lists etc.) in C++ is also very small. In
large programs
the disadvatages of python (like rumtime errors instead of compiler errors,
typemismatch,
functions defined twice...) dominates.
Thomas Wouters
> Memory leak tools - Python doesn't need them (except for circular refs which
> aren't that tough anyway). Python wins here. The next major release of
> python will probably have true garbage collection, which will remove orphan
> circular refs.
That's a bit extreme. The next major release would be Python 2, aka Py3k,
which has been repeatedly stated as being 'far away and undecided' at the
least ;) The next minor release, 1.6, *might* contain some form of garbage
collection to remove circular refs, but it certainly does not throw out
refcounting in favor of GC. The garbage-collection bit might even be a
compile-time option, off by default.
> Profilers - Never looked, so I don't know if python has any good ones. If
> I'm concerned with saving a few milliseconds, I code an extension.
The Python profiler is pretty good, but it doesn't profile beyond the python
level (it can't, it's written in Python ;) so you have to combine the python
profiler and a C-level profiler to get proper stats on your extensions.
But, I have to admit, I haven't used it much either, myself.
--
Thomas Wouters <tho...@xs4all.net>
Aahz Maruch
Thomas Thiele <thi...@muc.das-werk.de> wrote:
>
>I think the more complex the program is the more C++ is the better
>choice.
>
>It is very easy and fast to write short effective programs with python.
>But in larger programs a lot of time is spend for developing and
>testing the algorithm.
Yup. And that's precisely why Python looks better and better as your
programs get larger. Python allows you to concentrate on your problem
rather than the language. Python literally allows you to develop the
code for your algorithm in realtime, rather than designing your
algorithm and *then* writing the code to match your algorithm.
See Eric Raymond's article in the Linux Journal for more details:
http://www2.linuxjournal.com/lj-issues/issue73/3882.html
--
--- Aahz (Copyright 2000 by aa...@netcom.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"real love can't be explained by simplistic platitudes." --piranha
Thomas Thiele
> Yup. And that's precisely why Python looks better and better as your
> programs get larger. Python allows you to concentrate on your problem
> rather than the language. Python literally allows you to develop the
> code for your algorithm in realtime, rather than designing your
> algorithm and *then* writing the code to match your algorithm.
>
The only difference I see between developing algorythms in C++ and Python
is that python needs no time for compiling. But the advantage of C++ is that I
get
the most error messages during compilation (-> earlier!)
And I think the developing overhead (algorithms, class design) is larger than
translation into a special language.
Aahz Maruch
conversations.]
In article <39464CD8...@muc.das-werk.de>,
Thomas Thiele <thi...@muc.das-werk.de> wrote:
> Re-inserted attribution for Aahz:
>>
>> Yup. And that's precisely why Python looks better and better as your
>> programs get larger. Python allows you to concentrate on your problem
>> rather than the language. Python literally allows you to develop the
>> code for your algorithm in realtime, rather than designing your
>> algorithm and *then* writing the code to match your algorithm.
>
>The only difference I see between developing algorythms in C++ and
>Python is that python needs no time for compiling. But the advantage
>of C++ is that I get the most error messages during compilation (->
>earlier!)
<shrug> I'll accept that your experience is different -- if you've been
reading the whole thread, you'll realize that your experience really is
different. I do have to wonder whether you've yet learned to think in
Python; it's possible that you're trying to write C++ code in Python,
the way some Perl people find writing Python difficult.
>And I think the developing overhead (algorithms, class design) is
>larger than translation into a special language.
My experience is that Python is so "natural" that language translation
doesn't exist at all, really. Completely removing the translation
overhead makes it possible to focus almost completely on design, which
gives me more time to try out different approaches.
Thomas Thiele
> Python; it's possible that you're trying to write C++ code in Python,
> the way some Perl people find writing Python difficult.
May be. But what are typical mistakes?
How should a REAL python program looks like.
I design classes like in C++, thats true. But I also use typical python features
like lists, dicts, map etc. I'm not trying to write everything by myself.
How have I to think as a pythonprogrammer?
(P.S. don't misunderstand me: I like python!)
James C. Ahlstrom
> 1. What productivity increase do you achieve ?
I get 3 to ten times productivity increase.
> 2. How long did you use Python before you achieved increased
> productivity ?
Maybe six months.
IMHO, the increase is mostly due to the higher-level
language constructs. That is, Python has dictionaries and
lists, and so it is more likely a programmer will use
the correct algorithm in Python, rather than suffer through
having to program his own dicts and lists in C. So the
productivity gain is largest for programs which really
do need dicts and lists. If the Python resembles plain
low level C, I would not expect as much gain.
Relative to C++, Python is a simpler OO language to learn
and use.
Jim Ahlstrom
David Bolen
> >
> > Yup. And that's precisely why Python looks better and better as your
> > programs get larger. Python allows you to concentrate on your problem
> > rather than the language. Python literally allows you to develop the
> > code for your algorithm in realtime, rather than designing your
> > algorithm and *then* writing the code to match your algorithm.
> >
>
> The only difference I see between developing algorythms in C++ and
> Python is that python needs no time for compiling. But the advantage
> of C++ is that I get the most error messages during compilation (->
> earlier!)
This does raise an interesting question. Of the total set of errors
(which "most" you receive during compilation), how many of them are
related to syntactic or language overhead versus algorithmic issues.
It seems to me that the former does not necessarily represent a
benefit to C++ over Python, because in my experience C++ has more
syntactic "sugar" that can increase errors in that respect, so the
fact that you get more of them during compilation isn't something that
translates over to Python anyway.
Some amount of such errors (say errors in type declarations or other
issues related to the strong, static typing of C++) can certainly
point to algorithm issues during compilation. But again, many of
those issues arise from the requirement of strong typing an algorithm
in the first place, so need to be considered as errors whose existence
are largely a by-product of the development environment in use.
But true, there's the area of name errors during runtime, which my
first inclination was to consider a real problem with Python. Even
with some of the 'lint'-like tools around, it didn't seem to be
considered a major problem by the community. But the more code I
write the less concerned I become as I find that surprisingly it just
isn't showing up as a major problem, and it's easy enough to program
defensively against anyway.
But the latter (algorithm issues) are, I believe, just as likely to
show up in runtime in C++ as they are in Python. And at that point,
Python makes it much easier to iterate, debug and maintain those
algorithms and designs.
Ken Seehof
Christian Tanzer wrote:
> "Frank V. Castellucci" <fra...@colconsulting.com> wrote :
>
> > > > 2. There is the type information in standard conforming compilers.
> > >
> > > Nowadays, there is.
> >
> > Agreed, but the language had the ability for you to write your own, or
> > use someone else's library which provided the same.
>
> Sure it provides it. But you have to implement it. And that costs
> time.
>
> The decisive difference is:
>
> - in C++ you have to add RTTI code to every class in the class
> hierarchy -- it is simply impossible to factor the behavior into the
> root of the hierarchy.
>
> - In Python, you can implement the entire mechanism needed in the root
> of the hierarchy.
> Of course, nobody forces you to do that, and you might end up with
> exactly the same design as in C++.
What are you referring to? In python, you get more introspection capabilities
than RTTI without writing any mechanism at all! Arbitrary python objects can,
for example, be serialized with absolutely no serialization coding at all even
at the root of the heirarchy (provided that the objects are "well behaved").
> <snip>
> --
> Christian Tanzer tan...@swing.co.at
> Glasauergasse 32 Tel: +43 1 876 62 36
> A-1130 Vienna, Austria Fax: +43 1 877 66 92
Hung Jung Lu
>for (int i = 0; i < 10; ++i);
> cout << "Hello" << endl;
>
>This, of course, prints "Hello" only once, not 10 times as we
When I started to use Python a few years ago, the thing that told me that
Guido had some brain was exactly little tiny features like that.
Try to talk to some hardcore Perl or C++ programmers, and most likely they
will balk back at you. "What? Python does not even support increment
operator like i++? What kind of a retarded language is that?"
I have had hard time convincing to fellow C++ programmers that an assignment
inside an "if" statement is a bad thing, to no avail. E.g:
if ( a = getNumber() ) {...}
Sure, totally valid statement in C++, but why would anyone introduce such a
stupid feature so you and your compiler get confused all the time with
if ( a == getNumber() ) {...}
?
C++ programmer get bitten all the time with the == && || operators, and
refuse to acknowledge that there is a problem.
Guido was smart enough to get rid of the confusing operators. You can't do
if a = b:
and you have to use explicitly the "or" "and" keywords instead of the
cryptic "&&" "||". And the superflous operators "+=" "++" are eliminated.
(Why? If you are trying to save nanosecond execution time, or 3 bytes in the
code by using Python, you are in the wrong business.)
And Perl people would issue you a stern warning about the indentation in
Python, they'd say: "be very careful with the unusual indentation of Python,
you miss one space and all hell breaks loose." Yeah right. I've been
programming in Python for 3 years, now. It might have happened 2 or 3 times.
Compare with Perl where every single program I wrote was a nightmare to
debug, even if they are just a few lines. And guess what? No matter whether
it is Perl or C++, I always do proper indentation and match up all the
statements and parentheses neatly by hand, so do all the dozens programmers
that I have worked with. So the parenthesis and the semicolons sit there for
... I guess, to be pretty? :) For avoiding a bug that might happen once a
year, Perl and C++ prefer that you introduce bugs that happen daily or even
hourly. Great logics.
After I saw what Guido did with the == && || ++ operators, I knew some brain
was put into Python. And since then, I have never looked back.
Hung Jung
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Bijan Parsia
> Courageous dijo sobre Re: Python Productivity over C++,
> en fecha: Mon, 12 Jun 2000 06:33:05 GMT
>
> |Python is a simply wonderful prototyping environment, IMO.
> |Now only if it had an optimizing compiler...
>
> I think every Python fan dream with that...
>
> It's really so difficult?
1) Look at Vyper, a Python clone+extensions. I haven't heard much about
it in a while. It looked very promising to me. It intended to do a lot
with whole module/program analysis, espeically wrt to type inferencing.
For compiling to machine code executables, this seems like a very good
approach. Stalin (a scheme compiler) takes this path, plus giving up
some runtime dynamaticity (well, you kinda have to if you're going to
analyize the *whole* program) and it achieves quite amazing code.
Outpaced C for certain numeric code, where reasonably idiomatic C and
Scheme were used, and even when someone skanky C was thrown in, IIRC.
2) Common Lisp style compiler. Big grab bag of tricks there, including
optional type declarations. Probably not quite the right match for
Python.
3) Smalltalk/Self style VMs. Improving method/function dispatch alone
can do a hell of a lot, as simple hand optimization shows (e.g., binding
a function to a local variable in an inner loop). Self style is more
ambitious, and probably not worth the implementation effort.
My understanding is the CPython VM is designed for simplicity,
portability, embedability, and easy of using C for extendability. Not
speed. My guess is that one of these has to be reduced for speed to go
up. Acutally, more than one, since simplicity will always be compromised
as you at optimization, and if you add trying to preserve all the
others, you get more complicated quickly.
Vyper shows, in a preliminary way (as does JPython), that there may be
serious gains made by moving to a different, higher level implementation
language. There are indeed some whispers of YA implementation...
...but if I told you about it, you'd tell me back, and then you'd have
to kill me, and my life insurance isn't paid up.
--
Bijan Parsia
http://monkeyfist.com/
...among many things.
Thomas Thiele
Bijan Parsia
Neurocrat
[ compile time errors]
> This does raise an interesting question. Of the total set of errors
> (which "most" you receive during compilation), how many of them are
> related to syntactic or language overhead versus algorithmic issues.
>
> It seems to me that the former does not necessarily represent a
> benefit to C++ over Python, because in my experience C++ has more
> syntactic "sugar" that can increase errors in that respect, so the
> fact that you get more of them during compilation isn't something that
> translates over to Python anyway.
>
> Some amount of such errors (say errors in type declarations or other
> issues related to the strong, static typing of C++) can certainly
> point to algorithm issues during compilation. But again, many of
> those issues arise from the requirement of strong typing an algorithm
> in the first place, so need to be considered as errors whose existence
> are largely a by-product of the development environment in use.
My (admittedly very limited) experience with Python bears this
out. Many of my compile time errors caught by C++ are errors that
would not have been present in a language with cleaner syntax.
I know this is the exceptional case, but sometimes Python even has the
advantage here. Every C++ programmer has done this at some point:
for (int i = 0; i < 10; ++i);
cout << "Hello" << endl;
This, of course, prints "Hello" only once, not 10 times as we
intended. In a toy example it's easy to spot the offending ; at the
end of the loop construct, but is there a C or C++ programmer alive
who hasn't spent hours trying to track down insidious problems caused
by that single legal semicolon? I know I have.
If I made the corresponding mistake in Python:
for x in range(10) # forgot the :
print "hello"
I'd know it straight away.
> But true, there's the area of name errors during runtime, which my
> first inclination was to consider a real problem with Python. Even
> with some of the 'lint'-like tools around, it didn't seem to be
> considered a major problem by the community. But the more code I
> write the less concerned I become as I find that surprisingly it just
> isn't showing up as a major problem,
I too find it surprising, but my experience is the same.
> ... and it's easy enough to program
> defensively against anyway.
I think the use of assertions to define the intended behaviour of a
routine is a better way of both preventing and catching bugs than any
compile time mechanisms. That's just my personal opinion. (Of course,
that much is possible with C++ too).
Thomas Wouters
> for (int i = 0; i < 10; ++i);
> cout << "Hello" << endl;
>
> This, of course, prints "Hello" only once, not 10 times as we
> intended. In a toy example it's easy to spot the offending ; at the
> end of the loop construct, but is there a C or C++ programmer alive
> who hasn't spent hours trying to track down insidious problems caused
> by that single legal semicolon? I know I have.
>
> If I made the corresponding mistake in Python:
> for x in range(10) # forgot the :
> print "hello"
> I'd know it straight away.
This reminds me of a funny piece of code I saw not so long ago. A year or so
ago I inherited a codebase for a MUX, a Multi User Experience (similar to a
MUSH, which is similar to a MUD, a Multi User Dungeon ;) This particular MUX
is the engine for an online game of Battletech. It's also code that has been
around for a long, long time, and has been hacked by literally dozens of
people, either directly or indirectly.
A couple of years back, someone hacked in a new feature. Instead of always
displaying the same 'welcome' message before a login, the MUX now chose one
at random from a directory of such files. While I was doing a major cleanup
of the whole MUX, a couple of months back (and fixing a *lot* of bugs, by
the way) I came into the vicinity of that piece of code because of an unused
variable, and this is what I saw:
#if 0
/* Done this way IF things worked right */
while (1)
{
if (!(de = readdir(d))) break;
if (de->d_name[0] == '.');
continue;
if (!strstr(de->d_name, ".txt"))
continue;
if (*cnt == max) continue;
sprintf(buf, "%s/%s", dir, de->d_name);
fcache_read(&(foo[*cnt].fileblock), buf);
(*cnt)++;
}
closedir(d);
#else
sprintf(buf, "perl -e 'opendir(FOO,\"%s\");@files=readdir(FOO);foreach (@files) { if (/^[^\\.].*\\.txt$/) { print \"%s/$_\\n\";}; };closedir(FOO);'", dir, dir);
f = popen(buf, "r");
while (!feof(f))
[ ... code to read the pipe ... ]
#endif
I kid you not, this feature, which had been in for a couple of years,
running between 2 and oh, 5, public MUXes and probably lots more private
ones, at any one time, started *perl* to read a directory contents. And why?
Because the code that should've worked, using opendir() and all, didn't, and
the author itself (*not* one of those other thirty-odd hackers) couldn't
figure out why it didn't work.
Of course, none of the people who could have written that dare admit it now
;) so the real doofus will remain anonymous forever. I have to admit, too,
though, that I wouldn't have caught it that fast if it wasn't for 'indent'.
But then, that's why there are tools like that ;)
--
Thomas Wouters <tho...@xs4all.net>
Courageous
> > 2. How long did you use Python before you achieved increased
> > productivity ?
2-4 weeks for me.
> Maybe six months.
> Relative to C++, Python is a simpler OO language to learn
> and use.
It's *FAR FAR FAR* easier to learn. Furthermore, given
the deliberate paucity of primitives and forms, you're
very unlikely to run across unusual python idioms or
forms in other people's code, so being able to read and
quickly understand other people's code is much easier
in python, IMO.
C/
Wim Lavrijsen
>> From: wl...@atlas03.cern.ch [mailto:wl...@atlas03.cern.ch]
>> All that STL containers require is that your dtor and copy assignment
>> don't throw. The compiler generated members fullfill that requirement.
>True. And although it's not required, it *is* a good idea to make sure that
>each class's copy constructor and assignment operator behave properly.
For that matter, it *is* a good idea to make sure that all your code
behaves properly. So?
>The default copy ctor often does not do what you want, e.g., if your class
>contains pointers to other objects.
If generated members are 'often' not good enough, then all red lights
should start flashing, as you have a design flaw. It is extremely hard to
make such code exception safe. Instead, you should encapsulate the code
that needs a specialized cctor and use it as member or private base.
I've done a quick scan through some of my code base and I have found 2
classes that need an explicit cctor.
>> Please inform yourself better before making such statements. Blindlessy
>> drawing conclusions based on the C++ implementation of one particular
>> vendor from Redmond isn't good for your credability.
>And assuming that I'm blindlessly drawing conclusions based on Microsoft's
>compiler is not good for your credibility.
It is the only compiler that comes with an STL that beeps at you when you
don't provide said members. If I may ask then, where did you find your
enligntment?
>The default copy ctor (regardless of the compiler) simply does a
>member-by-member copy, which is often the wrong thing to do.
Again, I strongly disagree with your 'often'.
>The point is that, even if the default is
>acceptable, the C++ programmer has to (or should) think about it.
There is such a thing as 'second nature'.
>This discussion illustrates the original point: these are details that the
>Python programmer does not need to deal with.
I fully agree that Python is far simpler, but STL is not so complex as you
seem to want it to be.
Best regards,
Wim Lavrijsen
Wim Lavrijsen
>Wim Lavrijsen <wl...@atlas03.cern.ch> wrote in message
>news:8hr8fj$fu$1...@sunnews.cern.ch...
>> All that STL containers require is that your dtor and copy assignment
>> don't throw. The compiler generated members fullfill that requirement.
>This statement is both incorrect and misleading.
Bold words.
>Incorrect because there
>may be other requirements: for example, std::set (along with several others)
>requires that operator< and operator== are defined for the object.
Nonsense. You can specialize std::set with your own version of comparison
class instead of the standard less and you can make sure that your version
of it does not require said operators.
>Misleading because for many classes the compiler generated functions cause
>incorrect behavior.
As I have explained in another post, 'many' is only true for buggy code
that is not exception safe.
Of course, your statements only underline the original point, that is, that
the STL is to difficult to use for C++ novices. However, although it has
its flaws, the STL is well designed and all the simple things have been
taken care of real good.
Best regards,
Wim Lavrijsen
Martijn Faassen
> How should a REAL python program looks like.
> I design classes like in C++, thats true. But I also use typical python features
> like lists, dicts, map etc. I'm not trying to write everything by myself.
> How have I to think as a pythonprogrammer?
There are differences in approach and philosophy between Python and C++ (or
Java or one of the other statically typed languages):
Some of my observations on Python 'style':
* Pythoneers care less about encapsulation. That is, they like
encapsulation but they don't go out of their way doing getters/setters
and the like; the idea is to encapsulate later, when it becomes
necessary. Python allows this as prototyping can go really quickly.
The dynamic typing aspect also allows a lot of easy loose-coupling
straight away.
* Pythoneers care less about inheritance hierarchies. When a class
supports an interface it supports an interface; inheritance often
isn't needed.
* Pythoneers care less about static type safety (obviously). They don't worry
a lot inside any method or function what type the passed
arguments are (they may sometimes query if it supports an interface,
though). They'll worry about that when passing the arguments
in.
* Pythoneers care more about interfaces, but worry less about them.
Lots of interfaces are implicit, but that's fine, as Python's
dynamicity allows them to make the code do the right thing
anyway. Interfaces aren't really types, so there's less worry
about breaking interfaces.
* Pythoneers care more about rapid prototyping. The language allows it,
so they often write one to throw it away. Or at least overhaul it
drastically. Or not, as it may turn out.
* Pythoneers care more about (unit) tests. Again, tests are easier and quicker
to write because the language allows rapid prototyping.
* Pythoneers worry less about reuse. While reuse with Python is very
easy to accomplish, they don't have to *worry* about it; it just
happens when it does. When it doesn't, it's because it's too easy
to whip something up quickly yourself.
* Pythoneers use Python's introspection abilities such as hasattr() and
isinstance(). Not all the time, not even frequently, but often enough
it's very convenient glue to make things work the way they want,
without having to complicate (or even touch) everything else. Use it
when the design would've painted you in a corner in a statically
typed language.
Of course, any of these may be wrong. :)
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Michael Hudson
> * Pythoneers care less about inheritance hierarchies. When a class
> supports an interface it supports an interface; inheritance often
> isn't needed.
To expand on this: it seems to me that the only reason to inherit in
Python is to inherit implementation; there's just no point in
inheriting to inherit an interface (subtyping). I've lent my copy of
OOSC2 out, but that somewhere has a terrifying diagram listing (I
think) 13 different reasons to inherit; about two of them apply to
Python, IIRC.
simply-admire-simplicity-ly y'rs
Michael
--
There are two ways of constructing a software design: one way is to
make it so simple that there are obviously no deficiencies and the
other way is to make it so complicated that there are no obvious
deficiencies. -- C. A. R. Hoare
Michal Vitecek
>>From: Michal Vitecek <M.Vi...@sh.cvut.cz>
>> > if ( a = getNumber() ) {...}
>> the program shorter and as such more readable. this is really something i
>> hate about python, missing ++ and -- operators plus having to do the
>> assignment stupidly before if comment - more & longer source.
>
>Hey, I can recommend you a great language for shorter and notations: Perl.
>:) You've got all your lovely operators there. You are welcome to use it
>instead of Python. :) Why use Python if you've got Perl? :)
because perl is much less readable - we all know it.
>One thing we have learned from Python and Perl, it's that shorter notations
>are not better. Proper longer notations (not those exaggerated notations
>like in Cobol) are almost self documenting.
this is highly debatable - properly written C/C++ source is pretty well
readable and self-documenting. similarly, badly written python source
makes it as unreadable as in other languages - there's not a point in
trying to prevent people from writing (un)readable source code.
>Your experience with C++ certainly is highly limited.
:) one would never know what others are able to find out from a short
email. i advice you not to be so certain about my C++ experience.
>Do you know that
>Metrowerk compiler by default issues a warning when it encounters
>assignments inside an "if" statement? Now, are you going to tell people in
>Metrowerk that they are dumb, too? :)
if(a = someFunction()) should generate a warning: 'warning: suggest
parentheses around assignment used as truth value'
if((a = someFunction())) shouldn't.
now - is it you who's the dumb here? :)
>> >C++ programmer get bitten all the time with the == && || operators, and
>> >refuse to acknowledge that there is a problem.
>>
>> :) maybe C++ programmers like you?
>
>Wow wow, someone trying to lecture me about C++, you've got some guts. I
>pushed out quite a few products distributed worldwide, managed teams of
>programmers with several Ph.D. degree holders. Dear sir, what have you done
>in your life?
now your nose is so up the sky you should be happy it's not raining.
i don't see why one should care to fight one another as to who has higher
experience - it wouldn't change anything at all if your experience is
better or worse than mine.
>>i personally never had any problem with ==, && and ||,
>
>You are a newbie, and it shows. :)
again - give out some examples where you or your programmers had troubles
with ==, && and ||. just smiling, considering me a newbie without knowing
me and not showing any examples doesn't mark you high.
--
fuf
------------------------------ na IRC -------------------------------------
BillGates [bga...@www.microsoft.com] has joined #LINUX
...
mode/#linux [+b BillGates!*@*] by DoDad
BillGates was kicked off #linux by DoDad (banned: We see enough of Bill
Gates already.)
Aahz Maruch
Mike Steed <MSt...@altiris.com> wrote:
>
>ctor
Okay, does anyone else think this is a misspelling of "Chtorr"?
Q: What should you make when you invite a Chtorran to dinner?
A: Your will.
Aahz Maruch
Thomas Thiele <thi...@muc.das-werk.de> wrote:
>Thomas Thiele deleted the attribution for Aahz:
>>
>> I do have to wonder whether you've yet learned to think in
>> Python; it's possible that you're trying to write C++ code in Python,
>> the way some Perl people find writing Python difficult.
>
>program looks like. I design classes like in C++, thats true. But I
>also use typical python features like lists, dicts, map etc. I'm not
>trying to write everything by myself.
Let me give you an example to illustrate what Martijn wrote:
Suppose you needed a file object to connect to some chunk of memory. In
other languages, you would need to inherit from the Python file object
in order to ensure that random functions that expect file objects would
still work. In Python, that's completely unnecessary. It's probably a
lot simpler to create your own class, complete with open(), close(),
read(), and write() methods -- and because you've maintained *interface*
consistency, you can use your new class *ANYWHERE* a file object would
go.
Garry Hodgson
>
> m.fa...@vet.uu.nl (Martijn Faassen) writes:
>
> > * Pythoneers care less about inheritance hierarchies. When a class
> > supports an interface it supports an interface; inheritance often
> > isn't needed.
>
> To expand on this: it seems to me that the only reason to inherit in
> Python is to inherit implementation; there's just no point in
> inheriting to inherit an interface (subtyping).
except for clarity of expression.
saying "this Circle thing is a Shape"
is more useful to me than having to read its methods
to find that it behaves just like a Shape.
the computer doesn't care about this, but i do.
--
Garry Hodgson Every night
ga...@sage.att.com a child is born
Software Innovation Services is a Holy Night.
AT&T Labs - Sophia Lyon Fahs
Garry Hodgson
> And guess what? No matter whether
> it is Perl or C++, I always do proper indentation and match up all the
> statements and parentheses neatly by hand, so do all the dozens programmers
> that I have worked with. So the parenthesis and the semicolons sit there for
> ... I guess, to be pretty? :)
makes the parser easy to write.
not that this helps the users at all.
Ivan Van Laningham
Aahz Maruch wrote:
>
> In article <65118AEEFF5AD3118E8300508B1248774CB334@ALTNET>,
> Mike Steed <MSt...@altiris.com> wrote:
> >
> >ctor
>
> Okay, does anyone else think this is a misspelling of "Chtorr"?
>
Yes. When the hell is Gerrold going to get back to the series?
<topping-from-inside>-ly y'rs,
Ivan
----------------------------------------------
Ivan Van Laningham
Axent Technologies, Inc.
http://www.pauahtun.org
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Aahz Maruch
Ivan Van Laningham <iva...@home.com> wrote:
>Aahz Maruch wrote:
>> In article <65118AEEFF5AD3118E8300508B1248774CB334@ALTNET>,
>> Mike Steed <MSt...@altiris.com> wrote:
>>>
>>>ctor
>>
>> Okay, does anyone else think this is a misspelling of "Chtorr"?
>
>Yes. When the hell is Gerrold going to get back to the series?
(No, I'm not joking.)
Eric Lee Green
> this is highly debatable - properly written C/C++ source is pretty well
> readable and self-documenting. similarly, badly written python source
> makes it as unreadable as in other languages - there's not a point in
> trying to prevent people from writing (un)readable source code.
It's harder to write unreadable Python source because you can't write code
like, hmm,
opendir(FOO,\"%s\");@files=readdir(FOO);foreach (@files) { if
(/^[^\\.].*\\.txt$/) { print \"%s/$_\\n\";};};closedir(FOO);
since Python enforces proper indentation and limits you to one statement to
line.
Yes, you can write unreadable Python code. But you have to work at it.
--
Eric Lee Green er...@estinc.com
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
Thomas Thiele
> Suppose you needed a file object to connect to some chunk of memory. In
> other languages, you would need to inherit from the Python file object
> in order to ensure that random functions that expect file objects would
> still work. In Python, that's completely unnecessary. It's probably a
> lot simpler to create your own class, complete with open(), close(),
> read(), and write() methods -- and because you've maintained *interface*
> consistency, you can use your new class *ANYWHERE* a file object would
> go.
> --
But there is no mechanism to ensure that the behaviour of your memfileobjectsis
like a fileobject. For instance if you don't note that you forgot to write the
write()-function.
In a worst case scenario it works for many months until a user calls a function
in which
the write() -function is needed.
David Bolen
> But there is no mechanism to ensure that the behaviour of your
> memfileobjectsis like a fileobject. For instance if you don't note
> that you forgot to write the write()-function. In a worst case
> scenario it works for many months until a user calls a function in
> which the write() -function is needed.
I think there are probably both good and bad points to this very fact.
On the bad side I agree that there is no explicit mechanism to support
the verification of interfaces (e.g., it's not like inheriting from an
abstract base class in C++ where you'll get a compiler error if you
don't provide an implementation for each method). So if you want that
validation, there's no built-in method to ensure it. You could roll
your own pretty easily with introspection and some definition of what
you needed to validate as supported by the class, but that's extra work.
On the good side, it means you aren't absolutely wedded to the
interface in cases where you know you won't need it, and can produce a
useful partial implementation to get the ball rolling. For example, I
don't have to implement every file object method to create or use an
object to replace sys.stdout - just having a "write" is enough. This
contributes to more efficiency during prototyping and interative
development. And as you continue to build out, it isn't really that
much effort to ensure that you conform to the interface.
But I do admit that some additional built-in method of indicating
interfaces supported by a class might be nice. Of course you can
probe for whatever set of functions you may need if you are the user
of the class, but it would be nice to encapsulate a set of probes
based on an interface definition - or something along those lines.
I'm not that familiar with it, but Ruby's approach of including
modules into classes (where the module is basically the interface
definition) seems interesting.
Huaiyu Zhu
wrote:
>
>> Suppose you needed a file object to connect to some chunk of memory. In
>> other languages, you would need to inherit from the Python file object
>> in order to ensure that random functions that expect file objects would
>> still work. In Python, that's completely unnecessary. It's probably a
>> lot simpler to create your own class, complete with open(), close(),
>> read(), and write() methods -- and because you've maintained *interface*
>> consistency, you can use your new class *ANYWHERE* a file object would
>> go.
>> --
>
>like a fileobject. For instance if you don't note that you forgot to write the
>write()-function.
>In a worst case scenario it works for many months until a user calls a function
>in which
>the write() -function is needed.
>
Here's one example why not forcing complete interface compliance may be a
good thing:
In the matrix for python project I've just added a bunch of statistical
distribution classes, each of them supposedly provide cdf, pdf, rand and
other methods. Each method is a simple wrapper around some library function
but to do them all takes time. So I only added the easier ones and the ones
I may need shortly. I can already use them now, and the project goes along.
If each one had to confirm to a final complete interface specification the
whole thing might have been put off for a long time. If a user wants
something more he can easily add the missing pieces or ask me to do so. You
may say that when a project is finished everything should be there and
working, but my list of everything has an infinite length.
Now it could be nice if there were a tool that flags the not-implemented
parts and put them into a TODO list. For example it could give todo=['B.b',
'B.c'] from the following example:
class A:
def a(): raise NotImplementedError
def b(): raise NotImplementedError
def c(): raise NotImplementedError
class B(A):
def a(): pass
I'm not sure if this is feasible in general, but even a half-hearted job
would still be helpful.
Huaiyu
PS. The stats classes are only in the latest CVS version as I added them
last night.
--
Huaiyu Zhu hz...@users.sourceforge.net
Matrix for Python Project http://MatPy.sourceforge.net
Gordon McMillan
>Aahz Maruch wrote:
>
>> Suppose you needed a file object to connect to some chunk of memory.
>> In other languages, you would need to inherit from the Python file
>> object in order to ensure that random functions that expect file
>> objects would still work. In Python, that's completely unnecessary.
>> It's probably a lot simpler to create your own class, complete with
>> open(), close(), read(), and write() methods -- and because you've
>> maintained *interface* consistency, you can use your new class
>> *ANYWHERE* a file object would go.
>> --
>But there is no mechanism to ensure that the behaviour of your
>memfileobjectsis like a fileobject. For instance if you don't note that
>you forgot to write the write()-function.
>In a worst case scenario it works for many months until a user calls a
>function in which
>the write() -function is needed.
And there's no mechanism to ensure that you have the behavior right in C++,
even if the compiler accepted your interface.
Except good test cases, that is.
- Gordon
Moshe Zadka
> Michal Vitecek wrote:
> > this is highly debatable - properly written C/C++ source is pretty well
> > readable and self-documenting. similarly, badly written python source
> > makes it as unreadable as in other languages - there's not a point in
> > trying to prevent people from writing (un)readable source code.
>
> It's harder to write unreadable Python source because you can't write code
> like, hmm,
>
> opendir(FOO,\"%s\");@files=readdir(FOO);foreach (@files) { if
> (/^[^\\.].*\\.txt$/) { print \"%s/$_\\n\";};};closedir(FOO);
import os,re
for _ in os.path.listdir("%s"): if re.match("^[^.].*\.txt$': print(
"%%s/%(_)s" % vars())
writing-obfuscated-python-isn't-that-easy-ly y'rs, Z.
--
Moshe Zadka <mos...@math.huji.ac.il>
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
Rainer Deyke
news:8i7frt$o02$1...@sunnews.cern.ch...
> "Rainer Deyke" <ro...@rainerdeyke.com> writes:
> >This statement is both incorrect and misleading.
>
> Bold words.
>
> >Incorrect because there
> >may be other requirements: for example, std::set (along with several
others)
> >requires that operator< and operator== are defined for the object.
>
> Nonsense. You can specialize std::set with your own version of comparison
> class instead of the standard less and you can make sure that your version
> of it does not require said operators.
True, but writing your own comparison class is at least as much work as
implementing operator <. Besides, IIRC you still need operator ==.
> >Misleading because for many classes the compiler generated functions
cause
> >incorrect behavior.
>
> As I have explained in another post, 'many' is only true for buggy code
> that is not exception safe.
For some values of 'many'. Smart pointers can help, but the smart pointer
classes themselves almost always need explicit copy contructors and operator
=, and if you deal with a variety of objects and resources you'll need a
variety of smart pointers. For example, COM objects would need their own
smart pointer class. Then there are classes for which copy and assignment
operations simply don't make sense - nodes in a linked list for example (and
don't tell me to use STL for linked lists - this was only an example).
> Of course, your statements only underline the original point, that is,
that
> the STL is to difficult to use for C++ novices. However, although it has
> its flaws, the STL is well designed and all the simple things have been
> taken care of real good.
I actually agree with this.
--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware action/role-playing games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Tim Rowe
<E0C8C2A9B34C2EF9.8F6C18C4...@lp.airnews.net>,
cla...@starbase.neosoft.com (Cameron Laird) wrote:
> On the other hand, I'm still searching for the best
> way to speak about the "well you Python people only
> find those errors at run-time" objection.
Ask them why C and C++ are deprecated for safety critical applications.
It's essentially because C and C++ programmers only find errors at
run-time, too. The difference is that Python programmers know it and
account for it.
David Bolen
> I'm not sure if this is feasible in general, but even a half-hearted job
> would still be helpful.
How about just writing a function to verify methods against a
reference class. The reference class could either be an actual class
that you are mimicing the interface for, or a dummy class that is just
defined with the appropriate methods.
For a crude quick example, perhaps something like:
class MyInterface:
def method1():
pass
def method2():
pass
def method3():
pass
class MyImplementingInterface:
def method1():
# Actual method 1 implementation
pass
def method3():
# Actual method 3 implementation
pass
def verify_class (Reference, Instance):
import types
print "Checking %s for conformity with interface %s" % \
(Instance.__name__,Reference.__name__)
for curmethod in Reference.__dict__.keys():
if type(Reference.__dict__[curmethod]) == types.FunctionType:
if (not Instance.__dict__.has_key(curmethod) or
type(Instance.__dict__[curmethod]) != types.FunctionType):
print "Method %s not supported" % curmethod
if __name__ == "__main__":
verify_class(MyInterface,MyImplementingInterface)
when run, yields
Checking MyImplementingInterface for conformity with interface MyInterface
Method method2 not supported
I'm sure there's lots more that could be done - the dummy interface
class might provide special members to control optional functions, or
an interface could just be specified as a list, or you could also try
to check the signature of the function, etc...
David Bolen
> Now only if somebody could enhance that to check inherited methods too (the
> "more general case"). That is, if a method is not found, go recursively
> into the superclasses. The following example is not correct at the moment:
Ah, good point - try this variant - I switched to getattr() which
takes the inheritance into account (you could also write your own
recursive function that used Instance.__bases__ to look in the
superclasses).
Note that the object returned by getattr() is a method, whereas the
raw dictionary object is just a function, so there's a small change in
the type comparison. I'd be interested if anyone more familiar with
the introspective/metaclass features of Python might have a cleaner
way to identify the class member functions:
def verify_class (Reference, Instance):
import types
print "Checking %s for conformity with interface %s" % \
(Instance.__name__,Reference.__name__)
for curmethod in Reference.__dict__.keys():
if type(Reference.__dict__[curmethod]) == types.FunctionType:
try:
if type(getattr(Instance,curmethod)) != types.MethodType:
raise TypeError
except AttributeError, TypeError:
print "Method %s not supported" % curmethod
which for your test cases yields:
>>> verify_class(MyInterface,MyBase)
Checking PostBase for conformity with interface PostInterface
Method method3 not supported
Method method4 not supported
>>> verify_class(MyInterface,MyDerived)
Checking PostDerived for conformity with interface PostInterface
Method method4 not supported
Michael Hudson
> On Wed, 14 Jun 2000, Eric Lee Green wrote:
>
> > Michal Vitecek wrote:
> > > this is highly debatable - properly written C/C++ source is pretty well
> > > readable and self-documenting. similarly, badly written python source
> > > makes it as unreadable as in other languages - there's not a point in
> > > trying to prevent people from writing (un)readable source code.
> >
> > It's harder to write unreadable Python source because you can't write code
> > like, hmm,
> >
> > opendir(FOO,\"%s\");@files=readdir(FOO);foreach (@files) { if
> > (/^[^\\.].*\\.txt$/) { print \"%s/$_\\n\";};};closedir(FOO);
>
> import os,re
> for _ in os.path.listdir("%s"): if re.match("^[^.].*\.txt$': print(
> "%%s/%(_)s" % vars())
But that doesn't work:
>>> for _ in os.path.listdir("%s"): if re.match("^[^.].*\.txt$': print(
File "<stdin>", line 1
for _ in os.path.listdir("%s"): if re.match("^[^.].*\.txt$': print(
^
SyntaxError: invalid syntax
> writing-obfuscated-python-isn't-that-easy-ly y'rs, Z.
Indeed.
or-was-that-your-point-ly y'rs
Michael
--
SCSI is not magic. There are fundamental technical reasons why it
is necessary to sacrifice a young goat to your SCSI chain now and
then. -- John Woods
Huaiyu Zhu
>
>How about just writing a function to verify methods against a
>reference class. The reference class could either be an actual class
>that you are mimicing the interface for, or a dummy class that is just
>defined with the appropriate methods.
>
>For a crude quick example, perhaps something like:
>
>
> import types
>
> print "Checking %s for conformity with interface %s" % \
> (Instance.__name__,Reference.__name__)
>
> for curmethod in Reference.__dict__.keys():
> if type(Reference.__dict__[curmethod]) == types.FunctionType:
> type(Instance.__dict__[curmethod]) != types.FunctionType):
Cool! Things always look easier in python. :)
Now only if somebody could enhance that to check inherited methods too (the
"more general case"). That is, if a method is not found, go recursively
into the superclasses. The following example is not correct at the moment:
------------------------------------------------------------------
class MyInterface:
def method1(): pass
def method2(): pass
def method3(): pass
def method4(): pass
class MyBase:
"Actual implementations"
def method1(): pass
def method2(): pass
class MyDerived(MyBase):
"Actual implementations"
def method1(): pass
def method3(): pass
if __name__ == "__main__":
verify_class(MyInterface,MyBase)
verify_class(MyInterface,MyDerived)
print MyDerived().method2
------------------------------------------------------------------
gives
Checking MyBase for conformity with interface MyInterface
Method method3 not supported
Method method4 not supported
Checking MyDerived for conformity with interface MyInterface
Method method2 not supported
Method method4 not supported
<method MyBase.method2 of MyDerived instance at 80cb550>
Russell Wallace
>
> > I have read in several places productivity claims of 5 to 10 times over
> > 'C' and "C++". I would like to ask for some feedback from "C++"
> > programmers who have moved to Python as to whether these estimates are
> > realistic.
As someone who uses and likes both C++ and Python, I think estimates
like that are excessively simplistic.
I use C++ for commercial programming, because it gives me the power and
control I need. Productivity isn't the best when measured in time to
get the first prototype running, but I've found nothing better when
measured in time to develop, deploy, maintain and support something a
customer will pay for.
I use Python for scripting/prototyping/AI research stuff. (Used to use
Scheme for some of it, but never liked the syntax.) I find it gives a
substantial productivity advantage over C++ - nowhere near an order of
magnitude, but enough to be well worth having - because it does a lot of
things for you, or at least makes them more convenient.
The-right-tool-for-the-job-ly yrs,
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mailto:rwal...@esatclear.ie
http://www.esatclear.ie/~rwallace