What are your favorite Ruby features?

[Tony Arcieri]

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

I'm creating a new language which borrows heavily from Ruby, and I'm curious
what features of Ruby its users enjoy the most.

I've put up a poll here:

http://www.twiigs.com/poll/Technology/Computers/25588

It's multiple choice, but if possible, try to limit yourself to the top 10
features of Ruby you consider important, rather than checking every single
box.

And of course, feel free to respond on the list, particularly with any
features you think I've omitted which are worthy of attention.

 

[Phlip]

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

I'm creating a new language which borrows heavily from Ruby, and I'm curious
what features of Ruby its users enjoy the most.

I've put up a poll here:

http://www.twiigs.com/poll/Technology/Computers/25588

It's multiple choice, but if possible, try to limit yourself to the top 10
features of Ruby you consider important, rather than checking every single
box.

Many of the items you list, such as "metaprogramming", or "easy to create DSLs",
are now must-have features for any language, going forward. That is Ruby's
impact on the industry.

But about "Redefining the behavior of core types", one might conflate overriding
with Monkey Patching. Overriding is good - it's what OO is all about. But...

It would be nice if Ruby, and your language, made Monkey Patching safe. One
reason we monkeys must patch is lack of Construction Encapsulation. If we could
simply upgrade the target object itself to our derived type, then we would not
need to "underride" a method and risk everyone gets it. So a system that
encapsulates construction automatically, so programmers don't need to work extra
for it, might be useful.

Another way to make MP safe might be Aspect Oriented Programming. I suspect that
AOP is actually Monkey Patching, with the added benefit you can declare which
modules see the patch and which see the classic behavior.

Finally, this may come as a shock to those who read my posts, but I tend to
think that TDD support systems, beginning with the lowly assert() method, should
behave like a debugger's variable watch system when they fail. They should
report the source code and value of every expression in their neighborhood when
they fail. But implementing that for an assertion - even within the mighty Ruby
- is often freaking impossible. I have written an assert{ 2.0 } that comes
very close, using major hacking with internal Ruby tools on that block. But
getting rid of the block, and just using assert(), would be a major win.

Could your language provide all those abilities as first-class features, under
the "metaprogramming" and "reflection" banners, so we can use them anywhere?
(And [ahem!] why weren't they in your list?

 

[M. Edward (Ed) Borasky]

Many of the items you list, such as "metaprogramming", or "easy to
create DSLs", are now must-have features for any language, going
forward. That is Ruby's impact on the industry.

Those existed in Lisp, Scheme and Forth, but Ruby made them *popular*
and quite a bit more readable.

Another way to make MP safe might be Aspect Oriented Programming. I
suspect that AOP is actually Monkey Patching, with the added benefit you
can declare which modules see the patch and which see the classic behavior.

Well ... there *are* AOP languages. Does anybody use them?

 

[Bezan Kapadia]

Exception Handling , though it gets wacky at times...

 

[Robert Klemme]

I'm creating a new language
Why?

which borrows heavily from Ruby, and I'm curious
what features of Ruby its users enjoy the most.

I've put up a poll here:

http://www.twiigs.com/poll/Technology/Computers/25588

It's multiple choice, but if possible, try to limit yourself to the top 10
features of Ruby you consider important, rather than checking every single
box.

I got 9. Phew!

Kind regards

robert

 

[David A. Black]

Hi --

I'm creating a new language which borrows heavily from Ruby, and I'm curious
what features of Ruby its users enjoy the most.

I've put up a poll here:

http://www.twiigs.com/poll/Technology/Computers/25588

It's multiple choice, but if possible, try to limit yourself to the top 10
features of Ruby you consider important, rather than checking every single
box.

And of course, feel free to respond on the list, particularly with any
features you think I've omitted which are worthy of attention.

Some of the choices involve coupling things that I wouldn't
necessarily put together, like the standard library and its use of
blocks (I'm not sure what you mean by the latter; things like
File.open {} ?) 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) or optional parens and English-like readability
(I'm ambivalent about both, but for different reasons, and it depends
a bit which optional parens you mean).

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

String interpolation
Zero being true
Single inheritance

Anyway, I had no trouble finding ten and then some!


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)

http://www.wishsight.com => Independent, social wishlist management!

 

[Robert Dober]

Very nice, thank you for showing the polling results.
I see that the single most loved feature is lambdas with 88%.
I like that but do we use them to that extent?
Maybe something to reflect upon, right? - or is this high-jacking
this thread, yup feels so. I will open a new one.
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 --

Very nice, thank you for showing the polling results.
I see that the single most loved feature is lambdas with 88%.
I like that but do we use them to that extent?

There's no usage extent implied. Does your diet consist mainly of your
favorite food?


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)

http://www.wishsight.com => Independent, social wishlist management!

 

[Phlip]

Exception Handling , though it gets wacky at times...

The great thing about blocks is you can hide the wackiness:

def foo
x = 42
yield_me do
return x + 1
end
end

def yield_me
prepare()
yield()
explode()
ensure
cleanup()
end

That is the "execute around pattern" - prepare() and cleanup() will always call
around blocks passed to yield_me. Even if the block raises an exception.

Question - does the return throw away the explode() call? I have not yet
bothered to determine this while coding, though I may even have used the effect
in others' blocks, already!

 

[Robert Dober]

Hi --



There's no usage extent implied. Does your diet consist mainly of your
favorite food?

Good point, David, but in "my favor" . My diet consists mostly of my
favorite food... (pasta, caff=E8, cioccolati )
Surely you will eat as much of your favorite food as a balanced diet
allows (and probably just a little more).
Do we do this with lambdas? I do not think so..., do you?
R.


--=20
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]

Language features aren't gratifying in the same way that food is,
though.

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

Robert

 

[Horea Raducan]

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

I can tell you what feature/style recommendation I hate the most. Using "_"
instead of camel notation makes the language too verbose. If you want to
give some meaningful names to a method or variable, if you use more than two
underscores, it looks loooooooong. Ruby is so elegant in so many ways, why
do we have to subject ourselves to the ugliness of "_" ? You might say that
nobody is forcing me, but being the purist that I am I want a total
immersion in the language. And it looks like the leaders recommend using
this notation. Is everybody happy with the ugly_like_hell_notation ?

 

[Jesús Gabriel y Galán]

I can tell you what feature/style recommendation I hate the most. Using "_"
instead of camel notation makes the language too verbose. If you want to
give some meaningful names to a method or variable, if you use more than two
underscores, it looks loooooooong. Ruby is so elegant in so many ways, why
do we have to subject ourselves to the ugliness of "_" ? You might say that
nobody is forcing me, but being the purist that I am I want a total
immersion in the language. And it looks like the leaders recommend using
this notation. Is everybody happy with the ugly_like_hell_notation ?

I think this is a matter of opinion and getting used to things,
there's no right or wrong here.
I am quite happy with that notation. For my eyes it's easier to parse
the words because they are physically separated. For me it's
beautiful_like_heaven_notation, as opposed to uglyLikeHellNotation

Jesus.

 

[M. Edward (Ed) Borasky]

I think this is a matter of opinion and getting used to things,
there's no right or wrong here.
I am quite happy with that notation. For my eyes it's easier to parse
the words because they are physically separated. For me it's
beautiful_like_heaven_notation, as opposed to uglyLikeHellNotation

Jesus.

+1 ... I much prefer the Ruby / Rails convention. But you really need
to use whatever convention / programming style is in use on the
*project*. If it's a project that uses words_separated_by_underscores,
do that. If the first letter of a variableName is lower case, do that.
If underscore.is.not.a.letter.like.earlier.versions.of.R.but.dot.is.a.lette=
r
then do that, etc.


--=20
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.

 

[Horea Raducan]

In my opinion a well managed project will use whatever style convention is
predominant in the language of choice. So I am stuck with the ugly
convention. Maybe it is just me, looks like no other people complain. But i=
t
is like a thorn in my eye and I think it reduces the expressiveness of the
language, it almost forces us to use short/non-expressive names for methods
and variables.

 

[Brian Candler]

I'm creating a new language which borrows heavily from Ruby, and I'm
curious
what features of Ruby its users enjoy the most.

Are you interested in borrowing from other languages too? In that case:

- maybe you should poll (say) Erlang users about what their favourite
features are of that language

- maybe poll Ruby users about what their favourite features from *other*
languages are, that they would have liked to have seen in Ruby

- maybe poll Ruby users if there are any things they dislike about Ruby
in its current form

 

[Robert Klemme]

In my opinion a well managed project will use whatever style convention is
predominant in the language of choice. So I am stuck with the ugly
convention. Maybe it is just me, looks like no other people complain. But it
is like a thorn in my eye and I think it reduces the expressiveness of the
language, it almost forces us to use short/non-expressive names for methods
and variables.

That's interesting, I see it the other way round: because we have
underscores as clear separators between parts of an identifier we can
use short names (e.g. #to_s as compared to Java's toString(), #to_a etc.).

Having said that I do not really care much and follow the rule you
posted: just blend with whatever convention is present in the language
of choice. Readability - especially for others - is more important than
feelings about ugliness. In a project with at least two developers you
can be pretty sure that whatever convention you choose it will hurt at
least one of them in the eye.

Kind regards

robert

 

[Tony Arcieri]

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

Are you interested in borrowing from other languages too?

Yes!


In that case:

- maybe you should poll (say) Erlang users about what their favourite
features are of that language

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.

But yes, this is excellent advice, and as I'm trying to borrow the best
features of Python as well I intend to post a similar thread on python-list

- maybe poll Ruby users about what their favourite features from *other*
languages are, that they would have liked to have seen in Ruby

- maybe poll Ruby users if there are any things they dislike about Ruby
in its current form

Both excellent advice

 

[Tony Arcieri]

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

Some of the choices involve coupling things that I wouldn't
necessarily put together, like the standard library and its use of
blocks (I'm not sure what you mean by the latter; things like
File.open {} ?)

Sorry about that. That one was a particularly bad case of trying to jam
together poll options so there weren't so many to pick from.

But yes, you're correct: in regard to usage of blocks by the standard
library I'm talking about things like File.open {}, or for that matter
String#gsub(x) {} or Enumerable#zip {}

I feel the Ruby standard library does a great job of making use of blocks
and feel that's one of the reasons blocks are so popular in general.

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.

or optional parens and English-like readability
(I'm ambivalent about both, but for different reasons, and it depends
a bit which optional parens you mean).

This is another case of overlap... the "English-like readability" bit
typically plays into DSLs which use English words and generally try to make
your code read more like a natural language (e.g. RSpec)

I certainly understand that people can like optional parens for other
reasons but DSLs are one particularly compelling use case for them, I
believe.

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}"

I hadn't heard the phrase "string interpolation" before but that's what it
covers, correct? If so, glad to know the proper term. That's a
particularly nasty one to implement but one I'd like to try my hand at soon

Zero being true

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

Single inheritance

Given how pervasive single inheritance is (and the fact I already implement
it) I wasn't particularly concerned about this, so much as using mixins in
lieu of multiple inheritance. I thought about putting it on the poll, but
decided to just list mixins instead.

 

[David A. Black]

Hi --

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

This is another case of overlap... the "English-like readability" bit
typically plays into DSLs which use English words and generally try to make
your code read more like a natural language (e.g. RSpec)

I certainly understand that people can like optional parens for other
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.

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.

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


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