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

[John J. Lee]

"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