[ruby-talk:9322] Re: 101 Misconceptions About Dynamic Languages

Patrick Logan <[e-mail]> wrote:
>"Josh Stern" <[e-mail]> wrote in message
>news:3a615fb9$0$78691$[e-mail]...

>> C++... is strongly typed for function calls.

>In fact, C++ is *not* strongly typed for function calls. I can pass in
>any damn thing I want to, to a function, and the language will not
>prevent it.

Not so. You can only pass any damm thing if you use
casts or the clumsy stdarg interface to deliberately subvert 
the type system (or else if you have a bad point or 
reference to start with, in which case the problem happened 
somewhere else, not in the function call).  In the case of 
casts, the type conversion happens before the functional call, 
and C++ has a hierarchy of casts that refelcts their
relative safety.  Many programmers avoid the unsafe
ones altogether (which eliminates stdard), but in any case, 
it is flag to the programmer that something special and
dangerous is going on.

>In fact, I can cause the entire process to be corrupted because of
>this, and worse. It is a misnomer to say that C++ is *strongly*
>typed. It is not.

The terminology is common.  It is also common to note that
C++ is not type-safe.  This suggests that most people don't
use 'strongly typed' as a synonym for type-safe, but I
don't want to argue about a usage issue.

Ruby is not type-safe either.

>C++ is a statically, yet weakly, typed language. The most dangerous of
>combinations, IMHO.

This sentence suggests that you think static typing leads to
a lack of safety, where, in fact, the reverse is true, other
things being equal.

>Ruby *is* strongly typed. It happens to use dynamic type checking, but
>that checking is strong.

It is *easy* for a Ruby programmer to accidentally pass an argument of 
the wrong type to a function and to have this cause a run-time error 
so the program stops working.  Worse, in practice, would be a case
where the program continues to work but has silently performed
an unintended calculation.

>> One of the key benefits of static typing is obviously speed.  If one
>> always works on little problems then speed is not an issue...
>
>I have worked on little problems where speed *is* the issue. And I
>have worked on _many_ large problems where the speed of the language,
>per se, is not the issue. So I see that claim above as a gross
>oversimplification.

What point do you wish to make here?

>> ...many people work on problems where C, C++, Fortran, you name it,
>> are all not fast enough.
>
>I agree, and they should choose the best tools for their problems.

>However, a lot of people I have had discussions with over the last ten
>years or so have held on to the notion that that set of problems is
>much larger than it really seems to be from my experience of using
>dynamic languages for going on 20 years.

Clearly people move in different circles and any individual
programmer only works on a tiny subset of all computational
tasks.

>> Static typing also tends to catch a lot of  dumb errors.
>
>I have never suffered from lack of static typing. I *have* suffered
>from the presence of it.

Let's synchronize what we mean by static typing.  
Are Java, ML, and EiC all examples of statically typed
languages in your lexicon?  If so, then I'd be interested
to hear of what you think are the biggest inconveniences of
static typing.  If not, then I'd suspect that you mean
something like 'lacking an interpreter'.  I'd agree that
having an interpreted capability is important for some
tasks, and a convenience for others.

>> Such a feature needn't affect you if you didn't use it, but whatever.
>
>It would if other programmers used it and I wanted to use their code.

As something of an exercise, I mentioned a possible strategy type overloading
in Ruby in some earlier messages:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/8324
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/8334

Whether something like that would be a good idea overall, is not
something I know the answer to.  But I haven't come across
any really tight arguments/examples so far of how or where it 
would hurt.

-= Josh