Python Productivity over C++

[Ken Seehof]

"Frank V. Castellucci" wrote:

> Ken Seehof wrote:
> >
> > "Frank V. Castellucci" wrote:
> >
> > > Courageous wrote:
> > > >
> > > >
> > > > > As someone who uses and likes both C++ and Python, I think estimates
> > > > > like that are excessively simplistic.
> > > >
> > > > Me, too. And yet I will claim that I've become *more* productive
> > > > in Python after a brief 4-6 weeks of use than I am in C++ after
> > > > 15 years of use, and that's no exaggeration. If Python executed
> > > > as fast as other languages, I'd be tempted to *require* that our
> > > > staff use it. And please don't take this wrong; I'm no language
> > > > groupie -- I use C, C++, Java, Python, and Lisp -- all of them both
> > > > lately and frequently.
> > > >
> > > > > 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.
> > > >
> > > > Shrug. If it weren't for execution speed, your C++ environment would
> > > > be toast. Admit it. :)-
> > >
> > > While the last line seems rather toungue in cheek, there are other
> > > things that C++ brings to the table such as encapsulation, access
> > > control and type strictness.
> >
> > All three of these items were intentially left out of python because python
> > would not benefit from them, though C++ does.
> >
> > "Frank V. Castellucci" might have written (but actually didn't):
> > > A fish has certain definite advantages over a duck.  For example a fish has
> > gills.
>
> I didn't so it came from elsewhere.

I made it up.  That was a deliberate witty attempt to put words in your mouth :-)

> > Encapsulation, access control and type strictness are often erroneously
> > referred to as if they were features.  They aren't.  They are aspects of a
> > design philosophy.  To make a system less error prone, constrain the programmer
> > in order to prevent the programmer from writing bugs.  Of course, that's
> > impossible, since it is always possible to write bugs anyway.  Because C/C++
> > are extremely error-prone languages, they need stuff like encapsulation,
> > access, control and type strictness.  Because python is less error prone, it
> > doesn't need these "features".  Python is based on different philosophy: To
> > make a system less error prone, make it simple.
> >
> > You have to ask, "what is the actual value of these features?"  The answer is
> > that they prevent certain kinds of bugs from appearing.  Now ask, "what bugs
> > would a C++ programmer encounter if encapsulation, access, control and type
> > strictness were removed from C++."  Undoubtedly it would be a mess.  Get a
> > picture in your mind of these bugs.  Now ask a python programmer how often
> > these kinds of bugs come up.  Answer: "can't remember that ever happenning!"
> >
> > Look at the big picture.  Do encapsulation, access control and type strictness
> > really make C++ really less error prone than python?
>
> Somewhere in your conversation you went from the aspects of a particular
> language, while true they do reduce errors because the language is still
> low level enought to let you get in trouble, to implying that they were
> put in there to make a system less error prone. You then finish with
> justifying a position based on this posit.
>
> I disagree with the postulation.

My point is that encapsulation, access control and type strictness are relevant in a
comparison between C++ and python if they produce a specific advantage in C++ over
python that would make C++ preferable for some task.  My assumption is that
encapsulation, access control and type strictness produce robustness in C++, which
would be relevant if C++ were more robust than python as a result, which it isn't.

> Before these articles of disagreement, C had (and still does)
> structures. Systems built in C can be a mess, or not. That is based on
> the talent and experience writing the code. Python does not prevent you
> from writing "messy code", it just reduces the potential devastation
> caused by messy code. Python has the ability to hide data, you just use
> a different notation for the variable in the class. Python has the
> ability for type strictness, but you have to code it by hand as it is
> not a feature of the grammer.

Python doesn't /prevent/ messy code, but all other things being equal, it is easier
to write python code that is less messy because it's a simpler language. Typical ways
to be messy in C++ include: inconsistent choice of integer types and other basic
types, poor indentation practices, excessive abstraction layers, class inheritance
messiness, preprocessor messiness, etc.  Python has fewer basic types, no choice
about indentation, less need for abstraction layers, cleaner inheritance system and
less need for inheritance, and no need for a preprocessor.

Python is less messy /and/ messiness is less devastating in python.

> My original response was to the (lite hearted) statement that the only
> thing C++ brings to the table is execution speed. I will posit that
> languages for a solution space should be used that appropriatley address
> the design requirements. It ain't all C++, and it ain't all Python.

Agreed. So the question becomes: What are the relevant characteristics of the problem
spaces and corresponding characteristics of the candidate languages?  The best answer
I have so far is that python is a high level language and C++ is a low level
language, and that the two languages work well together.

> And the most original point of all these discussions was for
> qualification of productivity between the two languages. To which I
> still respond that if we measure productivity by the amount of time it
> takes to produce identical functionality (in something a bit more
> complex than "hello world") I would say Python.

Agreed.  Of course, python wins the "hello world" contest too. :-)

> I also believe that the larger the project, the more diminished the
> return on this particular measurement. Complexity takes it's toll on any
> language.

> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package

In my experience, complexity takes less of a toll on python because it is a higher
level language.  I find that when I write a module in python, I tend to make it
behave as a component (i.e. having minimum dependency issues).  More often than not,
these components can be separately posted on Parnassus and used (hopefully) in
unrelated projects.  Component programming is extremely good for making robust large
scale projects.

In C++, which I've been using for much longer, I tend not to componentize quite as
well.  As a result, my code tends to hang together on a large scale in python quite a
bit better than in C++.  In addition, the small scale advantages hold true for large
scales projects as well.  So IMHO, based on experience, pythons productivity
advantages relative to C++ tend to increase as the project gets larger and more
complex.  The advantages of C++ tend to be more significant on a small scale.

Specific features, such as the requirement that one use semicolons, don't amount to
much unless they produce characteristics that differentiate between languages.  So
the real question is, what characteristics does C++ bring to the table, and for what
kind of jobs do these characteristics make C++ the better choice.  IMHO, C++ brings
speed and legacy to the table, so I use C++ for high speed components within a python
project, and for integration of legacy software.  Maybe it brings other things as
well, but I don't know what they would be.

The question of which language scales better is very important.  If C++ scales
better, python should perhaps be used primarily as a scripting language within C++
applications.  On the other hand if python scales better, C++ should primarily be
used for high speed components within python applications.

--
Ken Seehof
kens at sightreader.com
starship.python.net/crew/seehof
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kens.vcf
Type: text/x-vcard
Size: 343 bytes
Desc: Card for Ken Seehof
URL: <http://mail.python.org/pipermail/python-list/attachments/20000615/39376e9d/attachment.vcf>