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.
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.
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.
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)
It isn't asymptotically slower than the normal algorithm for k=1, it doesn't need to make multiple passes over the data, and it doesn't mutate the original data structure, so it's a pretty sensible and natural extension to put in.
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
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).
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.
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.
