Ruby 2.2.0-preview1 Released(ruby-lang.org)
ruby-lang.org
Ruby 2.2.0-preview1 Released
https://www.ruby-lang.org/en/news/2014/09/18/ruby-2.2.0-preview1-released/
35 comments
Ruby is still my favorite programming language to use for a project. It doesn't have the immediate approachability of python but if you put in the effort to understand and accept it's quirkiness you fall in love. I hope it continues to move forward as far as performance goes so people will continue to use it, not just mostly for prototypes, but beyond. Ruby 2.2 is a great step.
What quirkiness are you referring to? I tend to find python more quirky but then I've got a lot more experience with Ruby.
Also curious here. I too find Ruby more consistent/predictable than Python.
Ruby is my main/favorite language, but I was exposed to Python first and used it a lot more for work/school, so it's not an experience thing here.
Ruby is my main/favorite language, but I was exposed to Python first and used it a lot more for work/school, so it's not an experience thing here.
> understand and accept it's quirkiness
Ruby is the child of Smalltalk and Perl/shell.
If you know said languages, then you can figure out Ruby much easier.
Ruby is the child of Smalltalk and Perl/shell.
If you know said languages, then you can figure out Ruby much easier.
I started using Ruby 10 years ago and I'm surprised by its longevity as my main language. It's quite far from falling down gradually. I'm glad I picked it for my most important projects: it really feels as a solid base to build upon.
Very impressive results with the new GC for symbols. Of 100,000 created, a `GC.start` got them down to about 2000.
It's a "weird feeling" to see a framework mentioned in a language update! it shows you that like Python has "one obvious way to do things" Ruby has one obvious framework, i can't see PHP 6.0 released and codeigniter/cake/any other framework mentioned in the release, correct me i'm wrong!.
It really isn't. They mentioned Rails because it will be the biggest winner from their new GC that also collects symbols (Rails is a heavy user of symbols). No harm in mentioning some of the beneficiaries of the change, as long as that change is not unfairly impacting other projects. Good move from Matz and co.
Never said it's a bad move, i love Rails and i love Ruby as well, it was just the first time i see a framework directly mentioned in a language changelog.
ruby-core has a history of making sure Rails does not guide the direction of Ruby the language. Most of the time, advancements to Ruby the language will always have a positive impact on Rails the framework. Sometimes these changes to Ruby the language come to light because of Rails the framework. It's a very healthy relationships between the two.
My fav feature:
* min, min_by, max and max_by supports optional argument to return multiple elements.
> uses fixed space
I guess the "normal" way to write this is with a heap? For `min`, I guess the algorithm is something like,
I guess the "normal" way to write this is with a heap? For `min`, I guess the algorithm is something like,
min(items, k=1):
h = max_heap(items[:k])
for i in items[k:]:
h.push(i)
h.pop_max()
return sorted(h)
yes, it's not hard (although I seem to recall mysql only implemented "limit" like this in v5.6), it's just that if it's not readily available people (well, me) tend to fall back to sort+first(n), which can be quite wasteful.
I always have a mixed feeling about ruby. The "magic-ism" of ruby is something that I just cannot deal with.
"require" gives you methods that appear out of nowhere (unlike other language where they are name spaced), method call without perens (so what is an attribute, what is a method call)
All of these look nice at first but kills maintainability later
"require" gives you methods that appear out of nowhere (unlike other language where they are name spaced), method call without perens (so what is an attribute, what is a method call)
All of these look nice at first but kills maintainability later
> method call without perens (so what is an attribute, what is a method call)
That's known as Uniform Access Principle[0] and is a wonderful feature to have.
Ruby is far less magical today than it was 5-10 years ago. Magic is a clever word for "I don't understand this thing yet."
0 - http://martinfowler.com/bliki/UniformAccessPrinciple.html
That's known as Uniform Access Principle[0] and is a wonderful feature to have.
Ruby is far less magical today than it was 5-10 years ago. Magic is a clever word for "I don't understand this thing yet."
0 - http://martinfowler.com/bliki/UniformAccessPrinciple.html
Disregarding the UAP thing you mentioned, I believe you might be dismissing the complaints of "magic" in Ruby too quickly if you think all it is meant by it is what you said.
In the contexts I usually see, the complaints of magic are regarding Ruby's fondness of Spooky Action at a Distance. I would then argue that Ruby or its frameworks do seem to rely too much on this "magic" that otherwise is condemned by recent literature (and Code Complete).
In the contexts I usually see, the complaints of magic are regarding Ruby's fondness of Spooky Action at a Distance. I would then argue that Ruby or its frameworks do seem to rely too much on this "magic" that otherwise is condemned by recent literature (and Code Complete).
I think the discussion is really about Rails, not Ruby. Ruby itself is fairly minimalist and easy to follow. Probably the biggest legitimate complaint about the language design itself is that it mixes functional, procedural, and object-oriented paradigms in a way that makes it hard to fully capture the benefits of any of them unless you really know what you're doing.
Now Rails on the other hand relies on a good deal more magic than say Django, but it's recognized in the community as a tradeoff and it is done carefully. Some of the things that rubyists accept in Rails they would never put in an application or library because it is deemed okay only by massively adopted convention at the framework level, but not generally a good practice.
Then you have libraries like rspec which started out being full of magic but which gradually got refined and cleaned up so that in rspec 3.0 you have zero monkey patches; it's just pure ruby, providing a totally modular set of DSLs that work together nicely and allow for amazingly readable test output.
Now Rails on the other hand relies on a good deal more magic than say Django, but it's recognized in the community as a tradeoff and it is done carefully. Some of the things that rubyists accept in Rails they would never put in an application or library because it is deemed okay only by massively adopted convention at the framework level, but not generally a good practice.
Then you have libraries like rspec which started out being full of magic but which gradually got refined and cleaned up so that in rspec 3.0 you have zero monkey patches; it's just pure ruby, providing a totally modular set of DSLs that work together nicely and allow for amazingly readable test output.
> so what is an attribute, what is a method call
It's all method calls. Attributes don't really exist.
It's all method calls. Attributes don't really exist.
> It's all method calls.
Probably nitpicking, but it's actually all messages. An object might not have a method "foo", but happily respond to the "foo" message.
Probably nitpicking, but it's actually all messages. An object might not have a method "foo", but happily respond to the "foo" message.
Its all method calls. Specifically, its all calls to #send, most of which get relayed to another method (either based on the message name or, if no such method exists, #method_missing.)
And the object responds to the "foo" message by calling a method.
The difference is whether we're discussing the invocation or the response. OP's usage of method isn't incorrect in this case if it's discussing the response. It is true that all message responses (including accessors) are implemented using methods.
The difference is whether we're discussing the invocation or the response. OP's usage of method isn't incorrect in this case if it's discussing the response. It is true that all message responses (including accessors) are implemented using methods.
> It is true that all message responses (including accessors) are implemented using methods.
An object can respond to a message even though it doesn't have a method with that name. A classic example are Rails' dynamic finders:
An object can respond to a message even though it doesn't have a method with that name. A classic example are Rails' dynamic finders:
User.methods.include?(:find_by_name)
=> false
User.respond_to?(:find_by_name)
=> trueYes and the responses are implemented with methods. Always.
> An object can respond to a message even though it doesn't have a method with that name.
Sure, by using a different method (method_missing); its still all method calls.
Sure, by using a different method (method_missing); its still all method calls.
I believe he meant local variables (or if he didn't he should have).
Well, they sort of do, in the form of instance variables.
Ish. In the context of the GP's point, they aren't a problem because the syntax to access them is distinct.
[deleted]
> "require" gives you methods that appear out of nowhere (unlike other language where they are name spaced)
I always worry about this too, but in practice I've rarely run into a namespace collision (I can't even remember the last time it happened.)
I always worry about this too, but in practice I've rarely run into a namespace collision (I can't even remember the last time it happened.)
This looks awesome so far - kudos to the team. I also started benchmarking it just for fun[0]
[0] - http://marianposaceanu.com/articles/ruby-2-2-0-preview-1-qui...
[0] - http://marianposaceanu.com/articles/ruby-2-2-0-preview-1-qui...
Waiting for Christmas...
> Because if this Rails 5.0 will be released for Ruby [...]
I guess there's a typo: s/if/of
I guess there's a typo: s/if/of
Now benchmarks Benchmarks...