Re: thoughts on typelessness

Hi David,

Your exposition is very wide and deep.  I will try to respond to just one
part of it:

[e-mail] wrote:
> All of this is so enthralling to me that I'm always surprised when
> people advocate explicit typing (in one form or another) for Ruby.  It
> seems that, in spite of everything (including the existence of other
> languages for those made queasy by typelessness), a number of Ruby
> users are more drawn to type-based programming than away from it.  I
> wonder why this is.

In a "statically typed" language (such as C), variables have types, while
data do not.  In a "dynamically typed" language (such as Ruby), variables
do not have types, while data do.  You see, we always need some "type",
but the problem is usually where to put it.  If variables have types, then
the compiler/interpreter works harder by keeping track of them, but the
data representation in the memory is more efficient: int is "always" 4
bytes in a memory location somewhere, and double is "always" 8 bytes in a
memory location somewhere (well, "always" means for a particular
machine/os.)

When variables are typeless such as in Ruby, then the types should be
stored in the data themselves.  A Float is not only 8 bytes of memory.  A
Float has to contain some bytes to signify its type.  When gc is presence,
than a Float datum also has to contain either a reference count or a mark
bit.  (Ruby is pretty good in this respect, that it has minimized all
those extra bits and bytes per object.)  Nonetheless, I think this is
true: in general, a statically typed language will have smaller memory
print than a dynamically typed language.

When variables have types, then it is possible to access data using
memory offset (which a computer will gladly do for us) rather than
using a hash function (in which a computer has to perform multiple extra
steps).  So I think this is also true:  for a given task, while the Ruby
code is probably 2 - 10 times shorter than a corresponding C code, the
net computer instructions run by the Ruby code is probably 2 - 10 times
more than that of the corresponding C code.

I think Ruby is so far the best from the programmer's point of view, while
C (we exclude assembly for now) is the best from the computer's point of
view.  Well, we all are programmers, so we love Ruby.  But when my
computer does not give me my desired result in 10 hours, then I have to
take care of my computer also so that it can give me the result in 1 hour
instead.  So far, the solution is to convert the core to C while leaving
the peripherals and interfaces in Ruby, similar in spirit to what Alan
Chen has mentioned.

Now, the question is, have we fully examined the design space between Ruby
and C?  If we come out with a language that is 50% the easiness of Ruby
and 50% of the performance of C, I don't think there is any useful
effort.  However, if it turns out that we can create something that is 80%
the easiness of Ruby and at the same time 80% the performance of C, I
think we really can call that a progress.

When we examine the design space between C and Ruby, then usually
static/dynamic typing is the first thing to come to mind, as these two
languages are exactly at the opposite spectrum in this respect.  And of
course, then all those discussions (such as R) follow...

Finally, it is true that for purely numerical computations, a solution
such as Ruby's NArray suffices, because basically we need only integers,
floats, and arrays, and they are usually static during the whole process
(which sometimes may take hours or even days).  However, a network 
simulation is entirely different, as we do need struct's/objects, and some
of those objects are highly dynamic (such as communication packets) while
some are really static (such as network nodes and links).  I have used a
commercial software which is totally based on C, and it is relatively
fast, but it takes so long to develop and test new protocols and
algorithms.  That's why I am exploring Ruby.  So far the programming
experience has been extremely great, but the resulting code performance is
not so.  That's why I am thinking other possibilities...

Regards,

Bill