Hi,

dblack / candle.superlink.net wrote:
> I hope Ruby will continue to be Ruby even if you write this third
> language :-)  But as for the question, I don't know.  I guess most
> languages represent an attempt to find that balance -- not
> specifically between Ruby-ish syntax and speed, but between ease of
> life for programmer and speed.

Exactly.  Right now, I have only two choices.  When I need ease of life, I
use Ruby; when I need speed, I use C.  And then, when I need both, I am
strangled in this complex world of Ruby-C integration.  Hopefully, the R
language can be a good, unified, language somewhere in between (closer to
the C side, I hope).

But if we think deeper, one of the first questions to be answered in
designing R is, do we want automatic memory management in terms of garbage
collector or not?  It is known that invalid memory access and memory leaks
are very common when the programmer manages the memory himself.  However,
this is just my guess, when we use a garbage collector, there immediately
we incur significant performance drop as compared to C.  (Not that the
application is unusable (Ruby is definitely very usable), but the measure
is applied more relative to pure C speed.)

Member data access using hashing (as in Ruby) as compared to access using
memory offset (as in C) I think is secondary, and therefore static typing
has secondary effects on performance.  And I am afraid that we
*may* already have such a language which is interpreted,
garbage-collected, and use memory offset (instead of hashing) to access
member data; the language is called.... Java (which I think is still too
slow for network simulations)

(Hmm, I guess probably the right way is to start looking from the C++ or
Objective C side, and then start reducing the language complexity from
there... Ugh, and then I haven't taken a look at that C# either...)

Regards,

Bill