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