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 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
* 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);}
[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
···
On 3.3.2005, at 13:57, Curt Hibbs wrote:
--
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.
Curt Hibbs wrote:
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
<snip/>
Some possible solutions:
1. Dump the RAA.
Don't bother fixing it.
Tell people to move their code to RubyForge.
2. Dump the RAA
Tell people to find a home page for their
project and include "RAA" and "Ruby" in the keyword meta tag,
and let Google do the rest.
2. Dump the RAA
Tell people to find a home page for their
project and tag it on del.icio.us with the tags 'Ruby'
and 'RAA', plus a brief description.
I get the sense that this blogger's opinion was based entirely on what he saw at the RAA. RAA has pretty much fallen off my radar; If I'm looking for a Ruby app or lib I turn to RubyForge or Google. The RAA has tended to be too incomplete or out-of-date. I've listed things there but have more or less forgotten about their respective pages; it is just too much extra work to have a project, maintain the README and home page for that project; AND have to duplicate much of that information someplace else.
RubyForge was a godsend (thanks, InfoEtherites!) if for no other reason that it facilitates one-stop shopping for both developer and end-user.
The RAA may be like a few other things in Rubyland: a good and appropriate idea at the time of conception, but possibly past its prime or superseded by more effective tools and infrastructure.
James
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
···
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.
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-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.
···
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
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
···
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-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.
James Britt wrote:
Curt Hibbs wrote:
> 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
<snip/>
Some possible solutions:
1. Dump the RAA.
Don't bother fixing it.
Tell people to move their code to RubyForge.
2. Dump the RAA
Tell people to find a home page for their
project and include "RAA" and "Ruby" in the keyword meta tag,
and let Google do the rest.
2. Dump the RAA
Tell people to find a home page for their
project and tag it on del.icio.us with the tags 'Ruby'
and 'RAA', plus a brief description.
I get the sense that this blogger's opinion was based entirely on what
he saw at the RAA. RAA has pretty much fallen off my radar; If I'm
looking for a Ruby app or lib I turn to RubyForge or Google. The RAA
has tended to be too incomplete or out-of-date. I've listed things
there but have more or less forgotten about their respective pages; it
is just too much extra work to have a project, maintain the README and
home page for that project; AND have to duplicate much of that
information someplace else.
RubyForge was a godsend (thanks, InfoEtherites!) if for no other reason
that it facilitates one-stop shopping for both developer and end-user.
The RAA may be like a few other things in Rubyland: a good and
appropriate idea at the time of conception, but possibly past its prime
or superseded by more effective tools and infrastructure.
I pretty much agree with your assessment, but I think one more thing is
needed. There needs to be of ranking and commenting on libraries (the way
one might do with books on amazon). This would be just as useful on
RubyForge as it would be on RAA.
Curt
Quoting jamesUNDERBARb@neurogami.com, on Fri, Mar 04, 2005 at 03:37:54AM +0900:
Curt Hibbs wrote:
>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 don't agree at all. I go first to RAA, then google, I've never
searched rubyforge.
Why should somebody have to put their package on rubyforge if they have
a place they'd rather do their development?
I do think that all rubyforge projects should automatically mirror to
RAA, as has been suggested before.
I also think that RAA entries should have a comments underneath them so
that people can add a rating/comment. That would help a bunch.
Also, the standard library docs are a mess, very incomplete, and
frustratingly hard to get documentation diffs into. I now maintain a
local tree of docs, and annotate the src with my docs as I figure out
how undocumented stuff works.
Cheers,
Sam
···
<snip/>
Some possible solutions:
1. Dump the RAA.
Don't bother fixing it.
Tell people to move their code to RubyForge.
2. Dump the RAA
Tell people to find a home page for their
project and include "RAA" and "Ruby" in the keyword meta tag,
and let Google do the rest.
2. Dump the RAA
Tell people to find a home page for their
project and tag it on del.icio.us with the tags 'Ruby'
and 'RAA', plus a brief description.
I get the sense that this blogger's opinion was based entirely on what
he saw at the RAA. RAA has pretty much fallen off my radar; If I'm
looking for a Ruby app or lib I turn to RubyForge or Google. The RAA
has tended to be too incomplete or out-of-date. I've listed things
there but have more or less forgotten about their respective pages; it
is just too much extra work to have a project, maintain the README and
home page for that project; AND have to duplicate much of that
information someplace else.
RubyForge was a godsend (thanks, InfoEtherites!) if for no other reason
that it facilitates one-stop shopping for both developer and end-user.
The RAA may be like a few other things in Rubyland: a good and
appropriate idea at the time of conception, but possibly past its prime
or superseded by more effective tools and infrastructure.
James
I disagree strongly with this "dump the RAA" verdict.
I don't understand the desire to dump something simply because it is
out of date. There is nothing wrong with its core fundamentals. Its
only problem is that it is not that up to date, but that is a solvable
problem.
If it was up to date, and had mirroring capabilities, it would serve
as an excellent directory and central download repository for
anything, including .gem/.rpa. RAA's virtue is its extreme simplicity.
In terms of browsing software, and finding something quickly, its UI
beats RubyForge hands down.
My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.
I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.
So why not add mirroring capabilities to RAA and have RubyForge focus
on the things that make it useful? And have RAA be the directory, with
RubyForge having being taught to speak to RAA.
Less is more...
Leon
···
On Fri, 4 Mar 2005 03:37:54 +0900, James Britt <jamesUNDERBARb@neurogami.com> wrote:
1. Dump the RAA.
Don't bother fixing it.
Tell people to move their code to RubyForge.
2. Dump the RAA
Tell people to find a home page for their
project and include "RAA" and "Ruby" in the keyword meta tag,
and let Google do the rest.
2. Dump the RAA
Tell people to find a home page for their
project and tag it on del.icio.us with the tags 'Ruby'
and 'RAA', plus a brief description.
I get the sense that this blogger's opinion was based entirely on what
he saw at the RAA. RAA has pretty much fallen off my radar; If I'm
looking for a Ruby app or lib I turn to RubyForge or Google. The RAA
has tended to be too incomplete or out-of-date.
Curt Hibbs(curt@hibbs.com)@2005-03-03 21:07:
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.
That is exactly my problem. I have come over from the python world
and looked around but I keep running into old or dead web sites and
old or dead libraries.
Rather than getting the impression that this is a hot language I get
the feeling that this is a dying language with a diminishing
community.
Not good.
Steve
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
···
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.
Alexander Kellett 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
···
On Mar 3, 2005, at 1:07 PM, Curt Hibbs wrote:
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
Hi ..
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.
The "usual" way around this are standards and review. If a library fails to
meets its obligations, poor documentation or whatever, then perhaps it
shouldn't make it into the general release. I am not sure how this would
work for Ruby though. Certainly, the place to start is the current library.
The second part about the libraries is one of use. There are certain
libraries that I use all the time and couldn't live without. There are
others that are essential to me every now and then (including my own ones).
And there are others that are just cool to look at and get ideas from.
It is the now-and-then libraries that would seem to be the biggest issue. For
example, if I need an database wrapper class, what am I going to use? How do
I find out which one suits my needs? Documentation is a big part, the honest
comments from users to whom these libraries are essential is another.
So, perhaps the best initial first step is to provide a user-feedback option
to RAA and rate the programs a la Tucows or similar.
Sorry for the ramble ..
···
On Thursday 03 March 2005 05:14, Francis Hwang wrote:
--
-mark. (probertm at acm dot org)
Author of a few unused, badly documented libraries
In my opinion, the lack of support for the RPA had a lot to do with,
for lack of a better phrase, poor public relations.
A certain person attached himself to the RPA project and proceeded to
make enemies of pretty much everyone in the Ruby community. If you
were hanging out on ruby-talk and/or the #ruby-lang IRC channel during
that unfortunate period, you know who I'm talking about. He seems to
have moved on, to troll in browner pastures, and for that reason it
might be a good idea for us as a community to reconsider the merits of
RPA.
A related problem, which I think had a lot to do with that person, was
that there was this "rivalry" of sorts set up between the RubyGems
packaging system and RPA, and although I never saw them as competing
efforts, it seemed to be the case that one of them had to "win". My
understanding of the RPA effort was that it had a lot to do with
quality control issues and was not quite so hung up on the packaging
approach (as long as the packaging approach was consistent).
···
On Thu, 3 Mar 2005 21:21:03 +0900, Alexander Kellett <ruby-lists@lypanov.net> wrote:
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.
Simon Strandgaard suggested something like this a while back:
http://tinyurl.com/6s8ds
It could be cool...
Yours,
Tom
···
On Fri, 2005-03-04 at 03:54 +0900, Curt Hibbs wrote:
I pretty much agree with your assessment, but I think one more thing is
needed. There needs to be of ranking and commenting on libraries (the way
one might do with books on amazon). This would be just as useful on
RubyForge as it would be on RAA.
Curt Hibbs wrote:
I pretty much agree with your assessment, but I think one more thing is
needed. There needs to be of ranking and commenting on libraries (the way
one might do with books on amazon). This would be just as useful on
RubyForge as it would be on RAA.
When I saw the description of the problem, I immediately thought of how the same is true of Sourceforge, but how one of the first things I look for on a new Sourceforge project page is the "activity percentile" and the last update.
Does RubyForge have similar features? If not, how hard would it be to add to RubyForge some automated way of deciding how reliable a library is likely to be based on a combination of:
* when it was last updated
* when it was first created
* how many people use (download) it
IMHO, as a relatively new, English-speaking Ruby programmer, I'd say "dump RAA, use RubyForge, dump RPA, use RubyGems". Any features that are not in RubyGems that are in RPA could probably be put in there... though they are different goals. I think growing the already-successful RubyGems is the easier, and more natural solution.
As for RAA vs RubyForge, RAA may be actively used by our Japanese friends, but unless they need it, it seems like it's really broken and maybe shouldn't be fixed.
Ben
Sam Roberts wrote:
Quoting jamesUNDERBARb@neurogami.com, on Fri, Mar 04, 2005 at
03:37:54AM +0900:
> Curt Hibbs wrote:
> >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 don't agree at all. I go first to RAA, then google, I've never
searched rubyforge.
Why should somebody have to put their package on rubyforge if they have
a place they'd rather do their development?
There are many projects on RubyForge that do not host their project there.
Ruby on Rails is a good example. It is hosted on its own servers, tracks
bugs and issues on its own servers, but releases RubyGems to RubyForge for
easy download and install.
Curt
Quoting bitserf@gmail.com, on Fri, Mar 04, 2005 at 02:04:51PM +0900:
On Fri, 4 Mar 2005 03:37:54 +0900, James Britt
I disagree strongly with this "dump the RAA" verdict.
If it was up to date, and had mirroring capabilities, it would serve
as an excellent directory and central download repository for
anything, including .gem/.rpa. RAA's virtue is its extreme simplicity.
In terms of browsing software, and finding something quickly, its UI
beats RubyForge hands down.
++100
My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.
I agree. In fairness, a lot of the features can be turned off by the
project admins, but most don't, and its still noisy.
I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.
So why not add mirroring capabilities to RAA and have RubyForge focus
on the things that make it useful? And have RAA be the directory, with
RubyForge having being taught to speak to RAA.
Yes!
Sam