Asp Forum - RAA Status & The Problem with Ruby

Curt Hibbs

3/3/2005 11:57:00 AM

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

http://sean.typepad.com/ditto/2005/03/the_proble...

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_proble...
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.

110 Answers

Curt Hibbs

3/3/2005 12:07:00 PM

Curt Hibbs wrote:
>
[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

3/3/2005 12:12:00 PM

* 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

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Alexander Kellett

3/3/2005 12:21:00 PM

On Mar 3, 2005, at 1:07 PM, Curt Hibbs wrote:
> 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

3/3/2005 12:29:00 PM

On 3.3.2005, at 13:57, Curt Hibbs wrote:
> [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-t... ).

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
--
66. The regions beyond these places are either difficult of access
because of their excessive winters and great cold, or else cannot be
sought out because, of some divine influence of the gods.

Glenn Parker

3/3/2005 12:51:00 PM

Ilmari Heikkinen wrote:
>
> 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-t... ).

I followed that link and got to this one:

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

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.

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoi...

Martin DeMello

3/3/2005 1:06:00 PM

Curt Hibbs <curt@hibbs.com> wrote:
> Curt Hibbs wrote:
> >
> [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

3/3/2005 1:08:00 PM

On Mar 3, 2005, at 7:21 AM, Alexander Kellett wrote:

> On Mar 3, 2005, at 1:07 PM, Curt Hibbs wrote:
>> 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.

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://f...

Francis Hwang

3/3/2005 1:15:00 PM

On Mar 3, 2005, at 7:28 AM, Ilmari Heikkinen wrote:
> 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-t... ).
>
> 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://f...

Randy Kramer

3/3/2005 1:54:00 PM

On Thursday 03 March 2005 08:07 am, Francis Hwang wrote:
> 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

3/3/2005 1:55:00 PM

Alexander Kellett wrote:
>
> On Mar 3, 2005, at 1:07 PM, Curt Hibbs wrote:
> > 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.

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

> 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
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.6.0 - Release Date: 3/2/2005
>

comp.lang.ruby

RAA Status & The Problem with Ruby

Curt Hibbs

Curt Hibbs

Nikolai Weibull

Alexander Kellett

Ilmari Heikkinen

Glenn Parker

Martin DeMello

Francis Hwang

Francis Hwang

Randy Kramer

Curt Hibbs

x Login to ForumsZone