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

Ruby 2.0.0 Released

ruby-lang.org

Post reply on HN
Print view View original

191–200 of 303 posts

Re: Ruby 2.0.0 Released

#191

Post by dgregd »

donw wrote: post #49

Overall, a good feature set. I only see some utility for keyword arguments, admittedly, but I tend to write very functional code, so maybe other people will get more mileage. Refinements, as I understand them, are a bad idea. I understand the motivation, but this is not the way to go about it. There's now a new scope all over the place (the set of refinements applied to any given class). This means that the behavior…

> Refinements, as I understand them, are a bad idea.

I agree. Some feature to debug monkey patching conflicts is needed. But do we really have to change methods call logic to achieve that goal?

I would like to see some diagnostic feature one can just turn on/off. Something that just shows conflicts.

Re: Ruby 2.0.0 Released

#193

Post by pjungwir »

jacquesc wrote: post #70
donw wrote: post #49

Overall, a good feature set. I only see some utility for keyword arguments, admittedly, but I tend to write very functional code, so maybe other people will get more mileage. Refinements, as I understand them, are a bad idea. I understand the motivation, but this is not the way to go about it. There's now a new scope all over the place (the set of refinements applied to any given class). This means that the behavior…

Totally agree about refinements. Hopefully the community pushes back enough on that experiment so it gets deprecated and removed. A better design approach to achieve this effect is wrapper objects (similar to jQuery and Underscore.js) where I can add functionality to existing objects. Ruby has everything we need for this already, and makes it quite easy to do.

Refinements worry me too. They make it a lot harder to read and understand code, or track down where strange behavior is coming from. I wish I could just ignore them, but unfortunately libraries like ActiveRecord probably won't. And then there are the performance problems.

Since so many people dislike them, I wonder what the community response will be? Will JRuby just leave them unimplemented? That seems bad, but I'm not sure I'd mind too much. But that's not viable if it means Rails and other things won't work on JRuby.

Re: Ruby 2.0.0 Released

#194

Post by stormbrew »

jacquesc wrote: post #63
aaronblohowiak wrote: post #54

Earlier quoted context omitted.

1.9 was not supposed to be a wide release, and it contained more breaking changes than 2.0, IIRC.

I'm not 100% sure on the history, but I believe 1.9.x started as a dev release and then they changed their minds and decided it was a wide release. That initial confusion might be why the community took the time to go from 1.8 to 1.9. I think they've learned from that, as 2.0 looks like a much cleaner/easier transition.

On the other hand, it means we've now had point and minor releases that broke everything (1.9, 1.8.7, and I think even one or two of the 1.8.7 patch releases actually backported breaking 1.9 features), while the major release is apparently one where nothing from the prior release should break. I'm not convinced that means they've 'learned their lesson' so much as that they still don't know how to version things.

We'll see how 2.1 goes, I guess.

Re: Ruby 2.0.0 Released

#195

Post by nathan_long »

noelwelsh wrote: post #83

I do wonder about the long term success of Ruby. Rails is easily the most visible project for Ruby. Rails is big, and all that code represents a high barrier to entry for any framework in a different language that wants to compete. However, a lot of people I talk to are moving to pure JS front-end + REST backend. In this world Rails doesn't deliver any particular value (in my opinion). Ruby also has utility for doing…

I work in Ruby and Rails. I can much more easily imagine moving away from Rails than from Ruby. It's such an enjoyable language to work with that I doubt I'll ever put it aside.

Re: Ruby 2.0.0 Released

#197

Post by tjlivesey »

steveklabnik wrote: post #173
tjlivesey wrote: post #123

Earlier quoted context omitted.

>However, a lot of people I talk to are moving to pure JS front-end + REST backend. In this world Rails doesn't deliver any particular value (in my opinion). I agree with this but I think there is a place for a javascript framework tied fairly closely to Rails. Possibly ember.js since the attitude towards both seems similarly opinionated and Yehuda Katz is one of the ember team. The Rails API gem accommodates this qu…

I maintain rails-api, and both Yehuda and I have commit to Rails. I just want to mention that while Ember + Rails will be a potent combo, Ember will work great with non-Rails backends as well, and rails-api will work great with other frameworks too. That said, we're working really hard to make sure that Rails 4 + rails-api + Ember 1.0 is a fantastic experience, so watch that space for sure.

Thanks for all the hard work Steve. I have been waiting for ember 1.0 to really give it a proper go but I'm looking forward to it. It seems like a slightly steeper learning curve than something like backbone but I'm sure it will do more for you once you get to grips with it.

Re: Ruby 2.0.0 Released

#198

Post by copx »

I like Ruby but keywords arguments are the solution to a problem which shouldn't exist in the first place. Namely functions like..

myFunction(something, 23,23,100, somethingElse, true)

People should write smaller, more specialized functions instead (less arguments). That makes software both: more efficient and more maintainable.

If you start thinking: "Damn I wish I had keyword arguments to make this function call more comprehensible!" .. the problem is elsewhere.

Re: Ruby 2.0.0 Released

#200

Post by TylerE »

copx wrote: post #198

I like Ruby but keywords arguments are the solution to a problem which shouldn't exist in the first place. Namely functions like.. myFunction(something, 23,23,100, somethingElse, true) People should write smaller, more specialized functions instead (less arguments). That makes software both: more efficient and more maintainable. If you start thinking: "Damn I wish I had keyword arguments to make this function call mo…

100% disagree. For some use cases they are very useful. Like, imagine a function that generates an HTML snippet, and can optionally assign some specific class names/ids to some of the elements.
Post reply on HN