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

[kragen@pobox.com (Kragen Sitaker)]

Shriram Krishnamurthi writes:
> Kragen Sitaker wrote:
> > If your polymorphism is resolved at compile-time, as in the C++ STL,
> > it doesn't mess up your performance (except, possibly, by bloating
> > your code and thrashing your icache.)
> 
> (1) That still doesn't address object polymorphism.

No, it doesn't.

> (2) The same techniques that C++ uses, ML can also.  See the TIL
>     compiler.  At least ML doesn't force you to do it manually.

I haven't looked at the TIL compiler (thanks for the pointer), but I
thought Matthias's point was that SML/NJ built slow code (news to me,
but hey, I mostly program in Python these days, so what do I know
about speed?) even though its input language was statically typed.
_Compiling with Continuations_ says SML/NJ doesn't use the same
technique C++ uses:

	If functors in ML behaved like the "generic" modules of Ada,
	this problem would not exist: It is expected of an Ada
	implementation that each applicaiton of a "generic" will
	generate new code specialized to the particular argument.  But
	in ML the intent of the designers was that machine-code
	generation (and type checking, etc.) needs to be done only
	once for each functor, and is independent of the actual
	parameter to the functor.

(Section 4.1, p. 41 in my copy.)


Anton van Straaten writes:
> If you "know what you are doing", you don't need a type system at
> all (think pure untyped lambda calculus, bay-bee! :) A type system
> that relies on you to implement it properly isn't doing the job for
> which type systems are intended.

It isn't doing the job for which type-safe type systems, like those in
most Scheme implementations, are intended.  C's type system was
intended for a completely different purpose: to make code more concise
and easier to read and type.

Some languages, like OCaml and Forth, require you to use different
symbols to add floating-point numbers and integers, because their
elementary operations aren't polymorphic.

If C didn't have types, it couldn't have polymorphic elementary
operations, such as +, *, and (especially) [].  B was typeless, and so
dealing with characters and floats was painful.  C added types to
remove that pain.  (This is all based on my fuzzy recollection of the
HOPL II paper on C, which I haven't read in a year or two.)

C++'s type system, by all appearances, has the same purpose.  It is
more effective at it, at the cost of being more complex.  Misguided
souls believing C++ to be something more than a portable macro
assembler have recently added run-time type identification and checked
casts to the language.

Before I picked up SICP in 1996, I was always mystified by all the
stupid people complaining that C was broken because you could subvert
its type system.  Now I understand how those people got confused.  In
this world, a "type system" has a different purpose.  C's "type
system" is, in many ways, technically similar to the type systems of
ML, Lisp, or Ada, but it was built for a completely different reason:
not to detect errors, but to make the code shorter and less
error-prone.

Please note that I am not advocating that people build large systems
in macro assembler or C or C++.  I just think it's dumb to complain
that C++ isn't much more than a portable macro assembler.  That's
what C was explicitly designed for, and C++ isn't much different.

To clarify: 

Oscar Fuentes wrote:
> If you want to do type safe programming in C++ you can do it and the
> compiler will help you. The only requirement is that you must know
> what are you doing. So it is understandable that teachers regards
> C++ as type unsafe because it is unsafe for their students.

"type safe" implies "even if you don't know what you are doing".
Teachers regard C++ as type-unsafe because they know what "type
safety" is.

> It's perfectly possible to do "elegant" (modulo syntactic
> aesthetics), reliable, maintainable, extensible C++ code.

Oscar, what's the biggest maintainable C++ program you've ever
written?


On other topics:

Sebastian Seidel wrote:
> One word about types though: Why did C++ come up with 'templates' if
> static typing would really be that great? Templates are used in 
> C++ - coded numeric libraries where speed is of much concern.

Templates are statically typed.  That's why they're fast.

Matthias Felleisen writes:
> there is no way to make cast-free C++ a safe language w/o changing the
> language radically.

I think you are mistaken, but I don't think it's a good idea.  There
are much better safe languages out there that are designed to be safe.
Scheme, for instance.  I think VisualAge for C++ is a type-safe
implementation, even with casts, but they are not very popular.

> Here is what I mean:
> 1. I need a decision algorithm for C++ standard programs 

To determine what about them?  Whether or not they are correctly
typed?

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
It frightens the daylights out of me whenever I hear people proclaim that
the less knowledge our children have access to, the better.  
-- Duane Lindstrom, at <URL:http://www.examiner.com/skink/skinkmail.html>