[ruby-talk:10149] Refactoring the Ruby Foundation (was: ArrayMixin 0.2)

Dave Thomas wrote:
> One day I'd love to go through the interpreter and #ifdef stuff out
> so we have a truly small base interpreter and then have the rest
> written in Ruby. RiR might be slow, but it would be a wonderful
> reference implementation.

This type of thing really excites me as well. What I'd love to see some day
is, as the standard distribution, all of the non-interpreter 'stuff' in Ruby
implemented in Ruby, with C extensions for those things that prove to be
slow and those things that are very platform-specific. Four advantages I see
to this approach:

1)	While I could kvetch about Java all day, one of the things I like about
it is that nearly all of the core libraries are written in Java itself. This
means that when I need to know usage for something in the lib, instead of
trying to find documentation, I just browse on over to the source (I'm using
VAJava) and see what it's really doing (and read the in-code javadoc). Of
course, this causes significant gnashing of teeth because the code is so
heinous, but that shouldn't be a problem with Ruby :-) Course, this would
also make an IDE much more useful, since you would be able to browse the
Ruby source for any object in the system, not just your own.

Call me crazy, but I'd rather read Ruby than C :-)

2)	It would isolate those things that vary between platforms, making porting
Ruby to new machines that much easier. If the goal is Ruby world domination,
ease of porting is critical.

3)	Similar to (2), it would be a big step in the direction of getting Ruby
'small-space' ready. I'd like to see Ruby on WindowsCE, PalmOS, routers,
printers, cellphones, watches, toasters, etc. The space limitations on many
of these devices is extreme, so it's important to be able to eliminate ALL
unnecessary baggage. The less 'built-in' functionality there is, the better.

4)	It would ferret out features that should be in the language proper
instead of tangled up in the interpreter. When I first heard about Ruby,
attr_reader, attr_writer, etc. were touted as showing the cool dynamic
nature of Ruby since such powerful constructs were implemented in the
language. Then I wanted to do some dynamic method definition and went
looking for the source for those methods... and found out they were
implemented in C! Why? My guess is because the things that they are doing
probably require an instance_eval if done in Ruby (anyone have clarification
on other reasons?). Whenever I feel like doing an instance_eval, it makes me
at least ask myself whether what I'm doing should be a part of the language
itself (sometimes it should, sometimes it should be an extension).

This point is perhaps a bit weaker than the preceding points, and I am by no
means advocating adding anything we might possibly ever need to Ruby. OTOH,
I believe the more dynamic I can make my code, the better, and implementing
the base library for a language in the language itself will show you the
most important dynamic constructs the language needs (I think). Sorry if I
confused you :)


Are there major holes in doing things this way? What other
advantages/disadvantages do others see? Matz, is this in-line or contrary to
what your future plans are for Ruby?


Nathaniel

<:((><
+ - -						+ - -
| RoleModel Software, Inc. &		| EQUIP VI
| The XP Software Studio(TM)		|