[ruby-core:19019] Re: Let Ruby be Ruby

On Sep 28, 11:02=A0pm, James Gray <[e-mail]> wrote:
> On Sep 28, 2008, at 6:10 PM, Trans wrote:
>
>
>
> > On Sep 28, 6:14 pm, James Gray <[e-mail]> wrote:
> >> On Sep 28, 2008, at 3:19 PM, hemant wrote:
>
> >>> Getting your library in stdlib means, you are mostly
> >>> handling over reins to someone else.
>
> >> I don't think this has to be true.
>
> >> My CSV (formerly FasterCSV) library was added to the standard library
> >> last December. =A0I have continued to maintain it since then =A0
> >> including a
> >> big rewrite of the parser to add m17n support.
>
> >> Thus, I think this depends entirely on the contributor. =A0I personall=
y
> >> feel a little more pressure to keep CSV running well now that it =A0
> >> ships
> >> with Ruby. =A0I would rather not see people saying, "That new CSV
> >> library sucks!" :)
>
> > Fair point. But really, would you have felt any different if FasterCSV
> > were still a separate gem? Your name is pretty synonymous with
> > quality.
>
> Thanks for the compliment, but doesn't this support my point? =A0Some of =
=A0
> us just care.
>
> > And as a separate gem you could improve your library faster,
> > on an independent release schedule.
>
> I concede this point. =A0It is probably better to include a library =A0
> after it's pretty mature and not changing as often.
>
>
>
> >>> Bundling of many libraries within stdlib has sorta killed
> >>> competetion (net/http for instance).
>
> >> FasterCSV and mini/unit were both developed with CSV and test/unit
> >> being in the standard library. =A0They gained enough traction to =A0
> >> replace
> >> the libraries they improved upon in this release. =A0Again, this =A0
> >> doesn't
> >> seem to be a universal truth.
>
> > That's not really true. Look at the download numbers for miniunit
> > (http://rubyforge.org/frs/?group_id=3D1040). I wouldn't call that
> > traction. It's adoption into stdlib has more to do with who's pushing
> > it then anything else. That's not so say it isn't a worthy
> > replacement. I think on the whole it probably is, but that lends
> > itself more to my argument.
>
> Well, I was reading that source yesterday. =A0I have to say the author =
=A0
> is right about it being terrific code. =A0I think the change is worth =A0
> it, for whatever reason we did it.
>
> > I'd rather see third party bundles of Ruby and popular libraries,
> > instead of Ruby harboring so much its own repository.
>
> I think Ruby would be shockingly less useful if I couldn't count on =A0
> having things like the networking libraries, IO tools like FileUtils =A0
> and Tempfile, and WEBrick being present with every install. =A0It's =A0
> worked for Perl for a long time and I feel it's working for us.

I certainly don't mean to exclude certain lower-level tools like
FileUtils, Tempfile and other IO/network libs. That would be going too
far. I mean it rather for higher level libs like REXML, testunit,
probably YAML, etc.

I used to think the big bundle was good too. But over time I've come
to see that there is balance to be achieved. Sort of like Einstein's
quote of "simple, but not too simple".

T.