Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Ruby Stdlib is a Ghetto

mikeperham.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: The Ruby Stdlib is a Ghetto

#21

Post by bobbywilson0 »

rmoriz wrote: post #12
bobbywilson0 wrote: post #3

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.

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

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.

Re: The Ruby Stdlib is a Ghetto

#22

Post by 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

Re: The Ruby Stdlib is a Ghetto

#23

Post by AndrewO »

Argorak wrote: post #6
AndrewO wrote: post #2

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…

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.

Re: The Ruby Stdlib is a Ghetto

#24

Post by 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.

Re: The Ruby Stdlib is a Ghetto

#25

Post by tenderlove »

bobbywilson0 wrote: post #3

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.

Hi,

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.

Re: The Ruby Stdlib is a Ghetto

#26

Post by rue »

rmoriz wrote: post #9

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 t…

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.

Edit: removed tautology in 4th paragraph.

Re: The Ruby Stdlib is a Ghetto

#27

Post by tptacek »

brendano wrote: post #18

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.

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.

Re: The Ruby Stdlib is a Ghetto

#29

Post by jseifer »

Argorak wrote: post #6
AndrewO wrote: post #2

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…

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.

Likewise for high performance http libraries.

Re: The Ruby Stdlib is a Ghetto

#30

Post by bdr »

tptacek wrote: post #27
brendano wrote: post #18

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.

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.
Post reply on HN