(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.
···
On Tuesday 05 August 2008 07:56:22 Martin DeMello wrote: