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.