What are your favorite Ruby features?

On 18 févr. 09, at 18:43, Bill K. wrote:

that their style preference is based on bias obtained from

natural course to take for someone intent on mastering the
necessary to the parser.
One of the things that confuses this discussion is that some people
are talking about the use of parentheses with regard to operator
precedence rules and others are discussing far more arbitrary and
questionable usages such as in declaring and calling functions. I
think it’s telling that such a seemingly minor complexity is cause
for confusion.

I doubt you’ll get much disagreement that operator precedence rules
for c (or Ruby) are complex enough that there are cases where the use
of parentheses simplifies reading. That doesn’t seem to be
something anyone is questioning.

Cheers,
Juan

On 19 févr. 09, at 10:21, David A. Black wrote:

don’t think too many people are deliberately thinking, "I want
Forth doesn’t need parens for anything… ( they’re comment
Thankfully I got past that phase eventually.

Ruby Training Atlanta! April 1-3, training - entp
atlanta09

I haven’t heard any different practices with regard to parenthesis
and operator precedence in this discussion. Am I wrong about this?
And with regard to operator precedence it doesn’t sound like there
are any unique issues with Ruby. Well, other than the fact that you
can create new operators with Ruby and you can’t in most languages.
But nobody has mentioned that feature.

Cheers,
Juan

From: “Juan Z.” [email protected]

One of the things that confuses this discussion is that some people
are talking about the use of parentheses with regard to operator
precedence rules and others are discussing far more arbitrary and
questionable usages such as in declaring and calling functions. I
think it’s telling that such a seemingly minor complexity is cause
for confusion.

Again:

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

Nowadays, my brain finds the latter declaration with the parens,
more restful to the eye than the former.

It’s easier for me to see the structure at-a-glance in the
latter…

I find these reasons sufficient and non-arbitrary.

I doubt you’ll get much disagreement that operator precedence rules
for c (or Ruby) are complex enough that there are cases where the use
of parentheses simplifies reading. That doesn’t seem to be
something anyone is questioning.

But we do get disagreement among programmers as to the degree
to which parens ought to be used to clarify operator precedence.

The same kind of disagreement happens in C with regard to
whether and when to use braces when the body of a conditional
is a single statement.

if (foo)
bar();
else
baz();

if (foo) {
bar();
}
else {
baz();
}

if (xyzzy)
if (foo)
bar();
else
baz();

if (xyzzy) {
if (foo)
bar();
else
baz();
}

On Wed, Feb 18, 2009 at 6:43 PM, Bill K. [email protected] wrote:

I agree there is some bias based on experience, as I went through
a phase about 18 years ago as a C programmer, deliberately
memorizing the operator precedence table and taking small delight
in being able to write expressions devoid of any parens except
those strictly necessary to the parser.

Eventually one of my co-workers told me he had trouble reading
my code. Initially my (private) reaction was, this guy isn’t
serious about his craft! He really ought to learn the language.

Thankfully I got past that phase eventually.

My current bias based on experience is that when reading code,
my brain does frequently prefer more parens than are strictly
necessary to the parser.

Somehow this reminds me of the old story of a waiter motioned over to
one of
his tables, the customer said:

“Would you taste this soup?”

Waiter, “I’m sorry sir, if there’s something wrong with your soup, I’d
be
happy to have the chef fix it or bring you something else, but the
health
inspector is rumored to be paying a surprise visit, and we’ve been
warned
not to do anything which might cause a problem.”

Customer, “No, I insist, please taste my soup!”

The waiter looked around to see if anyone was looking, turned back to
the
customer, and said,

“Okay, where’s your spoon?”

To which the customer replied

“AHA!”


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

[Sorry, hit some control key and sent my previous message before
completing it.]

From: “Juan Z.” [email protected]

One of the things that confuses this discussion is that some people
are talking about the use of parentheses with regard to operator
precedence rules and others are discussing far more arbitrary and
questionable usages such as in declaring and calling functions. I
think it’s telling that such a seemingly minor complexity is cause
for confusion.

Again:

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

“Nowadays, my brain finds the latter declaration with the parens,
more restful to the eye than the former.”

“It’s easier for me to see the structure at-a-glance in the
latter…”

I find these reasons sufficient and non-arbitrary.

I doubt you’ll get much disagreement that operator precedence rules
for c (or Ruby) are complex enough that there are cases where the use
of parentheses simplifies reading. That doesn’t seem to be
something anyone is questioning.

But we do get disagreement among programmers as to the degree
to which parens ought to be used to clarify operator precedence.

The same kind of disagreement happens in C with regard to
whether and when to use braces when the body of a conditional
is a single statement.

if (foo)
bar();
else
baz();

if (foo) {
bar();
}
else {
baz();
}

if (xyzzy)
if (foo)
bar();
else
baz();

if (xyzzy) {
if (foo)
bar();
else
baz();
}

if (xyzzy) {
if (foo) {
bar();
}
else {
baz();
}
}

Some programmers argue for one extreme or the other, while others
take some middle ground.

And some change their minds over the years, maybe multiple times.

shrug

Here’s some more ruby:

http://codefluency.com/articles/2008/08/17/arrow-lambdas-a-ruby-1-9-vignette/

The following is a completely legal single lambda being immediately
invoked

→ a = 1, b = 2, c, &d ; e { e = d.(a * b * c); e + 1 }.(3) { |p| p * 4
}

…and with parens:

→ (a = 1, b = 2, c, &d ; e) { e = d.(a * b * c); e + 1 }.(3) { |p| p *
4 }

They’re both funky, but the latter is clearer to me.

Anyway, really I don’t think it matters whether it’s function
declarations, operator precedence, or (in the case of the C
example) where to add braces…

Seems we just have individual programmers, with their own sense
of style, each (hopefully) trying to make their code as readable
as possible.

De gustibus, and all that…

Regards,

Bill

Hi –

On Fri, 20 Feb 2009, Juan Z. wrote:

operators with Ruby and you can’t in most languages. But nobody has
mentioned that feature.

I probably misunderstood you. Anyway, I’m pretty parenthesesed out :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

Even after 5 years of ruby, I cannot stand ruby code where
def foo bla
omits parens at definition-time.

I have no real problem if method calls omit parens, but my eyes HATE it
if the () is omitted - my brain needs extra time to decide where it
starts and ends, especially if more arguments are used.

Tony A. wrote:

On Mon, Feb 16, 2009 at 1:31 PM, Brian C. [email protected] wrote:

Are you interested in borrowing from other languages too?
Yes!

You asked for it …

From Newspeak (http://NewspeakLanguage.Org/):

  • extremist message sending paradigm (no variables, no constants, no
    class dictionary, no instance fields … just message sends)
  • if everything is a message send, (nested) classes automatically
    also become namespaces, modules, mixins, packages, libraries and
    frameworks – no need for a seperate module system or things like
    selector namespaces!
  • object-capability based security
  • mirror-based reflection (goes great together with
    object-capabilities: mirrors are capabilities for reflection)
  • object literals
  • aliens (extremely cool object-oriented FFI)
  • Brazil (extremely cool GUI widget bindings)
  • Hopscotch (there’s actually two seperate things, both called
    Hopscotch: a framework for GUI applications and an IDE built with
    that framework)
  • structured comments
  • optional type annotations for implementing optional pluggable type
    systems

From Ioke (http://Ioke.Org/):

  • even more extremist message sending: even literals are actually
    messages!
  • Common Lisp style condition system instead of exceptions
  • flexible handling of operators (however, see also Fortress)
  • macros (however, see also the next entry)

From Converge (http://ConverPL.Org/)

  • powerful compile-time metaprogramming in a language with complex
    syntax

From Fortress (https://ProjectFortress.Sun.Com/):

  • even more extremist operator flexibility
  • the idea that this is 2009 and we no longer have teletypes but
    instead pixel screens and Unicode and that programming language
    syntax should reflect that (e.g. Ruby’s syntax was essentially
    designed in 1957)

From Cobra (http://Cobra-Language.Com/):

  • both static (with inference) and dynamic typing
  • language-integrated documentation (like Python docstrings)
  • language-integrated unit tests
  • language-integrated contracts (pre- and postconditions, invariants)

From Clojure (http://Clojure.Org/):

  • arbitrary object metadata
  • sane equality semantics due to deep immutability
  • support for multiple orthogonal concurrency models that complement
    each other (Agents similar to Erlang Actors, Software
    Transactional Memory à la Haskell but better and variables with
    thread semantics)
  • extremely powerful polymorphism due to user-provided dispatch
    functions, even more powerful than Common Lisp multimethods

From Scala (http://Scala-Lang.Org/), Perl 6
(http://Perl.Org/perl6/) and OMeta (http://TinLizzie.Org/ometa/):

  • insanely powerful pattern matching, yet respecting OO encapsulation

whow That’s quite a list! I expect a first prototype of Reia
sometime around 2030 (-:

jwm

Tony A. wrote:

I just blogged about the results of my
pollhttp://unlimitednovelty.com/2009/03/what-do-rubyists-like-about-ruby.html.

Tx for the work; this survey is relevant for all of language design. By
“like”
we simply mean “find very profitable” here.

Here they are for the curious:

  1. Blocks (71%)

Certain other languages don’t know what they are missing there.

  1. Duck-typing (53%)

And maybe some folks don’t realize how important “emergent behavior” is.
You can
write designs in a dynamic language that you simply cannot translate to
a static
language. The emergent behavior is too subtle!

I just blogged about the results of my
pollhttp://unlimitednovelty.com/2009/03/what-do-rubyists-like-about-ruby.html.
Here they are for the curious:

  1. Blocks (71%)
  2. Lambdas / Procs (57%)
  3. Mix-ins / Modules (55%)
  4. Open classes / monkeypatching (53%)
  5. Duck-typing (53%)
  6. First-class regexps (49%)
  7. Metaprogramming (49%)
  8. Syntactic sugar e.g. val ||= x; array <<>
  9. Optional parens / English-like readability (44%)
  10. Object#method_missing (42%)

On 05.03.2009 04:31, Tony A. wrote:

  1. Metaprogramming (49%)
  2. Syntactic sugar e.g. val ||= x; array <<>
  3. Optional parens / English-like readability (44%)
  4. Object#method_missing (42%)

Tony, thanks for posting the outcome of your poll!

Kind regards

robert