From: dblack@...
Date: 2003-01-25T15:24:47+09:00
Subject: Re: Can we attack the 'not enough libraries' thing straight on?

Hi --

On Sat, 25 Jan 2003, David Garamond wrote:

> dblack@candle.superlink.net wrote:
> >>>I don't know what Simon thinks, but I really do think that exactly.  It
> >>>took me a while to find NArray.  The only reason why I can find it in RAA
> >>>now is because I already know it exists.
> >>
> >>Right. I believe there are decent Ruby modules for handling MIME mails;
> >>of course, I can't find them, because they're not sensibly named.
> >
> > Any package that doesn't turn up on an RAA search for "mime" doesn't
> > deserve to be found.  Even if it's called "marcel", it should have
> > "mime" in its description.
>
> 1) what if i have installed, say, 150 packages from RAA. i forgot which
> modules are the mime modules. of course i can search RAA again, or i can
> do a "grep -r" on my site_ruby/ directory. but with perl modules i can
> do "man -k MIME" or just know that it will be below the MIME/ subdirectory.

I was talking specifically about searching on RAA, which I thought was
what Simon meant.

I think that somehow my advocacy of the idea of getting "missing"
modules written sooner rather than later (even if naming/hierarchy
issues haven't been worked out yet) has been taken to mean that I
advocate some kind of chaos and non-searchability among Ruby modules.
I don't; I just advocate finding a way that will work, and that can
happen soon, to put an end to the "not enough libraries" rap on Ruby.

Judging from what people have been saying, it's sounding to me like
that process will be a mixture of writing modules and continuing to
make it easier to search RAA on different views.

As for searching on one's system: I think it's a given that it's good
to be able to do very high-level things to get information about
modules, and to retrieve modules.  Whether it's man -k or something
else (rpkg -something, or whatever), there's no question that easy
indexing and searching are key.

> 2) what if i have several ruby packages tarballs laying around in my
> download directory...

I guess you'd use a package analyzing utility (of which there are
several in the works, I believe :-) to analyze the contents.

> 3) what if i am looking at someone else's ruby code and see "require
> 'marcel'", "require 'bobbit'", "require 'hamster'", ...
>
> encoding some metada (esp. the categorical one) into the
> namespace/filename itself will make things much easier, much more
> predictable, much more organized. take a look at RPM packages for
> another example (in this case, an RPM filename include the
> architecture/type/version/release metadata).

My main qualm about this has always been at the last link in each
chain -- that is, the "c.rb" in "a/b/c.rb".  One problem is that if
there's one franchise holder for each potential module space, then if
that person's module isn't very good, there are all sorts of problems.
(I'm undiplomatic enough to suggest that this might happen, but would
probably be too diplomatic and/or cowardly to flag it publicly if it
did :-)

Another problem is that more than one person might well write
perfectly useable modules in the same domain, which might differ from
each other in matters of API but each be to some people's taste.
There has to be room for these.

That's why, at the very least, I would advocate naming along the lines
of text/soundex/dbsndx.rb and text/soundex/marcel.rb, rather than
text/soundex.rb.

(I have no problem with the latter style for things in the standard
distribution.)

I admit too that I have a distaste for this kind of categorization,
because it freezes a particular, sometimes unconvincing snapshot of
how the pie is sliced.  But I haven't come up with any way to do away
with it entirely.


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav