
The Ruby Stdlib is a Ghetto - chanks
http://www.mikeperham.com/2010/11/22/the-ruby-stdlib-is-a-ghetto
======
rmoriz
It seems to me the massive "investments" made in mainly web-related frameworks
(Rails, Merb, Sinatra + ORMs) didn't help the foundation of the Ruby
ecosystem: Take rubygems, take RAA, take the MRI development process.

If you got "brainwashed" in the last 5 years about code quality (DRY etc.) +
test methods (TDD/BDD) and then look at today's Stdlib, you'll scream and want
to put bleach into your eyes…

To me it seems the "übercool" guys already moved away to their
NoSQL/node.js/whatever next party, so it's not easy to motivate people to
change such "messy" and large projects anymore.

I'm also not sure about the number of Ruby interpreters around and their
useful impact: If you e.g. change something for Ruby 1.9.x / 2.0.0, it will
cost a lot of manpower to port those changes to JRuby, Rubinius, maglev,
IronRuby and BlueRuby (if SAP's Ruby is still alive?) and most of them are
just used by very few people.

Maybe resources are better spent in creating a new Stdlib, improve the
rubygems infrastructure (already started with gemcutter) and do something with
RAA?

~~~
mileszs
The Ruby language specification (<http://www.rubyspec.org/>), to which all
Ruby VMs are written, helps as far as the "number of Ruby interpreters around
and their impact" goes. (Assuming I understood your concern correctly.) A new
Ruby VM is considered legit if it passes Ruby Spec. That should help in both
transparency and compatibility across implementations.

Would you agree?

~~~
joe_the_user
Following your link: _"This website is presently being redesigned. We expect
to be back soon."_

But I knew already that "rubyspec" wasn't a spec in the ordinary sense but a
test-suit built with MSpec.

The thing is that real spec actually fully specifies a language - at least up
to syntax. There are real specs for Python and Java for instance. The only
real spec for Ruby is still crufty Yacc code for MRI.

A test suit doesn't do that and the whole Rubyspec thing is a testimony to
people drinking too much of the Test Driven Development Cool Aid. TDD may be
fine for some things but some formal design is needed for things like the
creation of interpreters.

Part of the challenge is that MRI has such a fluid syntax that specifying it
conventionally would be quite hard. But I suspect that's what will have to
happen if Ruby's going to go forward.

~~~
devinj
Java has a real spec. Python has documentation, but it isn't really sufficient
for a spec, and for the most part alternative implementations copy down to the
last implementation detail (gc details notwithstanding). A test suite is
probably better than what it has.

~~~
joe_the_user
It depends what you mean by "better".

Maybe Python has lousy spec but as I recall, the documentation does include a
BNF breakdown of what Python is.

A test suite can be good for a lot of things BUT it cannot be a specification,
it cannot be even sort-of a specification. Test suites only "prove a
negative", only prove that an application won't do X. A specification is at
least a rough assertion of a positive, that a language does follow this
pattern.

~~~
devinj
Yeah, there's an EBNF syntax description. I must have missed the part where
the GP thought that's all that was necessary for a "real spec". I guess I just
disagree.

Java specifies the semantics of Java and the JVM remarkably fully. Python, not
so much.

------
AndrewO
I got the updated version of the Pickaxe recently and skimmed through all of
the 1.9 updates. I was appalled to see REXML is still the blessed XML parser.
I liked it when I started using Ruby and I still see it in the wild, but to me
that's usually the sign of old code or a developer not tuned in to the latest
developments.

On the other hand, there has been some progress. It's good to see MiniTest
replace Test::Unit (while also remaining mostly backwards compatible).

~~~
Argorak
REXML is kept because many projects that need a pure ruby XML parser rely on
it and it works for them. Usually, if you use XML beyond something small, you
should use Nokogiri.

Actually, 1.9.2 ships with replacements where possible: for example, CSV is
now FasterCSV with a compatibility interface, Psych can be used instead of
Syck for YAML parsing.

~~~
jseifer
Likewise for high performance http libraries.

~~~
Argorak
Yes, but most high-performance libraries are MRI specific.

I'm still searching for a good Net::HTTP replacement that runs on both MRI and
JRuby.

------
bobbywilson0
I am not sure the author's solution, removing the said libs, is the right
direction. I agree that the stdlib is crufty and slow, but they do 'work', and
people certainly use them. I think the better option might be to deprecate and
replace.

~~~
rmoriz
To me the Stdlib API looks unfixable. So imho there's only one way:

* put the existing stdlib into a legacy gem

* create a new stdlib with a new, good, (incompatible) API from scratch

* deal with the incompatibilities that will happen

~~~
bobbywilson0
I am not opposed to your solution, but sadly, I think it would be an extremely
rare case. The ruby core team is very conservative with change, and I don't
see some sweeping stdlib switch happening. James Edward Gray II was successful
with ousting CSV for his improved implementation, and I think that's probably
the way it will happen, if anything does happen. One library at a time.

------
chrislloyd
I wrote something similar a while ago[0]. Ruby should be the language and
everything you "require" should be a Gem. It won't happen with Ruby (and isn't
worth the effort). New languages, however, take heed.

    
    
      [0] http://thelincolnshirepoacher.com/pages/standard-libraries

~~~
mcantor
Instead of forcing users to "install file" and "install path," which is bound
to cause frustration, you could probably just have an "install stdlib" meta-
package. Or at least an "install list stdlib" command that showed people all
of the packages to install if they wanted stdlib functionality, which would be
completely clear and allow for cherry-picking packages. _Or_ install all
packages in stdlib by default and let people remove them if they want.

~~~
chrislloyd
Yeah absolutely. I think what is important is that people can fork and change
the stdlib. I also like the idea of platform independence coming from
installing different Gems, i.e. "file-java" and "file-win32". However, that
could work out to be a cluster-cuss in practice.

------
thomaz
Rails went (and is still going) through the same process. They realized they
had a lot of code not being used (or being replaced by other gems) and just
moved everything away from the core.

IMHO, with a lib sharing system such as rubygems, having a standard set of
"external" libs in kind of unnecessary.

------
lulin
I don't think this is that much of a problem. If I want to use a modern
library, I just type "gem install whatever" and I have the new library.
Documentation for the stdlib is not really better or easier to find than that
for third party libs, so I tend to use whatever seems nicer after a quick
google search and I guess other people do it like that, too.

------
bokchoi
Ghetto? How about just "old and crufty"?

~~~
telemachos
It's not 'ghetto' in the slangy adjectival use (e.g., "That coat is so
ghetto."), but 'ghetto' in the normal noun use: "The Ruby Stdlib is _a_
Ghetto" (my emphasis).

And if you still think that's hyperbole, it's an allusion to Zed Shaw's
infamous "Rails Is A Ghetto" post.

~~~
bhickey
I thought it was a reference to the tact and grace embodied by titles like
"CouchDB: Perform like a pornstar".

------
krainboltgreene
One of the Ruby implementations is going to have to change the game, because
the current standard is hacked around rather than used naturally. That isn't
productive, both for hacking and professional work.

------
Spakman
I heard this about 3rd hand, so consume with a large helping of salt: the Ruby
core developers are considering using the Rubinius stdlib for Ruby 2.0.

------
rmoriz
Database Error :(

~~~
chanks
Copy:

Much of Ruby’s standard library (the set of classes shipped with the Ruby VM
itself) is old and crufty. For laughs, go look at the code for some of the
classes that you’ve never used. Chances are it’s from 2000-2003 and doesn’t
even look like idiomatic Ruby. I’m wondering what classes should be removed
from the standard library or deprecated so that higher quality replacements
can take their place.

The canonical example is Ruby’s net/http library. Its performance and API are
just terrible. (Side note: how do you know if an API is terrible? If you have
to consult the docs even after having used the API for the past 5 years.) But
because it’s in the standard library, most people use it as the base for
higher-level API abstractions (e.g. httparty, rest-client).

So looking at Ruby’s core RDoc, my suggested list for removal (where removal
means move to a rubygem):

Net::* DRb REXML RSS Rinda WEBrick XML

Any others I missed? Will Ruby 1.9.3 or 2.0 get a good spring cleaning or will
we have to live with these classes forever?

~~~
n8tron
Great comment - I completely agree about REXML. One question for you - what's
an example of a http library in another language which you think provides a
good API? Personally, I haven't found net/http to be any worse/better when
compared to many other standard http libs.

~~~
catch23
Wasn't rexml's original implementation completely replaced in Ruby 1.9,
Rubinius, & JRuby? It seems like the only people who might complain about it
are those who are still stuck in 1.8 land.

------
brendano
Hate to sound preachy, but compare to Python developers, who very carefully
maintain and update their stdlib.

I feel like it is risky to commit to using Ruby for the long-term.

~~~
tptacek
Is that a joke? How many different interfaces are there to popen(3)? How many
different ways to get the current time? If Ruby's standard library is a
ghetto, Python's is a jungle.

If you like Python, I don't know why you'd even think about "committing to
Ruby for the long term"; you're a Python dev. They're practically the same
language. Stop trying to pick fights.

~~~
bdr
Yes, there are many interfaces to popen, but that doesn't refute the
grandparent, who claims that the Python stdlib is maintained and updated. See
the top of <http://docs.python.org/library/subprocess.html> \-- the bad
solution was deprecated, and a good solution was created. This is movement
towards goodness, which the OP laments the lack of in Ruby.

~~~
kingkilr
It's the ciiircle of liiffeee...

