Python Productivity over C++

[Ken Seehof]

"Frank V. Castellucci" wrote:

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

I doubt that.  Your python code is probably much cleaner than most C++ code I've seen over
the years. :-)

Well it seems like there are less ways to be messy in python, but my knowledge of set
theory (enumeration of infinite sets, etc) is insufficient.  Both languages allow an
infinite number of ways to be messy, assuming unbounded memory capacity.  The same could be
said of assembly vs. C++.  There are just as many ways to be messy in C++ as there are in
assembly.

I've been coding C++ since it first arrived, and I consider my C++ code to be relatively
neat and robust.  And yet, my first major python project is less messy, required less
planning, and seems to be more robust than recent C++ projects of similar or smaller
scope.  Python code that I have downloaded has generally been of exceptional quality
(unlike the vast majority C++ source code, free or otherwise).  This shouldn't be
surprising.  High level languages are typically less messy than low level languages.
Otherwise we should all just go back to assembly (except when we need portability).

Unfortunately I don't have any quantatative data on the subject.  Does anyone reading this
know of any relevant studies.

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

Actually I consider my C++ to be of very high quality.  It's just not as good as my python
code.  There are situations in C++ where one has to choose between different kinds of
messiness, but can't avoid messiness altogether, especially when integrating with multiple
external modules.  C++ lets you encapsulate messiness, but those extra layers are another
form of messiness.

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

It is possible for a C++ programmer to use techniques specific to C++ in order to increase
robustness, reduce maintenance and be more resiliant to change than other C++ programs.  In
the ultimate case, a C++ program could be 100% robust, have very low maintenance cost, and
be extremely resiliant to change.  However, this is not likely to happen on a tight
schedule with a random team of programmers.  It is more likely to happen with python under
similar conditions.

> 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

--
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/e4a0d95b/attachment.vcf>