From: William Djaja Tjokroaminata <billtj@...>
Date: 2002-08-28T04:42:17+09:00
Subject: Re: compile time type checking

Hi,

In my opinion, compile time type checking helps, but it is by itself not
sufficient.  I think guarding against arbitrary user input goes beyond
type checking; for example, although user inputs a numeric when we expect
numeric, we also need to check the range of the value.  However, I don't
think it is impossible to write an input checking routine in a
scripting language that is as robust as that used in a compiled language.

During development time, yes, the lack of compile time type checking
sometimes gives me trouble when I run a script.  However, the
corresponding error message is usually obvious enough for me to quickly
fix the error and rerun the program.  So I think it is a trade-off; we
may get error more easily, but we can also fix it faster.  The only
tricky part is, if there is some type mismatch but the code is not
invoked, the error will not appear.  I also do not know how to make sure
that every part has been tested with all possible values (maybe it is
impossible?)

Regarding the crashing, I think it has more to do with the exception
mechanism in the language than the compile type checking.  For example,
although C provides compile time type checking, I see a lot of commercial
codes which crashed severely.  When an exception hierarchy is well
defined, on the other hand, the crash can be more graceful.  Finally, I
think preventing crash on a user really depends on how much testing we can
do before releasing the code, independent of the type of language.

For me, the more serious problem with scripting languages is the extra
overhead in terms of memory and execution performance.  We simply cannot
gain something for nothing.

Regards,

Bill
==============================================================================
Volkmann, Mark <Mark.Volkmann@agedwards.com> wrote:
f> I think the main reason that languages such as Ruby, Python, Perl and
TCL
> *tend* to be used for "scripting" as opposed to "real applications" is that
> they lack compile time type checking. Since there is no compile step in
> Ruby, maybe this should be called pre-release type checking.

> I'm curious how some of you that have written real applications in Ruby have
> dealt with this. Don't you have problems where an application crashes on a
> user because the wrong type of object gets passed to a method and it tries
> to invoke a method of the object that it doesn't have?

> It seems to me that it's nearly impossible to write enough unit tests to
> catch all of these issues before code is released for production use.

> I love Ruby syntax, but this issue may be one that keeps many people using
> Java instead.


> ***********************************************************************************
> 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.
> ************************************************************************************