Opinion on Ruby maturity, the missing things

ruby-talk
1

Hello all,

The post by John Knight about Ruby vs. Python maturity seemed to focus just
on that, Ruby vs. Python. And since everybody probably has a strong personal
reason for using Ruby (mine is the builtin regexps and happy syntax),
there’s also reasons for not using it. Here’s my short personal view of
Ruby’s maturity in terms of what’s missing. I feel these two points are
showstoppers for Ruby from really becoming widely accepted:

  1. it’s not embeddable.

If you’ve ever tried using Ruby for, say, doing input text parsing (one of
it’s incredible strengths) in your C/C++ program (think config file or
similar), then you know it’s very difficult to embed Ruby cleanly into your
app (I’ve tried and failed).

  1. there’s no (bytecode) compiler.

Commerical applications will not use Ruby until there’s a way to guard Ruby
code from being used by others. The possibility of compiling scripts to
bytecode would be a great leap forward in this respect.

Any comments?
And yes, I know about Rite, but I’m just trying to start some discussion on
maturity here…

Regards,
Paul

2

<in_wisecracking_tone_of_voice>
Is that why no one uses Java? You can decompile the .jar files at
will…
</in_wisecracking_tone_of_voice>

<more_serious>
Clearly, no, that is not the problem. Speed is perhaps an issue, but
probably more importantly, Ruby is percieved by Pointy Haired Bosses as
weird Jap thing that nobody knows / uses.

I have yet to see a perl app that is shipped only in bytecode form, yet
Perl is weirder than Ruby and more popular with the PHB’s
</more_serious>

Real Maturity issues of Ruby…

  1. Speed compared to Perl
  2. RAA doesn’t yet match CPAN. (But then CPAN is so huge and the
    crossed up dependencies so sprawling these days, it is almost
    unusable…)
  3. Needs to come bundled with a larger slice of the RAA.
  4. Needs a “ship standalone installer + ruby + myapp + modules my app
    uses” thing.
  5. Needs a better cross platform GUI/OS layer, bundled standard.

Still, none of the above stops me from advocating Ruby as my language of
choice…

If I were to prioritise that list I would say :-

  1. bundle more of the RAA with the standard package,
  2. and create a standalone installer thing that would
    allow trivial installation of Ruby programs. ie. Telling users to first d/load
    and install vx.y.z of Ruby and Vxi.yi of RAA package_i where i goes
    from 1 to lots doesn’t work!
···

On Fri, 26 Jul 2002, Paul E.C. Melis wrote:

  1. there’s no (bytecode) compiler.

Commerical applications will not use Ruby until there’s a way to guard Ruby
code from being used by others. The possibility of compiling scripts to
bytecode would be a great leap forward in this respect.

–

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

This email message is intended only for the addressee(s) and contains
information which may be confidential and/or copyright. If you are not
the intended recipient please do not read, save, forward, disclose, or
copy the contents of this email. If this email has been sent to you in
error, please notify the sender by reply email and he will be
along to delete you, this email and any copies or links to this email.
No representation is made that this email, you, or the sender are free of
viruses. Virus scanning and prevention is recommended and is the
responsibility of consenting adults.

3

I’m curious about this. I’ve embedded Ruby in more than a few
applications, and while it’s not simple (I have to worry about
exception-safety, for example, which isn’t an easy problem to begin
with), it’s certainly not “very difficult,” imo.

Some questions:
a) What problems come up when embedding Ruby make it “very difficult”?
b) Would more documentation on the subject be helpful?
c) What do other languages (perl, python, scheme, etc.) do that make
embedding them into applications easier?
d) What else could Ruby do to make this task easier? Would a library
help?
e) Has the author of this comment tried using SWIG? Did it make his
job easier or harder?

Paul

···

On Fri, Jul 26, 2002 at 07:09:59AM +0900, Paul E.C. Melis wrote:

  1. it’s not embeddable.

If you’ve ever tried using Ruby for, say, doing input text parsing (one of
it’s incredible strengths) in your C/C++ program (think config file or
similar), then you know it’s very difficult to embed Ruby cleanly into your
app (I’ve tried and failed).

4
  1. it’s not embeddable.

If you’ve ever tried using Ruby for, say, doing input text parsing (one of
it’s incredible strengths) in your C/C++ program (think config file or
similar), then you know it’s very difficult to embed Ruby cleanly into your
app (I’ve tried and failed).

Are you talking about writing a C/C++ application and embedding Ruby
into your application?

I tried this also, and the problem I ran into on both Linux 2.4 and
WinXP was that when ruby returned it was calling exit(), or something,
because my whole application exited right after ruby did.

I thought it was just me. Is this an acknowledged bug in the Ruby
community; is anyone fixing this? I was hoping to build and engine
and had planned on using Ruby as the embedded language. Are you
saying this won’t work.

How can this be fixed?

Can we fork a new thread of discussion on this?

Sorry to detract from your original post, we need to fix this.

//ed

5

[…]
<more_serious>
Clearly, no, that is not the problem. Speed is perhaps an issue, but
probably more importantly, Ruby is percieved by Pointy Haired Bosses as
weird Jap thing that nobody knows / uses.

I have yet to see a perl app that is shipped only in bytecode form, yet
Perl is weirder than Ruby and more popular with the PHB’s

You don’t have compile Perl for it to be unreadable; just have to write it.
</less serious>
</more_serious>

-Martin

PS No language flames intended - if you think it is, can’t you laugh for once ? :slight_smile:

···

On Fri, Jul 26, 2002 at 08:44:29AM +0900, John Carter wrote:

6

Real Maturity issues of Ruby…

  1. Speed compared to Perl

I have not found ruby to be any different than Perl in
speed. I can write apps faster and maintain them better,
but they run about the same speed.
(This is taken from samples of over 20 apps and 200,000 lines
of ruby code that I have written).

  1. RAA doesn’t yet match CPAN. (But then CPAN is so huge and the
    crossed up dependencies so sprawling these days, it is almost
    unusable…)
  2. Needs to come bundled with a larger slice of the RAA.
  3. Needs a “ship standalone installer + ruby + myapp + modules my app
    uses” thing.
  4. Needs a better cross platform GUI/OS layer, bundled standard.

I’m not sure ruby should take sides here. There are plenty fine
ones to choose from. Don’t make others pay the expense.

···

On Fri, Jul 26, 2002 at 08:44:29AM +0900, John Carter wrote:

On Fri, 26 Jul 2002, Paul E.C. Melis wrote:

–
Jim Freeze
If only I had something clever to say for my comment…
~

7

“Paul Brannan” pbrannan@atdesk.com wrote in message
news:20020725194932.O22783@atdesk.com…

I’m curious about this. I’ve embedded Ruby in more than a few
applications, and while it’s not simple (I have to worry about
exception-safety, for example, which isn’t an easy problem to begin
with), it’s certainly not “very difficult,” imo.

Can you describe what the tasks for Ruby where in these applications?

Some questions:
a) What problems come up when embedding Ruby make it “very difficult”?

As given below, lack of documentation, a not very cleanly interpreter state
and problems with thread-safety. But I would go with lack of docs and
examples as the main reason.

b) Would more documentation on the subject be helpful?

YES! Also, one or two simple example applications.

And answers to questions like

  • what does ruby_run() do exactly? (without having to dive in the source to
    get the answer)
  • how do you get top-level objects, method, etc.
  • how can you execute a Ruby script from a C/C++/other application (e.g. has
    Ruby embedded in it), preferably a script precompiled to memory, and after
    that transfers control back to the application

c) What do other languages (perl, python, scheme, etc.) do that make
embedding them into applications easier?

Well, the language that I love most when it comes to easy embedding is Lua.
The main reason is that the interpreter state is fully encapsulated in a
Lua-managed block of mem. Although you need to pass the pointer to this
state for every API call you do, there are no globals anywere and it makes
it a breeze to create another Lua-interpreter in memory. The two states
won’t bite each other because you always explicitly pass the interpreter
state you’re working with.

And I’m also not sure Ruby is ready for a threaded environment yet.

d) What else could Ruby do to make this task easier? Would a library
help?

Can you be a bit more specific on what kind of library and what it would do?

e) Has the author of this comment tried using SWIG? Did it make his
job easier or harder?

Use SWIG to do what? Generate interface definitions of my own programs?
That’s not very useful is it, I want to embed Ruby in my stuff, there is
no need for it to know anything the particular application I’m writing. The
Ruby API in the headers should be all that is necessary to do embedding.

Regards,
Paul

8

“John Carter” john.carter@tait.co.nz wrote in message
news:Pine.LNX.4.44.0207261037400.11795-100000@parore…

  1. there’s no (bytecode) compiler.

Commerical applications will not use Ruby until there’s a way to guard
Ruby
code from being used by others. The possibility of compiling scripts to
bytecode would be a great leap forward in this respect.

Actually, I should have been clearer on the view I had of Ruby embedded in
an application and a bunch of precompiled Ruby scripts coming with the app.

<in_wisecracking_tone_of_voice>
Is that why no one uses Java? You can decompile the .jar files at
will…
</in_wisecracking_tone_of_voice>

Sure, but that won’t make them very useful without the original variable
names and lack of documentation, to name a few. It’s not about counteracting
reverse-engineering, it’s about keeping others from simply stealing your
code, which is darn easy when it’s just sitting there unprotected in a text
file.

I have yet to see a perl app that is shipped only in bytecode form, yet
Perl is weirder than Ruby and more popular with the PHB’s

You probably wouldn’t have mentioned this if I had been clearer in the
original post. I have never seen an application that has Perl embedded in
it. Perl scripts are distributed frequently with apps, but they are almost
always stand-alone or use a pipe or socket to talk to the main application.
And I have also never seen a bytecode compiled version of Perl script, but
this should change with version 6 and Parrot coming up.

Regards,
Paul

···

On Fri, 26 Jul 2002, Paul E.C. Melis wrote:

9

Hi,

I tried this also, and the problem I ran into on both Linux 2.4 and
WinXP was that when ruby returned it was calling exit(), or something,
because my whole application exited right after ruby did.

I thought it was just me. Is this an acknowledged bug in the Ruby
community; is anyone fixing this? I was hoping to build and engine
and had planned on using Ruby as the embedded language. Are you
saying this won’t work.

Use rb_eval_string_protect() instead of ruby_run().

#include <ruby.h>
#include <stdio.h>

int main(int argc, char **argv)
{
int state;
ruby_init();
ruby_script(argv[0]);
rb_p(rb_eval_string_protect(argv[1], &state));
if (state) {
rb_p(ruby_errinfo);
}
return state;
}

···

At Wed, 31 Jul 2002 04:36:54 +0900, Edward Wilson wrote:

–
Nobu Nakada

10

Who needs to take sides? If there are two prime time ready modules for the
same niche, bundle both.

The aim is to get to a state where you can exchange scripts that will
“work out of the box” with the standard bundle. Currently too much of RAA
and far too much of CPAN will only work once you have download a long
list of modules, sometimes entering into circular tangles of mutually
incompatible versions.

Large footprint for the developer is not a problem. I love having a rich
library to pick and choose from. A 20Gb drive is smaller than you
can buy at the moment.

Having developed something I want a way of navigating the module “require”
tree to package up a small footprint package to install on the users
machine

There is a niche in the Ruby environment for “distro” makers. Like RedHat
/ Debian / SUSE / Slackware / … download, resolve dependency
conflicts and bundle up literally thousands of Linux apps for you to
enjoy, there is a niche for a super rich Ruby distro.

And like the Linux distro’s there is a need for ultra lean linux on a
floppy distro’s, there is also room for a super barebones embedded Ruby
distro.

···

On Fri, 26 Jul 2002, Jim Freeze wrote:

I’m not sure ruby should take sides here. There are plenty fine
ones to choose from. Don’t make others pay the expense.

–

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

This email message is intended only for the addressee(s) and contains
information which may be confidential and/or copyright. If you are not
the intended recipient please do not read, save, forward, disclose, or
copy the contents of this email. If this email has been sent to you in
error, please notify the sender by reply email and he will be
along to delete you, this email and any copies or links to this email.
No representation is made that this email, you, or the sender are free of
viruses. Virus scanning and prevention is recommended and is the
responsibility of consenting adults.

11

[dd]

You probably wouldn’t have mentioned this if I had been clearer in the
original post. I have never seen an application that has Perl embedded in
it.

Exim (http://www.exim.org) has optional an embedded Perl interpreter.

Quoting:
“… embedded Perl interpreter, which allows Perl subroutines to be called
during string expansion.”

On other hand, Vim (http://www.vim.org) has optional Ruby interpreter.

Quoting again:

“Vi IMproved version 6 with embedded Ruby interpreter”

Perl scripts are distributed frequently with apps, but they are almost
always stand-alone or use a pipe or socket to talk to the main application.
And I have also never seen a bytecode compiled version of Perl script, but
this should change with version 6 and Parrot coming up.

Regards,
Paul

Regards,

···

On Fri, Jul 26, 2002 at 07:31:22PM +0900, Paul E.C. Melis wrote:

Igor A. Karpov phone: +380(44)238-0624
Unix System Administrator

  Hurry up and jump on the individualist bandwagon!
12

“Paul Brannan” pbrannan@atdesk.com wrote in message
news:20020725194932.O22783@atdesk.com…

I’m curious about this. I’ve embedded Ruby in more than a few
applications, and while it’s not simple (I have to worry about
exception-safety, for example, which isn’t an easy problem to begin
with), it’s certainly not “very difficult,” imo.

Can you describe what the tasks for Ruby where in these applications?

Some of these tasks were:

  1. A scriptable configuration file; Ruby can make calls into C++ code
    to set various configuration values, or the C++ code can pull these
    values from a hash. In one case, this configuration file contains
    Ruby code that gets called at various points during the C++
    program’s execution.
  2. A “guru mode” for a server; the user connects to a socket, and
    types ruby code like in irb; the code is evaluated, and may make
    calls into C++ functions.
  3. A driver for a C++ program where an extension would not work. I
    originally tried making an extension, and the program segfaulted
    (possibly due to a global C++ object not getting properly
    initialized). As a compromise, I added a few lines to a .cpp file,
    where the last line was ruby_run(). I now have a C++ program that
    acts like a full Ruby interpreter, but has extra “built-in”
    functions available.

Some questions:
a) What problems come up when embedding Ruby make it “very difficult”?

As given below, lack of documentation, a not very cleanly interpreter state
and problems with thread-safety. But I would go with lack of docs and
examples as the main reason.

I also had problems in this area when I first started. The pickaxe book
pointed me in the right direction, but I had to read the source to
really know what was going on.

c) What do other languages (perl, python, scheme, etc.) do that make
embedding them into applications easier?

Well, the language that I love most when it comes to easy embedding is Lua.
The main reason is that the interpreter state is fully encapsulated in a
Lua-managed block of mem. Although you need to pass the pointer to this
state for every API call you do, there are no globals anywere and it makes
it a breeze to create another Lua-interpreter in memory. The two states
won’t bite each other because you always explicitly pass the interpreter
state you’re working with.

This is definitely a problem with Matz’s implementation of Ruby.
Hopefully Rite (Ruby 2.0) will fix this problem.

And I’m also not sure Ruby is ready for a threaded environment yet.

d) What else could Ruby do to make this task easier? Would a library
help?

Can you be a bit more specific on what kind of library and what it would do?

A library that is:
a) Well-documented
b) Has useful functions for writing applications with Ruby embedded
that make the job easier (maybe a one-liner that starts an
interpreter, for example).
c) Properly initializes Ruby for the user, so that the user cannot
make the mistake of leaving out calls to key functions, such as
rb_init_loadpath().

I’m just brainstorming here; I don’t really have a clear idea of what
this library would look like or how it would be used.

e) Has the author of this comment tried using SWIG? Did it make his
job easier or harder?

Use SWIG to do what? Generate interface definitions of my own programs?
That’s not very useful is it, I want to embed Ruby in my stuff, there is
no need for it to know anything the particular application I’m writing. The
Ruby API in the headers should be all that is necessary to do embedding.

Often, it’s useful for Ruby to be able to call into C/C++ code, and not
just vice-versa. Imagine using Ruby to script a Gimp plug-in; having
access to the Gimp’s entire set of image manipulation functions would be
very useful.

Paul

···

On Fri, Jul 26, 2002 at 07:31:20PM +0900, Paul E.C. Melis wrote:

13

Sure, but that won’t make them very useful without the original variable
names and lack of documentation, to name a few. It’s not about
counteracting
reverse-engineering, it’s about keeping others from simply stealing your
code, which is darn easy when it’s just sitting there unprotected in a
text
file.

True enough. I wonder if there is room/need for an
automatic obfuscator? Would be fairly easy for most
cases, perhaps impossible in the general case. (For
example, if a string is built dynamically and then
eval’d, it may depend on the existence of certain
variables which would be difficult/impossible to
rename then).

I have yet to see a perl app that is shipped only in bytecode form,
yet
Perl is weirder than Ruby and more popular with the PHB’s

You probably wouldn’t have mentioned this if I had been clearer in the
original post. I have never seen an application that has Perl embedded
in
it. Perl scripts are distributed frequently with apps, but they are almost
always stand-alone or use a pipe or socket to talk to the main
application.
And I have also never seen a bytecode compiled version of Perl script, but
this should change with version 6 and Parrot coming up.

Well, there is such a thing as PerlScript
(ActiveStatePerl, I guess?). And the HomeSeer
app is one case where (some) people do use
embedded Perl in this way (www.homeseer.com).

And there is ActiveScriptRuby (by arton) which
works fine in general, but I can’t get it to
work in HomeSeer.

Guess we’re wandering offtopic now, though. And
I’m replying days after the fact, since I’ve
been out of town.

Hal

···

----- Original Message -----
From: “Paul E.C. Melis” paul@floorball.nl
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Friday, July 26, 2002 5:31 AM
Subject: Re: Opinion on Ruby maturity, the missing things

14

I’m not sure ruby should take sides here. There are plenty fine
ones to choose from. Don’t make others pay the expense.

Who needs to take sides? If there are two prime time ready modules for the
same niche, bundle both.

I know what you are saying, and I am trying to not be resistant to change,
but there are several issues here that make bundling gui’s ineffective.
My experience has been that the ruby part is very easily obtained and
installed. The hard part is getting the library installed.
And after causing code bloat with the bundling, you will be lucky
if you got the version that your downloaders needed.

Instead of adopting a ‘nice little commercial package’ model, I
think your comments about a distribution below make a better solution.

The aim is to get to a state where you can exchange scripts that will
“work out of the box” with the standard bundle. Currently too much of RAA
and far too much of CPAN will only work once you have download a long
list of modules, sometimes entering into circular tangles of mutually
incompatible versions.

Large footprint for the developer is not a problem. I love having a rich
library to pick and choose from. A 20Gb drive is smaller than you
can buy at the moment.

Having developed something I want a way of navigating the module “require”
tree to package up a small footprint package to install on the users
machine

There is a niche in the Ruby environment for “distro” makers. Like RedHat
/ Debian / SUSE / Slackware / … download, resolve dependency
conflicts and bundle up literally thousands of Linux apps for you to
enjoy, there is a niche for a super rich Ruby distro.

I agree that Ruby needs a good solution here. This is one of the
main topics discussed (and we even had a brainstorming session) at
the first ruby conference.

Boy I hope ruby does not end up with the fractured model that
linux has ended up with. Diversity in this scenario is not a source
of strength. I think unity is needed. I would rather see ruby with
a unified solution (like CPAN or BSD). We definetly have the language
to create a good solution.

···

On Fri, Jul 26, 2002 at 10:10:05AM +0900, John Carter wrote:

On Fri, 26 Jul 2002, Jim Freeze wrote:

–
Jim Freeze
If only I had something clever to say for my comment…
~

15

And can also be built with a Perl, Python, and/or TCL interpreter.

···

On Friday 26 July 2002 03:59 am, Igor Karpov wrote:

On other hand, Vim (http://www.vim.org) has optional Ruby
interpreter.

–
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

16

“Igor Karpov” jc@minjust.gov.ua wrote in message
news:20020726105836.GV79354@key.minjust.gov.ua…

[dd]

You probably wouldn’t have mentioned this if I had been clearer in the
original post. I have never seen an application that has Perl embedded
in
it.

Exim (http://www.exim.org) has optional an embedded Perl interpreter.

Well, that’s the first time I heard about it. Did some searching on
Freshmeat, and yes, there’s more projects, but not many.

On other hand, Vim (http://www.vim.org) has optional Ruby interpreter.

Right, that was done by one of the developers of Ruby (Shugo Maeda). Note
however, that he knows - and uses - internal Ruby stuff that is nowhere to
be found in the documentation (e.g. usage of ruby_init_loadpath() and
rb_eval_string_protect()).

My point being that, yes Ruby (and Perl) is being used in some cases as an
embedded language, but that’s not because in those instances people simply
picked up the documentation and started hacking. There simply is not enough
information available in the docs for that.

Regards,
Paul

···

On Fri, Jul 26, 2002 at 07:31:22PM +0900, Paul E.C. Melis wrote:

17

“Paul Brannan” pbrannan@atdesk.com wrote in message
news:20020726153631.A14534@atdesk.com…

Can you describe what the tasks for Ruby where in these applications?

Some of these tasks were:

  1. A scriptable configuration file; Ruby can make calls into C++ code
    to set various configuration values, or the C++ code can pull these
    values from a hash. In one case, this configuration file contains
    Ruby code that gets called at various points during the C++
    program’s execution.

This is exactly what I was trying to accomplish some months ago. I gave up
then because of lack of docs and problems I suspected where
threading-related (not my favorite stuff to investigate). I resorted to
using plane windows .ini files :confused:

  1. A “guru mode” for a server; the user connects to a socket, and
    types ruby code like in irb; the code is evaluated, and may make
    calls into C++ functions.
  2. A driver for a C++ program where an extension would not work. I
    originally tried making an extension, and the program segfaulted
    (possibly due to a global C++ object not getting properly
    initialized). As a compromise, I added a few lines to a .cpp file,
    where the last line was ruby_run(). I now have a C++ program that
    acts like a full Ruby interpreter, but has extra “built-in”
    functions available.

Cool stuff! Nice to see someone more persistent than me getting it done…

Some questions:
a) What problems come up when embedding Ruby make it “very
difficult”?

As given below, lack of documentation, a not very cleanly interpreter
state
and problems with thread-safety. But I would go with lack of docs and
examples as the main reason.

I also had problems in this area when I first started. The pickaxe book
pointed me in the right direction, but I had to read the source to
really know what was going on.

Yup, had the same experience, not a good sign huh?

c) What do other languages (perl, python, scheme, etc.) do that make
embedding them into applications easier?

Snip, [Lua’s state handling]

This is definitely a problem with Matz’s implementation of Ruby.
Hopefully Rite (Ruby 2.0) will fix this problem.

I can’t imagine it won’t :slight_smile:

Can you be a bit more specific on what kind of library and what it would
do?

A library that is:
a) Well-documented
b) Has useful functions for writing applications with Ruby embedded
that make the job easier (maybe a one-liner that starts an
interpreter, for example).
c) Properly initializes Ruby for the user, so that the user cannot
make the mistake of leaving out calls to key functions, such as
rb_init_loadpath().

I’m just brainstorming here; I don’t really have a clear idea of what
this library would look like or how it would be used.

Right, kind of a higher-level lib for easy embedding. Not a bad idea…

e) Has the author of this comment tried using SWIG? Did it make his
job easier or harder?

Use SWIG to do what? Generate interface definitions of my own programs?

Often, it’s useful for Ruby to be able to call into C/C++ code, and not
just vice-versa.

Okay, I can see how that would alleviate some of the handwork of adding the
c+±side thingies into Ruby. Hadn’t considered it actually, mostly because I
haven’t used SWIG.

Paul

···

On Fri, Jul 26, 2002 at 07:31:20PM +0900, Paul E.C. Melis wrote:

18

I’m not sure ruby should take sides here. There are plenty fine
ones to choose from. Don’t make others pay the expense.

Who needs to take sides? If there are two prime time ready modules for the
same niche, bundle both.

The aim is to get to a state where you can exchange scripts that will
“work out of the box” with the standard bundle. Currently too much of RAA
and far too much of CPAN will only work once you have download a long
list of modules, sometimes entering into circular tangles of mutually
incompatible versions.

Personally, I would prefer a base install which included a pre-
configured rpkg or rapt, and a series of distributed synched rpkg or
rapt mirrors (ala the Debian packaging system).

Large footprint for the developer is not a problem. I love having a rich
library to pick and choose from. A 20Gb drive is smaller than you
can buy at the moment.

A large footprint for users is a problem, especially modem users.
There’s no reason a user or a developer should have to download an extra
five megs of libraries and documentation that they’re never going to use.
A working package management and distribution system gives users and
developers both a lean install and a rich library of libraries to choose
from.

I realize you’re talking about separate Ruby “bundles”, but I’m not so
sure that’s a good idea. We already have different distributions for
different platforms, including multiple distributions for the same
platform (eg, multiple releases for Windows with different sets of
included packages). There’s nothing wrong with having more than a few
“official” releases. However, I believe we should be wary providing too
many choices for a the following reasons:

  • It complicates end-user installation. Ever seen a kid in a candy
    store? How is a novice user supposed to distinguish between
    ruby-1.8.4-large.tar.gz, ruby-1.8.4-medium.tar.gz,
    ruby-1.8.4-small.tar.gz, ruby-1.8.4-large.exe, ruby-1.8.4-large2.exe,
    ruby-1.8.4-small_by_someone_else.exe, etc? I’ve seen users – even
    technically adept ones – aghast at the sheer number of options
    available in certain installation programs and preference dialog boxes.

  • It complicates development and deployment. Multiple base
    distributions complicate deployment plans for developers because it
    gives them multiple, moving targets. Imagine the following
    conversation:

    “Are regular expressions available with Ruby?”
    “Sure, that comes with every distribution of Ruby.”
    “Is an XML parser available with Ruby?”
    “Well this distribution of Ruby includes REXML, but this other
    distribution includes NQXML, and these two over here don’t include
    one at all.”

    The solution usually involves one of the following: hand-rolling and
    including “yet another” mini-implementation in order to guarantee your
    software will run (quick quiz: how many APIs are there to create
    linked lists on your system?), requiring users to manually traverse a
    list of dependencies in the README and compile and install each one
    (how many emails have you gotten about OpenSSL not compiling properly
    on a users’ system?), or distributing and using a specific version of
    each dependency along with your package, thus negating the benefit
    of shared objects and DLLs.

Again, I’m not saying we should impose some sort of draconian package
restriction on the various Ruby distributions. Rather, I believe the
effort required for the “A Different Ruby for Everyone!” system you’re
proposing would be better spent on maintaining and extending the rich
standard API we already have, and deploying a standard Ruby library
package distribution system.

Having developed something I want a way of navigating the module “require”
tree to package up a small footprint package to install on the users
machine

There is a niche in the Ruby environment for “distro” makers. Like RedHat
/ Debian / SUSE / Slackware / … download, resolve dependency
conflicts and bundle up literally thousands of Linux apps for you to
enjoy, there is a niche for a super rich Ruby distro.

And like the Linux distro’s there is a need for ultra lean linux on a
floppy distro’s, there is also room for a super barebones embedded Ruby
distro.

–
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand
[snipped uninforceable and inappropriate email suffix]

···
  • John Carter (john.carter@tait.co.nz) wrote:

On Fri, 26 Jul 2002, Jim Freeze wrote:

–
Paul Duncan pabs@pablotron.org pabs in #gah (OPN IRC)
http://www.pablotron.org/ OpenPGP Key ID: 0x82C29562