Ruby 2.1.0 Released
Today marks the release of Ruby version 2.1.0. A brief list of changes since 2.0.0 has been posted, and file downloads are available. Here are some of the changes:
- Now the default values of keyword arguments can be omitted. Those 'required keyword arguments" need giving explicitly at the call time.
- Added suffixes for integer and float literals: 'r', 'i', and 'ri'.
- def-expr now returns the symbol of its name instead of nil.
- rb_profile_frames() added. Provides low-cost access to the current ruby stack for callstack profiling.
- introduced the generational GC a.k.a RGenGC (PDF).
Why does Ruby get its own color?
What comedic timing: Is Ruby Dying.
Wow, just yesterday it was dying, and today they release a new version! I guess they didn't get the memo
"Hello, IT... Have you tried turning it off and on again? Yeah... No problem."
And I accidently sent my comment away. The syntax is great, but I don't like the way Ruby hasn't crystallized yet. Every new version they somehow remove compatibility with the old versions, that's bad. My scripts stop working and I have to fix everything, this is not userfriendly.
Documation is scattered and incomplete. It's something that needs to fixed if they want to get to version 4
"My scripts stop working and I have to fix everything, this is not userfriendly."
That's not a problem with Ruby, it's a problem with jruby.
"Documation is scattered and incomplete. It's something that needs to fixed if they want to get to version 4"
No, it isn't.
And if you want more documentation get your hands on the book "Programming Ruby" (often incorrectly called "the pickaxe book"), like everybody else does. It is frequently updated for the latest ruby versions. Since it's from Pragmatic Programmers, purchase once and get the (pdf) updates whenever they come out.
Out of curiosity, excluding Rails, why would one prefer to use Ruby over...say...Python? Is there an area in which Ruby is widely regarded to be superior?
Python is a great language. I wouldn't want to fan the flames of the Ruby vs. Python debate as the intent behind both languages is essentially the same. Matz designed the language to be human-centric, following the "principle of least surprise". Python is similarly very friendly to coders. That's what I love about Ruby. When I started out coding in the language and had to figure out how to do something new it was often a matter of asking what's the most obvious way. And usually that worked. Plus you have all the best bits of PERL, Smalltalk and Lisp in a clean, easily readable syntax.
As an aside, I'm surprised the "meta-programming" reference got targeted over "programmer joy".
Not to be snarky...but what I'm hearing from you is this: "Ruby and Python occupy the same niche and there's no compelling reason to prefer Ruby over Python". This seems to jive with what the guy said who you were responding to: "Ruby adds nothing to the existing languages". If the only language that existed were C then I'd say that guy is full of shit because in that case Ruby would clearly "add something to the existing languages". But, given Python's existence, he kind of has a point. Python is more widely supported, has a larger base of developers, is generally thought to be a better "thought out" language in terms of design, and is well-suited to solving the same sort of problems Ruby is well-suited to solving.
I've used both a fair bit. They are similar in many ways so it's mostly a matter of preference.
I've found Ruby makes it easy to explore objects and see what can be done with them. The consistent OO model makes it easy to perform concise data manipulation. Here's a quick example:
irb(main):001:0> arr = ["1", "2", "3", "4"]
=> ["1", "2", "3", "4"]
irb(main):002:0> arr.methods - Object.methods
=> [:to_a,
irb(main):003:0> arr.pop
=> "4"
irb(main):004:0> arr.join
=> "123"
irb(main):005:0> arr.map { |i| i.to_i }
=> [1, 2, 3]
irb(main):006:0> arr.map(&:to_i).reduce(&:+)
=> 6
Here's the same thing in Python:
In [1]: arr = ["1", "2", "3", "4"]
In [2]: dir(arr)
Out[2]:
[(stuff removed, fucking lameness filter) 'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']
In [3]: arr.pop()
Out[3]: '4'
OK, it's pretty sim
In respect to our Python-coding brothers and sisters, both Python and Ruby are very developer-friendly. Anyway, here is a nice comparison of the two languages' features: http://stackoverflow.com/questions/1113611/what-does-ruby-have-that-python-doesnt-and-vice-versa
Obviously I prefer Ruby and to touch on the meta-programming aspect (whether good or evil), IMHO Ruby does a better job in this area. Mutable classes might give some people the heebie-jeebies, but it's saved my bacon several times. Ruby's Smalltalk-like message passing is sweet. Writing DSLs in Ruby is much more straightforward than in Python. There are many things to like.
Python gives you a nice sense of structure, but that can be a curse as well as it feels quite rigid. Most of the people I know who code in Python come from an engineering background, and that kinda makes sense to me. It feels like an engineering language. Ruby on the other hand is more fluid. It lends itself to more organic styles of coding.
The original AC post about "Ruby adds nothing to the existing languages" is clearly a troll, though I'd say the poster is right in a way. Ruby doesn't necessarily introduce anything new - it just puts it all together in the one place. Plus it's a joy to code in.
I like both. For different reasons. Python's mental model is a bit simpler to reason about usually. Equating modules to files and the like is very clean. With Ruby any object's definition is open, and can be continued in any part of the program. This does make it harder to reason about, but like with many advanced features, this is best used sparingly. It does open the door for other programming syles though. I've seen this applied to create AOP and SOP type programs. Another element I enjoy is the block parameter, which allows you to pass a block of code from the current context as a parameter to any method you're calling. This block could be called at any point within that method's call stack, referring back to objects from the call site.