[Python] I come not to bury C++, but to praise it...

"John Benson" wrote in message...
Apples and oranges; there are lots of things C++ does better than
Python (or Java) and vice versa. There are lots of factors to
consider, not just the "smoother ride" up the learning curve.

You also seem to have a narrow view of C++ as a strictly OO language
when in fact it supports several programming paradigms (write whatever
you want: template metaprograms, modules, procedures, classes, etc.).

And while C++ may seem "traditional" compared to fast-moving
feature-of-the-week-rich languages, stability can be a Good Thing.

That being said, I'm a big fan of Python (and even Java), but I think
writing a eulogy for C++ is a bit premature.

C++ is rather similar to Python in this respect. ;-)

I currently have two languages that I regularily use: C++ and Python. C++
produces faster programs, gives direct access to the hardware, and has many
third-party libraries that Python doesn't have. Python is more concise,
more flexible, safer, and has its own set of libraries that C++ doesn't
have. Both have their place. None of the other languages I've looked at
(with the possible exception of Common Lisp) seem to offer me anything that
I can't find in either Python or C++, and many of them (Java in particular)
are far too restrictive for my taste.

I also use C++ and Python as my main languages and I agree with your
comments. However, I don't agree that Python is inherently "safer"
than C++. At best I see it as a tie. For example, C++ let's you
corrupt memory among other "unsafe" things, most of which can be
avoided by using standard containers, smart pointers, etc. Python
lets you do "unsafe" things such as passing an object to a function
when it makes no sense to do so, which can lead to nasty runtime
surprises.

A traceback is *much* less nasty than memory corruption. One stops the
program immediately and shows you exactly where the problem lies, the other
may let the program run for quite a long time before simply causing the
process to die, leaving few clues as to the source of the problem.

Python may not be *completely* safe (indeed, memory corruption is still
possible due to bugs in the interpreter and extension modules), but it is
quite a bit safer than C++.

Jp

A traceback is also much less nasty than deciphering a 1000-character
long compiler error message reported in code that uses a heavily
templated library.

Oren

Absolutely correct. But remember that ugly template-related compiler
error messages are a reflection of current compiler technology, not a
fundamental limitation of C++. I suspect future compilers will make
debugging templates much easier.

I believe I heard that claim, almost verbatim, sometime around the last time
I was actively using C++, which was about a decade ago...

-Peter

Peter> Derek wrote:
Peter> I believe I heard that claim, almost verbatim, sometime
Peter> around the last time I was actively using C++, which was
Peter> about a decade ago...

Yes, C++ doesn't suck, it's the implementations. C++ will rock any day
now. Honest.

The same is true for Python - Python isn't slower than C, it's just an
artifact of the current implementation. Python-in-the-sky actually
runs 10-20% faster than C++ code.

Hmmm. As late as 1997 I couldn't get consistent template behavior
between BCC, GCC, and MSVC. To this day most compilers are broken in
some way or other with respect to templates. Even basic STL
containers like std::vector were often improperly implemented or
incomplete just a few years ago (try GCC 2.95 or VC6 to see what I
mean). I also don't remember typelists, traits, policies, or other
modern template techniques being popular a decade ago.

My point is that while templates aren't new, their widespread use is.
I'm not surprised that compiler vendors are only now looking at ways
to improve template-related compiler errors.

In article <bu3khe$dbm5v$1 at ID-46268.news.uni-berlin.de>,
Derek wrote:
.
.
.
We disagree on some matters.

I *do* regard Python as inherently safer than C++, and much more so.
My aim for now is not to persuade you to my view, but only to make
it explicit. Memory management, and mismanagement, as mundane as it
is, is so poorly applied in so much of the C++ code I see, that it
swamps all other dimensions of comparison between the two languages.
I quite agree with you that competent C++ programmers should exploit
smart pointers and so on. My experience is that, somehow, C++ as
it's generally practiced appears to have barriers to their use.

I don't understand your last sentence, and, given my own focus on
reliability, I very much want to understand it. Are you alluding
precisely to Python's dynamic typing, and observing that, as earlier
is better, C++'s compile-type checks beat Python's run-time checks?

In article <100aq779r2h2c9e at corp.supernews.com>,
claird at lairds.com (Cameron Laird) wrote:
Your wording is precise enough that your question could have
been better. Note "compile type checks" vs. "run-time checks" -
a difference not only in when, but what. There's more to it
than "earlier is better".

Donn Cave, donn at u.washington.edu

In article <donn-DF9867.09340714012004 at nntp3.u.washington.edu>,
Donn Cave wrote:
.
.
.
Great! *What* more? When I look at Python and C++, I see the
former as having *stricter*, if more dynamic, typing, so I don't
understand what advantage C++ has in this one regard apart from
time-of-detection.

I apologize, by the way, for writing "compile-type" where I
intended "compile-time".

In article <100b266i0r70g86 at corp.supernews.com>,
claird at lairds.com (Cameron Laird) wrote:
...
Oops, so that was only an accident! Well, I mean that
the semantics of types are different between C++ and
Python.

When we say Python has "dynamic typing", and C++ has
"static typing", I guess that's the generally accepted
way to describe what they do, but it makes it sound
like they're doing the same thing, only on a different
schedule. Of course they are not at all doing the same
thing. It might be more accurate to use a table, like

static dynamic
C++ yes no
Python no yes
Objective C yes yes


Python may have stricter dynamic typing than C++ has
static typing, but that's hard to quantify. On the
other hand, Python has no static typing at all. There
is no way to tell it ``this function must be applied
to a string and must return an int.'' If applied to
a list instead, there's a non-trivial chance it will
manage to do something absurd with it. If it returns
None under certain circumstances, there's a non-trivial
chance that value will be stashed away somewhere and
you'll later wonder where the heck that None came from.

Whether that's an advantage for C++ depends on 1) how
important you think that is, and 2) how well you think
C++ does it. Between those two, I think I'd have to
agree it isn't much of an advantage, but then I'm just
a hacker. Of course C++ is an easy target, but then
that's the nominal subject here.

Donn Cave, donn at u.washington.edu

You clearly don't know enough of python to talk like this about the
language features...

You need static typing (why then... I cannot see any good reason,
anyway...)? Well then, use pyrex. You'll find yourself writing code
like this:

cdef int a, b
def sum(int a, int b):
return a+b

Then using pyrex parser you would build a python extension module
which you will compile it. If you do errors using types it will catch
it. Anyway there's no need to use this stuff... absolutely no
reasonable need. Except if you need a lot of speed and you need to
implement an algorithm directly in C using native C types and not
python objects.

I see your point and -- despite my original post -- I agree with it.
Reflecting on my own experience with C++, I agree that C++ does not
seem to make writing safe code as easy as it should, at least for the
uninitiated. Standard containers (eg, vector, list, map, etc.) don't
get used as much as they should. Robust smart pointers (eg,
boost::shared_ptr) seem to get used even less. In terms of memory
management, Python does seem safer.
Yes, I prefer compile-time checks to run-time checks. I don't know
which method is "better" by any objective measure, but I prefer to
know if there is a problem as early as possible. It's not hard to
make a change in Python that will go unnoticed until much later, and
in the real world test suites often don't have enough coverage to
catch every runtime error up front.

In article <bu3vku$den0t$1 at ID-46268.news.uni-berlin.de>,
Derek wrote:
.
.
.
Got it; thanks. There's been extensive discussion here and elsewhere
on just this point. One of us might follow-up in a bit with a refer-
ence to highlights ... While I spend most of my time in the Trotskyite
fringe of those who proclaim that Testing Is The Answer, and that
compile-time checks count for little, I'm deeply sympathetic with the
anguish of letting the latter go. 'Fact, I just spent the morning do-
ing "-Wall" to yet another corpus of unsanitized code, and *I* feel a
lot better for it.

[...]

http://www.artima.com/weblogs/viewpost.jsp?threadF39

http://www.mindview.net/WebLog/log-0025

(important: Bruce Eckel says "weak typing" where he really means
"dynamic typing")

(next two are from this group, both threads and the particular posts
quoted are picked pretty much at random, except that I search for Alex
Martelli's posts, which are reliably good)

http://www.google.com/groups?selm=ft6tb.21351%249_.767461%40news1.tin.it&rnum=1

http://www.google.com/groups?selm=pNfIa.206219%24g92.4232233%40news2.tin.it&rnum=2

The last one (above) is part of an argument between Alex and David
Abrahams, both C++ experts and well-known Pythonistas, but on opposite
sides of the debate.


John

"Derek" <none at none.com> writes:
[...]
It would certainly be better if Python had some kind of optional
static type checking (though that seems unlikely to happen). Many
people (eg. Alex Martelli in this group) have argued that requiring
*everything* to be statically checked is harmful because of the cost
it imposes in terms of inflexibility and lines of code.

The argument runs like this: If you don't have near-100% test
coverage, you are missing many bugs that static typechecking will not
catch. So don't do that (the fact that it's perfectly feasible to
have near-100% coverage, when given support from bosses where
relevant, has been repeatedly demonstrated recently). OTOH, if you do
have 100% coverage, the set of bugs that *are* caught by the static
typechecks, but *not* by the tests is usually very small, in practice.
So, you can catch bugs by introducing static checks, but you introduce
*even more* bugs (so the argument runs) if you pay the cost (see
above) of static checking for *everything*, as you must in C++. So,
though Python beats C++ here, the even-happier medium is achieved with
systems like the static type-inference of ML and Haskell. Whether
this argument holds in general is hard to answer, but in the
particular case of C++ and Python, I find it extremely persuasive.


John

There is a subtle fallacy in this argument, at least in the context of C++
and Python, namely that there is a significant category of errors that
static type checking (as C++ and some other languages do it) can detect but
can escape even 100% test coverage.

Before you get out your flame-thrower, please hear me out -- I am not saying
that this reasoning applies to all errors, or even a majority of them, but
only to a significant category. That category consists of programs where
the types of key objects are not known when the program is written, but are
known when the program is compiled.

Here's an example. Suppose you're writing a library sort function, which
you intend to be able to work with any kind of sequence. Suppose further
that you test it only with vectors. Then you might well have 100% test
coverage, but the code might break when you call it with another kind of
sequence, because it relies on some property of vectors that not all
sequences share.

In practice, C++ programmers often solve such problems by using templates,
which defer type checking until the last possible moment during the
compilation process. In effect, the compiler looks at each call to our
hypothetical sort function, and verifies that the type assumptions that the
sort function makes are valid in the context of that particular call. The
result is that the compiler can detect type errors that would show up in a
dynamically typed environment only if the function were tested with the
specific types that revealed the error.

The price one pays for this extra checking, of course, is that one cannot
call such a sort function with an argument with a type that is known only at
run time. But in practice, there are many cases where being able to defer
type checking until the end of compilation is just as useful as being able
to defer it until run time. I believe that many people who dislike static
type checking are unaware of this distinction.

It may be subtle, but it's also the starting point for most of these
debates.

OK... :-)

Agreed.

[...snip example...]
Yes.

I do like static type checking. I *don't* like the price that C++
makes me pay for it in terms of lines of code and inflexibility. When
comparing Python and C++, the longer, more inflexible programs
required to solve problems in C++ introduce more bugs than its static
typechecking system removes. It's a shame some tiny fraction of the
trillion dollars recently allocated to George Bush's electoral
campaign <0.2 wink> can't be diverted to experiments to test this
hypothesis (but I guess those dollars are mostly fictional anyway ;-).

So, I think the various interface proposals that have been made for
Python are interesting. Also, it seems attractive to have static type
inference wedged into Python somehow (not holding my breath: I don't
even know if that idea really makes any sense in the context of
Python). But I see Python in its current state as a safer language
than C++.

Alex Martelli goes much further than I do:

http://www.google.com/groups?selm=ft6tb.21351%249_.767461%40news1.tin.it&rnum=1

[...]
And perhaps he's right: my attraction to static type inference in a
Python-like language is both theoretical and almost maximally vague
(and my grasp of the issues is weaker than Alex's), and I don't have
any decent ML or Haskell experience with to compare with my Python
experience...

See also the couple of posts near this article in the exchange between
Alex and David Abrahams (same one I posted in a followup to Cameron
earlier):

http://www.google.com/groups?selm=pNfIa.206219%24g92.4232233%40news2.tin.it&rnum=2


John

Maybe I didn't make myself clear. I counted the ease with which
memory can be corrupted in C++ as a minus for C++ and a plus for
Python. I agree with you.

On the flip side, C++ can catch errors immediately that Python will
not complain about until runtime, and in this imperfect world tests
may not catch all such errors up front. In this respect I consider
C++ safer.

"Derek" <none at none.com> writes:
[...]
No, you don't (assuming I understand Jp's post), because...

...you made no evaluation of the relative importance of these two
qualities (memory-safety and static type-safety). Nor of the fact
that C++ comes unavoidably packaged with the more-lines-of-code-per-
function-point anti-feature -- KIS!


John

"John J. Lee" wrote...
Are you joking? Because if you have some magical way to assign a
meaningful relative importance to unrelated language features that is
sufficiently general to be useful, I'd like to hear it.

For *me* memory safety in C++ is not an issue. I use range-checked
containers, scoped pointers, shared pointers, etc. and don't encounter
memory management/safety problems.

For *me* the lack of static type safety in Python is an issue. We
have a lot of developers working on a relatively large Python
codebase, and sooner or later some edge case calls a function with an
argument who's type makes no sense. Sometimes tests catch the problem
early, sometimes they don't.

No.

(No funny business here, just straightforwardly trying to answer your
question to advance the debate:) Well, yes, I do: I think about it
rationally, just as you do. I think about the "unrelated" language
features (though I suppose few language features are truly unrelated),
consider their impact on things like detection and location of bugs,
and make a judgement about how they, as a result, affect the success
and costs of the development process.

I'm afraid I'm probably completely missing what you're getting at
here, though! (again, not trying to make any rhetorical point, just
puzzled)

For the particular issues at hand, Jp made an evaluation that looked
quite rational to me, as do your comments immediately below.

Oh. That's interesting. Do those practices get rid of all such
issues?

Yes, many people -- including me! -- agree on this, I think (but not
everyone -- see the quote from Alex Martelli in my reply to Andrew
Koenig). The question is one of the relative sizes of the various
costs and benefits, and of the way those costs and benefits are tied
to each other in current languages. If only we could pick language
properties a la carte...

I think we've been round this loop already. Schematically, though:
Static typechecking tests reliably for a small set of bugs. Unit
testing tests unreliably for a very large set of bugs. No controversy
so far, I hope. Now, the bugs found by unit testing are in practice
almost a simple superset of those found by static typechecking
(clearly, this point can generate much debate!). C++ buys you static
typechecking (gain: a small number of bugs found that your unit tests
miss), but also buys you a big jump in lines of code (loss: many extra
bugs created (amongst other losses)). I don't argue that this is a
fundamental limitation of static typechecking, or that Python is the
best of all possible worlds. I do claim that Python achieves a net
gain in safety over C++ by dropping the naive static checking found in
C++.


John

What I meant by "safer" is that the worst thing that usually happens in a
defective Python program is that it terminates with an exception, complete
with traceback. A defective C++ program can do a lot worse.

Thanks for the considerate (and temperate) responses to my C++ post. I know
that language advocacy is particularly flame-prone, and find the responses
informative. Who knows? I might even change my mind about C++! But I suppose
that that's one of the dangers of participating in a dialogue.

I normally try to avoid posts based on

sprintf("All the cool guys use %s because %s\n", Myfavoritelanguages,
Mylimitedexperience)

but I most definitely fell into that trap this time around.

Very good! I hope that that's not under copyright, I plan to use it.

Dave

"John Benson" <jsbenson at bensonsystems.com> wrote in message
news:mailman.337.1074032524.12720.python-list at python.org...
Perhaps you should cast around for a different C++ book while you're at it,
too -- maybe the one you found isn't well suited to your particular learning
style.

Andrew's own "Accelerated C++" is good (written with Barbara Moo). :-)


John

John, thanks for the reminder about the origins of C++. (I suspect the majority
of readers in this group were not even programming during the CFront era
(roughly 1983-85?), and a history lesson is always good from time to time.)

I remember C++ as a welcome enhancement which allowed me to extend the
scope of several large C projects without significantly affecting their
complexity. Over the years I gradually found C++, especially as a result
of its ongoing evolution, to be negatively affecting my development instead,
however, and I was happy to finally move on to the more modern languages
which software engineering has produced in the over 20 years since C++ came out.

-Peter

P.S.: Found http://merd.net/pixel/language-study/diagram.html while researching
the timing on C++' conception... interesting, and might be nice wallpaper for
some.

In article <40055560.7A0DCD0D at engcorp.com>,
Peter Hansen wrote:
.
.
.
.
.
.
I was still fussing with cfront in the early '90s.
Its era *had* passed by then, though.

And I actually went looking for it again as recently as two years
ago, considering the possibility of using it to allow the use of
C++ code for a small embedded processor which did not have an
available C++ compiler. I actually don't remember precisely why
we didn't try it out, and I assume we simply got distracted by having
to make things work and forgot to continue the search.

Can it be used as a front-end for such chips, where at best there
are two or three C compilers on the market?

-Peter

claird at lairds.com (Cameron Laird) wrote in message news:<100aoq8efq3nt1e at corp.supernews.com>...
Ahh yes, the good old days. Well maybe not.

I once played with version E of cfront once. Ie., before even version
1.0, the E
being for experimental. At least that is from memory what is was
called. That
was back in 1984 and even at that time version 1.2 of cfront was
already out
I think. At the end of that year I got a student vacation job at the
first company
in Australia to be using C++. We had access to beta versions of the
compiler
from AT&T/USL and I think during that time a beta version of 2.0
turned up.
Not sure how long after that it actually got released properly. It was
after that
that Sun and Centerline brought out compilers based on cfront. Note
that these
compilers still didn't implement templates, they only turned up some
number
of years later in version 3.0 in the early 90's some time. In the
interim we were using
a hacked up cpp which could understand enough of the C++ template
syntax
to allow us to make decent use of them. From memory, the first C++
compiler
to actually come out with support for templates wasn't even the
AT&T/USL
version 3.0 of cfront, instead it was a hacked up version of cfront
2.1 made to
support templates and was released by ObjectStore, the OODBMS
developer.
Don't think it supported template functions though, only template
classes.
Anyway later cfront 3.0 became more available. Actually, it was
version 3.0.1.
Version 3.0 mustn't have lived very long because we never actually got
to
see it. There was a subsequent cfront 3.0.2 and I think that was the
last of
them from USL. Sun and Centreline also came out with versions based on
cfront 3.0.1 before Centerline dissappeared altogether and Sun changed
to
the cafe based compiler which they developed. There was GNU C++ as
well,
but it was quite late to the game in providing a version with
templates which
actually worked. Lucid C++ was an interesting compiler but it also
died. At
that time the best compilers were probably those based on the EDG
engine. Oh
must not forget the SGI and HP versions of cfront 3.0.1. Ah, but then
maybe
we should forget the HP version. Anyway, there were a number of other
C++
compiler vendors as well, especially in the cross development arena,
but enough
already.

Are you against using C++ wrapped in a library such as wxWindows? This
library makes it pretty easy painless to write cross-platform stuff, but
even on Windows alone, it beats MFC or the going price of Delphi.

"John Benson" <jsbenson at bensonsystems.com> wrote in message
news:mailman.337.1074032524.12720.python-list at python.org...

Except when it causes memory corruption and segmentation faults :(

Jp

I give up! Enough already! Maybe C++ will make my teeth brighter and my
socks whiter, and remove the yellowish wax buildup on the kitchen floor! :^)

I read Koenig's C Traps and Pitfalls years ago; it's been one of my favorite
programming language books for a long time, so I'm predisposed to set a
certain store by the following pronouncement:

Message: 6
Date: 15 Jan 2004 02:37:32 +0000
From: jjl@pobox.com (John J. Lee)
Subject: Re: I come not to bury C++, but to praise it...
To: python-list at python.org
Message-ID: <87wu7uq6mr.fsf at pobox.com>
Content-Type: text/plain; charset=us-ascii

"Andrew Koenig" <ark at acm.org> writes:
Andrew's own "Accelerated C++" is good (written with Barbara Moo). :-)


John

(end quote)

It took years to get IT managers to feel comfortable with software
development in C as opposed to COBOL. I suppose I may still be haunted by
that; it just seems that advocating C++ raises the bar even more for the
maintenance programmers that get stuck with my code. Python is a whole
different story, since the rapidity with which I can field a serviceable
prototype changes the economics completely. But again, this may be more an
artefact of my personal experience than a Universal Truth.