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

[Sebastian H Seidel <Sebastian.H.Seidel@hno.med.uni-giessen.de>]

Sorry,

I've been starting out with C++ and the whole language as well as the
glorious STL is one huge syntactic mess. I've seen Scheme-programs
translated into C++ and yes, it seems to work but the resulting code
is so ugly that you could as well hard-code it on a Turing-Machine.
In my opinion that guy Stroustroup had a little too much fun
elaborating on his crooked syntax and rather than keeping it simple
like C he decided to write a sleep-pill of 1024 pages and design a
language that enslaves your mind.

Join the right side,
Sebastian

PS: 
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. So maybe it's
the compiler and algorithm that makes your program racing and not the
choice or lack of type-system.

Other factors concerning speed might be:
- Homogenous arrays beat heterogenous ones.
- Doubles beat Reals and Bignums.
- Explicit memory-management beats garbage-collection.
- The human-factor: In C it's almost impossible not to think about
efficiency because that's all you have.

After all I'm glad that Scheme is not a crooked syntactic mess like
C++, not just a portable assembler like C, not a language with walls
all over the place like others might be that I did not yet bother to
try out.

Nevertheless I'd gladly use a cleanly designed (no glitches like the
'=>'-thing and the superfluous 'else' in 'cond'-clauses) type-system
if I can restrict it to single modules. Maybe one could do it like:

(typed-lambda ((double: a int: b)
               (double:))
   (+ a b))

Or even include multiple-value-return:

(typed-lambda ((double: a int: b)
               (double: int:))
   (values a b))


------------------------------------------------------------------



> Shriram Krishnamurthi <sk@cs.brown.edu> writes:
> 
> > Oscar Fuentes wrote:
> > 
> > > This last paragraph confused me. In what sense C++'s type system
> > > fails? The whole point around C++ type system is that it is
verified
> > > at compile time in a way that there is no need for run-time
checks
> > 
> > Define a new type, A.
> > 
> > Define a vector of ten A's.
> > 
> > Make an instance of this vector.
> > 
> > C++'s type system says that all dereferences of this vector will
give
> > you objects of type A.
> > 
> > Dereference the eleventh element of this vector.
> > 
> > Do you get an A?
> 
> The C++ standard does not says that _any_ _pointer_ dereference will
> return a _well_ _constructed_ instance. If you want to stay safe,
> avoid "naked" pointers. (And yes, it is perfectly possible to do C++
> using wrapped pointers, and not just barely dressed pointers like
> std::vector)
> 
> Still, the case you mention does show a "problem" with std::vector
(or
> with traditional C style arrays, which are more or less the same for
> the case we are discussing). It is not a problem with the
> _language_. The same applies to most Standard C++ Library, where
> performance criteria prevails over safety. If run-time performance
is
> not as critical to you as safety, use a safe library.
> 
> -- 
> Oscar
> 
>