What are your favorite Ruby features?

[Bill Kelly]

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

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:

"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

 

[Marc Heiler]

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.

 

[Jörg W Mittag]

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