What are your favorite Ruby features?

Ruby
21

Tony A. wrote:

some.

Reia! I thought your name sounded familiar.

Here’s my own list. I did fill out the questionnaire, but I’m not sure
which of these were covered:

I like Ruby’s relaxed syntax. I like letting things like parentheses be
implied, leading to interesting, emergent phenomena like hashes as named
arguments. (Not that I would complain if the language implemented named
arguments – even better if I don’t have to use them as a hash – so
long as I can if I need to.)

I like the ability to create good-looking DSLs, but that’s similar to
the above.

The biggest thing I like from Python, and miss in Ruby, is significant
indentation. Having a ton of end statements at the end of a file isn’t
particularly DRY, and I tend to have consistent indentation anyway.

The biggest thing I like from Javascript, and miss in Ruby, is
prototypal inheritance and the near lack of a type system. There’s no
difference between a proc, a block, a function, and a method, and I can
take any function, and apply it as a method to any object.

I also like things like Rubinius. I’d love to be able to dig deep into
something like Reia without needing to use Erlang, just as I can usually
dig into Ruby without needing C.

One thing I like from Erlang, and hope Reia keeps, in some form:
Reloading modules on the fly.

This may be difficult, though – technically it’s possible in Ruby, but
Ruby is dynamic enough that the sanest way has been Merb’s approach of
loading all of the library and framework code (everything except your
app), then forking, then loading your app. When you want to make a
change to your app, it kills the child, forks again, and loads your
code, rather than try to patch a new version of your code onto the
old…

Probably your best bet is to make it possible, and let other solutions
be developed on top of that capability.

I love the idea of Reia, and can’t wait to see where it goes. It’s not
yet polished enough to be used at work, and I’ve been impatient enough
that I’ve started trying to write an actor library in Ruby. It’s going
very, very slowly.

22

Hi –

On Tue, 17 Feb 2009, Tony A. wrote:

On Mon, Feb 16, 2009 at 3:25 AM, David A. Black [email protected] wrote:

or open classes and monkeypatching (I don’t know which
of the various meanings of the latter you mean; I think they’re all
subsets of the former)

Pretty much, that was meant to cover all cases of altering the definitions
of existing classes/modules at runtime by a facility which may lack formal
knowledge of what the original definition actually was.

I would say that altering core functionality badly is not a favorite
thing, but doing it knowledgeably might be :slight_smile:

reasons but DSLs are one particularly compelling use case for them, I
believe.

I know people sometimes bundle the concept of DSL and the idea of
sounding like English together (with mixed success, usually, in my
view), but “domain-specific” doesn’t really imply emulation of natural
language; it just implies a particular well-defined emergent notation
based on a subset of (computer) language constructs. At least, that’s
how I see it.

I guess the only form of optional parentheses I actually would prefer
Ruby not to support is:

def a b, c = 1

but it’s not a very big deal.

A couple of other things that might go on such a list:

String interpolation

This was covered by the poll, I believe, although described as:

Embedding code in strings with “#{mycode}”

Whoops, I forgot that when I made my list.

Zero being true

Yes, definitely a noticeable omission. I love Ruby’s boolean semantics
although they seem to confuse newbies to the language.

It’s definitely one of the Ruby rites of passage :slight_smile:

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp

23

On 17 févr. 09, at 01:16, David M. wrote:

I like Ruby’s relaxed syntax. I like letting things like
parentheses be implied, leading to interesting, emergent phenomena
like hashes as named arguments. (Not that I would complain if the
language implemented named arguments – even better if I don’t have
to use them as a hash – so long as I can if I need to.)

I like the ability to create good-looking DSLs, but that’s similar
to the above.

It’s possible that without the humble feature of optional parentheses
Rake would never have been invented and I might never have been
compelled to take a serious look at Ruby. Since then I’ve often
wondered why parentheses are still so heavily used in most Ruby code
even when they offer no compelling utility for most uses. In
contrast, omitting unnecessary semicolons seems almost universal. I
suppose parentheses are more habit forming for some reason.

24

On Mon, Feb 16, 2009 at 9:59 PM, David A. Black [email protected]
wrote:

reasons but DSLs are one particularly compelling use case for them, I
believe.

I know people sometimes bundle the concept of DSL and the idea of
sounding like English together (with mixed success, usually, in my
view), but “domain-specific” doesn’t really imply emulation of natural
language; it just implies a particular well-defined emergent notation
based on a subset of (computer) language constructs. At least, that’s
how I see it.

Yes, I agree. In fact I could argue that:

Fortran is an example of an early DSL for the Domain of numerical
algorithms
and
APL or at least a large subset, is an example of a DSL for matrix and
vector manipulation

Neither of these is particularly English like, in the second case not
even
remotely.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

25

On Feb 17, 2009, at 5:59 PM, Rick DeNatale wrote:

“just because you can” to tend to look far stranger to my eye than
putting
them in. In fact, sometimes when reading code without them I find
myself
having to read very slowly in order to figure out just how Ruby is
parsing
what I’m reading.

I like to switch on situation. Usually, my rule of thumb is:

Descriptive code without braces, algorithmic code with braces.

===
has_many :foobars
#vs.
has_many(:foobars)

(really, the braces bring no gain)

and

===
foo(bar(batz))
#vs.
foo bar(batz)

(the omission kills readability)

Btw., my favourite feature about Ruby is its ability to mix
descriptive code and algorithmic code very well.

Regards,
Florian

–
Florian G.

smtp: [email protected]
jabber: [email protected]
gpg: 533148E2

26

On 17 févr. 09, at 11:59, Rick DeNatale wrote:

arguments. (Not that I would complain if the language implemented
It’s possible that without the humble feature of optional
for some
executed
what I’m reading.
It seems to me as if the coding style and the language feature are at
odds with regard to Ruby and optional parenthesis. And I wonder if
this is a consideration in making a new language, choosing features,
and determining coding style. Should you add features that you plane
to avoid using in common practice? I don’t know if DSLs were a
consideration when deciding to have optional parenthesis. If they
weren’t, then maybe the utility of Ruby for DSLs required a bit more
luck than otherwise. Parenthesis seem so often used at times that
it’s almost if the option doesn’t exist.

Strangeness is somewhat arbitrary. That’s why a brought up the use
of semicolons. Many languages require them all over the place. Ruby
makes them
optional. Yet Ruby style conventions universally omit them when
they’re superfluous. So it isn’t strange to not use them even
though many common languages do. And of course some language don’t
use parentheses nearly as much as is commonly practiced in Ruby and
it isn’t strange in those languages.

27

Rick DeNatale wrote:

On the other hand, I’ve always found leaving out parentheses in Ruby code,
“just because you can” to tend to look far stranger to my eye than putting
them in. In fact, sometimes when reading code without them I find myself
having to read very slowly in order to figure out just how Ruby is parsing
what I’m reading.

I found that after a few days of deliberately only using parentheses
when needed, combined with a decent editor with synatx highlighting, and
I no longer need them at all. I don’t find code unreadable with them –
I have to work in JavaScript, after all – but I don’t have a problem
without them, and they do get annoying sometimes.

28

David M. wrote:

I found that after a few days of deliberately only using parentheses
when needed, combined with a decent editor with synatx highlighting, and
I no longer need them at all. I don’t find code unreadable with them –
I have to work in JavaScript, after all – but I don’t have a problem
without them, and they do get annoying sometimes.

Same here. I think of them as FGPs: Feel-good parentheses, used because
they make people accustomed to C or Java feel more comfortable, though
they do not contribute any real code value.

–
James B.

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

29

On Tue, Feb 17, 2009 at 9:44 AM, Juan Z.
[email protected]wrote:

above.

It’s possible that without the humble feature of optional parentheses Rake
would never have been invented and I might never have been compelled to take
a serious look at Ruby. Since then I’ve often wondered why parentheses are
still so heavily used in most Ruby code even when they offer no compelling
utility for most uses. In contrast, omitting unnecessary semicolons seems
almost universal. I suppose parentheses are more habit forming for some
reason.

IMHO, coding Ruby without parentheses is a particular kind of spice.
Whether you should use a particular spice depends on what you are
cooking.

The parentheses free style works well for certain internal DSLs like
Rake or
ActiveRecord association declarations, since they make run-time executed
expressions feel declarative.

On the other hand, I’ve always found leaving out parentheses in Ruby
code,
“just because you can” to tend to look far stranger to my eye than
putting
them in. In fact, sometimes when reading code without them I find myself
having to read very slowly in order to figure out just how Ruby is
parsing
what I’m reading.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale

30

Hi –

On Tue, 17 Feb 2009, Robert D. wrote:

I have the feeling you did not take my suggestion seriously, pity…
I’m not sure I quite understood. Can you recap your suggestion?

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp

31

Hi –

On Wed, 18 Feb 2009, Robert D. wrote:

What kind of confused me was your metaphor with food, of which, when I
took it up, you said: “well one cannot compare with food” …
And that somehow was a show stopper which I found a lit bit a pity.

I didn’t actually say that, but the food analogy isn’t really worth a
whole analysis.

No big deal of course, nobody seems to be interested anyway …

I think what I was saying mainly was: even if I like, say, string
interpolation, that doesn’t mean that I get pleasure out of placing
“#{}” into my programs as often as I can, nor that I think I should
look for ways to write programs with string interpolation. I don’t
think that’s what it means to like a language feature.

Of course there are language features that one might want to use more
because they solve particular problems, or do things better than other
ways, but those may or may not be the ones I would put on an informal
list of my favorite bits of Ruby.

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp

32

On Feb 17, 2009, at 9:30 PM, James B. wrote:

David M. wrote:
Same here. I think of them as FGPs: Feel-good parentheses, used
because they make people accustomed to C or Java feel more
comfortable, though they do not contribute any real code value.

Thats a harsh statement for those that do actually like parantheses
and not because they are C//Java-Guys.

For example, i find the following irritating and bad style:

===
def initialize foo, bar, batz = {}, &block
#(vs.)
def initialize( foo, bar, batz = {}, &block )

I see the argument list as a tuple and I like it to resemble one.

Also, i tend to brace long and unbalanced statements:

===
var_foo_bar = (::Something::Somewhere::Object.new(
:foo => “bar”
)
)

Regards,
Florian

–
Florian G.

smtp: [email protected]
jabber: [email protected]
gpg: 533148E2

33

On Tue, Feb 17, 2009 at 10:45 PM, David A. Black [email protected]
wrote:

Hi –

I’m not sure I quite understood. Can you recap your suggestion?

Gladly, let us ponder why lambdas are not used more although everyone
likes them so much.
That does not mean that we shall use them more (though that is my
guess), but only that we might not be able to tell if we do not try.

What kind of confused me was your metaphor with food, of which, when I
took it up, you said: “well one cannot compare with food” …
And that somehow was a show stopper which I found a lit bit a pity.

No big deal of course, nobody seems to be interested anyway …

Cheers
Robert

34

On Wed, Feb 18, 2009 at 9:48 AM, Florian G. [email protected]
wrote:

because they are C//Java-Guys.
I did not think so, unless you feel inferior because you are a C /
Java guy, which IMHO you should not.

For example, i find the following irritating and bad style:

===
def initialize foo, bar, batz = {}, &block
#(vs.)
def initialize( foo, bar, batz = {}, &block )

I find the second irritating because those parens are sooo superfluous.
Does that mean that the first idiom is bad style??? Certainly not, I
can get used to it if I must.

I see the argument list as a tuple and I like it to resemble one.
Very valid point of view, but my brain sees it as a declaration. My
brain could be trained to see it as a tuple, but right now I do not
want to do that.

Cheers
Robert

35

On Feb 18, 2009, at 1:04 PM, Robert D. wrote:

do not contribute any real code value.

Thats a harsh statement for those that do actually like parantheses
and not
because they are C//Java-Guys.
I did not think so, unless you feel inferior because you are a C /
Java guy, which IMHO you should not.

Nice bait. But I just had dinner.

I find the second irritating because those parens are sooo
superfluous.
Does that mean that the first idiom is bad style??? Certainly not, I
can get used to it if I must.

I consider it bad style. It’s a personal opinion. I can live with
people using it, thats the freedom Ruby gives them.
If I hack other peoples code, I have no problem with using it to keep
the code consistent.

As I said: I consider it a supreme feature of Ruby of making this
optional depending on your viewpoint.

I see the argument list as a tuple and I like it to resemble one.
Very valid point of view, but my brain sees it as a declaration. My
brain could be trained to see it as a tuple, but right now I do not
want to do that.

Sure, it is a declaration, but for two seperate entities (the method
and its arguments). We could go on like this for ages ;).

Actually, I think round braces are more an indicator of a secret lust
for LISP.

Regards,
Florian

36

On Wed, Feb 18, 2009 at 2:38 AM, David A. Black [email protected]
wrote:

Of course there are language features that one might want to use more
because they solve particular problems, or do things better than other
ways, but those may or may not be the ones I would put on an informal
list of my favorite bits of Ruby.
Understood David
I did not want to say what I think about lambdas because I was really
interested in what people might think of it.
But nothing happened :(.
Well that’s life.
At least I can speak freely now and sorry for having been cryptic but
it was intentional, although not productive.

I believe that Ruby would highly benefit of using all of its
behavior implementing features.
Assumption: “Lambdas are often the better way to implement behavior
instead of using a class right away.” Problem is that I am so
conditioned to using classes that I never think of it.
I once looked at some of the easier Ruby Q.zes and I estimated that
more than 50% could have been written with lambdas and without classes
resulting in “simpler” code…

But it remains to be seen what the exact advantage of that approach
would be. In order to be able to do that one would need more code
examples, right? And in order to have more code examples one would
need some folks to adapt that approach… ( me first LOL)

Am I talking too much? Well at least it should be clear now what I
wanted to say.
And of course I accept all opinions that this exercise might be
futile, which indeed it might be of course.

Thanx for listening.
Robert

37

On Wed, Feb 18, 2009 at 1:47 PM, Florian G. [email protected]
wrote:

Actually, I think round braces are more an indicator of a secret lust for
LISP.
Oh but I like LISP too, you see there is always some common ground :wink:
Actually I believe that my relative dislike for parens comes from
Smalltalk…
Robert

38

Hi –

On Wed, 18 Feb 2009, Florian G. wrote:

Actually, I think round braces are more an indicator of a secret lust for
LISP.

I’ve never written any Ruby code for the purpose of making C and Java
programmers feel comfortable, and I don’t secretly lust for Lisp. I
think that takes care of all the non-Ruby motives attributed to those
of us who wrap parameter lists and (some) arguments in parentheses :slight_smile:

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp

39

2009/2/18 Robert D. [email protected]:

Thats a harsh statement for those that do actually like parantheses and not

I find the second irritating because those parens are sooo superfluous.
Does that mean that the first idiom is bad style??? Certainly not, I
can get used to it if I must.

yes, for a def the parentheses are superfluous. However, for a method
call with more than one argument they often add quite a bit
readability, at least for me.

I also often write things like

foo(bar baz)
foo(bak, (bar baz))

I really wish it was possible to write

foo (bar baz)

but it issues a warning in ruby.

What I like about Ruby is that many things are easy to start and
change, and once written they are still short enough to grasp.

The features that make your programs short are

  1. useful utility functions in the stdlib and the possibility to
    monkey-patch in things that you do repeatedly

  2. useful return values of many methods

Together they allow chaining of methods that makes a single line of
code do several things in a readable way.

On the other hand there are places where you hit limits.

Methods like gsub! that can return nil instead of the value on which
it operates.

Webrick is a nice simple web server included in stdlib. It’s easy to
start with. It has authentication and index generation but last time I
asked around it seemed impossible to merge the two without rewriting
substantial part of webrick.

Thanks

Michal

40

On Tue, Feb 17, 2009 at 2:40 PM, David M. [email protected]
wrote:

I found that after a few days of deliberately only using parentheses when
needed, combined with a decent editor with synatx highlighting, and I no
longer need them at all. I don’t find code unreadable with them – I have to
work in JavaScript, after all – but I don’t have a problem without them,
and they do get annoying sometimes

That might be fine as long as you are the only one reading your code.

But I’ve read lots of ruby code written by myself and a lot of other
ruby
programmers of varying levels, and I find code which eschews parentheses
whenever possible rather than in more declarative DSL contexts MUCH
harder
to read.

And to second what other have said

def foo bar

Is not a declarative DSL context, at least in my estimation.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale