What are your favorite Ruby features?

[David Masover]

Well, in my case, my language is running on the Erlang VM (
http://wiki.reia-lang.org) and will have all the features of Erlang and then
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.

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

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.

 

[Juan Zanos]

I like Ruby's relaxed syntax. I like letting things like =20
parentheses be implied, leading to interesting, emergent phenomena =20
like hashes as named arguments. (Not that I would complain if the =20
language implemented named arguments -- even better if I don't have =20=

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 =20
to the above.

It's possible that without the humble feature of optional parentheses =20=

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

 

[Rick DeNatale]

It's possible that without the humble feature of optional parentheses Rak= e
would never have been invented and I might never have been compelled to t= ake
a serious look at Ruby. Since then I've often wondered why parentheses a= re
still so heavily used in most Ruby code even when they offer no compelli= ng
utility for most uses. In contrast, omitting unnecessary semicolons seem= s
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 o=
r
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.

--=20
Rick DeNatale

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

 

[Florian Gilcher]

On Tue, Feb 17, 2009 at 9:44 AM, Juan Zanos


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

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 like to switch on situation. Usually, my rule of thumb is:

Descriptive code without braces, algorithmic code with braces.

===
has_many :foobars
#vs.
has_manyfoobars)
===
(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 Gilcher

smtp: (e-mail address removed)
jabber: (e-mail address removed)
gpg: 533148E2

 

[Juan Zanos]

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

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

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

It seems to me as if the coding style and the language feature are at =20=

odds with regard to Ruby and optional parenthesis. And I wonder if =20
this is a consideration in making a new language, choosing features, =20
and determining coding style. Should you add features that you plane =20=

to avoid using in common practice? I don't know if DSLs were a =20
consideration when deciding to have optional parenthesis. If they =20
weren't, then maybe the utility of Ruby for DSLs required a bit more =20
luck than otherwise. Parenthesis seem so often used at times that =20
it's almost if the option doesn't exist.

Strangeness is somewhat arbitrary. That's why a brought up the use =20
of semicolons. Many languages require them all over the place. Ruby =20=

makes them
optional. Yet Ruby style conventions universally omit them when =20
they're superfluous. So it isn't strange to not use them even =20
though many common languages do. And of course some language don't =20
use parentheses nearly as much as is commonly practiced in Ruby and =20
it isn't strange in those languages.

 

[David Masover]

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.

 

[James Britt]

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 Britt

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

 

[David A. Black]

Hi --

I am glad you realize.
Now do you really think it is a bad idea to think about modifying our
approach to what we do in general and programming in Ruby in special?
Is there anything intrinsically counter productive or maybe even
stupid in my remark?
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 (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09

 

[Robert Dober]

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

--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[David A. Black]

Hi --

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.

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 (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09

 

[Florian Gilcher]

David Masover 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 Gilcher

smtp: (e-mail address removed)
jabber: (e-mail address removed)
gpg: 533148E2

 

[Robert Dober]

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 Quizzes 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

David

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

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09

--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[Robert Dober]

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.

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

--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[Florian Gilcher]

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.

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

 

[Robert Dober]

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
Actually I believe that my relative dislike for parens comes from Smalltalk....
Robert
--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[David A. Black]

Hi --

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


David

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

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09

 

[Michal Suchanek]

I did not think so, unless you feel inferior because you are a C /
Java guy, which IMHO you should 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

 

[Rick DeNatale]

[Note: parts of this message were removed to make it a legal post.]

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.

 

[Robert Dober]

def foo bar

That is very hard to read indeed, but why?

def foo( bar )

This is not so much better!
We are all totally accustomed to the fact that foos and bars designate
the same kind of thing.

I therefore think that

def fact n

is more readable for most people than

def n( fact )

which is nonsense of course (in the particular context).

Naming seems more important than params or not params (of course if I
might say?).

Cheers
Robert


--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)