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

Conrad Schneiker wrote:

> Nathaniel Talbott wrote:
>
> # [but neglected to cite who he quoted]

<snipped what was quoted>

Sorry; I was quoting Kevin Smith. My mail reader doesn't do citations on its
own very well, and I forgot to put it in. Will be more careful in the future
(although I almost forgot to cite you at the top :-)


> Too many people have drawn comfort from clean Java compiles, only for
> others of us to have later on encountered
> "NullPointerException"s rather
> more often then we would have liked. (This in a language once
> promoted as
> having no pointers.)

LOL! I get them all the time, but never realized the inherent inconsistency
:-)


> # Hmmm...
> #
> #                "Ruby - the language that makes you feel like unit
> #                testing"
> #
> # Sounds like an advantage, not disadvantage :-) While I see pros for
> # going to byte-code compilation, none of them have anything to do
> # with error-checking.  It seems to me the compiler is a tempting
> # crutch to lean on instead of properly testing your code. Just my
> # $0.02.
>
> Hmmm.... That's also a good reason for removing Ruby's -w
> flag, which is
> just another tempting crutch. Indeed, syntax error messages should be
> removed too, since they are just crutches for those slothful
> holdouts that
> don't properly test after each newly added statement. :-)

Excellent counter to my high level of sarcasm, and point taken, although I
still think compile-time type checking, in all of the forms that I know it,
is inherently evil (Oops, now I'm exaggerating :-)


> Actually, I think it would be nice if Ruby's -w flag were as
> powerful as
> Perl's and if there was something comparable to Perl's "use
> diagnostics;".
> These features do a fairly remarkable job of warning about and of
> explaining about probable/actual programming errors at compile time
> (although Perl is so big and complex that these features
> still miss lots
> of problems).

Certainly, the more stupid programmer errors we can catch before running the
code, the better (and I make plenty of them). My personal experience from
Java has been, though, that the nastiest errors come from forgetting a
message send, something that will never be caught by any compiler, no matter
how smart. OTOH, I find myself dancing around typing in Java all the time,
for instance knowing that the right method exists on an object, but unable
to call it without casting (collections, anyone?). If you like to dance
everywhere you go, that's fine, but I prefer to walk (or run) in a somewhat
straight line :)

It's hard for me to judge how many errors in our code are caught by typing,
since the code comes out totally differently due to it. I know that our team
has added several major 'extensions' in Java using reflection to give us
dynamic linking and automatically twiddle the types so that they go into the
method properly. How often do we get errors in our code due to the dynamic
linking? After the initial get it working phase, I'd have to say 0.01% of
the time. I wish our overall error rate were that low, but the errors we do
have are almost never related to bad typing or dynamic linking.

As I've begun writing Ruby code, I haven't found it to be buggier than my
Java; rather, it has been more stable because it's easier to test, simpler,
smaller, expresses its intent better, and I can keep more of it in my head
at once. As I write more Ruby (and continue to write Java, at least until I
can get paid to write Ruby), I'm curious to see what errors come up in Ruby
that strong type checking would have fixed. I'm also curious to see more
*concrete* examples of errors in Ruby code that would have been caught by
strong, static type checking.


Nathaniel

<:((><
+ - -						+ - -
| RoleModel Software, Inc. &		| EQUIP VI
| The XP Software Studio(TM)		|