From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-15T08:23:45+09:00
Subject: Re: begining programmer questions

------=_Part_59614_8283148.1147649020481
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

With some trepidation I'll commit the sin of threadjacking in order to
clarify some of this. I'm doing this because "weakly-typed" is an
unjustified criticism often made by Ruby's detractors, so I think it's
important for us to be able to answer it.

A strongly-typed language has well-defined, unambiguous rules about the
operations that may be performed on an object, and it refuses to perform
inferred type conversions. (Which is why Ruby won't let you add numbers to
strings as Perl does.) Ruby doesn't ever figure out for itself what type an
object is. If you create an object yourself, you need to type it (generally
with Klassname.new, or one of the shorthands like x=3D[]). Of course, if yo=
u
call a method that returns an object, that object will have a type
(determined by the writer of the method) and you can use it without
declaring it, but that doesn't mean Ruby figured out the type on its own.

Similarly, to say:
c =3D 100
c =3D "100"
is not dynamic re-typing, but rather a dynamic *rebinding* of a different
object to an already-used variable name. Perhaps the point you wanted to
make with this example is the distinction between static and dynamic
languages. In the former (C++, Java, etc), the type of every object in the
program must be determinable by the compiler, whereas in Python or Ruby
these determinations are not made until runtime. For people who come to Rub=
y
with strong experience in C/C++/Java, the lack of static typing is perhaps
the biggest shock. But it doesn't mean that Ruby is weakly-typed! Type
mismatches in Ruby always generate errors, but they occur at runtime rather
than compile-time.

I think the big controversy here is with people who reflexively reject the
idea that type errors should not be visible until runtime. It took me a lon=
g
time to get over this hump, but I now believe that dynamic type errors are
not a particularly nasty class of error and not to be feared.

Now that I'm a million miles away from Corey's original point, I'll go back
into my hole :-).

On 5/14/06, Michael Gorsuch <michael.gorsuch@gmail.com> wrote:
>
> Corey -
>
> A strongly type language would insist that you declare everything before
> use.
>
> Example, in C, you would have to do
>
> "int my_variable" before you put anythign in it.  And it better be an int
> ;-)
>
> In Ruby, you can just start working.  Objects do have to be created,
> though
> some can be figured out Ruby itself.
>
> Even better, a variable can become something else.  Example:
>
> # 'c' is a string here
> c =3D "some text"
>
> # 'c' is now an array of strings
> c =3D []
> c << "some more text"
> c << "some other stuff"
>
> You couldn't get away with this in a strictly typed language such as Java
> or
> C - variables must always behave as they are commanded in the beginning.
>
> On 5/14/06, corey konrad <0011@hush.com> wrote:
> >
> > you're talking over my head francis, i am a beginner. I have no idea
> > what strongly typed even means to be honest.
> >
> >
> > Francis Cianfrocca wrote:
> > > A lot of people have the mistaken notion that Ruby is not "strongly
> > > typed"
> > > (perhaps because they confuse dynamic type-resolution with weak
> typing),
> > > and
> > > this is a good counterexample. You might suppose that Ruby could infe=
r
> > > from
> > > the syntax info[]=3D that it should create an object of type Array, b=
ut
> in
> > > fact the method named []=3D is defined on other classes (such as Hash=
),
> > > and
> > > could of course be defined or meta-defined in your own classes. So
> Ruby
> > > doesn't try to guess what class you meant.
> >
> >
> > --
> > Posted via http://www.ruby-forum.com/.
> >
> >
>
>

------=_Part_59614_8283148.1147649020481--