[ruby-talk:03750] Re: Ubiquitous Ruby

Hi,

"Dave Thomas" wrote:

> In terms of security, I agree there are issues here, but not
> insurmountable ones.

Famous last words. :-)

> Part of my interest in this is a longer-term idea. I'd like to see Ruby
> as a dynamic, distributed programming language, running in net
> appliances as well as desktop machines. I'd like to see Ruby
> applications negotiate and broker services among themselves, providing
> the first real implementation of the roaming agent technologies that
> have been hyped over the last few years. I honestly think the
> potential is there, but to realize it we need to keep the core of
> Ruby small and flexible (hence my 'do it in a library' posts).

I think these are all of course very cool prospects, but I don't that
hypothetical possibilities (i.e. what we would call "vaporware" if this were
being said by corporations :-) should be the basis of determining what the
size of Ruby's core should be. And how small is small? Maybe the core is
already too big.

Now that we are in the biotechnology century (modulo the 6 months disputed
by purists versus conventionalists), the utility of Ruby's dynamic OO
capabilities for a huge range of _existing_ bioinformatics tasks (where Perl
and Python have made substantial inroads) may be much more important to the
human species than for extremely _hypothetical_ widespread use in net
appliances (that may have 10X or 50X more memory by the time Ruby could
become a genuinely serious contender anyway--even if it didn't suffer Jini's
fate :-). More generally, for most business, engineering, and scientific
applications (of the sort that C++ and Java and Perl and Python are
presently used for), getting a factor of 2X or 5X or more performance
increase by moderate increases in the core Ruby size would be much more
beneficial for the world-wide Ruby community and would do much more to
increase the size of that community. I think our primary focus should be in
providing very competitive (i.e. reasonably high-performance) dynamic OO for
these fields and for the great programming masses that toil therein.

Ruby is still a very young language, and partly for that reason has a small
core. Since Ruby is still a developing language, it is unreasonable not to
expect that its core will tend to grow over time as has happened with most
other successful languages. While obviously no one wants a wildly bloated
core, there is also no good reason to impose arbitrary constraints on the
continuing moderate growth of Ruby's core solely on the basis of one
potential class of applications that are subject to constraints that are
very untypical of those faced by the overwhelming majority of existing and
prospective Ruby users.

There is no reason why roaming agent technology cannot be implemented in
more conventional sorts of environments that are not memory-poor. If Ruby
becomes widely accepted, it can still move into 2nd or 3rd generation net
devices that are not memory-poor, with the advantage of having an
established support infrastructure (large cadre of experts, many
field-proven modules) and without the huge risks entailed by doing
exploratory development on the bleeding-edge. We should also keep in mind
that this is only one application of dynamic OO out of many, and one that
might well turn out to be a dud or a relatively small niche in the greater
scheme of things.

I am all for trying to do all sorts of neat new things in Ruby. But I think
we should be very wary of letting highly hypothetical tail wag a very real
dog.

Conrad