Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.peepcode.com

Post reply on HN
Print view View original

81–90 of 95 posts

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

#81

Post by kleiba »

jrockway wrote: post #78

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', } to { 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.

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

#82

Post by sigzero »

telemachos wrote: post #18
xentronium wrote: post #16

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

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

#83

Post by wazoox »

lelele wrote: post #72
jlangenauer wrote: post #25

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

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

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

#84

Post by phaylon »

pyre wrote: post #19
jiaaro wrote: post #5

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

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

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

#85

Post by bitwize »

obiefernandez wrote: post #24

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

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

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

#86

Post by jrockway »

kleiba wrote: post #81
jrockway wrote: post #78

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', } to { 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 inclu…

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.

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

#87

Post by barrkel »

cma wrote: post #60
j_baker wrote: post #52

Earlier quoted context omitted.

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=…

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…

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.

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

#88

Post by jherdman »

aneth wrote: post #41

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…

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

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

#89

Post by lelele »

wazoox wrote: post #83
lelele wrote: post #72

Earlier quoted context omitted.

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

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

#90

Post by wazoox »

lelele wrote: post #89
wazoox wrote: post #83

Earlier quoted context omitted.

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 .
Post reply on HN