I don’t like the Ruby 1.9 hash syntax

http://logicalfriday.com/2011/06/20/i-dont-like-the-ruby-1-9-hash-syntax/

by mshafrir • 15 years ago

46 28 15 years ago

tzs• 15 years ago

OnSwipe warning.

ScotterC• 15 years ago

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.

jcromartie2• 15 years ago

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.

yock• 15 years ago

Not everything is about simplification or minimization. Much like serifs on fonts, syntax aids readability and therefore understanding. Not needing to study the wider context to determine if some collection declaration is a list or hash is invaluable to my time.

chc5• 15 years ago

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• 15 years ago

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

jcromartie2• 15 years ago

I don't know about Ruby 1.9, but in 1.8, you can't do (for example):

    { :foo => rand 40 }

It requires parens. So Ruby seems to enforce some limit where it's too ambiguous.

chc5• 15 years ago

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• 15 years ago

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.

tptacek2• 15 years ago

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.

twelvechairs• 15 years ago

Ruby may be a TIMTOWTDI language, but on the other hand, without calling a method, proc, etc. to do so, every type of basic object usually has a single way to create it (Procs excluded - I really dont like the way ruby handles these - but thats just me and I still like Ruby).

Symbols always start with a ':'. Creating a symbol from 'foo:' is quite foreign to me (as a 1.8.x user) - ':foo :' [replacing hash rocket with a colon] or similar I would have no complaints about.

ericwaller2• 15 years ago

I agree that the lack of ':' preceding a symbol is the most awkward part. Especially since it only works in object literals. It means that the expression

{ :test => 1 } == { test: 1 }

is true, but the expression

{ :test => 1 } == { test : 1 }

results in a syntax error. In other words

test:

is almost like a preprocessor directive for

:test =>

which is a strange expansion to have by default in a language.

tvon• 15 years ago

> The hashrocket itself looks bizarre and excessively noisy to people coming from JavaScript or Python or pretty much anything but PHP.

Just my experience, but I have about a decade of professional Python experience and all of 8 months of professional Ruby experience, and while the rocket syntax drives me nuts in PHP, I actually prefer it in Ruby to the 1.9 syntax.

> I'm just saying, "only one way to do it" is the Python philosophy

Well, there is a lot of effort put into not duplicating functionality in libraries and whatnot, but the actual mantra is:

> There should be one-- and preferably only one --obvious way to do it.

That just means if you need to accomplish a basic task, there should be one obvious solution, it doesn't mean there can't be more than one way to do it.

That's how I've always read it, anyway.

jgavris• 15 years ago

long live the

  { :hash => :rocket }

!

damncabbage• 15 years ago

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".)

zapadapa• 15 years ago

ruby is retarded.

AmazingBytecode• 15 years ago

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.

cheald• 15 years ago

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.

nagnatron• 15 years ago

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

Argorak• 15 years ago

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

euroclydon2• 15 years ago

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.

jhrobert• 15 years ago

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/...

Matz’s response : http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...

I don’t like the Ruby 1.9 hash syntax

Related Stories