Python Productivity over C++

[Frank V. Castellucci]

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

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.

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.

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.

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