Compile time type checking

That is what I meant. It seems to me that having compile-time type checking
allows certain coding errors to be found more quickly and reduces the
possibility that users will experience the equivalent of a Java
ClassCastException or whatever happens in Ruby when you attempt to invoke a
method on an object that doesn’t support it.

···

-----Original Message-----
From: Michael Campbell [mailto:michael_s_campbell@yahoo.com]
Sent: Tuesday, August 27, 2002 2:50 PM
To: ruby-talk@ruby-lang.org
Subject: Re: compile time type checking

— William Djaja Tjokroaminata billtj@z.glue.umd.edu wrote:

Hi,

In my opinion, compile time type checking helps, but it is by
itself not
sufficient.

I don’t think that was the assertion, was it?

If I read the original poster correctly, he was saying compile time
checking helps a lot; it obviates the need for some unit tests.


WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.


If I read the original poster correctly, he was saying compile time
checking helps a lot; it obviates the need for some unit tests.

> That is what I meant.  It seems to me that having
> compile-time type checking allows certain coding errors to
> be found more quickly and reduces the possibility that users
> will experience the equivalent of a Java ClassCastException
> or whatever happens in Ruby when you attempt to invoke a
> method on an object that doesn't support it.

This is a very common fear amoung programmers coming from a statically
typed language to a language like Ruby, Python or Smalltalk.
Surprisingly (I know I was surprised), the fear does not match the
reality.

By far, the most common NameError I run across is happens when I send
a message to nil, which is the moral equivalent of getting a
NullPointerException in Java. Static typing helps neither situation.

Personal Testimony …

About 3 years ago I was doing a lot of non-work related programming in
Eiffel, a very nice, statically typed object oriented language. I was
a strong believer in the advantages of strong typing and the DbC
provided by Eiffel. In an email conversation with a friend I
mentioned that I needed to get back to programming in a statically
type safe language (implying Eiffel). My friend challenged the need
for “static type safety” and pushed the idea that statically typed
languages were inherently less flexible than a dynamically typed one.
I (politely) disagreed and pointed out that Eiffel had a clean type
system and didn’t limit you the way other statically typed languages
did.

Since that time I discovered Ruby. In the first six months I was
using Ruby, I wrote twice as much software as I did in my entire two
years of exploring Eiffel. Ruby is that much more productive
(easily).

I don’t miss the static type safety of Eiffel[1]. It wasn’t helping
me as much as I thought. But I do miss the extreme flexibility of a
dynamic language like Ruby whenever I go back to Java or related
languages.

So, your milage my vary. Give it some time. Get in the habit of
driving your design with unit tests. It will come.

···


– Jim Weirich jweirich@one.net http://w3.one.net/~jweirich

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

[1] I do miss the DbC aspect of Eiffel, not so much for program
correctness (XP-style test driven design really picks up the
slack there), but for the documentation value of explicit
contracts.

Hi,

I think there have been many good, informative, responses from people. I
just want to add that in my own experience in C, compile-time type
checking only helps me in finding the wrong type of pointer (when I forget
to cast it); however, compile-time type checking does not help at all when
the address itself is wrong, which then usually results in a crash.

The first time I used a scripting language, I was also wondering, won’t I
make more errors if there is no static type? In C, for example, I will
get an error such as “struct has no member with name ‘name’” when I
mistype. Actually, this will be a good example, as in Python you will not
get an error in this code:

x.cunter = 1    # when we mean 'counter'

but you will in Ruby (when you run it). Therefore even without
compile-time type checking, assuming that you will test and run your code,
you will get a lot of help from the Ruby interpreter, sometimes more than,
for example, that in Python. (This is one of the reasons why I switched
from Python to Ruby.)

Really, I agree with the people who mentioned to just try it. Once you
are used to coding in a scripting language, you will not miss compile-time
type checking very much. What you will miss is execution (and
memory) performance. When a “real application” has certain requirements
regarding memory and execution performance, then usually scripting
languages are out-of-the-question.

Regards,

Bill

···

=============================================================================
Volkmann, Mark Mark.Volkmann@agedwards.com wrote:

That is what I meant. It seems to me that having compile-time type checking
allows certain coding errors to be found more quickly and reduces the
possibility that users will experience the equivalent of a Java
ClassCastException or whatever happens in Ruby when you attempt to invoke a
method on an object that doesn’t support it.