

Why Ruby rocks - Skoofoo
http://skofo.github.io/blog/why-ruby-rocks/

======
nopal
I'm sure it does, but I can write the same class in C# just as easily:

    
    
        class Person
        {
            public int Sanity { get; set; }
        
            public Person()
            {
                Sanity = 50;
            }
        }
    

And to call it:

    
    
        var programmer = new Person();
        programmer.Sanity += 1000000;
        Console.WriteLine(programmer.Sanity);
    

I don't see much difference between Person.new and new Person();.

What are the real ways in which it will knock my socks off? I'm honestly
asking. Even though I program C# at work, I'm very interested in the
advantages of other languages.

~~~
effbott
Ruby really is a great language. The author just posted a poor example that is
frankly NOT idiomatic Ruby. The proper way to create a getter and setter
method on an instance variable is like so:

    
    
      class Person
        attr_accessor :sanity
    
        def initialize
          @sanity = 50
        end
      end

~~~
jfarmer
All the attr_* class methods do is define precisely the instance methods the
author wrote by hand. Indeed, if attr_reader, attr_writer, and attr_accessor
weren't part of Ruby's Module class you could write them yourself, like so:
[https://gist.github.com/jfarmer/6b4deeb8bcfbe030f876](https://gist.github.com/jfarmer/6b4deeb8bcfbe030f876)

If using an "eval" method seems smelly to you, you can achieve the same result
in pure Ruby using define_method, instance_exec, and instance_variable_get.
There are good practical reasons to use module_eval, though.

Regardless, I think the author's point was more that there's nothing "special"
about getters and setters in Ruby. They're just plain ol' methods. As a class
of methods we write them often enough that we've also defined a higher-order
method that takes an instance variable name as input and dynamically defines
those getters and setters on the underlying object.

We wouldn't "lose" anything by not having attr_reader and friends, though. Our
code would just be slightly more verbose.

~~~
effbott
>Regardless, I think the author's point was more that there's nothing
"special" about getters and setters in Ruby. They're just plain ol' methods.

Ah, that's a good point. That seems to be a more accurate interpretation of
what the author was trying to express.

------
CoffeeDregs
Not needing getters/setters makes Ruby rock? Lots of languages allow this, but
Ruby's allowing you to elide parentheses means you can't assume that a
property is a property or a function. In other languages, the property versus
accessor distinction is more limited and less confusing.

 _method_missing_ , which is a bit of a hack and is at least a double edged
sword, makes Ruby rock? Sure, it's handy magic, but it's a pretty dangerous
form of magic.

I'm not sure I could think of less significant attributes for a language.

Note: I work on a large Ruby codebase...

~~~
jamesbritt
_you can 't assume that a property is a property or a function. In other
languages, the property versus accessor distinction is more limited and less
confusing._

Ruby does not have "properties." All data is private and you interact with
objects using messages.

As a user of an object's interface all you need to know is how something
behaves when sent various messages. Whether "foo = 12" is really setting an
instance variable named "@foo" or something else entirely should be
irrelevant. It's an implementation detail.

I realize this sounds possibly condescending and pedantic, but I've seen too
many Ruby tutorials that try to present the language in terms of behavior
found in other languages where the result is a broken mental model of how Ruby
actually works. Hence, confusion.

Unfortunately the conflation of methods that happen to get or set instance
variables with the notion of properties (AKA "attributes") has become
ingrained.

 _method_missing, which is a bit of a hack and is at least a double edged
sword, makes Ruby rock? Sure, it 's handy magic, but it's a pretty dangerous
form of magic._

Thinking in terms of messages sent to a receiver, "method_missing" is far less
magical. It's more something you'd expect in a message-handling system.

------
akoumjian
It is my impression that Python does exactly the things listed here, but more
explicitly. With the python approach, instance variables are public by default
(as attributes). There is never any confusion between when you are calling a
method, or referencing an attribute. If you are doing something something more
complicated than getting or setting an attribute, you must either call a
method (this is so you and other developers actually know what is going on),
or alternatively you use a property decorator.

You could do something similar to Ruby's missing_method, by setting the
class's __getattr__, but you'd really have to ask yourself why. What kind of
creation are you building that you are expecting to not know which methods are
available while running your program?

These are the kinds of things that drive me batty with Ruby. Perhaps if I
spent about double or triple the hours on Ruby that I have, I might have an
"aha" moment. However, from what I've seen I can't help but feel that what
it's really trying to accomplish is much more comfortable in functional form
(say Lisp?).

~~~
dpritchett
Try listening to Sandi Metz on the Ruby Rogues podcast. It's a longish episode
but she'll give you an appreciation for message-passing OO and how it makes an
application design more pliable.

In a pinch the (free?) "Barewords" episode of Ruby Tapas will get you close in
five minutes.

~~~
akoumjian
Awesome, will do.

------
laureny
I started programming in Ruby in early 2000 and I really liked it back then,
but when I look at it today, the language feels very old.

I don't know if it's the lack of types, the fact that you see streams of "end
end end" like Pascal used to do, the abysmal performance of the default VM or
just the heavy reliance on monkey patching, but Ruby is not aging very well.

~~~
area51org
_I don 't know if it's the lack of types_

Ruby is a dynamic language, so no, there are no types as such. There are ways
to create types, but if you're doing that a lot, you're probably doing Ruby
wrong. It's not meant to have types. Different way of thinking.

 _the abysmal performance of the default VM_

That's a myth, a pervasive one. I'll point you to one source that debunks
this, but there are many. [http://www.unlimitednovelty.com/2012/06/ruby-is-
faster-than-...](http://www.unlimitednovelty.com/2012/06/ruby-is-faster-than-
python-php-and-perl.html)

 _the heavy reliance on monkey patching_

Monkey patching is generally considered an anti-pattern. I'm not sure what in
particular has "heavy reliance" on it, but it's not Ruby's libraries
themselves, and it's not Rails. (Metaprogramming is not the same thing as
monkey patching.)

 _Ruby is not aging very well._

IMHO Ruby is just now coming fully into its own, and is, for a young language,
just reaching maturity.

~~~
namidark
I would hardly say the performance of the default VM is a _myth_... just look
at performance characteristics under multi-threading and GC pressure.

~~~
bhauer
Speaking of Ruby performance, we haven't received a whole lot of pull requests
improving the performance of the Ruby implementations on our benchmarks
project [1]. If you feel Ruby isn't getting a fair shake on performance
measurements, we'd love to see some pull request love.

[1]
[http://www.techempower.com/benchmarks/](http://www.techempower.com/benchmarks/)

~~~
laureny
That's quite a weird angle. Surely I can express unhappiness about a product's
performance without being asked to fix it or to shut up?

~~~
bhauer
I think we're on the same side here.

We've measured the performance of the fundamentals of web applications on two
Ruby implementations (MRI, JRuby) and both perform poorly, as compared to the
rest of the field. area51org says that Ruby's reputation of slowness is
undeserved. I feel our data confirms the reputation.

In fact, I don't think there's much room for improvement by tweaking our
tests, but I figured I'd make the solicitation anyway to keep an open mind
about it.

I'm not asking you to fix it or shut up, especially since I feel your point of
view is corroborated by the data. I am asking, however, for those who say
Ruby's reputation is undeserved to consider providing some evidence for that
point of view. And one conceivable way to do that would be to improve our Ruby
tests.

------
xmodem

      def sanity
        @sanity
      end
    
      def sanity=(val)
        @sanity = val
      end
    

how are those six lines not boilerplate?

~~~
dpritchett
I believe it'd be idiomatic to use

    
    
      attr_accessor :sanity
    
      def initialize
        @sanity = 0
      end
    

On that note I like Go's default values for primitive types. An int sanity
would be zero by default.

Edit: seeing five simultaneous posts saying the same thing makes me feel
trolled a bit :)

~~~
rmrfrmrf
Nah, Rails devs are just _really_ excited to finally have their chance to
shine in the HN comments ;)

------
swang
Ruby is a pleasure to program in, however...

1\. The drama that surrounds Rails makes a lot of people just throw their
hands up and quit. 2\. There are very few Ruby shops that aren't just Rails
shops.

~~~
Schwolop
I agree. I tried web development professionally; loved Ruby, thought Rails was
pretty decent, but hated web development (and ultimately wasn't at all
inspired by the product we were building).

Now every Ruby meetup I attend, 99% of the presentations are from web devs
about rails and associated infrastructure.

~~~
jamesbritt
_Now every Ruby meetup I attend, 99% of the presentations are from web devs
about rails and associated infrastructure._

That's pretty much why I lost interest in not just local groups but most
online activity.

I use Ruby and JRuby all the time, but for Web dev I'll start with some simple
Rack stuff and evolve to a Ramaze app if needed.

Listening to someone discuss installation and assorted config params for a gem
that only works with a specific framework is not terribly interesting.

There are some bright spots online, Greg Brown's Practicing Ruby site being a
solid example.

[https://practicingruby.com](https://practicingruby.com)

------
wittekm
Showing people boilerplate instead of attr_accessor isn't really a way to
convince people that Ruby's great.

------
andyl
What I like about Ruby: Bundler, Gems, Enumerable, concise syntax, Ruby2,
Rspec, RubyMine, Scripting, rbenv/rvm

What I would like to have: better support for concurrency, less memory
consumption in production

------
grey-area
I'm not sure this really sells what's best about Ruby. Python and many other
languages offer very similar tools, and the example given is nowhere near
idiomatic Ruby anyway - it should be using attr_accessor as others have
pointed out. I can't see that this is markedly different from many other
languages which now have shortcuts for accessors.

method_missing is interesting because it has been criticised in projects like
Rails, precisely because it leaves you with an API which isn't documented
explicitly in the code. As Rails matures they've moved away from dynamic
finders, and more towards defined methods which take options, so instead of

Post.find_all_by_xxx or Post.find_by_xxx

People often use:

Post.where(xxx)

I've never been tempted to use it explicitly myself, in quite a few years of
using Ruby, it just feels too hacky somehow and too akin to monkey-patching,
another early Ruby practice which Rails has moved away from.

In contrast I do love the automatic accessors (not as shown in this post) in
Ruby and the philosophy that everything should be as simple and predictable as
possible, just having to edit header files is so jarring when going back to
something like Obj-C. Ruby feels comfortable to me mostly because of the
attitude of the language and the standard library which is pretty surprise
free and covers most of the bases, but it's not markedly superior or different
IMHO from other languages like Python, and choosing between them is really a
matter of taste.

------
ionforce
I admit I'm being myopic here but that's exactly why I ask. In what scenario
is a genuine message passing/arbitrary methods useful?

I tend to look through everything in an OOP/type safe way, so the idea of
having an unlimited, highly dynamic vocabulary for method calling is very...
Foreign to me.

When does this pattern outshine static interfaces?

~~~
acjohnson55
One spot when it's very useful is in making objects that are proxies for
external resources (file data, executable utlities, etc.). Particularly when
those resources can be inspected, it can be much better from a DRY perspective
to let the interface of your proxy object automatically adapt even as the
underlying resource changes.

------
jasonm23
How is this even on the front page?

------
jamesli
Ruby has many awesome features, like metaprogramming. But methods without
parenthesis, method definitions with operators, etc.?

[edit] I am NOT a native English speaker. Is OP's blog supposed to be a joke
and I don't get it?

------
smoyer
Seems like a pretty weak set of arguments - I'm not for or against Ruby but is
that really a good "five paragraph" description of why I should learn it and
love it?

------
brandonbloom
Setters are an anti-feature.

They give the illusion that they can be set in any order, but most meaningful
classes have invariants that are ambiguous to preserve with single-value
setters. Object Oriented designs jump through some serious hoops to preserve
the pretty `object.property = value` syntax. Besides, there are considerable
advantages to immutability even in the absence of concurrency. `new_object =
frob(object, value)` is generally preferable in the long run.

------
bluedino
Every time I start learning Python, after a few hours I remember "I already
know Ruby", and that's the end of that.

I already know it, so it rocks. Python is fun but I already have Ruby. It's
just a language and there's nothing I can really do in Python that I can't do
it Ruby, and vice-versa (at my level, anyway).

I guess I'm just lucky I have the option of using either instead of say,
______.

------
area51org
While I do appreciate the OP's enthusiasm, there is a lot more to love about
Ruby than its simplicity. Spend some time learning about metaprogramming, and
you may really be impressed.

------
tobias382
Let's talk about Ruby...
[http://destroyallsoftware.com/talks/wat](http://destroyallsoftware.com/talks/wat)

------
ntaylor
So the takeaway here is that Ruby is great because it has core OOP concepts
built into it? Color me unimpressed.

------
laureny
What year is this, 2005?

------
billsix
On front page? Really?

~~~
billsix
OK, I'll be more constructive.

>There are various interwoven reasons for this, but the biggest thing that
makes Ruby shine in my eyes is its objects

Learn Smalltalk-80. Its been around a long time, and has a rich history.

