--nextPart4143664.IJGqfZ9GWs
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 26 September 2005 21:29, Austin Ziegler wrote:
> Then you fail to see the point in general. Ruby needs something that
> works similar to -- but better than -- CPAN. This means a packaging
> system. You may not see it, but those of us who have to deal with
> other platforms see it.

Well, I'll agree there.  CPAN is an anti-solution which causes more problem=
s=20
than it solves.  Only people who work with Perl regularly seem to like it;=
=20
for users of Perl applications, it is often more of a curse.  There are eve=
n=20
many Perl developers who grumble about CPAN.  However, Perl is stuck with=20
CPAN.  It is so intrinsically intertwined with Perl that getting rid of or=
=20
replacing CPAN would be an excercise in pain and suffering the likes of whi=
ch=20
hasn't been seen since... well, pick your favorite historical ethnic=20
atrocity.  However, at least CPAN isn't built into Perl.

I don't understand the comment about "those ... who have to deal with other=
=20
platforms".  What does that mean?  From the packager's point of view?  From=
=20
the library author's point of view?

<rant>
Personally, I don't think software installation is at all the job of the=20
language.  Software management is the job of the operating system (or=20
distribution).  It is the very essense of their value-added.  It is bad=20
enough when some poor schmuck of a user has to figure out and remember how =
to=20
use the package manager of their system, much less having to remember a=20
separate one for each language they install because they want to use some=20
application.

Language-specific package managers, in my experience, are often -- perhaps=
=20
exclusively -- championed by *developers*.  Never by end-application users,=
=20
because they always suck for casual users.

Ruby is still largely a scripting language.  That is, main *users* of Ruby =
are=20
still people *programming* Ruby for bespoke applications.  I suspect that=20
inclusion of Gems will cement that role for Ruby.
</rant>

Incidentally, last time I checked, Gems *still* didn't work behind an=20
authenticating firewall, despite the fact that I can get through with wget=
=20
=2D-proxy-user.  There is nothing -- NOTHING -- worse than trying to instal=
l=20
something that depends on a library that is *only* distributed via a gemfil=
e. =20
This makes the package impossible to install.

=46inally, I understand that some people want a CPAN-like solution.  That's=
=20
fine.  However, I agree with Sam that versioning should handled separately=
=20
from the language-specific package manager.  The manager is *heavily*=20
dependant on the versioning mechanism, but the opposite shouldn't be true. =
=20
This is poor coupling, exhibits feature envy, and should offend anybody wit=
h=20
any extensive experience in OO architecture and design.

=2D-=20
=2D-- SER

"As democracy is perfected, the office of president represents,=20
more and more closely, the inner soul of the people.  On some=20
great and glorious day the plain folks of the land will reach=20
their heart's desire at last and the White House will be adorned=20
by a downright moron."        -  H.L. Mencken (1880 - 1956)

--nextPart4143664.IJGqfZ9GWs
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux)

iD8DBQBDOoPUP0KxygnleI8RAr6XAKCTcY8pWm9g18joH+d/kdp30hd8fgCfWAzl
98aSONbOyRno+nrjD2Ggk6w=
=l1iY
-----END PGP SIGNATURE-----

--nextPart4143664.IJGqfZ9GWs--