R.I.P. Ruby Hash Rocket Syntax 1993-2010

http://blog.peepcode.com/tutorials/2011/rip-ruby-hash-rocket-syntax

by there • 16 years ago

159 89 16 years ago

blog.peepcode.com

kondro• 16 years ago

Now if only more gems were 1.9 compatible.

ionfish2• 16 years ago

It's more problematic for those that include Ruby extensions in C, but fixing a library to make it 1.9-compatible is not generally that onerous a task (the major exception to this is string encoding, which is fine in simple cases but a complete nightmare in anything complex). If enough people just write patches for a couple of gems they use, everything would be 1.9-compatible soon enough. rvm lets you install all the different Ruby versions you'll need for testing easily enough.

catch23• 16 years ago

I've been using 1.9 for a year now but I haven't come across any incompatible gems yet!

jamesbritt• 16 years ago

http://isitruby19.com/

ericb2• 16 years ago

Am I reading this right that it only applies if your hash key is a symbol? So really, the hash rocket isn't dead?

jim_h• 16 years ago

Ruby 1.9 still uses hash rocket. I'm using RoR3 on 1.9.2 and I haven't changed any of my hashes.

I guess if you want to save some key strokes and you use symbols as keys you can use the new syntax.

The other cool/different thing about Hash in 1.9 is that it preserves order.

ionfish2• 16 years ago

That's right. It is nice for DSLs though!

http://beastaugh.github.com/stylish/ruby19.html

laymil• 16 years ago

Correct. It is wonderful sugar, but somewhat limiting. Realistically, you need to know both syntaxes.

  irb(main):001:0> hash={:"symbol with space" => nil}
  => {:"symbol with space"=>nil}
  irb(main):002:0> hash={"symbol with space": nil}
  SyntaxError: (irb):2: syntax error, unexpected ':',  expecting tASSOC
  hash={"symbol with space": nil}
                          ^
	from /usr/bin/irb1.9.1:12:in `<main>'
  irb(main):003:0> hash={"symbolwithoutspace": nil}
  SyntaxError: (irb):3: syntax error, unexpected ':',  expecting tASSOC
  hash={"symbolwithoutspace": nil}
                           ^
	from /usr/bin/irb1.9.1:12:in `<main>'
  irb(main):004:0> hash={symbolwithoutspace: nil}
  => {:symbolwithoutspace=>nil}
  irb(main):005:0> hash={symbol with space: nil}
  SyntaxError: (irb):5: syntax error, unexpected tIDENTIFIER, expecting keyword_do or '{' or '('
  hash={symbol with space: nil}

cubicle673• 16 years ago

My own opinion is that although Ruby allows string-like symbols (like :"symbol with space"), I think they should be avoided. There may be a case for them, but I've not encountered one yet.

The new syntax works only with conventional symbols (no quotes), not with any other key type, so no integers, strings, objects etc. For everything else, you can fall back to the original syntax. You can even mix then if you really feel the need (yech!)

That said, for almost all use cases hashes use symbols as keys, and for these cases the new syntax is much cleaner and I'm glad to see it

jiaaro• 16 years ago

also says this syntax is compatible with python which is not really true. if you have this in python:

    {
      key: "value",
      dr_nic: "The Comedian",
      ttl: 42
    }

python will expect there to be a variable called 'key', one called 'dr_nic', and one called 'ttl'. If you intend to do

    d['ttl']

you'll need to create a hash using a literal string

j_baker4• 16 years ago

You don't necessarily have to create a hash using a literal string. You can also do this:

    dict(
        key="value",
        dr_nic="The Comedian",
        ttl=42
        )

...but that is a bit different syntax.

cma2• 16 years ago

It will also make your code drastically slower.

Ingaz• 16 years ago

Yeah.

I always do in such way. And I will continue even if it's a bit slower =)

pyre• 16 years ago

Yea. So they've move away from the Perl-like 'rocket' syntax to a more JavaScript/Python-like syntax. Ruby+Python hackers will rejoice while Perl+Ruby hackers will pout. This isn't necessarily some 'huge' win.

[Though I guess it could be a 'win' for Rails hackers since they are likely to just be Ruby/Rails+JavaScript hackers.]

phaylon• 16 years ago

As a Perl developer I'd say »More power to them.« Also, since Perl's => is basically a comma operator that turns a bareword on its left into a string, I'd say Ruby's move is a step away from Perl regarding syntax, but a step towards Perl regarding functionality.

Anyway, as a non-Ruby developer I can appreciate the move. Also reminds a bit of some Scheme's ability to prefix and postfix symbols with »:«.

jerf• 16 years ago

I am not a Ruby programmer. What's the syntax for using a variable as the key, which is actually synonymous with the Python code?

j_baker4• 16 years ago

It would be something like this:

    >> a = :foobar
    => :foobar
    >> {a => 1}
    => {:foobar=>1}

akavlie4• 16 years ago

Cool. Now why doesn't PHP join the crowd and do this with arrays already?

code_duck2• 16 years ago

I absolutely agree. The PHP array instantiation syntax is atrocious... I really dislike '=>'. While they're at it they might as well replace array() with [] and/or {}.

akavlie4• 16 years ago

Yep, array() is the icing on the cake. Why is the most common data structure in the language instantiated with a function?

I could probably rant on PHP syntax all day long, but it's too off topic here.

tcdent• 16 years ago

Let's throw in support for keyworded arguments while we're at it, too.

dools• 16 years ago

To what end?

akavlie4• 16 years ago

More elegant and easier to type syntax.

lalc• 16 years ago

[NSArray arrayWithObject:notToMentionObjectiveC];

mkramlich2• 16 years ago

shudder

Having written and shipped 5+ iPhone apps written in the verbosphemy* that is ObjectiveC, I'm strongly looking forward to being able to do all future iPhone apps in a saner language like JavaScript or Python. If I do them at all. Ever again. In fact it's pretty much a hard requirement. Just after this current one ships.

(*: verbose + blasphemy)

thmzlt2• 16 years ago

Am I the only one who thinks adding more syntax is a bad thing?

njonsson• 16 years ago

No, you aren't.

cubicle673• 16 years ago

probably not, but there's some cases where I think it's a good thing. This is one of those cases.

mapgrep• 16 years ago

It's fairly terrifying what an accretion of these sorts of options did to Perl, and I say that as someone who does a lot of Perl5 coding and enjoys it.

It would be one thing to just have a new symbol that was a drop-in alternative to what works now. But in this case you have a _sometimes_ alternative, so you need to remember a new rule, if only to be able read other people's code. That cognitive cost outweighs any keystroke benefit IMHO.

cubicle673• 16 years ago

oh really?

Are you a Ruby dev?

If so, is your concern based on the impact this has on you personally, or is it based on concern for some mythical other dev who might have problems with the additional "cognitive cost"?

I've been a developing in Ruby now for about 4 years, I think this (the new syntax) is absolutely the right thing to do

jhrobert• 16 years ago

:) Matz eventually implemented my 2002 proposal. See http://virteal.com/RubyLanguage

xentronium• 16 years ago

I think they won't be removing hashrocket anywhere before 2.0, so you may use whatever you like better.

telemachos• 16 years ago

I think people are misunderstanding the title (which is not meant to be taken literally). They won't be removing the hashrocket ever, since (surely) they don't plan to limit hash keys to symbols only. The syntax only works in limited cases (namely symbols without spaces).

sigzero• 16 years ago

Which makes me wonder...why do it all if it is just for a limited case. Seems to make the code less understandable (to me) and it seems an unnecessary change to the language (to me).

obiefernandez• 16 years ago

In related news, Hashrocket (the consultancy) is alive and well, with no intentions of changing our name to Hashcolon. http://hashrocket.com/

In fact, like almost everyone else in our space we're looking to hire => http://hashrocket.com/jobs

thmzlt2• 16 years ago

I was actually surprised that the Hashrocket/Ruby 1.9 syntax joke didn't come up.

astrodust• 16 years ago

Rebranding to "Colon" just isn't as sexy.

chunkbot• 16 years ago

    :sex

Sex symbol, or colon sex?

smokinn• 16 years ago

I imagine what you're looking for most is people for reliability and/or scaling?

The jobs link is down.

bitwize• 16 years ago

Maybe you should change it to Fatcomma? That's what it's called in Perl, where the syntax is still used.

jlangenauer• 16 years ago

I have to say I cried a little bit when I read this - it seems that Matz et al are trying to make the language unparseable.

(Of course, perhaps I'm more sensitive than most, having actually written an Ruby lexer - http://github.com/jasonl/eden - which made me deal with the dusty, hidden corners of the Ruby grammar.)

scott_s2• 16 years ago

How does this make the language harder to parse?

lelele2• 16 years ago

Only ruby will be able to parse Ruby ;-)

Ruby is just showing its Perl roots.

wazoox2• 16 years ago

Given that the hashrocket came from Perl to Ruby primarily, and that it changed to look more like Python, I'd say you're wrong :)

ballsacky2• 16 years ago

lol aka javascript circa 1920

Andys2• 16 years ago

On the contrary, I wish javascript had more Rubyisms.

Don't you get sick of typing function(){..} when just {..} would do?

mhansen• 16 years ago

It sounds like you'd love CoffeeScript

ballsacky2• 16 years ago

syntax is rad, ask any pure mathematician.

aneth• 16 years ago

Interesting to see this convergence of syntax. Unfortunately, it's not true that you don't have to learn a "new syntax." As often with Ruby libraries, the devil is in the subtleties.

This does not work (although I think it could):

{"foo bar": 'b'}

but this does:

{:"foo bar" => 'b'}

Without being truly JSON compatible, it's only moderately useful.

One annoyance of Ruby for me has always been that many libraries, such as Rails, allow for symbols or strings interchangeably - but only in "most" cases, often leading to head banging in the other cases.

More intrigue: the syntaxes are also mixable

{foo: 'bar', "add-a" => 'dash', :'or a' => 'space in a symbol'}

is valid.

wfarr• 16 years ago

Who would put a space inside the key name for an item in a hash?

I'm confident it's commonly understood best practice (among many languages at that) to use an underscore (_) in lieu of spaces in such things.

I agree that the quirks themselves are odd, but the matter of using a key with a space in it really stood out.

ark• 16 years ago

It's really common, actually. A symbol can actually have spaces in it:

:"Some Text" is a perfectly valid symbol.

ruby-1.9.2-p136 :001 > h = {:"Some Text" => 123} => {:"Some Text"=>123} ruby-1.9.2-p136 :002 > h[ "Some Text".to_sym ] => 123

korny• 16 years ago

When your key is a phrase, for instance? A hash of { phrase => count } is a pretty common data structure.

jherdman• 16 years ago

Agreed. Also, { foo-bar: 'baz' } is not valid either. This is kind of a shame per the JSON argument as well.

alanh• 16 years ago

In case anyone doesn’t get it, the comic (and its lapel button), the yellow words to the left, and the phrase "The Comedian" are a reference to the fantastic graphic novel Watchmen.

lylejohnson• 16 years ago

I couldn't figure out why no one was commenting on this aspect of the post, and all the effort that must have gone into its creation. Maybe folks are just so used to topfunky's blog posts being works of art (see the archives for more examples) that they've come to take it for granted.

petercooper• 16 years ago

Though Ruby 1.9 itself doesn't agree ;-)

  [03:17:49 ~]$ irb
  ruby-1.9.2-p0 :001 > { a: 10 }
  => {:a=>10}

rbxbx• 16 years ago

This is one of the more upvoted Ruby stories I've seen on HN in some time, and it's a little bit disappointing. Sensationalism and inaccuracy are all it takes these days, eh?

mattkern• 16 years ago

I'm hoping that the story is upvoted more for the artistry of the post, The Watchmen reference and the plead to move to 1.9 and less for the argument of hashrocket vs. colon syntax.

But, given the chance HN will always fan the flames of the argument that lies within.

rb2k_• 16 years ago

When I was looking at the page, I noticed that the example:

{

  key: "value",

  dr_nic: "The Comedian",

  ttl: 42

}

didn't seem to use the :symbols I know but omitted the colon.

Turns out, it somehow works:

> a = {my_key: "my_value"}

=> {:my_key=>"my_value"}

Has this always been there? It's kinda weird because that way they look like regular variables O_o

forkrulassail• 16 years ago

Now if only you could change

list.sorting = {:name => 'ASC'} to list.sorting = {:name: 'ASC'}

darshan• 16 years ago

I'm not familiar with the particular 'sorting' thing you're doing, but if the first things works, then the second should work in 1.9 if you use the correct syntax -- you have an extra colon. It should be: list.sorting = {name: 'ASC'}

jrockway2• 16 years ago

I prefer the "hash rocket" (I call it the fat comma), because it looks nicer when you have a hash with keys of varying length. Compare:

    {
        foo: 'bar',
        hello_world: 'OH HAI',
    }

    {
        foo         => 'bar',
        hello_world => 'OH HAI',
    }

If you try to do that with colons, it goes all wonky:

    {
        foo         : 'bar',
        hello_world : 'OH HAI',
    }

kleiba• 16 years ago

It's debatable whether aligning the mapping operator - be it a colon or a hash rocket - is a good idea to begin with. The point has been made in the past that if you edit the map so that the longest key changes, you'd have to realign all other entries too. For code versioning, e.g., in shared development, this creates unnecessarily large diff's. For instances, patches become more difficult to read, because they include lines that haven't actually changed content-wise, just layout-wise.

jrockway2• 16 years ago

For code versioning, e.g., in shared development, this creates unnecessarily large diff's. For instances, patches become more difficult to read, because they include lines that haven't actually changed content-wise, just layout-wise.

Well, no.

Here's an example. File a:

    {
        foo         => 'bar',
        hello_world => 'OH HAI',
    }

File a with a long key added, let's call it b:

    {
        foo              => 'bar',
        hello_world      => 'OH HAI',
        longlonglonglong => 1,
    }

Then we do a diff:

    $ diff -uw a b
    --- a	2011-01-06 08:51:55.725595229 -0600
    +++ b	2011-01-06 08:51:52.285595452 -0600
    @@ -1,4 +1,5 @@
     {
         foo         => 'bar',
         hello_world => 'OH HAI',
    +    longlonglonglong => 1,
     }

So see, that's not a problem.

R.I.P. Ruby Hash Rocket Syntax 1993-2010

Related Stories