Python Productivity over C++
Frank V. Castellucci
frankc at colconsulting.com
Fri Jun 16 08:31:36 EDT 2000
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
More information about the Python-list
mailing list