Hacker News Reader

Comment by andrewvc | Hacker News Reader

I wish 2.0 had focused on speed, not a bunch of features that working rubyists really don't care about. Esp. not ones this poorly thought out (you'd think given 2 years discussion they would have abandoned the idea).

View on HN

The decision making in the Ruby world seems to be fairly centralized and not very inclusive. To see that one of core devs of one of the biggest Ruby implementations thinks it's a bad idea is really confusing to me. I really wish there had been more discussion about it before it happened.

Cause now not only do we have that confusing feature which very few people seem to like, it also underlines a worrying trend where the different parts of the Ruby world don't reach a consensus before going in radical directions.

No one summed it up better than Brian Ford at his RubyConf talk really: http://www.confreaks.com/videos/1278-rubyconf2012-toward-a-d...

It's a must-see.

Refinements are not yet a part of Ruby 2.0 and their implementation in Ruby 2.0 is still under discussion. As Akira Matsuda pointed out @ the same RubyConf: "Warning: Refinements are experimental and may be removed from Ruby 2.0!" [23:15]

http://www.confreaks.com/videos/1275-rubyconf2012-ruby-2-0-o...

While I enjoyed most of Brian's talk, I wasn't particularly convinced by his dislike of refinements. Essentially, it boiled down to "this feature is hard to implement, it hides complexity, and it isn't well specified". The first and third arguments shouldn't matter to us nearly as much as the middle one. And I fail to see how namespacing monkey patches can do anything but decrease and contain accidental complexity (in the same way that method dispatch and polymorphism are better at limiting complexity than explicit conditionals).

The benefit to refinements is in preventing code conflicts from a shared namespace (like monkeypatching a core class).

The downside is it becomes even _harder_ to figure out what code is being run just by reading it. Right now, you just have superclasses and included modules, potentially gummed up by method_missing. Now, you need to also pay attention to refinements included by code that _calls_ the code you're looking at, which may change the way it behaves.

Unless used with great care, it's going to create a nightmare debugging situation. And with some of the code I've seen, it'll happen.

Speed and Memory usage. Both needs a huge improvement. And i could not understand why they are even trying with mRuby. ( I mean have they not heard of a thing called Lua and LuaJIT? )

Hopefully a lot of the tweaks and refinement will come from now to Final 2.0 release.

> And i could not understand why they are even trying with mRuby. ( I mean have they not heard of a thing called Lua and LuaJIT? )

LuaJIT is pretty much impossible in a language with as complex semantics as Ruby (it's probably impossible in Python already, and Ruby is significantly more complex)

They have done minor improvements to both speed and memory usage in 2.0.

http://igor-alexandrov.github.com/blog/2012/11/05/yet-anothe...

Reply on news.ycombinator.com