Live data from Hacker News

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

blog.peepcode.com

51–60 of 95 posts

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

#51
post #28

Earlier quoted context omitted.

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.

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!

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

#52
post #49

Earlier quoted context omitted.

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

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.

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

#53

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?

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

#54
post #28

Earlier quoted context omitted.

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.

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

#55
post #28

Earlier quoted context omitted.

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

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

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

#56

Earlier quoted context omitted.

array() isn't a function, it's just PHP array literal syntax. $x = array("a" => 100); // legal $y = my_func("a" => 100); // illegal

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.

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

#57
post #43

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.

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

#58

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

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

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

#60
post #52
post #49

Earlier quoted context omitted.

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

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 invariant, the same could be true of the function-call case, but potentially not as easily.

Post reply on HN