R.I.P. Ruby Hash Rocket Syntax 1993-2010 | Hacker News Reader

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

blog.peepcode.com

159 pointsthere92 comments

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

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

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

    :sex

Sex symbol, or colon sex?

It's not reddit, but I upvoted you anyway.

Reference: http://www.bash.org/?925050

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

The jobs link is down.

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

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

How does this make the language harder to parse?

Only ruby will be able to parse Ruby ;-)

Ruby is just showing its Perl roots.

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

Well, the pun was not about the => operator, but about Ruby becoming "less parseable". As they say: "Only perl can parse Perl" ;-)

So => is the "hashrocket" operator? I can't find any reference to this name besides this: http://www.ruby-forum.com/topic/152544

I suppose. It goes well with the spaceship operator <=>.

Now we need to find a meaning for |=| so it can be the Tie Fighter operator.

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

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.

It will also make your code drastically slower.

Slower than what alternative?

Slower than my_dict = { "foo": 1, "baz": 2 }

I was unaware that there was a difference in performance, but a quick timing check shows that it takes about twice as long to create a dictionary with 7 items using dict() than using {}.

It makes sense when I stop to think about what the code would have to do, though.

You're right; I'm seeing dict() with explicit kwargs taking 3 times as long as a literal. My unscientific and non-rigorous benchmarks tell me that the construction and unpacking of the kwargs in the dict() call are the cause of most of the slowdown.

With the time it takes to assign with a literal normalized to 1, I'm seeing dict(kwargs) (with kwargs created before the benchmark) take 2 and dict(key_1=val_1, key_2=val_2, etc.) take 3.

Unpacking kwargs is pretty much equivalent to building a dict. The major slowdown is 1) looking up dict and 2) calling a function:

    >>> def dict1():
    ...     {"a" : 1, "b" : 2}
    ... 
    >>> from dis import dis
    >>> dis(dict1)
      2           0 BUILD_MAP                2
                  3 LOAD_CONST               1 (1)
                  6 LOAD_CONST               2 ('a')
                  9 STORE_MAP           
                 10 LOAD_CONST               3 (2)
                 13 LOAD_CONST               4 ('b')
                 16 STORE_MAP           
                 17 POP_TOP             
                 18 LOAD_CONST               0 (None)
                 21 RETURN_VALUE        
    >>> def dict2():
    ...     dict(a=1, b=2)
    ... 
    >>> dis(dict2)
      2           0 LOAD_GLOBAL              0 (dict)
                  3 LOAD_CONST               1 ('a')
                  6 LOAD_CONST               2 (1)
                  9 LOAD_CONST               3 ('b')
                 12 LOAD_CONST               4 (2)
                 15 CALL_FUNCTION          512
                 18 POP_TOP             
                 19 LOAD_CONST               0 (None)
                 22 RETURN_VALUE

Given that, I'd assume that the overhead doesn't grow as the dict grows.

As python runtimes/JITs get better and better, the literal version could get relatively faster, since static assertions can potentially more easily be made about it; whereas the global 'dict' could be replaced with anything, requiring much more sophistication.

Say you use a dict in a non-mutating manner, it is made up of string literals only, and you construct it within a loop; it could be able to be pulled out as an invariant, the same could be true of the function-call case, but potentially not as easily.

In optimizing a dynamic language, the problem of a symbol being replaced like this is no big deal; it's all but the expected norm, and inline caching ought to take care of it.

On invariant code motion: it tends not to be a big win because programmers usually move obvious big code out of loops explicitly. They do that because relying on a compiler optimization to do it is unpredictable; you may accidentally trigger a wall in your optimizer's ability to analyze your code as it grows more complex over time.

But we really are arguing over small potatoes here.

Slower yes, but not drastically:

    % python -m timeit '{"key": "value", "dr_nic": "The Comedian", "ttl": 42}'
    1000000 loops, best of 3: 0.296 usec per loop

    % python -m timeit 'dict(key="value", dr_nic="The Comedian", ttl=42)'
    1000000 loops, best of 3: 0.771 usec per loop

There are far better ways to make code faster than worrying about the extra fraction of a microsecond you're spending calling dict rather than using the literal syntax.

Yeah.

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

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

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

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?

It would be something like this:

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

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

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.

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

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

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}

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

Combining Haml with jQuery Mobile makes it pretty much mandatory:

    #main_page{:"data-role" => 'page'}

Haml keys can be plain strings.

    #main_page{"data-role" => 'page'}

`data-` attributes are also special-cased:

    #main_page{data: {role: 'page'}}

I did not know that. Thanks for the heads up, and thanks for Haml and Sass!

You can also use "HTML-style attributes" [1]

    #main_page(data-role='page')

[1] http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#ht...

> That said, for almost all use cases hashes use symbols as keys

I'd say there are more vanilla symbol hash uses by number, but the most interesting and powerful things you can do with hashes don't involve symbols for keys, imho.

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.

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.

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

No, you aren't.

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

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.

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

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

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?

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.

Though Ruby 1.9 itself doesn't agree ;-)

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

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',
    }

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.

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.

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

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

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 {}.

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.

array() isn't a function, it's just PHP array literal syntax.

    $x = array("a" => 100); // legal
    $y = my_func("a" => 100); // illegal

You're right, I was a bit hasty and didn't consider that. It sure does look like a function though, where other languages typically use {} or something similar.

Yeah, call_user_func('strlen', 'hello world') works but call_user_func('array', 'hello world') does not. But for ugly syntax, it's hard to beat the $ sigil being required everywhere for no reason at all (unlike Perl where it actually did something).

$vars remind me of programming mIRC.

It's technically a 'language construct', but it sure does seem like a function. Same with PHP's 'list'. It's not good syntax, in my opinion also. It doesn't even seem like syntax!

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

To what end?

More elegant and easier to type syntax.

"This is your father's language sabre. A simpler syntax from a more elegant age."

[NSArray arrayWithObject:notToMentionObjectiveC];

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)

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

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

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

Now if only you could change

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

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'}

Now if only more gems were 1.9 compatible.

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.

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

http://isitruby19.com/

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.

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.

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

You can do it, but is it a good idea? What it implies to me is that at some point in your program, you're constructing symbols from arbitrary strings which aren't known ahead of time. This sounds like a recipe for disaster given that symbols aren't garbage collected.

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

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

syntax is rad, ask any pure mathematician.

lol aka javascript circa 1920

On the contrary, I wish javascript had more Rubyisms.

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

It sounds like you'd love CoffeeScript

I would love it if it the browser could run it natively. But if we're replacing browser language, can I just have plain Ruby?

Reply on news.ycombinator.com