FAQ

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

John Benson
Jan 13, 2004 at 10:21 pm
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.
reply

Search Discussions

36 responses

  • Derek at Jan 13, 2004 at 11:28 pm
    "John Benson" wrote 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 at Jan 13, 2004 at 11:49 pm

    Derek wrote:
    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.


    --
    Rainer Deyke - rainerd at eldwood.com - http://eldwood.com
  • Derek at Jan 14, 2004 at 2:42 pm

    "Rainer Deyke" wrote:
    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.
    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 at Jan 14, 2004 at 3:35 pm

    On Wed, Jan 14, 2004 at 09:42:52AM -0500, Derek wrote:
    [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
  • Oren Tirosh at Jan 16, 2004 at 8:40 pm

    On Wed, Jan 14, 2004 at 10:35:16AM -0500, Jp Calderone wrote:
    On Wed, Jan 14, 2004 at 09:42:52AM -0500, Derek wrote:
    [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.
    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
  • Derek at Jan 20, 2004 at 4:19 pm

    "Oren Tirosh" wrote:
    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.
    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.
  • Peter Hansen at Jan 20, 2004 at 4:47 pm

    Derek wrote:
    "Oren Tirosh" wrote:
    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.
    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
  • Ville Vainio at Jan 20, 2004 at 9:07 pm
    "Peter" == Peter Hansen <peter at engcorp.com> writes:
    Peter> Derek wrote:
    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.
    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.
  • Derek at Jan 20, 2004 at 9:20 pm

    "Peter Hansen" wrote:
    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.
    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
    I around the last time was actively using C++, which was
    I about a decade ago...
    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.
  • Cameron Laird at Jan 14, 2004 at 4:05 pm
    In article <bu3khe$dbm5v$1 at ID-46268.news.uni-berlin.de>,
    Derek wrote:
    .
    .
    .
    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?
    --

    Cameron Laird <claird at phaseit.net>
    Business: http://www.Phaseit.net
  • Donn Cave at Jan 14, 2004 at 5:34 pm
    In article <100aq779r2h2c9e at corp.supernews.com>,
    claird at lairds.com (Cameron Laird) wrote:
    In article <bu3khe$dbm5v$1 at ID-46268.news.uni-berlin.de>,
    Derek wrote:
    .
    .
    .
    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?
    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
  • Cameron Laird at Jan 14, 2004 at 6:21 pm
    In article <donn-DF9867.09340714012004 at nntp3.u.washington.edu>,
    Donn Cave wrote:
    In article <100aq779r2h2c9e at corp.supernews.com>,
    claird at lairds.com (Cameron Laird) wrote:
    In article <bu3khe$dbm5v$1 at ID-46268.news.uni-berlin.de>,
    Derek wrote:
    .
    .
    .
    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".
    .
    .
    .
    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 <claird at phaseit.net>
    Business: http://www.Phaseit.net
  • Donn Cave at Jan 14, 2004 at 10:50 pm
    In article <100b266i0r70g86 at corp.supernews.com>,
    claird at lairds.com (Cameron Laird) 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".
    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
  • Valentino Volonghi aka Dialtone at Jan 16, 2004 at 11:47 pm

    Donn Cave <donn at u.washington.edu> writes:

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

    --
    Valentino Volonghi, Regia SpA, Milan
    Linux User #310274, Gentoo Proud User
  • Derek at Jan 14, 2004 at 5:52 pm

    "Cameron Laird" wrote:
    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 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.
  • Cameron Laird at Jan 14, 2004 at 6:30 pm
    In article <bu3vku$den0t$1 at ID-46268.news.uni-berlin.de>,
    Derek wrote:
    .
    .
    .
    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.
    --

    Cameron Laird <claird at phaseit.net>
    Business: http://www.Phaseit.net
  • John J. Lee at Jan 15, 2004 at 2:35 am

    claird at lairds.com (Cameron Laird) writes:

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

    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
  • John J. Lee at Jan 15, 2004 at 2:24 am
    "Derek" <none at none.com> writes:
    [...]
    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
  • Andrew Koenig at Jan 15, 2004 at 3:53 pm

    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.
    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.
  • John J. Lee at Jan 16, 2004 at 3:53 pm

    "Andrew Koenig" <ark at acm.org> writes:

    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.
    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.
    It may be subtle, but it's also the starting point for most of these
    debates.

    Before you get out your flame-thrower, please hear me out -- I am not saying
    OK... :-)

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

    [...snip example...]
    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.
    Yes.

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

    [...]
    I see static typing
    as a theoretically-interesting field of no real applicability to my
    work. If I felt otherwise about it, I would most likely be coding
    in Haskell or some kind of ML, of course -- nobody's come and FORCED
    me to choose a dynamically-typed language, you know?
    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
  • Derek at Jan 14, 2004 at 6:02 pm

    "Jp Calderone" wrote:
    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++.
    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.
  • John J. Lee at Jan 15, 2004 at 2:01 am
    "Derek" <none at none.com> writes:
    [...]
    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
  • Derek at Jan 15, 2004 at 3:12 pm
    "John J. Lee" wrote...
    [...]
    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!
    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.
  • John J. Lee at Jan 16, 2004 at 3:59 pm

    "Derek" <none at none.com> writes:

    "John J. Lee" wrote...
    [...]
    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!
    Are you joking?
    No.

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

    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.
    Oh. That's interesting. Do those practices get rid of all such
    issues?

    For *me* the lack of static type safety in Python is an issue. We
    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...

    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.
    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
  • Rainer Deyke at Jan 14, 2004 at 7:47 pm

    Derek wrote:
    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.


    --
    Rainer Deyke - rainerd at eldwood.com - http://eldwood.com
  • John Benson at Jan 14, 2004 at 2:05 am
    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.
  • Dave Murray at Jan 14, 2004 at 3:32 am

    sprintf("All the cool guys use %s because %s\n", Myfavoritelanguages,
    Mylimitedexperience)
    Very good! I hope that that's not under copyright, I plan to use it.

    Dave
  • Andrew Koenig at Jan 14, 2004 at 6:35 am
    "John Benson" <jsbenson at bensonsystems.com> wrote in message
    news:mailman.337.1074032524.12720.python-list at python.org...
    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.
  • John J. Lee at Jan 15, 2004 at 2:37 am

    "Andrew Koenig" <ark at acm.org> writes:

    "John Benson" <jsbenson at bensonsystems.com> wrote in message
    news:mailman.337.1074032524.12720.python-list at python.org...
    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.
    Andrew's own "Accelerated C++" is good (written with Barbara Moo). :-)


    John
  • Peter Hansen at Jan 14, 2004 at 2:42 pm

    John Benson wrote:
    [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.
  • Cameron Laird at Jan 14, 2004 at 3:42 pm
    In article <40055560.7A0DCD0D at engcorp.com>,
    Peter Hansen wrote:
    .
    .
    .
    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 <claird at phaseit.net>
    Business: http://www.Phaseit.net
  • Peter Hansen at Jan 14, 2004 at 4:16 pm

    Cameron Laird 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
  • Graham Dumpleton at Jan 15, 2004 at 10:19 am
    claird at lairds.com (Cameron Laird) wrote in message news:<100aoq8efq3nt1e at corp.supernews.com>...
    In article <40055560.7A0DCD0D at engcorp.com>,
    Peter Hansen wrote:
    .
    .
    .
    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.
    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.
  • Python newbie at Jan 15, 2004 at 3:03 am
    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...
    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.
  • Jp Calderone at Jan 15, 2004 at 5:54 am

    On Thu, Jan 15, 2004 at 03:03:53AM +0000, python newbie wrote:
    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.
    Except when it causes memory corruption and segmentation faults :(

    Jp
  • John Benson at Jan 15, 2004 at 7:15 pm
    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:
    "John Benson" <jsbenson at bensonsystems.com> wrote in message
    news:mailman.337.1074032524.12720.python-list at python.org...
    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.
    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.

Related Discussions