From: Robert Klemme <bob.news@...>
Date: 2004-05-24T16:53:48+09:00
Subject: Re: How to duck type? - the psychology of static typing in Ruby


"Ben Giddings" <bg-rubytalk@infofiend.com> schrieb im Newsbeitrag
news:40AB8459.7090601@infofiend.com...
> Robert Klemme wrote:
> >>I worry more about the hazard of undeclared variable names.  There's a
> >>story, probably apocryphal, about a space probe being lost back in the
> >>1960's because somebody held down a keypunch key too long and turned
the
> >>variable X into XX on the left-hand of an assignment.  Since FORTRAN4
> >>didn't require explicit declaration of variables, the calculation was
> >>stuffed into XX (which appeared nowhere else in the program) and X
> >>contained an incorrect value for subsequent calculations.  Because of
> >>this story, I worry sometimes that variables need not be delcared in
> >>Ruby.  I realize that since everything is an object there's no need
for
> >>type declarations.  However, I think variable set declarations would
> >>make some sense - "Here's the set of variable names I'll be using, and
> >>anything not in this set is a typo."
> >
> > If there were proper tests in place they'd certainly catched that one.
> > Declarations could only prevent the accidental usage of an undeclared
> > variable.  But they can't ensure calculcations and algorithms are done
> > properly.
>
> I have a beef with this attitude.  Of course you'll catch this error if
> you have a test in place to test for it.  Of course proper testing will
> ensure a working product.  Of course testing for undeclared variables
> won't prove you have a working program.  That doesn't mean it's useless.
>   In fact, this is one of the most useful features of compilers in a
> compiled language.
>
> Matz has often said that one of his major goals with Ruby is to make
> things easy for the programmer, unlike most languages that make things
> easy for the computer.

Naturally people's opinions on what is "easy for the programmer" will
differ.  Some will find it more easy to be forced to declare all
variables, others will find it more easy to not have to.

> Checking to see if you're assigning to an undeclared variable is one of
> those really helpful things that a computer can do for you.  It can't
> easily prove the correctness of your algorithms, it can't easily decide
> if your code needs to be refactored.  But catching this kind of typo is
> something that it should be pretty good at.  So, why is this a bad
thing?
>
> Sometimes, you don't want the extra keystrokes of having to declare your
> variables.  That's fine.  But, sometimes you really want typo detection.
>
> $num = 2
> $num += 3
>
> if ($numb != 5)
>    puts "foo"
> end
>
> If I run the above by default, it just prints "foo".  If I run it with
> '-v' it tells me:
>
> ritf.rb:7: warning: global variable `$numb' not initialized

This kind of warnings cannot be done for instance variables because you
don't know the invocation order when you see method definitions.  Only if
you enforce initialization in the constructor, you can check omissions -
but then you practically have enforced declaration of instance variables.

While the solution might be appropriate for the more procedural Perl I'd
say it isn't for Ruby, because Ruby is to a far bigger extend OO than
Perl.

> That's some really useful information!  It's a shame that I get that
> information too late.  At this point my program is already running and
> already doing the wrong thing.

Hopefully in a test. :-)

> I think it would be great if there were some analysis software for ruby
> code that would look over it, and without actually running it, find
> potential problems like this one.  This would be the equivalent of
> compiling a C program, in that it would weed out all the obvious typos
> and similar mistakes.  This could even be the behaviour of 'ruby -c' if
> the '-v' flag is supplied.
>
> Among people who don't program Ruby, one of the biggest complaints I've
> heard is that they'd be scared to create a really big program in Ruby
> because it wouldn't find a simple typo until it is actually executing
> the code at that point.

Well, there are lots of other typos you wouldn't catch with strong typing
or variable declarations.

sum = 0
enum.each do |x|
  sum -= x  # ooops
end

foo.gsub(/x/, 'u')  #  oops, meant to do inplace substitution

....

>  If it's a rarely-hit spot, then it could be a
> long time before it is discovered.  This concerns me too -- but I'm a
> big enough fan that I overlook this flaw and use Ruby anyhow.
>
> One of the few things that Perl still has that Ruby doesn't is this:
>
> use strict;
>
> $num = 3;
> $num += 2;
> if ($numb != 5) {
>      print "Foo!!\n";
> }
> % perl perl.pl
> Global symbol "$num" requires explicit package name at perl.pl line 3.
> Global symbol "$num" requires explicit package name at perl.pl line 4.
> Global symbol "$numb" requires explicit package name at perl.pl line 5.
> Execution of perl.pl aborted due to compilation errors.
>
> It's an option.  You don't have to use it, but for critical packages,
> most people do.  Sure, it's nothing more than partial typo detection,
> but is any of us really prefekt?

You might not be, but... ;-)))

> And besides, if you think proper unit tests will catch all your errors,
> so you don't need this type of check -- what if the typo is in  your
> unit test?

Unfortunately men are able to do lots of errors and whatever you do, you
won't stop them from failing.  Of course, the more you can help with
automation to detect errors early, the better we're off.  I just think
that static typing would not fit Ruby and that Perl's kind of typo
detection doesn't help us much with Ruby.

Kind regards

    robert