From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2000-10-23T19:34:50+09:00
Subject: [ruby-talk:5782] Re: Dynamic languages, SWOT ?

On Mon, 23 Oct 2000, Dave Thomas wrote:

> A type is defined by a state domain and a set of operations that
> (normally) act on that domain. The state domain determines the valid
	[...]
> Many languages, such as C and Fortran, have built-in types, such as
	[...] 
> Some languages, such as Pascal, have the ability to create new types
> based on these existing types. In Pascal, these new types have the
> same operations as their base types, but their domain is restricted to 
> some subset of their parent's domain.
> 
> Object-oriented languages extend the paradigm. Now we can define a
> class, where we manage the state internally and export the operations
	[...] 
> Languages such as Java (and, less elegantly, C++), introduce a
> twist. Using multiple inheritance or using interfaces, a class may
	[...] 
> 
> So, on to Ruby, Smalltalk, and the like.
> 
> Here the picture is somewhat more subtle. At their simplest,
> Ruby classes implement types, and subclasses implement subtypes. Ruby
> mixins add capabilities similar to interfaces, and hence associate
> multiple types with a class (for example, [1,2,3] is both an Array and
> an Enumerable object).

This seems to be the crux of what is gained by having a dynamic language.
And it would seem to make type checking very difficult.
> 
> However, Ruby differs from Java and other static languages in that it
> does not check the types of objects at compile or runtime. It doesn't
> care about an object's class per se. Instead, it cares that an object
> implements the required methods. This leads to interesting
> possibilities.  For example, things that would traditionally be
> implemented as subclasses in order to pass type-checking need not be
> in Ruby. Instead, they can be implemented as two independent classes
> that happen to implement a common set of methods (Think of the way that
> you can use ARGF as a File, or ENV as a Hash, even though they are
> actually just Objects.) So, Ruby immediately gives us a more complex
> class/type relationship:
	[...]
I had not noticed how these were implemented but they are very powerful.
> 
> Many classes can implement a type, and any one class can have many
> types.
> 
> Then we muddy the waters even further. In Ruby, you can extend both
> classes and objects while your program is running. Say you want to

Yes, with new methods and Mix-ins.
	[...]
> 
> Given this tremendous flexibility, I'm not sure how an enforced system 
> of static tye checking could be shoe-horned in to Ruby: the paradigms
> are just plain different.

I think this answers my question.  I have not done much with Mix-ins
myself, but have bumped into them of course.  This is something I will
look into further.
> 
> In my opinion, this is not a bad thing. While programming Ruby, I have 

I was not trying to suggest that it was a bad thing :-).  I was trying
to see why not having type checking provided some advantaage(s) that
outweighed the advantages type checking gives.  I think you have answered
this pretty effectively.  It could be summarized by saying it is more of
a consequence of the extra flexibility than an intentional omission, but
the power gained by sacrificing it is considerable.  It can be worth
sacrificing a knight to allow a pawn to become a queen, but it doesn't
mean knights are worthless.


> never really felt the need for static type analysis nor for dynamic
> type checking. In the face of mutable types and extendible classes,
> I'm not even sure what form type checking could take.
> 
> Help me understand the other point of view.

:-)  I have used type checking langauges rather a lot.  This was exactly
my point, I want to understand the point of view of dynamic languages.
> 
> 
> Regards
> 
> 
> Dave
> 
	Thank you,
	Hugh
	hgs@dmu.ac.uk