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

[John Benson]

I got into Python because I took one look at C++ and saw all the handwaving
in the introductory O'Reilly book to the effect that "everything looks sweet
now, but wait until these snazzy little features interact..." and then
started casting around for another road to OOP. I happened upon Python, and
continue to use Python.

I think that the already-posted comments seeking to appreciate the
historical origin and motivations of C++ are essential to understanding it's
applicability in the present.

C++ started as a quintessentially Unix-like exercise in software
engineering: add functionality by leveraging existing software components to
the max. Another level of preprocessor (Cfront) was added to the compiler
tool chain and Bingo! you had a new language. The advantage was quick
time-to-implement. A big disadvantage was that you had to grok C to debug
C++. Later compilers took C++ direct to object, but the C, non-OOP heritage
persisted in the new language: you had to master pointers and references to
really do C++. Later languages simplified the situation by dumping pointers.

I think that C++ was a great exercise, but software engineering has
advanced. Why not take advantage of the latest packaging of OOP and enjoy
the smoother ride? Pick Java, or Python or whatever pleases you. I'm happy
using C for projects that fit it, and Python for more ambitions OOP stuff.
C++ was a great way to move OOP forward, but now it looks more like a
transitional form than a best-of-breed. Sic transit gloria mundi, which is
Latin for "when you're hot, your hot; when you're not, you're not" or
something like that.

If you have a big investment in C++ and can crank out beautiful code in your
sleep, that's fine too. I just don't expect it to be as easy to find people
to maintain it as if it were written in C, or Python, or Java, or whatever.

 

[Derek]

in message...

I think that C++ was a great exercise, but software
engineering has advanced. Why not take advantage of the
latest packaging of OOP and enjoy the smoother ride? Pick
Java, or Python or whatever pleases you. I'm happy using
C for projects that fit it, and Python for more ambitions
OOP stuff. C++ was a great way to move OOP forward,
but now it looks more like a transitional form than a
best-of-breed. Sic transit gloria mundi, which is Latin for
"when you're hot, your hot; when you're not, you're not" or
something like that.

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.

 

[Rainer Deyke]

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

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.

 

[Andrew Koenig]

I got into Python because I took one look at C++ and saw all the handwaving
in the introductory O'Reilly book to the effect that "everything looks sweet
now, but wait until these snazzy little features interact..." and then
started casting around for another road to OOP.

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.

 

[Peter Hansen]

[snip]
I think that the already-posted comments seeking to appreciate the
historical origin and motivations of C++ are essential to understanding it's
applicability in the present.

C++ started as a quintessentially Unix-like exercise in software
engineering: add functionality by leveraging existing software components to
the max. Another level of preprocessor (Cfront) was added to the compiler
tool chain and Bingo! you had a new language. [snip]

I think that C++ was a great exercise, but software engineering has
advanced.

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.

 

[Derek]

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.

 

[Jp Calderone]

[snip]

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

 

[Cameron Laird]

.
.
.

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 was still fussing with cfront in the early '90s.
Its era *had* passed by then, though.

 

[Cameron Laird]

.
.
.

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.

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?

 

[Peter Hansen]

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

 

[Donn Cave]

.
.
.

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?

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, (e-mail address removed)

 

[Derek]

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

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?

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.

 

[Derek]

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

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.

 

[Cameron Laird]

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

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

 

[Cameron Laird]

.
.
.

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.

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.

 

[Rainer Deyke]

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.

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.

 

[Donn Cave]

....

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

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, (e-mail address removed)

 

[John J. Lee]

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.

No, you don't (assuming I understand Jp's post), because...

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.

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

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

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.

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.

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

 

[John J. Lee]

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

[...]

http://www.artima.com/weblogs/viewpost.jsp?thread=4639

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/[email protected]&rnum=1

http://www.google.com/[email protected]&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