From: Trans <transfire@...>
Date: 2008-08-08T20:46:00+09:00
Subject: Re: perl and the culture of libraries



On Aug 5, 4:33 pm, Mark Thomas <r...@thomaszone.com> wrote:
> I agree with Advi and Martin that the landing page of a project is
> important. The CPAN authors' documentation quality improved because of
> CPAN, not the other way around. Rubyforge would lead to better Ruby
> libraries if it looked less like Sourceforge and more like the module
> pages athttp://search.cpan.org. This is not to knock Rubyforge; it
> filled a community need. But I think the community deserves more now.
>
> On that note, let's look at a sample distribution page (http://
> search.cpan.org/~abw/Template-Toolkit-2.19/). For those unfamiliar
> with CPAN, a distribution is sort of the "top level"; it can contain
> many modules. CPAN is a lot more than well-documented modules. There
> are ratings and reviews, which can help when your searches bring up
> multiple modules that do the same thing. I find it useful for
> identifying abandon-ware: sometimes you'll see in a review that the
> module has been superceded by another. There is also a gaggle of
> volunteers who test Perl modules on various platforms. This is
> invaluable if you are using a non-mainstream environment (e.g. cygwin)
> or if the module has C extensions. And it's fairly automated; there's
> a CPAN module called Test::Reporter and a special version of CPAN
> (CPANPLUS) that can automatically download a module, run its test
> suite, and report results. You can also find dependencies prior
> versions. Like Rubyforge, there are discussions and bug reporting that
> are sometimes used, sometimes not.
>
> Module authors tend to use Module::Starter which is just like hoe, in
> that it generates a nice module skeleton, ready to submit to CPAN.
> Another thing I noticed about module authors is that they tend to use
> more pragmatic, namespaced module names, i.e. they would tend to use a
> name like "PDF::Simple" instead of "prawn". Though this may be due to
> the fact that 14,000 modules require a bit more organization and
> findability.

While there is no hard standard for Ruby, the general convention for
namepaces is the opposite of Perl.

In Perl for instance you might find "PDF::EasyPDF" or "PDF::API2". It
is the second (or last) part of the namespace that makes it unique.
This leads to many project names having more technical names (eg.
API2), rather than colorful names.

In the Ruby world the general convention has moved in the opposite
order. With the unique name coming before the technical
classification. Eg. RedCloth::TextileDoc, or LibXML::XML::Document.

The reason for the difference stems from the fact that Perl
development is organized around CPAN, which is organized by module
namespace, whereas Ruby development is much more decentralized and the
main organizing factor is RubyGems with organizes us by project names.
I also suspect this difference arises in no small part to the fact
that Ruby file names do not have to match our module names (though it
can be a helpful practice to do so).

We can of course argue about which is better. Some Ruby developers
have taken to trying the Perl way, but b/c of the decentralized nature
of Ruby development, name clashes in these cases are not uncommon. I
find the Ruby convention preferable, since it allows for more easily
including modules into my own for convenience. Eg.

  module MyApp
    include LibXML
    doc = XML::Document.new
    ...
  end

T.