RAA Status & The Problem with Ruby

[Curt Hibbs]

Below, I posting the entire text of this blog entry:

http://sean.typepad.com/ditto/2005/03/the_problem_wit.html

I think that this guy has really called it right. There have been a few
postings about a reworking of RAA... does anyone know the current status of
this effort?

Curt

==========================
http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
The Problem with Ruby

I've been singing the praises of Ruby lately but I gotta come clean. There
are some real problems as well.

First, let me summarize my favorite points of Ruby:

1. Intuitive syntax for any OO programmer.
2. Rails is simply stated the perfect balance between a highly productive
and an easily manageable web application development environment.
3. The entire Ruby community is amazingly friendly and helpful.

Now for the bad:

1. Libraries are in an awful state. It appears nearly half of them are
abandoned. There's no consistency in reporting dependencies or interoperable
versions - and many don't bother at all.
2. Documentation is similarly weak. There doesn't seem to be any
conventions at all.

It may seem that these two points are minor, but I assure the Ruby community
that these two points are more than enough to frustrate 90% of the
programmers who are otherwise attracted to Ruby's syntax and Rails.
Especially when you consider Perl's massive library - I still find myself
using Perl when I'd like to use Ruby simply because I can easily find a Perl
module.

These two problems are serious enough that I'd suggest that Matz and
community establish specific standards for denoting how libraries are
packaged, documented, and version dependencies (with third party product, C
libraries, other Ruby libraries, etc.) are designated. I'd also suggest that
RAA come up with a mechanism for denoting abandoned libraries vs. ones that
simply don't need to be ugpraded. Maybe an auto-email once a quarter to the
developer?

Core libraries need to be merged, maintained, and updated regularly. It
seems that many Ruby users are on Mac OS X, yet rubycocoa is compiled for
1.6.1 of Ruby and OS X 10.2? The mysql libraries, last I checked, were also
a convoluted mess of different libraries. Let's just pick one and keep it up
to date.

Anyway, enough said. I think I've made my point. Great language, great web
framework (Python still doesn't have anything comparable), but horrendous
libraries.

 

[Curt Hibbs]

[snip]
1. Libraries are in an awful state. It appears nearly half of them are
abandoned. There's no consistency in reporting dependencies or
interoperable
versions - and many don't bother at all.

What is really bad about this is that many of the libs that are current are
*way* better than your average library, and a few are simply *brilliant*.
Many people (especially newcomers) don't know this because this brilliance
of drowned out in a sea of dead-ends.

Curt

 

[Nikolai Weibull]

* Curt Hibbs (Mar 03, 2005 13:00):

1. Libraries are in an awful state. It appears nearly half of them
are abandoned. There's no consistency in reporting dependencies or
interoperable versions - and many don't bother at all.

2. Documentation is similarly weak. There doesn't seem to be any
conventions at all.

I agree. However, there are projects that radiate excellence. Anything
written by Jamis Buck, for example,
nikolai

 

[Alexander Kellett]

What is really bad about this is that many of the libs that are
current are
*way* better than your average library, and a few are simply
*brilliant*.
Many people (especially newcomers) don't know this because this
brilliance
of drowned out in a sea of dead-ends.

this issue comes up every few months.
yet the last real answer (rpa) basically
disappeared into the mist because people
are far more interested in talking about
the problems than actually taking some
action. rpa provides the infrastructure
needed to prevent the above from happening
via its stated procedures with respect to
test suites and api versioning.

so the question really is, which bright
spark is going to put some actual work into
this. mauricio proved that developing the
infrastructure was a job for a single devoted
person. keeping the infrastructure going
requires people to actually take an interest
in ruby's future, and actually *do something*.

Alex

 

[Ilmari Heikkinen]

[from the blog post]
These two problems are serious enough that I'd suggest that Matz and
community establish specific standards for denoting how libraries are
packaged, documented, and version dependencies (with third party
product, C
libraries, other Ruby libraries, etc.) are designated. I'd also
suggest that
RAA come up with a mechanism for denoting abandoned libraries vs. ones
that
simply don't need to be ugpraded. Maybe an auto-email once a quarter
to the
developer?

And continued in the other email:

What is really bad about this is that many of the libs that are
current are
*way* better than your average library, and a few are simply
*brilliant*.
Many people (especially newcomers) don't know this because this
brilliance
of drowned out in a sea of dead-ends.

Throwing some thoughts into air:

An archive of production-quality libraries, kept up-to-date, with the
archive tools included in the stdlib. A sort of "extended stdlib." RPA?
It has a sort of standardised good practices thing in it too (
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118064 ).

It's a marketing problem aswell. If people don't know about it, they
won't use it.

So the solution is three-fold:
1. agree on the "extended stdlib" tools and appoint a maintainer for
them
2. advertise the tools until everyone knows about them (and uses them)
3. provide advocacy on the good libraries in the form of news hype and
tutorials.

The point is that the tool needs to be in the stdlib, its package
database needs to be maintained, and it needs positive exposure.


Ilmari

 

[Glenn Parker]

An archive of production-quality libraries, kept up-to-date, with the
archive tools included in the stdlib. A sort of "extended stdlib." RPA?
It has a sort of standardised good practices thing in it too (
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118064 ).

I followed that link and got to this one:

http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto

Sadly, I found that page to be 100% wikispam. Looks like
pc125.ntcpe.edu.tw was responsible. I reverted it, but I see that there
are 6 other pages affected.

One might opine that the use of easily corrupted wiki's for publishing
documentation is another problem with Ruby.

 

[Martin DeMello]

[snip]
1. Libraries are in an awful state. It appears nearly half of them are
abandoned. There's no consistency in reporting dependencies or
interoperable
versions - and many don't bother at all.

What is really bad about this is that many of the libs that are current are
*way* better than your average library, and a few are simply *brilliant*.
Many people (especially newcomers) don't know this because this brilliance
of drowned out in a sea of dead-ends.

Curt

 

[Francis Hwang]

this issue comes up every few months.
yet the last real answer (rpa) basically
disappeared into the mist because people
are far more interested in talking about
the problems than actually taking some
action. rpa provides the infrastructure
needed to prevent the above from happening
via its stated procedures with respect to
test suites and api versioning.

I was never quite clear on how RPA was supposed to do this. Not to
criticize the work of Mauricio and others, but it seemed to me to have
a scaling problem: If you have a few volunteers trying to evaluate
hundreds of Ruby libs, they're not going to have time to really
evaluate them.

I'd like to see some sort of a website where Rubyists can sign on and
then vouch for given libraries that they use from day to day. You'd be
able to search for libs based on who else is using them--it'd be, at
the least, a more automated way to find community opinion than emailing
ruby-talk and asking "What do people use when they're trying to use
Ruby with XYZ problem?"

Francis Hwang
http://fhwang.net/

 

[Francis Hwang]

Throwing some thoughts into air:

An archive of production-quality libraries, kept up-to-date, with the
archive tools included in the stdlib. A sort of "extended stdlib."
RPA? It has a sort of standardised good practices thing in it too (
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118064 ).

It's a marketing problem aswell. If people don't know about it, they
won't use it.

So the solution is three-fold:
1. agree on the "extended stdlib" tools and appoint a maintainer for
them
2. advertise the tools until everyone knows about them (and uses them)
3. provide advocacy on the good libraries in the form of news hype and
tutorials.

The point is that the tool needs to be in the stdlib, its package
database needs to be maintained, and it needs positive exposure.

I don't think it's a given that just because a certain library gets
knighted as part of an "extended stdlib" that it will automatically be
well-maintained and well-documented. In fact, there are more than a few
libs in the _actual_ stdlib that have fairly crummy documentation even
today.

Sometimes I wonder if this could be helped with a little healthy
competition. If you've got a little lib that competes with other little
libs doing the same thing, you might be more eager to write docs and
fix bugs. But if the community pre-emptively approves of code that sort
of works but isn't documented at all, you're going to have less
incentive to write docs for it.

It's sort of like running a race where everybody gets a medal; you're
not going to run as hard. Maybe that sounds like a sort of Randian
perspective on competition, but I think it's worth thinking about in
the case of Ruby--especially given the way that certain libs were,
IMNSHO, brought into the standard library too quickly.

Francis Hwang
http://fhwang.net/

 

[Randy Kramer]

I'd like to see some sort of a website where Rubyists can sign on and
then vouch for given libraries that they use from day to day. You'd be
able to search for libs based on who else is using them--it'd be, at
the least, a more automated way to find community opinion than emailing
ruby-talk and asking "What do people use when they're trying to use
Ruby with XYZ problem?"

+1!

(Another job for a wiki!?)

Randy Kramer

 

[Curt Hibbs]

this issue comes up every few months.
yet the last real answer (rpa) basically
disappeared into the mist because people
are far more interested in talking about
the problems than actually taking some
action. rpa provides the infrastructure
needed to prevent the above from happening
via its stated procedures with respect to
test suites and api versioning.

RPA could provide a very good answer to this problem. But no matter what
happens with RPA, RAA is still the public face of Ruby libraries. It is
current state it has some obvious deficiencies. It was my understanding that
this was being worked on by someone, but I'm not sure who or where things
are with this (or perhaps the effort has stalled or never even got
started)... I'm really not sure. But, I posted this in an effort find out by
raising (once again) the problem.

Curt

 

[Curt Hibbs]

+1!

(Another job for a wiki!?)

A wiki would not be the best choice for this. Anyway, this is what should be
built in to RAA.

Curt

 

[Brian Schröder]

I was never quite clear on how RPA was supposed to do this. Not to

criticize the work of Mauricio and others, but it seemed to me to have
a scaling problem: If you have a few volunteers trying to evaluate
hundreds of Ruby libs, they're not going to have time to really
evaluate them.

I'd like to see some sort of a website where Rubyists can sign on and
then vouch for given libraries that they use from day to day. You'd be
able to search for libs based on who else is using them--it'd be, at
the least, a more automated way to find community opinion than emailing
ruby-talk and asking "What do people use when they're trying to use
Ruby with XYZ problem?"

Those are just halvedone thoughts but I wanted to write it up. If you
look for something with a high snr don't read further.

I really like a package system like rpa, and its great that there are
people actually doing the work of packaging libraries. If one looks at
the debian project, it is obviously quite scalable to seperate
upstream developers from packagers.

The voting website would be a possibility, or maybe just include the
possibility to browse the rpa package tree and make comments on the
packages?

The problem with this kind of things is that they are only interesting
while they sting (until you've got your needed libraries compiled and
installed) and then they are forgotten. I haven't used rpa or gems for
quite some time, because the libs I need are now installed on my
systems.

So an applause to the people doing rubforge - raa - rpa - gems etc...
you are very important, even though its only a short contact once in a
while.

sorry for the noise,

Brian

 

[Tom Copeland]

The problem with this kind of things is that they are only interesting
while they sting (until you've got your needed libraries compiled and
installed) and then they are forgotten. I haven't used rpa or gems for
quite some time, because the libs I need are now installed on my
systems.

Very true! I remember converting my Outlook data to Evolution; there
were some bugs with the import/export routines. But once I had my data
moved over, my motivation to go back and hack on that code was nil.

So I +1 your props to the Gems guys.

Yours,

Tom

 

[James Edward Gray II]

A wiki would not be the best choice for this. Anyway, this is what
should be
built in to RAA.

I agree that this is the right way to go. We just need a little more
metadata available in the RAA, including User Ratings and Reviews.

James Edward Gray II

 

[Daniel Berger]

I don't think it's a given that just because a certain library gets
knighted as part of an "extended stdlib" that it will automatically be
well-maintained and well-documented. In fact, there are more than a few
libs in the _actual_ stdlib that have fairly crummy documentation even
today.

Francis Hwang
http://fhwang.net/

I definitely think a massive code and documentation "refactoring" is in
order for both the standard library and the core itself. Almost every
time I look at the source these days, I'm thinking "jeesh" (or worse).

But, this is where that "patch" tracker on RubyForge for the Ruby
project comes in handy. It's good for doc patches, too, folks.

Regards,

Dan

 

[Daniel Berger]

RPA could provide a very good answer to this problem. But no matter what
happens with RPA, RAA is still the public face of Ruby libraries. It is
current state it has some obvious deficiencies. It was my understanding that
this was being worked on by someone, but I'm not sure who or where things
are with this (or perhaps the effort has stalled or never even got
started)... I'm really not sure. But, I posted this in an effort find out by
raising (once again) the problem.

As Martin DeMello suggested, I definitely think a merging (of some
sort) between RubyForge and the RAA is in order.

Regards,

Dan

 

[James Britt]

A wiki would not be the best choice for this. Anyway, this is what should be
built in to RAA.

Good point.

James

 

[martinus]

I think an amazon-style thing would be cool. "Ruby hackers who use this
library also use ..." For even more ideas I think a look to
http://www.43things.com/ is a good idea. Just replace the "things" with
ruby libraries/apps, and you have a wonderful tool that helps bring
together the right people

martinus

 

[Mike Woodhouse]

I must confess to being one of those who doesn't have a clear
understanding of what's available or installed or current or deprecated
or whatever. It sounds like there's a framework for pulling this stuff
together: could that pulling be achieved by a divide-and-conquer
strategy? I.e. Individuals attack a single library at a time? I might
even feel brave enough to "do" an easy one myself...