On Tuesday 05 August 2008 07:56:22 Martin DeMello wrote:
(excerpt quoted from the linked article)
>    The important thing about Perl is that we have a culture of writing
> good libraries. No Perl programmer would write a few lines of code,
> post it to a blog, and call it a "library". Everyone feels obligated
> to create a CPAN distribution, with documentation (sometimes a bit on
> the minimal side, but not everyone is a writer), a test suite, a
> Makefile, etc. I'm not sure why, but this always happens. I think it's
> because there is a strong convention, and tools that make following
> the convention easy.

This is somewhat true, and somewhat not. I think the best way to encourage it 
would be to build a public, web-facing index of gems, and evolve some 
community pressure. It could be as simple as a rating system -- actually 
embarrass people for putting up poorly-documented, poorly-tested code.

Some automated tools could help with that, but this is really a social 
project. As you said:

> Hoe and friends
> [http://nubyonrails.com/articles/tutorial-publishing-rubygems-with-hoe]
> are a great step forward, but their use doesn't seem to be widespread
> yet.



Before I start my rant, I'm going to provide my suggestion. I think this is 
more important than the rant, and I realize some people will get bored.

I suggest that we work on improving the gem system itself. Specifically, we 
need to make it as flexible, powerful, and _easy_ as possible, so that people 
stop developing things like Rails Plugins.

Right away, the biggest feature I miss is reverse dependencies. (Not that CPAN 
had them...) I want to be able to safely install a gem, test it out, and 
remove it, and not have to go hunting in my gems directory for other things 
I'd like to remove.

Second biggest would be virtual dependencies -- only second biggest because I 
don't know if they exist or not. If not, they should. I should be able to 
depend on "any Rack engine", not just Rack itself, and certainly not specific 
things like Mongrel or Thin.



Now, there is another disturbing thing about Ruby, at least, coming from a 
formerly-Perl perspective:

Perl encourages people to modularize. CPAN packages are (at least, in my 
limited experience) consistently named, and the actual namespace within the 
language generally matches the name of the package on CPAN.

In Ruby, I've mostly seen polar opposites: Either tiny little gems with few 
external dependencies, which will play nice with almost anything -- metaid is 
an extreme example -- or HUGE gems like Rails.

Yes, I realize Rails is broken up into several gems. Well, three of them, 
really -- actionpack, activerecord, and activesupport.

I'm going to argue that activesupport should be at least 10, maybe 20 
different packages -- there are so many little pieces of it that I wish I 
could use for a one-off script, without pulling in the whole library. Things 
like symbol-to-proc, 3.days.ago, etc. But it's going to add significantly to 
the startup time of my script even to require activesupport -- that's bloat.

And ActiveRecord -- why, exactly, is validation included? Why not make it a 
mixin? That way, with duck typing, I could pull at least some of the default 
Rails validations into another ORM. (validates_uniqueness_of might even work, 
if the #find methods are similar.)

Things like Rack are a refreshing step forward -- but there are very few 
things like Rack.

In Perl, there's an XML namespace, and most XML things are done through 
XML::Parser, which provides a common frontend to several actual XML parsers. 
The actual interfaces to those parsers -- that is, the pure Perl one, the 
LibXML one, and the expat one -- are all separate modules.

Because of this, new things like XML::SAX can be written to fairly easily plug 
into all of those libraries.

In Ruby, well, rfeedparser has its own interfaces to the expat gem, the libxml 
gem (whatever their names are), and its own internal (sloppy) parser, in case 
the others can't be found. Anyone else who just wants to parse XML is going 
to have to do the same thing -- or worse, just pick a library.


As long as I'm ranting, may as well talk about plugins. I know about 
gem_plugin -- why isn't it used more? Why, instead, are plugins distributed 
as things tightly-bound to Rails? Suppose I like ActiveRecord, and I need 
has_many_polymorphs -- if I'm in Merb, there's no clear indication of whether 
that will work or not.

Well, that, and plugins are a whole separate (and inferior!) package 
management system that I have to learn, in addition to gems. The one 
advantage I can buy is that you can then distribute your entire, working app 
to a web host who simply has Ruby, no external dependencies required -- but 
you'd still have to freeze Rails to your app to accomplish that. Why not 
freeze other gems, too?

Here's a crazy idea (not sarcasm; I realize it's quite possibly insane): When 
you build a framework like Rails, designed to aid in rapid development of an 
app, design it around building components, not whole applications. That is, 
design it around building gems -- possibly lots of tiny gems (would one per 
model be too much?) -- so that when it comes time to "extract functionality" 
from your app, you'll already know what depends on what, and what you'll need 
to disentangle.

If you made it this far, thanks for reading. Hope I made some kind of sense.