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?
Gems has been significantly improved in the last year-two years both under the hood and in the frontend (not to mention since it first came about…I refused to use it until 2007).
RAA has been obsolete since RubyForge (which was subsequently succeeded by Gems and Github), I am not sure why you would even bring it up.
The MRI development process is very conservative, yes, but that is offset by the very dynamic development processes of Rubinius and JRuby (even if in part driven by the conservativeness). There are few things in the language itself that need change, and those are to be resolved for 2.0. The main development cost is in actually setting forth the changes, not in implementing them.
The Stdlib sucks, sure, even if some of the libraries are better-maintained than others. Better alternates can be installed via Gems in almost all cases. There is an ongoing proposal to gemify the rest of the Stdlib (some parts are needed just to support Gems itself) mainly to reduce the distribution size and there are some arguments back and forth. By and large, however, it is pretty irrelevant to day-to-day life with Ruby.
In the meanwhile, if you are serious about the problem: spend your own resources to adopt one of the stdlibs and update it as necessary. This is open source, and that is how problems get solved.
RAA is basically considered dead for all intents and purposes. I have rarely ever gotten anything useful from there considering it was considered "outdated" when I started Ruby some 5 years ago.
Rubygems has gotten a few improvements from the popularity of Rails. Github gem hosting may have been a stepping stone, but it did help. Bundler and gemcutter are definitely an improvement.
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.
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.
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.
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.
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.
but you still have to implement a "language change" into all different VMs. This does cost time and money but delivers redundancy that has to be maintained. Which is great, if you don't have more important problems.
A horrible Stdlib is imho a more important problem today.
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).
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.
Good points (I'd forgotten about FasterCSV and Psych).
I guess it's a mixed blessing if your library becomes part of stlib. On the one hand, it's gotta feel great to have so many people using your code. But on the other, your release cycle is pegged to Ruby's.
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.
I agree, deprecate and replace is the way to go. That's what I'm doing with Psych and with Fiddle. I really like this option because I don't want to break people's code.
There is a downside though. I've tried shoehorning the REXML api on top of Nokogiri. The problem is that doing that work is thankless and not very fun. The API for REXML is just too large, and the deviations between the way it works and how libxml2 works are too many.
I think if we add new libraries, and encourage people to move to the new ones, then start removing the old ones, that would be best.
Unfortunate choice of wording on the authors part, because it makes it seem like your solution is less drastic than his, whereas your solution is actually more drastic. To quote the author: "removal means move to a rubygem".
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
GP is trolling. No need to counter-troll while feeding. The flamebait on committing to Ruby does not invalidate his point on stdlib maintenance though.
We can sit here and ping each other with examples of cruft all day. I think it can be shown objectively that Python's standard library is better maintained. I'll attempt to below.
I'm not saying this has a great significance in picking one
language over the other in and of itself. Just that if you want to talk
specifically about stdlibs, the differences are pretty clear-cut imo.
== In terms of quantity of updates ==
- Mar 13 2007: Ruby 1.8.6 launched
- May 18 2008: Ruby 1.8.7 launched
- Distance: ~14 months
- Sep 19 2006 Python 2.5 launched
- Oct 18 2008 Python 2.6 launched
- Distance: ~23 months
So discount the amount of 2.5->2.6 changes accordingly to account
for the extra time.
You'd need to compare across actual libraries (unittest vs
Test/Unit etc). I didn't provide specific examples in links to
avoid inevitable accusations of cherry-picking.
> How many different interfaces are there to popen(3)?
popen, popen2 - both deprecated. The new "proper" one is available since 2.4 (quite a long time now) - subprocess.
> How many different ways to get the current time?
time.time() <- timestamp, datetime.now() <- date
Is this that bad? Sure, popen and popen2 are silly, but they're left for compatibility, while subprocess was introduced to update stdlib (as OP claimed). It's hardly a jungle...
You could pretty much substitute Ruby for Python in this post and it wouldn't change much. I mean, right down to the http modules being outdated and non-idiomatic (especially urllib and urllib2). I seem to recall reading somewhere that they were written by Guido himself and were some of the first pieces of the python standard library.
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?