From: jm <jeffm@...>
Date: 2005-08-02T09:12:48+09:00
Subject: Re: lowering ruby's reach


On 01/08/2005, at 5:44 PM, Caleb Clausen wrote:

>> Has anyone given any thought to what ruby needs to make it reach 
>> lower into
>> areas where even now C/C++ and assembler are used?
>
> You look at zenspider's stuff yet?

I've been watching this and yarv with interest. I've tried yarv, but 
not zenspider's stuff as I've been waiting for a stable release and 
possible a how-to or walk through. Yet, this  is just bolting C closer 
to ruby. It's like inline assembler. Don't get me wrong it should make 
it a lot easier to write extensions for ruby - especially those that 
are merely for speed gains.

> The short answer: you need ways to constrain the dynamism of the
> language so the program is more predictable. Constraining the types of
> various expressions is probably the most straight-forward way to
> start.

This was what I was thinking, but raising static typing here may get 
you shouted at as a heretic. I missed the garbage collector, but now 
that you mention is it's obvious. And, didn't realise that 
missing_method and alike would case a problem.

What I was think of was the introduction of language profiles which 
would trigger certain language features. I wouldn't what to lose ruby's 
dynamic behavior which allows me to sketch out programs fast, but I 
would like to restrict it when it comes to producing production code or 
libraries for general consumption. Further from what little I've read 
it seems to be easier to produce jit and native compilers for 
statically typed languages and it's easier to make them faster (a 
counter example here may be python's psyco engine). This would look 
like the following,

# normal ruby code
a=5
puts a
a="hello world"
puts a

while with static typing,

language_profile static_types
a=5
puts a
a="hello world"
puts a

would refuse to run complaining about "hello world" not being an int.

language_profile static_types,declarations
a=5
puts a

would complain about variable a not being declared and would need to be 
change to include a forward declaration,

language_profile static_types,declarations
Int a=5
puts 5

which would work, note that a is declared a Class Int. the 
language_profile would be declared at a file level. These are trivial 
examples and there may be a better way to do this. If there is don't be 
shy (not that anyone on this list would be), but before you say it I 
use unit testing extensively.

In short, what I'm trying to think of language features that would,

1) widen ruby's usefulness
2) make it easier for the writers of language tools to implement
3) make it easy for the users of ruby to take advantage of.
4) increase the acceptance of ruby (eg, by squashing concerns about 
robustness and speed).
5) maintain backward compatibility.
6) keep ruby fun

With regard to point 6, I've already mentioned that one of the reasons 
I like ruby is that it's easy to sketch out programs before you have 
everything mapped out. This make it a good prototyping language as well 
as a good language for web and sysadmin work. This is a lot harder, at 
least for me, in C/C++.

Jeff.