
I don’t like the Ruby 1.9 hash syntax - mshafrir
http://logicalfriday.com/2011/06/20/i-dont-like-the-ruby-1-9-hash-syntax/
======
chc
This is such a superficial argument — even more superficial than the feature
it's criticizing. It's only _possibly_ misleading if you aren't familiar with
the syntax, and that's true of a whole boatload of things, such as block
syntax. The hashrocket itself looks bizarre and excessively noisy to people
coming from JavaScript or Python or pretty much anything but PHP.

This really is just, "I am not used to this syntax, so it looks weird to me."
It's the same argument some people make against calling methods without
parentheses in Ruby. If you're the sort of person who writes
"self.houses().map(){|house| house.sale_price()}.sort()", then I guess at
least you're being consistent. If not, don't be that guy.

More philosophically, Ruby is a TIMTOWTDI language. There are five different
and largely interchangeable ways to create a Proc, half the core library
methods are aliases for other methods, several keywords are just slight
variations on each other for no purpose other than to give you options, you
can take or leave parentheses, etc. The new hash syntax is just one more
example of this ethos. If this embarrassment of ways to write any given
program bothers you (and you're certainly in good company if it does), you'd
probably be more at home with Python. (I don't mean to tell anyone their
business, I'm just saying, "only one way to do it" is the Python philosophy.)

~~~
TylerE
The function without () thing annoys the crap out of me.

I much prefer Python's way of doing things, () is the no-argument call, and
without parens is the actual callable object. It emphasizes that functions
really _are_ first class values that can be passed around, instead of having
to use some special-case syntax to get at the callable.

~~~
tptacek
I felt the same way, until I wrote my first program that used DSL-style. The
parens-optional syntax thing is immensely useful in DSLs; it has saved me from
writing tens of parsers.

I'll add the ()'s to intra-class method calls, though; the ambiguity between
variable references and funcall expressions bothers the hell out of me, too.

Optional parens are a net win.

~~~
euroclydon
I've suspected Ruby's optional parentheses helped with some parsing or code
generation activities, but after your comment I still can't find enough
specific examples or general theory. Is there a stated design objective for
this in Ruby or can you point me to a good article on optional parents and
DSLs?

By the way, I'm pouring over the source for Nancy, a Sinatra inspired micro
framework in C# and I see where extension methods and implicit conversion
operators are helpful in a DSL.

~~~
chc
It's part of the language's overriding design philosophy of pervasive OO. As
much of the language as possible is implemented in terms of objects and
methods, including seemingly syntactic things like "private", "attr_accessor",
the top-level scope and all member access to other objects. It's all objects
and methods under the hood, but you shouldn't have to think about it in those
terms. You're not supposed to be concerned with how the accessor for an
object's name is implemented — you're just supposed to feel like you're
accessing it.

Other languages have been moving in this direction, too. Objective-C has dot
notation, C# lets you define getters and setters, Python has the @property
decorator, Scala has special "magic" methods and quirky syntax rules to make
this work, etc. All of these serve the same purpose as Ruby's optional
parentheses: To make simple method calls less inherently "heavy".

~~~
tptacek
His specific question has a more prosaic answer, I think; optional parens make
DSLs easier by making Ruby's syntax more flexible, thus allowing it to stand
in for more languages.

For instance, a few years ago, a summer internship project was to build a
native debugger for OS X in pure Ruby, and to help with that, I wrote a chunk
of X86 assembly as a Ruby DSL:

<http://news.ycombinator.com/item?id=284238>

~~~
chc
I don't think so, at least not so directly. IIRC, this idea of "DSLs" in Ruby
didn't gain currency until relatively late in the language's history, a little
while after Rails made it explode and Why wrote his Poignant Guide featuring
Dwemthy's Array. But Ruby had basically the same syntax _long_ before that.

I think the real answer is what I said: It makes Ruby's syntax lighter and
more flexible so the pony could get more mileage out of its one trick (pure
OO), and the convenience of writing DSLs just falls out of that.

BTW, that DSL is an awesome hack.

------
jcromartie
Clojure made me realize that both of these styles are silly. Why do you need
hashrockets, colons, or even _commas_? Why do you need a key/value separator
AND a pair separator?

They might be useful as separators sometimes, but why are the absolutely
required? They seem like noise. Anyway... I'll stick with hashrockets because
the colon at the end is just confusing.

~~~
chc
Clojure's Lisp roots make its minimalistic hashes possible. There is a
possible reason for separators in a language that doesn't have special syntax
for function application (e.g. function calls can be written as "foo bar"
rather than "(foo bar)" or "foo(bar)"), but Ruby doesn't take advantage of it.
Take this map:

    
    
      { 
        foo: capitalize bar,
        baz: sanitize quux
      }
    

Without the punctuation, it would be very ambiguous:

    
    
      { foo capitalize bar baz sanitize quux }

~~~
rayiner
I cringe at the thought of whitespace as an infix operator...

~~~
chc
That's not really the right way to look at it. Function application is just
the default interpretation of two juxtaposed symbols. It's not any worse than
"new MyObject()", which has whitespace acting just as much like an infix
operator. There's no inherent reason why you'd need a special operator to
apply "capitalize" but not "-" or "new" or "def". That's just how C does it,
and by an accident of history most mainstream languages just parrot C by
default.

------
ScotterC
My issue with the new syntax is bringing other people up to speed. Two
syntaxes for the same functionality can be confusing _especially_ when it's
similar to another language such as javascript. I, a rubyist for a whole year
and a half now (sarcasm), thought it had something to do with only JSON at
first glance. I myself will be sticking to the hash rocket.

------
Argorak
A bit of history: this syntax originally appeared in MacRuby and is used for
the named parameters needed to call ObjectiveC methods:

    
    
        person.setFirstName(first, lastName: last)
    

So, introducing it into Ruby 1.9 gave MacRuby the ability of hooking into
valid ruby syntax to do its special thing.

As a wild speculation, it may also be used for named parameters, should they
ever be introduced in Ruby.

Personally, i like it for exactly that case. I do not like it as a generic
hash syntax for another reason: its easy to align the =>, but its hard to
align the:.

------
cheald
I don't think I like it either, but I'm pretty sure it's just because colons
are already very commonly used in hashes as symbol delimiters.

{foo: :bar} just feels _weird_.

It's not a world-ending issue - certainly not enough to make an effective
difference in practical usage - but it's enough of a visual collision that it
rubs me the wrong way.

------
damncabbage
My only misgivings about the new syntax is that these sorts of lists now look
rather dumb:

    
    
      foo: :bar,
      baz: :quux,
      wub: :bozo
    

(This is, admittedly, a very subjective complaint. We could start calling this
new double-colon syntax collision "Paamayim Nekudotayim".)

------
euroclydon
As someone with no Ruby experience, I was reading through the lasted RoR
config files recently, and I encountering these key/vals separated sometimes
by a comma, other times by a colon, sometimes by nothing with the colon on the
wrong side. I had to research new Ruby syntax for an hour to figure it out.

If you are unfamiliar with Ruby symbols to begin with then it's tough on the
brain because there is no discernible pattern.

------
jgavris
long live the

    
    
      { :hash => :rocket }
    
    !

------
jhrobert
name: value instead of :name => value makes as much sense as p->q instead of
(*p).x in C

As an historical note, here are the message (and matz’s response) where I made
a proposal for the new syntax, back in 2002. It includes rationals.

[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-
talk/...](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/38391)

Matz’s response : [http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-
talk/...](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/38402)

------
nagnatron
Just don't use it. I won't.

------
tzs
OnSwipe warning.

------
zapadapa
ruby is retarded.

~~~
AmazingBytecode
Is that the best unsubstantiated diss you can come up with? Here are four
better sounding and equally valid ones.

node.js killed my dog. CoffeeScript gives you diarrhea. a time-traveling Scala
user killed JFK. using Erlang is an unforgivable sin.

