From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-15T19:03:27+09:00
Subject: Re: begining programmer questions

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

I have to admit I don't understand the distinction you're making between
"class" and type. To level-set: I care about this discussion primarily
because plenty of people (but no one on this thread, of course) criticize
Ruby as being less strongly-typed than C++ or Java, whereas the truth is
that Ruby is _dynamically_ typed rather than _weakly_ typed. In Ruby, an
object never changes its type (although delegation and the ability to add
methods to a single object instance also may make it seem like it does).

More to the point, Ruby will never implicitly perform operations on an
object that are not part of its type, as a result of inferences about some
particular statement of code. This Ruby code will generate an error:
"abc" + 5
because Fixnum can't be an argument to the String method named +. Both C an=
d
Ruby will perform certain type-transformations automatically (mostly
widening numeric types) but these are well defined and stated upfront in th=
e
language definition.

Weak typing (such as you see in languages like Perl and Javascript) can
often be the source of very difficult errors. Ruby and other dynamic,
strongly-typed languages (Python) don't go this far. However, they do relax
the requirement that the object bound to a particular variable be constant
throughout the run of a program. Types are attributes of objects, not of
variables. For example:
a =3D "abc"
b =3D a
a =3D 5
isn't permitted in a static program but is permitted in a dynamic one. The
object "abc" (of type String) still exists (it's bound to variable b at the
end of the fragment) but it's meaningless to speak of the type of variable
a. Rather, at the end of the run, a is bound to an object of type Fixnum
(and value 5). This throws people who are used to the fact that compilers
can find a large class of errors in languages that don't permit variables t=
o
be rebound to objects of different types. However, the key insight of
dynamic languages is that this class of statically-discoverable errors,
while large, is not deep or difficult.

I've noticed that younger programmers seem to have much less conceptual
trouble with "duck typing" and dynamic languages than older people like me.
I wonder if it's because for a while, CS programs taught people with
functional languages like Scheme, where the distinction between objects and
variable-bindings is explicit and clear. (Nowadays of course, all the
younger people coming out of university seem to have learned nothing but
Java...)

On 5/15/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>
> Hi --
>
> On Mon, 15 May 2006, Francis Cianfrocca wrote:
>
> > 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 perfor=
m
> > 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 typ=
e
> 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, i=
f
> you
> > 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.
>
> It sounds like you're talking about class, rather than type.  A
> string, for example (that is, an object that says "String" when you
> ask it its class), can allow integers to be added to it, and is
> therefore of class String but of *type* "string-like thing that lets
> you add integers to it" (or whatever).
>
> So the type of Ruby objects is almost a tautology: the type of object
> o is "the type of objects that have the capabilities and interface of
> object o."  Class, meanwhile, though more tangible in a sense, is only
> the starting point for the object's life-cycle.
>
>
> David
>
> --
> David A. Black (dblack@wobblini.net)
> * Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
>    > Ruby and Rails consultancy and training
> * Author of "Ruby for Rails" from Manning Publications!
>    > http://www.manning.com/black
>
>

------=_Part_65451_22699997.1147687404191--