atom feed13 messages in org.ruby-lang.ruby-core[ruby-core:39996] Re: problems with R...
FromSent OnAttachments
Shugo MaedaOct 6, 2011 7:03 am 
Steve KlabnikOct 6, 2011 7:48 am 
Yukihiro MatsumotoOct 6, 2011 9:05 am 
Yukihiro MatsumotoOct 6, 2011 9:07 am 
Steve KlabnikOct 6, 2011 12:16 pm 
Bill KellyOct 6, 2011 12:39 pm 
Yukihiro MatsumotoOct 6, 2011 2:49 pm 
Shugo MaedaOct 6, 2011 9:00 pm 
Steve KlabnikOct 6, 2011 10:02 pm 
Adam PrescottOct 7, 2011 2:34 am 
Steve KlabnikOct 7, 2011 12:24 pm 
Kurt StephensOct 7, 2011 12:55 pm 
Yukihiro MatsumotoOct 7, 2011 7:39 pm 
Subject:[ruby-core:39996] Re: problems with Refinements
From:Steve Klabnik (ste@steveklabnik.com)
Date:Oct 6, 2011 12:16:17 pm
List:org.ruby-lang.ruby-core

Unfortunately, I missed Brian's talk, so we have to wait until the video to check what he said.  But when he claimed against refinements, there must be reasons behind.  I am open to hear.

                                                       matz.

I don't claim to speak for Brian, and I've sent him a link to this thread, so that he can make his own statements about it, but my understanding of it is this: refinements provide very little benefit at the cost of increased complexity for both Ruby programmers and Ruby language developers.

Refinements for Rubyists: Pros: - protect a library from interference from other library's monkeypatches Cons: - End up making libraries harder to understand, since the details of MyLibrary's String are opaque from outside MyLibrary - Are a pretty complex feature to use. - This complexity makes code with refinements hard to reason about.

Refinements for Ruby Implementors: Pros: - Giving users a feature they want Cons: - Complex features are complex to implement - Refinements in particular place a large burden on send (I think), which is what makes the performance penalty so large. - This feature affects Ruby at a very, very deep level, and therefore deserves significant consideration

Finally,

"If I had asked people what they wanted, they would have said faster horses." -
Henry Ford

Many people _do_ want refinements, but that doesn't mean that it's good for Ruby. Just like 'optional typing,' when people ask for a language feature like this, what they actually want is different from what they're asking for. For example, people want optional typing because they've heard it will 'make Ruby faster,' not because they want to use optional typing to write better Ruby code. It's the same thing with Refinements. People are actually saying, "I don't have a way to know if my library will conflict with another, and what to do about it." This is a _tooling_ problem, not a language feature problem. I also personally feel that the problem is overblown. I've been doing Ruby for a few years now (though not as long as many on this list. :) ), and I don't think I've ever been particularly bitten by this issue. Maybe once or twice, and it wasn't too bad to resolve. In my mind, paying a 10%-15% performance penalty for a once-a-year bug is a bad tradeoff. I'm willing to acknowledge that it might be more of a problem with others, however, I've never actually met someone for whom that's the case.