Forum: Ruby What are your favorite Ruby features?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2f55791ab9018b4d01fb741fab21843d?d=identicon&s=25 Tony Arcieri (Guest)
on 2009-02-16 05:29
(Received via mailing list)
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.
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-16 05:55
(Received via mailing list)
Tony Arcieri wrote:

> 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?;)
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-16 06:10
(Received via mailing list)
Phlip wrote:

> 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? :)



--
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.
9d5ecfdd21d16e79e14aa1800ae095d9?d=identicon&s=25 Bezan Kapadia (bezan)
on 2009-02-16 07:24
Exception Handling , though it gets wacky at times...
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-16 09:35
(Received via mailing list)
2009/2/16 Tony Arcieri <tony@medioh.com>:
> 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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-16 11:26
(Received via mailing list)
Hi --

On Mon, 16 Feb 2009, Tony Arcieri wrote:

>
> 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!
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-16 12:09
(Received via mailing list)
On Mon, Feb 16, 2009 at 5:26 AM, Tony Arcieri <tony@medioh.com> wrote:
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-16 12:36
(Received via mailing list)
Hi --

On Mon, 16 Feb 2009, Robert Dober wrote:

> On Mon, Feb 16, 2009 at 5:26 AM, Tony Arcieri <tony@medioh.com> wrote:
> 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!
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-16 13:12
(Received via mailing list)
Bezan Kapadia wrote:

> 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!
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-16 13:36
(Received via mailing list)
On Mon, Feb 16, 2009 at 12:36 PM, David A. Black <dblack@rubypal.com>
wrote:
> favorite food? :-)
Good point, David, but in "my favor" ;). My diet consists mostly of my
favorite food... (pasta, caffè, 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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-16 14:13
(Received via mailing list)
On Mon, 16 Feb 2009, Robert Dober wrote:

>> 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è, 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?

Language features aren't gratifying in the same way that food is,
though. There's another agenda: writing a program as well as possible.
If that agenda isn't served by lambdas, then there are no lambdas,
even if I think lambdas are really cool.

I love many Ruby features but they don't have the same kind of pull
as, say, Sugar Pops :-)


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!
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-16 16:54
(Received via mailing list)
On Mon, Feb 16, 2009 at 2:13 PM, David A. Black <dblack@rubypal.com>
wrote:

>
> 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
2d7caf0e6a41bd012c77e5e2035a3a2f?d=identicon&s=25 Horea Raducan (Guest)
on 2009-02-16 17:22
(Received via mailing list)
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 ?
E088bb5c80fd3c4fd02c2020cdacbaf0?d=identicon&s=25 Jesús Gabriel y Galán (Guest)
on 2009-02-16 17:32
(Received via mailing list)
On Mon, Feb 16, 2009 at 5:21 PM, Horea Raducan <hraducan@gmail.com>
wrote:
> 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.
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-02-16 18:07
(Received via mailing list)
On Mon, Feb 16, 2009 at 8:29 AM, Jesús Gabriel y Galán
<jgabrielygalan@gmail.com> wrote:
> 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.letter
then do that, etc.

:)
--
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.
2d7caf0e6a41bd012c77e5e2035a3a2f?d=identicon&s=25 Horea Raducan (Guest)
on 2009-02-16 18:49
(Received via mailing list)
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.

On Mon, Feb 16, 2009 at 12:01 PM, M. Edward (Ed) Borasky
753dcb78b3a3651127665da4bed3c782?d=identicon&s=25 Brian Candler (candlerb)
on 2009-02-16 21:31
Tony Arcieri wrote:
> 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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-16 22:51
(Received via mailing list)
On 16.02.2009 18:48, Horea Raducan wrote:
> 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
2f55791ab9018b4d01fb741fab21843d?d=identicon&s=25 Tony Arcieri (Guest)
on 2009-02-17 01:46
(Received via mailing list)
On Mon, Feb 16, 2009 at 1:31 PM, Brian Candler <b.candler@pobox.com>
wrote:

> 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
2f55791ab9018b4d01fb741fab21843d?d=identicon&s=25 Tony Arcieri (Guest)
on 2009-02-17 03:21
(Received via mailing list)
On Mon, Feb 16, 2009 at 3:25 AM, David A. Black <dblack@rubypal.com>
wrote:

> 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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-17 04:01
(Received via mailing list)
Hi --

On Tue, 17 Feb 2009, Tony Arcieri wrote:

> On Mon, Feb 16, 2009 at 3:25 AM, David A. Black <dblack@rubypal.com> 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 :-)

> 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 :-)


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
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-17 07:17
(Received via mailing list)
Tony Arcieri 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.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-17 14:20
(Received via mailing list)
On Mon, Feb 16, 2009 at 9:59 PM, David A. Black <dblack@rubypal.com>
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
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-17 15:44
(Received via mailing list)
On 17 févr. 09, at 01:16, David Masover 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.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-17 18:00
(Received via mailing list)
On Tue, Feb 17, 2009 at 9:44 AM, Juan Zanos
<juan_zanos@talkhouse.com>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
D1f1c20467562fc1d8c8aa0d328def62?d=identicon&s=25 Florian Gilcher (skade)
on 2009-02-17 18:32
(Received via mailing list)
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 Gilcher

smtp:   flo@andersground.net
jabber: Skade@jabber.ccc.de
gpg:    533148E2
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-17 19:13
(Received via mailing list)
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.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-17 20:41
(Received via mailing list)
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.
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2009-02-17 21:32
(Received via mailing list)
David Masover 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 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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-17 22:46
(Received via mailing list)
Hi --

On Tue, 17 Feb 2009, Robert Dober 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 (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-18 00:22
(Received via mailing list)
On Tue, Feb 17, 2009 at 10:45 PM, David A. Black <dblack@rubypal.com>
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-18 02:39
(Received via mailing list)
Hi --

On Wed, 18 Feb 2009, Robert Dober 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 (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09
D1f1c20467562fc1d8c8aa0d328def62?d=identicon&s=25 Florian Gilcher (skade)
on 2009-02-18 09:48
(Received via mailing list)
On Feb 17, 2009, at 9:30 PM, James Britt wrote:

> 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:   flo@andersground.net
jabber: Skade@jabber.ccc.de
gpg:    533148E2
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-18 12:58
(Received via mailing list)
On Wed, Feb 18, 2009 at 2:38 AM, David A. Black <dblack@rubypal.com>
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 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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-18 13:08
(Received via mailing list)
On Wed, Feb 18, 2009 at 9:48 AM, Florian Gilcher <flo@andersground.net>
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
D1f1c20467562fc1d8c8aa0d328def62?d=identicon&s=25 Florian Gilcher (skade)
on 2009-02-18 13:48
(Received via mailing list)
On Feb 18, 2009, at 1:04 PM, Robert Dober 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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-18 14:09
(Received via mailing list)
On Wed, Feb 18, 2009 at 1:47 PM, Florian Gilcher <flo@andersground.net>
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 ;)
Actually I believe that my relative dislike for parens comes from
Smalltalk....
Robert
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-18 14:19
(Received via mailing list)
Hi --

On Wed, 18 Feb 2009, Florian Gilcher 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 :-)


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
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-18 14:31
(Received via mailing list)
2009/2/18 Robert Dober <robert.dober@gmail.com>:
>> 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
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-18 14:39
(Received via mailing list)
On Tue, Feb 17, 2009 at 2:40 PM, David Masover <ninja@slaphack.com>
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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-18 15:08
(Received via mailing list)
On Wed, Feb 18, 2009 at 2:38 PM, Rick DeNatale <rick.denatale@gmail.com>
wrote:
> On Tue, Feb 17, 2009 at 2:40 PM, David Masover <ninja@slaphack.com> wrote:
>

> 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
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-18 15:48
(Received via mailing list)
On 18 févr. 09, at 09:07, Robert Dober wrote:

> def foo( bar )
>
>
> --
> 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)
>

Good point.  Syntax isn't all there is to readability.   But it does
have some effect.

In this case the parenthesis don't make anything inherently more
readable and aren't helpful in resolving the nonsense names.  The
parenthesis are only meaningful if you already know what they mean.
Readability arguments are often tainted by experience with previous
languages.   And it must be remembered that no programmer is born
knowing a previous programming language.  If we insist, implicitly or
otherwise, that readability means that something looks like 'C' or
Java or any other language then we place limits on how much we can
simplify syntax.  I'd actually say that each example with parenthesis
requires a lot more explanation of why they are their, what they
mean, what are the syntax rules that govern them, etc.

Cheers,
Juan
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-18 16:01
(Received via mailing list)
2009/2/18 Juan Zanos <juan_zanos@talkhouse.com>:

> limits on how much we can simplify syntax.  I'd actually say that each
> example with parenthesis requires a lot more explanation of why they are
> their, what they mean, what are the syntax rules that govern them, etc.
>

Parentheses are traditionally used to group things together. If you
have things that are logically linked together but do not visually
appear so then adding parentheses which are not required might help
you to make the code more readable.

This has nothing to do with other programming languages, you should
have learned that in elementary school during your math classes.

Thanks

Michal
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-18 16:05
(Received via mailing list)
Hi --

On Wed, 18 Feb 2009, Juan Zanos wrote:

>> That is very hard to read indeed, but why?
>>
> some effect.
> mean, what are the syntax rules that govern them, etc.
I agree (except for your last sentence). I honestly don't give C or
Java (or Lisp, etc.) a moment's thought in any of this, when I'm
writing Ruby. Just Ruby.

One thing I've had to come to terms with, reluctantly (because it
would be so nice if it were otherwise), is that there is literally no
such thing as inherent readability. Readability simply does not inhere
in the notation, any more than it does in a given alphabet.

I'm not sure why these discussions, when they're about Ruby, always
seem to be 99% about other languages. Ruby has one of the most
distinct visual styles ever. I guess the issues arise because you
*can* make it look like C:

   printf("%s\n", string);

or Lisp (sort of), or whatever. I've always thought of that stuff as
marginal -- kind of a party trick, more than a real exploration of
Ruby's own style.

The reason I don't agree with your last sentence is that I don't think
it's possible to explain or defend most of these things. For example,
the convention of:

   attr_accessor :x

without parentheses can't really be explained or rationalized. It's
just the convention.

In the end, it's a bit fuzzy. There's a clustering around certain
conventions (like the attr_accessor one), but there are outlying
practices, slopes to the bell curve, whatever. I do wish people would
not write:

   def a b, c=1

but if they do, I can't really expect an explanation. It's just what
they like.


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
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-18 16:09
(Received via mailing list)
On 18 févr. 09, at 10:00, Michal Suchanek wrote:

>> only meaningful if you already know what they mean.  Readability
>> example with parenthesis requires a lot more explanation of why
> This has nothing to do with other programming languages, you should
> have learned that in elementary school during your math classes.
>
> Thanks
>
> Michal
>


Michal,

Did you look at the message to which I was replying?   Were
parentheses being used to group things together?  No.  They were
not.   They were being used to distinguish a single argument from a
function name.   In what elementary school should I have learned that
use of parentheses?

Cheers,
Juan
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-18 16:28
(Received via mailing list)
On 18 févr. 09, at 10:04, David A. Black wrote:

>>
>>> the same kind of thing.
>> does have some effect.
>> example with parenthesis requires a lot more explanation of why
> in the notation, any more than it does in a given alphabet.
Ok.  We don't have to agree completely.  We both seem to agree that
there are arbitrary aspects to syntax conventions that do not
inherently affect readability.   Perhaps where we disagree is that I
do believe something can be inherently more or less readable and you
do not.    I believe that overly complicated syntax becomes less
readable and even more unwritable.   So I tend to prefer a simpler
syntax even if it's slightly different from a particular convention.

Cheers,
Juan
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-18 16:29
(Received via mailing list)
2009/2/18 Juan Zanos <juan_zanos@talkhouse.com>:
>>> only meaningful if you already know what they mean.  Readability
>> Parentheses are traditionally used to group things together. If you
>>
>
>
> Michal,
>
> Did you look at the message to which I was replying?   Were parentheses
> being used to group things together?  No.  They were not.   They were being
> used to distinguish a single argument from a function name.   In what
> elementary school should I have learned that use of parentheses?
>

I have taken your "each example with parenthesis" as referring to the
parenthesis discussion on this thread in general, not the particular
examples with defining methods.

For that the 'def' keyword should be distinctive enough.

Thanks

Michal
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-18 16:38
(Received via mailing list)
On Wed, Feb 18, 2009 at 4:08 PM, Juan Zanos <juan_zanos@talkhouse.com>
wrote:
> Michal,
>
> Did you look at the message to which I was replying?   Were parentheses
> being used to group things together?  No.  They were not.   They were being
> used to distinguish a single argument from a function name.   In what
> elementary school should I have learned that use of parentheses?
I agree with you here, Juan.
We are of course not talking about parentheses which are *needed* and
IIRC we learned in math classes to leave away all parentheses which
were *not needed*.
Robert
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2009-02-18 18:30
(Received via mailing list)
Florian Gilcher wrote:
> not because they are C//Java-Guys.
It's simply an observation based on reasons people have given me when  I
try to understand what value the parens offer.  It ends up being, "I'm
used to them", or, "It looks weird without them", or, "I find it more
readable."

Basically, their absence makes some people uneasy; they feel better with
them there, though they do not provide any information or programmatic
value.

I'm sure there are people who did not come to Ruby after using Java or C
and still think the parens make the code easier to work with.  I just
haven't met them. :)



>
Except you can't do this:

def foo  (my, tuple, arg); end



> Also, i tend to brace long and unbalanced statements:
>
> ===
> var_foo_bar = (::Something::Somewhere::Object.new(
>                             :foo => "bar"
>                                                  )
>               )


There *are* times when the parens may make the arg list more readable,
but it ends up being a matter of taste, and that comes from exposure.

The more people add the redundant parens, the more they see it as
"right", and the more they do it.

I prefer to omit whatever I can until I have a good reason not to.
Maybe that good reason ends up being, "I'm making more stupid errors",
and that's fine, but so far I've had fewer such errors without the
parens than with them.

I don't expect anyone is going to change their minds on this based on
words alone, but it's interesting to see how preferences evolve.

For example, in learning Haskell, I've come across a number of places
that explain that while one can use parens in various places, the
preferred style is to leave them out when possible.  Different culture.

--
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
D1f1c20467562fc1d8c8aa0d328def62?d=identicon&s=25 Florian Gilcher (skade)
on 2009-02-18 19:40
(Received via mailing list)
On Feb 18, 2009, at 6:30 PM, James Britt wrote:

> or C and still think the parens make the code easier to work with.
> I just haven't met them. :)

Meet: me. No Java//C-Exposure beyond the absolute must in university
courses (and I learned Ruby before them). And as I said before, it's
highly depending on the context.

>
> def foo  (my, tuple, arg); end

Sure, it is not a perfect image. It's just the direction.

>
>
> There *are* times when the parens may make the arg list more
> readable, but it ends up being a matter of taste, and that comes
> from exposure.

I'm a fan of consistency. Even in relativly strict defined languages
like Java and C I always shriek when seeing people using several
styles just as they see fit. Obviously, making them mandantory (and
them omittable in some very special cases...) doesn't fix the problem
as well.

As you said: there are moments where parens help ("def a b,c = {}"
being a good example). So, I prefer to stick to them in all parameter
lists to eliminate this question. Especially because I have a tendency
for creative use of parameter lists (that make Java guys shriek).

Rest assured, I am writing:

===
div.address "bla", :class => bar do
  #something different
end
===

when using Builder//Markaby (for example), because parens would
clutter the declaration.

The thing is that I try not to mix the styles. As I said, I clearly
prefer:

===
foo(bar(batz))
# over
foo bar(batz) # looks unbalanced
===

To extend this:

===
some_method bar(batz)
some_other_method bar # oh
===

Suddently, the braces really hurt. While in a balanced display
(granted, it's hard to conjure up nice examples):

===
some_method(bar(batz))
some_other_method(bar)
===

So, I prefer to just stick to the braces.

> The more people add the redundant parens, the more they see it as
> "right", and the more they do it.

That sounds like they are utterly wrong.

> I prefer to omit whatever I can until I have a good reason not to.
> Maybe that good reason ends up being, "I'm making more stupid
> errors", and that's fine, but so far I've had fewer such errors
> without the parens than with them.

I don't to parens errors as well... so? I think the difference is
neglectible.

> I don't expect anyone is going to change their minds on this based
> on words alone, but it's interesting to see how preferences evolve.
>
> For example, in learning Haskell, I've come across a number of
> places that explain that while one can use parens in various places,
> the preferred style is to leave them out when possible.  Different
> culture.

Not only a different culture but also different facilities. Haskell is
far better in grasping things like "foo bar batz a" (oh, didn't write
Haskell for at least 2 years... is that valid?).

At the end of the day, it is the projects maintainers call how the
code should be written.
Maybe it might be worthwhile to document those styles at a certain
place for maintainers to refer to "their" style.

And, thats why I tuned in: attributing brace styles other then Your
Enlightened One to other persons inability to find The True Way. There
is a language called Python for that ;).

Regards,
Florian Gilcher

--
Florian Gilcher

smtp:   flo@andersground.net
jabber: Skade@jabber.ccc.de
gpg:    533148E2
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2009-02-18 20:38
(Received via mailing list)
Florian Gilcher wrote:

> And, thats why I tuned in: attributing brace styles other then Your
> Enlightened One to other persons inability to find The True Way. There
> is a language called Python for that ;).

I think you're putting words in my mouth.

I have my own preference, and have so far found arguments to the
contrary unsatisfying because they are usually based on previous use of
parens in other languages.    (The most interesting suggestion I've
heard is to use the parens to indicate if the return value of the method
is useful or not.  That is, whether a  method is intended as a statement
or an expression.)

I'm truly puzzled when people get their back up at the suggestion that
their style preference is based on bias obtained from previous exposure
to other language, conscious or not.  I don't think too many people are
deliberately thinking, "I want to make this look like
[C|Java|Perl|PHP]", but surely there is *some* bias based on experience.

Whether or not that makes anyone enlightened is yet another matter of
opinion and not all that interesting a topic.  I'm certainly not
claiming it for myself.

The debate is not entirely academic.  New features and syntax are being
added to Ruby on 1.9, and there are similar debates about the
readability of many things.  It's worth understanding why people have
such issues, and whether or not the difficulties can be overcome by
extended exposure, or whether there are intrinsic reason why something
is hard for people to visually parse.

Ruby is quite similar to other languages, and people bring assorted
expectations, and to what degree those expectations should be matched or
encouraged in Ruby as it evolves is a reasonable question.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-18 20:54
(Received via mailing list)
Hi --

On Thu, 19 Feb 2009, Juan Zanos wrote:

>>> On 18 févr. 09, at 09:07, Robert Dober wrote:
>>>> the same kind of thing.
>>>
>>
> arbitrary aspects to syntax conventions that do not inherently affect
> readability.   Perhaps where we disagree is that I do believe something can
> be inherently more or less readable and you do not.    I believe that overly
> complicated syntax becomes less readable and even more unwritable.   So I
> tend to prefer a simpler syntax even if it's slightly different from a
> particular convention.

That just offloads the subjective judgment onto the concept of
"overly" :-)

I guess it comes down to this. If someone says they find

   def m a, b, c=1

clearer or more readable than

   def m(a,b,c=1)

I have no idea what they're talking about -- but I have to assume they
really do find it more readable, and that whatever is going on in
their brain when they look at the first version is similar to what
goes on in my brain when I look at the second.


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
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-18 21:01
(Received via mailing list)
Florian Gilcher wrote:
> 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.

However, tuples in Ruby can also be assigned without parens:

some_array = 1, 2, 3

I find that it's purely a matter of style. I like to drop whatever
syntax I can, and infer the rest from the environment. However, I also
like the fact that they are _optional_ -- it means we don't actually
have to agree, unless we're working on the same codebase. We can both
use the same language, and you can use parens, and I can drop them.

That was my point -- I like the syntax to be flexible like that.

> Also, i tend to brace long and unbalanced statements:
>
> ===
> var_foo_bar = (::Something::Somewhere::Object.new(
>                             :foo => "bar"
>                                                  )
>               )
> ===

In that case, I would tend to write it either like this:

var_foo_bar = Something::Somewhere::Object.new :foo => 'bar'

Or, if that was really getting cumbersome, and I had to wrap it, I'd
probably do something like this:

var_foo_bar = Something::Somewhere::Object.new(
  :foo => 'bar',
  :frobinate => true,
  :frobs => [1, 2, 3]
)

Again, a matter of style. In particular, I would be just as frustrated
with a language that did not allow superfluous parentheses as one that
required them.

We should never forget that the purpose of the language is to encode our
thoughts in a machine-readable and human-readable form. If some rule of
syntax gets in the way of that, the language is failing in its purpose.
If it's possible for humans to write unreadable code (Perl's "line
noise" problem), that is poor style on the part of the coder, not a
fault of the language.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-18 21:04
(Received via mailing list)
Michal Suchanek wrote:
> Parentheses are traditionally used to group things together. If you
> have things that are logically linked together but do not visually
> appear so then adding parentheses which are not required might help
> you to make the code more readable.

That is a good rule of thumb.

However, my editor has decent syntax highlighting, so in many cases,
things are grouped together by color. When they are not, or when it is
actually ambiguous, I use parentheses.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-18 21:09
(Received via mailing list)
Hi --

On Thu, 19 Feb 2009, James Britt wrote:

>> Thats a harsh statement for those that do actually like parantheses and not
> still think the parens make the code easier to work with.  I just haven't met
> them. :)

I did learn C before Ruby, but post hoc ergo propter hoc is still a
logical fallacy :-)

I write what I think is clearest, which as we know means that some
people will also find it clearest and others won't. I don't have any
emotions or convictions one way or another about the characters '('
and ')' themselves.

I understand why you think it's sort of mushy and non-rigorous to use
discretionary parentheses, and it probably is, but I can't seem to
convince myself to stop being guided by criteria of (what I judge to
be) clarity. I'm just an old softy :-)


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
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-18 22:43
(Received via mailing list)
On Wed, Feb 18, 2009 at 8:52 PM, David A. Black <dblack@rubypal.com>
wrote:

> I have no idea what they're talking about -- but I have to assume they
> really do find it more readable, and that whatever is going on in
> their brain when they look at the first version is similar to what
> goes on in my brain when I look at the second.
That seems quite likely to me and I even daresay that if you were
exposed to the first style for a given time T your brain would adapt.
And probably T is not even very long.
And vice versa of course.
Robert
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-18 22:45
(Received via mailing list)
Hi --

On Thu, 19 Feb 2009, Robert Dober wrote:

> On Wed, Feb 18, 2009 at 8:52 PM, David A. Black <dblack@rubypal.com> wrote:
>
>> I have no idea what they're talking about -- but I have to assume they
>> really do find it more readable, and that whatever is going on in
>> their brain when they look at the first version is similar to what
>> goes on in my brain when I look at the second.
> That seems quite likely to me and I even daresay that if you were
> exposed to the first style for a given time T your brain would adapt.
> And probably T is not even very long.
> And vice versa of course.

Just to be clear: I do understand the notation that I don't
particularly like. I just don't particularly like it :-)


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
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-19 00:15
(Received via mailing list)
On 18 févr. 09, at 16:42, Robert Dober wrote:

> And probably T is not even very long.
> And vice versa of course.
> 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)
>

Relative to time spent learning a language I'd say the T might as
well be zero.  Mostly the arguments for using parentheses when they
aren't necessary seem to be arguments of taste.  There's no disputing
taste, but simplicity is a powerful argument.   If someone can give
me a convincing argument for why the way I do something is less
simple than the way they do something I'm very likely to change.  I
find myself swayed by the argument that unnecessary use of
parentheses is more complicated.   It's more ink.   It's more
syntax.   It's more overloading of the meaning of the parentheses
character.

When it comes to pure taste I try to be ambivalent.   If everyone in
the world decided it would be cool to switch parentheses around so
the ends pointed outside I don't think I could raise a legitimate
argument against it.  At least I can't think of a convincing argument
off the top of my head and it would be mildly amusing.

Cheers,
Juan
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2009-02-19 00:48
(Received via mailing list)
From: "James Britt" <james.britt@gmail.com>
> to other language, conscious or not.  I don't think too many people are
> deliberately thinking, "I want to make this look like
> [C|Java|Perl|PHP]", but surely there is *some* bias based on experience.

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.

Note, also, that my first language was Forth, which I programmed
in for seven years--initially as a hobbyist, then professionally--
before I learned C.

Forth doesn't need parens for anything... ( they're comment delims. )

However, I'm not sure my Forth experience played a role in my
temporary dalliance with extreme paren minimalism in C.  At the
time, I felt memorizing the operator precedence table and making
use of that knowledge by minimizing use of parens was sort of a
natural course to take for someone intent on mastering the
language.

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.

Example from earlier post:

2009/2/18 Robert Dober <robert.dober@gmail.com>:
> I find the second irritating because those parens are sooo
> superfluous.

If I could have participated in this thread eighteen years ago I
would almost certainly have been in the superfluous==suboptimal
camp.

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 realize this is necessarily very subjective.  But my point is
just that the strictly minimal syntax required to satisfy the
parser is no longer an important criterion to me when I'm
writing code I want to be easy for me(*) to read.

*(((and apparently my poor co-workers)))        <grin>


Regards,

Bill
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-19 15:58
(Received via mailing list)
On 18 févr. 09, at 18:43, Bill Kelly 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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-19 16:23
(Received via mailing list)
Hi --

On Thu, 19 Feb 2009, Juan Zanos wrote:

>>> That is, whether a  method is intended as a statement or an expression.)
>> those strictly necessary to the parser.
>> use of that knowledge by minimizing use of parens was sort of a
>> my brain does frequently prefer more parens than are strictly
>> 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 don't think there's any confusion, just (rather trivially, in the
overall scheme of things) different practices.


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
01cd7a5d8751789819701518f3fe6ffa?d=identicon&s=25 Juan Zanos (Guest)
on 2009-02-19 16:45
(Received via mailing list)
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, http://www.entp.com/training/
> 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
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2009-02-19 17:35
(Received via mailing list)
From: "Juan Zanos" <juan_zanos@talkhouse.com>
>



> 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();
  }
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-02-19 17:38
(Received via mailing list)
On Wed, Feb 18, 2009 at 6:43 PM, Bill Kelly <billk@cts.com> 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
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2009-02-19 18:01
(Received via mailing list)
[Sorry, hit some control key and sent my previous message before
completing it.]


From: "Juan Zanos" <juan_zanos@talkhouse.com>
>
> 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-l...

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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-19 21:53
(Received via mailing list)
Hi --

On Fri, 20 Feb 2009, Juan Zanos 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 :-)


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
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2009-02-20 10:35
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.
Ba91caa4b1fd66471e4180151b379dd7?d=identicon&s=25 Jörg W Mittag (Guest)
on 2009-02-26 00:51
(Received via mailing list)
Tony Arcieri wrote:
> On Mon, Feb 16, 2009 at 1:31 PM, Brian Candler <b.candler@pobox.com> 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
2f55791ab9018b4d01fb741fab21843d?d=identicon&s=25 Tony Arcieri (Guest)
on 2009-03-05 04:33
(Received via mailing list)
I just blogged about the results of my
poll<http://unlimitednovelty.com/2009/03/what-do-rubyis....
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%)
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-03-05 04:50
(Received via mailing list)
Tony Arcieri wrote:

> I just blogged about the results of my
> poll<http://unlimitednovelty.com/2009/03/what-do-rubyis....

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.

>    5. 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!
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-03-05 11:36
(Received via mailing list)
On 05.03.2009 04:31, Tony Arcieri wrote:
>    7. Metaprogramming (49%)
>    8. Syntactic sugar e.g. val ||= x; array <<>
>    9. Optional parens / English-like readability (44%)
>    10. Object#method_missing (42%)

Tony, thanks for posting the outcome of your poll!

Kind regards

  robert
This topic is locked and can not be replied to.