[ruby-talk:5717] Re: Dynamic languages, SWOT ?

Hugh Sasse Staff Elec Eng wrote:

> On Sat, 21 Oct 2000, Charles Hixson wrote:
>
> > Sorry, I feel the need for clarification here.  Ruby is strongly typed
> > AND dynamic.
>
> I think from what you say below, I may be using the terms imprecisely.
>
> > Weakly typed, statically bound languages are things like
> > Fortran60.  There the language couldn't tell the type of the item upon
> > which you were operating, so it made assumptions based on the name.
>
> OK, I through K [?] as INTEGER, all others FLOAT.

Yes, but if you equivalence two names, then the program doesn't know which
kind of variable you have.  And then there are all the variations of
parameter calls and function or subroutine declarations, which don't
necessarily match.  I once ended up redefining what the value of 0 (numeric
zero!) was.  (Well, that was a compiler issue, but the language didn't say
what to do.)

> ...
> > else off the top of my head. Strongly typed, dynamically bound
> > languages are, among others, Ruby, Python, Common Lisp, Smalltalk, ...
>
> This is the area I'm thinking about where the typing is not so strong
> as would ease error detection.  OK, types can be dynamic, but for
> parameters it only make sense for them to be in a subset of the
> class heirarchy.   There is no way to express this constraint in Ruby

This is a run time check in a dynamically bound language.  I'm pretty sure
that Ruby does have ways to catch this, though they don't seem, to me, to be
quite as ?elegant?, ?standardized? as those that Smalltalk uses.  Much more
similar to the techniques of Python.

> or Python.  I have not really used Lisp or Smalltalk.  What I mean is
> that it is a weakness [in typing?] to allow a parameter to be of *any*
> class, for example when you know it must be a Numeric
> or descendent of Numeric.  So does this weakness create a different

This is a consideration that I have, also.  Ada, Eiffel, and Java each
address this in some way or other.  But notice that none of those are really
dynamically bound.  Ruby's type system seems more akin to that of Self.  Run
time checks are the only way to handle this.  If you want, you could raise an
exception.  How else would you want this to be handled?  You can't know at
"compile" time what the type of the variable will be.  But it would be nice
to be able to have some types that were bound at "compile" time.  Still, how
much are you willing to have the size of the interpreter increase to add that
feature?  Greater size and complexity creates slower code, even though
certain optimizations would become possible.

I think what's really practical would be a library of type checking
routines.  But I haven't even thought of an appropriate generalized
specification.  And it will be quite awhile before I'm doing much fancy
design in Ruby.  Just today I learned about the !~ operation (i.e., no
match).  But the book should be out soon, and that will help.

> strength which outweighs the inability to type-check at compilation time?
> I can see that supporting polymorphism is a strength, so that subclasses
> can be handled, but at the moment there is nothing wrong with passing in
> superclasses of the originally intended type.

Actually, there's nothing wrong with passing in a totally separately declared
class, as long as it ended up with the appropriate API.  This is both a
strength and a weakness, but I think more of a strength.  Consider:

There is a standard problem that models inheritance in classes and
evolution.  Call it the bird problem.
Now a Rubyesque solution would be a bit different than the normal one, and
would involve mix-ins.
consider constructing separate trees of inheritance, one for descent, and the
other for capabilities.  To create a species, you inherit from the
inheritance tree, and mix-in the appropriate capabilities.  Thus penguins
don't end up with flight being denied, but just not being available.  I'm not
sure that this is an appropriate construct, I'm still thinking about it, but
it is a way in which mix-ins more than substitute for the lack of  multiple
inheritance.

> > Java seems to sit (un?)comfortably in the center, leaning towards sort
> > of strongly typed, and sort of dynamically bound.
> >
> > -- (c) Charles Hixson
> > --  Addition of advertisements or hyperlinks to products specifically
> > prohibited
> >
>         Hugh
>         [e-mail]

-- (c) Charles Hixson
--  Addition of advertisements or hyperlinks to products specifically
prohibited