9 ms·
R.I.P. Ruby Hash Rocket Syntax 1993-2010
- kondro 16y agoNow if only more gems were 1.9 compatible.
- ionfish 16y agoIt'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 16y agoI've been using 1.9 for a year now but I haven't come across any incompatible gems yet!
- jamesbritt 16y agohttp://isitruby19.com/ http://isitruby19.com/
- ericb 16y agoAm 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 16y agoRuby 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.
- deleted 16y ago[deleted]
- JonnieCache 16y agoOuch. Thanks for pointing that one out. PS. Ruby 1.9 does have a native OrderedHash, the same as the one from ActiveSupport.
- nicholaides 16y agoActually, insertion order preservation is a 1.9 feature: > Hashes enumerate their values in the order that the corresponding keys were inserted. from http://www.ruby-doc.org/core/classes/Hash.html http://www.ruby-doc.org/core/classes/Hash.html
- rue 16y agoThe docs were wrong for a long time, but looking back at the issue, there was a quiet turnaround in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/21856 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/.... So, hashes can be considered ordered in 1.9. It's a mistake to corrupt the data structure, in my opinion, but apparently that boat has now sailed. Thanks for the prod to recheck and sorry about the outdated info.
- ionfish 16y agoThat's right. It is nice for DSLs though! http://beastaugh.github.com/stylish/ruby19.html http://beastaugh.github.com/stylish/ruby19.html
- laymil 16y agoCorrect. 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}
- cubicle67 16y agoMy 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
- aaronbrethorst 16y agoCombining Haml with jQuery Mobile makes it pretty much mandatory: #main_page{:"data-role" => 'page'}
- nex3 16y agoHaml keys can be plain strings. #main_page{"data-role" => 'page'} `data-` attributes are also special-cased: #main_page{data: {role: 'page'}}
- 16y ago
- jiaaro 16y agoalso 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_baker 16y agoYou 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.
- cma 16y agoIt will also make your code drastically slower.
- baddox 16y agoSlower than what alternative?
- SoftwareMaven 16y agoSlower 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.
- baddox 16y agoYou'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.
- akavlie 16y agoCool. Now why doesn't PHP join the crowd and do this with arrays already?
- code_duck 16y agoI 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 {}.
- akavlie 16y agoYep, 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.
- postfuturist 16y agoarray() isn't a function, it's just PHP array literal syntax. $x = array("a" => 100); // legal $y = my_func("a" => 100); // illegal
- akavlie 16y agoYou'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.
- prodigal_erik 16y agoYeah, 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).
- sjs 16y ago$vars remind me of programming mIRC.
- thmzlt 16y agoAm I the only one who thinks adding more syntax is a bad thing?
- njonsson 16y agoNo, you aren't.
- cubicle67 16y agoprobably not, but there's some cases where I think it's a good thing. This is one of those cases.
- mapgrep 16y agoIt'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.
- cubicle67 16y agooh 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 16y ago:) Matz eventually implemented my 2002 proposal. See http://virteal.com/RubyLanguage http://virteal.com/RubyLanguage
- xentronium 16y agoI think they won't be removing hashrocket anywhere before 2.0, so you may use whatever you like better.
- telemachos 16y agoI 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 16y agoWhich 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 16y agoIn related news, Hashrocket (the consultancy) is alive and well, with no intentions of changing our name to Hashcolon. http://hashrocket.com/ http://hashrocket.com/ In fact, like almost everyone else in our space we're looking to hire => http://hashrocket.com/jobs http://hashrocket.com/jobs
- thmzlt 16y agoI was actually surprised that the Hashrocket/Ruby 1.9 syntax joke didn't come up.
- astrodust 16y agoRebranding to "Colon" just isn't as sexy.
- chunkbot 16y ago:sex Sex symbol, or colon sex?
- dasil003 16y agoIt's not reddit, but I upvoted you anyway.
- ordinathorreur 16y agoReference: http://www.bash.org/?925050 http://www.bash.org/?925050
- smokinn 16y agoI imagine what you're looking for most is people for reliability and/or scaling? The jobs link is down.
- bitwize 16y agoMaybe you should change it to Fatcomma? That's what it's called in Perl, where the syntax is still used.
- jlangenauer 16y agoI 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 http://github.com/jasonl/eden - which made me deal with the dusty, hidden corners of the Ruby grammar.)
- scott_s 16y agoHow does this make the language harder to parse?
- lelele 16y agoOnly ruby will be able to parse Ruby ;-) Ruby is just showing its Perl roots.
- wazoox 16y agoGiven that the hashrocket came from Perl to Ruby primarily, and that it changed to look more like Python, I'd say you're wrong :)
- lelele 16y agoWell, 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 http://www.ruby-forum.com/topic/152544
- ballsacky 16y agolol aka javascript circa 1920
- Andys 16y agoOn the contrary, I wish javascript had more Rubyisms. Don't you get sick of typing function(){..} when just {..} would do?
- ballsacky 16y agosyntax is rad, ask any pure mathematician.
- aneth 16y agoInteresting 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 16y agoWho 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 16y agoIt'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
- regularfry 16y agoYou 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.
- korny 16y agoWhen your key is a phrase, for instance? A hash of { phrase => count } is a pretty common data structure.
- 16y ago
- alanh 16y agoIn 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 16y agoI 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 16y agoThough Ruby 1.9 itself doesn't agree ;-) [03:17:49 ~]$ irb ruby-1.9.2-p0 :001 > { a: 10 } => {:a=>10}
- rbxbx 16y agoThis 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 16y agoI'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_ 16y agoWhen 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 16y agoNow if only you could change list.sorting = {:name => 'ASC'} to list.sorting = {:name: 'ASC'}
- darshan 16y agoI'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'}
- jrockway 16y agoI 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', }
- kleiba 16y agoIt'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.
- jrockway 16y agoFor 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.