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.
