Re: Strong Typing, Dynamic Languages, What to do?

[Chris Uzdavinis <chris@atdesk.com>]

"Anton van Straaten" <anton@appsolutions.com> writes:

> However, you've implied that there's some advantage to the C++ lack of true
> type safety, but you haven't actually said what that is.  You've pointed out
> that you can use C++ features to program in a more typesafe way, by building
> your own abstractions and avoiding basic built-in C++ features like native
> array dereferencing.  But why are you doing this?  Because the type system
> of C++ is broken, and you're trying to fix it.  And that's the point: it's
> broken, and needs to be fixed.

A vector of 5 elements is the same type as a vector of 6 elements.
The type of the vector is not a function of its size.  Adding a new
element doesn't change the type of the vector.  You can go out of
bounds on a vector, but that's not due to type checking, it is due to
range checking... two orthogonal concepts, IMHO.

Also, you are assuming that every access in C++ is unsafe, or that for
every potentially unsafe access some validating abstraction has to be
written.  Sometimes it comes in handy, but if you write code that
depends on range checking, I'd claim that the program is seriously
buggy. 

If a bug causes an invalid index to be calculated, and the "type
system" checks that such an access is out of range and attemps to
recover, the real problem has shifted:

  * the original bug remains in your code, which keeps on calculating
    the wrong value (which is now "allowed" by your program)

  * now that the access has translated into an error, recovery code is
    written to handle the error.  This is misleading to people,
    because they think that it's OK to go out of bounds in the first
    place, and that if they do, all that is necessary is to handle the
    error. 

> The only real argument for the shortcomings of C++ in this area is
> its role as an object-oriented assembly language: avoiding runtime
> overhead that the programmer doesn't explicitly create.  Like
> assembly language, though, this role becomes increasingly
> marginalized as safer languages match or exceed the efficiency of
> C++.  C++ shortcomings are an historical artifact, they can't be
> defended on technical grounds (academic or otherwise) alone.

C++ places a different language contract on the programmer, but I
don't agree with your wholesale conclusion that C++ is broken, that it
has shortcomings, etc.  

> BTW, I speak as an active C++ programmer who has tried very hard to write
> what you referred to as "elegant, ... reliable, maintainable, extensible C++
> code".  I've written successful commercial products in the language.  C++
> filled an important need when I began using it in the mid-80s.

C++ has changed a lot since then.

> 15+ years later, it seems to me that C++ needs some major
> improvements if it is to remain a competitive language in the longer
> term. 

We do real-time stock trading, and I have written the software to
handle all of the quotes that come in from every ECN in the market,
millions upon millions of quotes a day.  It has never crashed once in
2 years, it has never had any mis-behavior, nor any of the problems
that you suggest are inherent in C++.  

I like Scheme very much, but there is no possible way that such a
language could possibly keep up with the volume of data that my C++
code handles so elegantly.

(In all honesty, I'd be thrilled to be able to have written these
programs in Scheme, but it's just too slow to be practical.)

> One important area in which those improvements will need to
> happen is in type safety, perhaps along the lines of something like
> Safe C (http://www.cs.wisc.edu/~austin/scc.html).  For all I know,
> Managed C++ in .NET will be the next big thing, but I find myself
> sort of hoping not...  ;)

Agreed!  It's not even C++.  :)

-- 
Chris