Python Productivity over C++

[Frank V. Castellucci]

Ken Seehof wrote:
> 
> "Frank V. Castellucci" wrote:
> 
> > Ken Seehof wrote:
> > >
> > > "Frank V. Castellucci" wrote:
> > >
> > > > Courageous wrote:
> > > > >[snip]
> > > > > 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 :-)

Well the words in my mouth did make me witty, when I tried it out on my
son he said "Your a dimwit", so find something better for me please as I
am loosing ground here.
 
> > > 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.

I have found that encapsulation and type strictness are useful in class
libraries. If we consider invarient state in line with B. Meyer, I have
some insurance that the inner workings will continue to do so without
fear of change. And I know that the user can change this by changing the
code, but that is the same everywhere no? I enjoy and employ development
by contract, if you use the class then you agree to it's interface, and
you agree to use it as such.

But more to your point, I won't argue over robustness advantages because
the argument goes both ways and therefore cancels itself out. In my
dimwitted view anyway.
 
> > 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.

I would say that the enumeration of what in C++ allows one to get messy
are vast. I would also say that experience has a tendency to cancel
these things out as "newbie" mistakes, or a poor design.

Like with any language, Python can be messy. There are not less ways to
be messy in Python, there are just different ways. As I am pretty much a
neophyte in the Python ways (but trying to come up to speed), a review
of any code I have written by someone like yourself would probably
elicit the statement "Well, thats a wee bit messy lad". 

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

I would add to this that the protection the interpreter sandbox offers
has value, although the 'C/C++' or other language extensions are not
protected there. 

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

I would be curious to know how large scale Python applications fare
(defects per release, etc.) but I (in my newbie Python suit) am not yet
aware of the really big projects (Zope? - ignorance disclaimers apply).
 
> 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.

Just remember you are unique, just like everyone else. <grin> (Now thats
witty, although I can't claim it).

But seriously, your habits are not neccessarily the standard are they?
You could do a better job with your C++ work, if you elect to.
 
> 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.

As I said earlier, I believe you can be more productive in Python
(although I acutally need to be so first before I commit totally to that
opinion). But I also know from experience that in addition to speed, C++
can be used in a very clean way to take advantages - To increase the
robustness of the deliverables. If done right, it reduces maintenace
cost, as well as more resiliant to change. I am not saying Python isn't,
just that C++ is also.

The net of all of this will be that there are different views for the
two from different people.
 
> 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.

I don't know if I posed it more as a question or a tenet of large
systems. See my large system question earlier in this missive.

-- 
Frank V. Castellucci