7 ms·

I don’t like the Ruby 1.9 hash syntax

46 points by mshafrir 15y ago

tzs 15y ago
OnSwipe warning.
ScotterC 15y ago
My issue with the new syntax is bringing other people up to speed. Two syntaxes for the same functionality can be confusing especially when it's similar to another language such as javascript. I, a rubyist for a whole year and a half now (sarcasm), thought it had something to do with only JSON at first glance. I myself will be sticking to the hash rocket.
jcromartie 15y ago
Clojure made me realize that both of these styles are silly. Why do you need hashrockets, colons, or even commas? Why do you need a key/value separator AND a pair separator? They might be useful as separators sometimes, but why are the absolutely required? They seem like noise. Anyway... I'll stick with hashrockets because the colon at the end is just confusing.
- yock 15y ago
  Not everything is about simplification or minimization. Much like serifs on fonts, syntax aids readability and therefore understanding. Not needing to study the wider context to determine if some collection declaration is a list or hash is invaluable to my time.
- chc 15y ago
  Clojure's Lisp roots make its minimalistic hashes possible. There is a possible reason for separators in a language that doesn't have special syntax for function application (e.g. function calls can be written as "foo bar" rather than "(foo bar)" or "foo(bar)"), but Ruby doesn't take advantage of it. Take this map: { foo: capitalize bar, baz: sanitize quux } Without the punctuation, it would be very ambiguous: { foo capitalize bar baz sanitize quux }
  - rayiner 15y ago
    I cringe at the thought of whitespace as an infix operator...
    - chc 15y ago
      That's not really the right way to look at it. Function application is just the default interpretation of two juxtaposed symbols. It's not any worse than "new MyObject()", which has whitespace acting just as much like an infix operator. There's no inherent reason why you'd need a special operator to apply "capitalize" but not "-" or "new" or "def". That's just how C does it, and by an accident of history most mainstream languages just parrot C by default.
  - jcromartie 15y ago
    I don't know about Ruby 1.9, but in 1.8, you can't do (for example): { :foo => rand 40 } It requires parens. So Ruby seems to enforce some limit where it's too ambiguous.
chc 15y ago
This is such a superficial argument — even more superficial than the feature it's criticizing. It's only possibly misleading if you aren't familiar with the syntax, and that's true of a whole boatload of things, such as block syntax. The hashrocket itself looks bizarre and excessively noisy to people coming from JavaScript or Python or pretty much anything but PHP. This really is just, "I am not used to this syntax, so it looks weird to me." It's the same argument some people make against calling methods without parentheses in Ruby. If you're the sort of person who writes "self.houses().map(){|house| house.sale_price()}.sort()", then I guess at least you're being consistent. If not, don't be that guy. More philosophically, Ruby is a TIMTOWTDI language. There are five different and largely interchangeable ways to create a Proc, half the core library methods are aliases for other methods, several keywords are just slight variations on each other for no purpose other than to give you options, you can take or leave parentheses, etc. The new hash syntax is just one more example of this ethos. If this embarrassment of ways to write any given program bothers you (and you're certainly in good company if it does), you'd probably be more at home with Python. (I don't mean to tell anyone their business, I'm just saying, "only one way to do it" is the Python philosophy.)
- TylerE 15y ago
  The function without () thing annoys the crap out of me. I much prefer Python's way of doing things, () is the no-argument call, and without parens is the actual callable object. It emphasizes that functions really _are_ first class values that can be passed around, instead of having to use some special-case syntax to get at the callable.
  - tptacek 15y ago
    I felt the same way, until I wrote my first program that used DSL-style. The parens-optional syntax thing is immensely useful in DSLs; it has saved me from writing tens of parsers. I'll add the ()'s to intra-class method calls, though; the ambiguity between variable references and funcall expressions bothers the hell out of me, too. Optional parens are a net win.
    - 15y ago
jgavris 15y ago
long live the { :hash => :rocket } !
damncabbage 15y ago
My only misgivings about the new syntax is that these sorts of lists now look rather dumb: foo: :bar, baz: :quux, wub: :bozo (This is, admittedly, a very subjective complaint. We could start calling this new double-colon syntax collision "Paamayim Nekudotayim".)
deleted 15y ago
[deleted]
zapadapa 15y ago
ruby is retarded.
- AmazingBytecode 15y ago
  Is that the best unsubstantiated diss you can come up with? Here are four better sounding and equally valid ones. node.js killed my dog. CoffeeScript gives you diarrhea. a time-traveling Scala user killed JFK. using Erlang is an unforgivable sin.
  - zapadapa 15y ago
    are you feeling insecure?
cheald 15y ago
I don't think I like it either, but I'm pretty sure it's just because colons are already very commonly used in hashes as symbol delimiters. {foo: :bar} just feels weird. It's not a world-ending issue - certainly not enough to make an effective difference in practical usage - but it's enough of a visual collision that it rubs me the wrong way.
nagnatron 15y ago
Just don't use it. I won't.
Argorak 15y ago
A bit of history: this syntax originally appeared in MacRuby and is used for the named parameters needed to call ObjectiveC methods: person.setFirstName(first, lastName: last) So, introducing it into Ruby 1.9 gave MacRuby the ability of hooking into valid ruby syntax to do its special thing. As a wild speculation, it may also be used for named parameters, should they ever be introduced in Ruby. Personally, i like it for exactly that case. I do not like it as a generic hash syntax for another reason: its easy to align the =>, but its hard to align the:.
euroclydon 15y ago
As someone with no Ruby experience, I was reading through the lasted RoR config files recently, and I encountering these key/vals separated sometimes by a comma, other times by a colon, sometimes by nothing with the colon on the wrong side. I had to research new Ruby syntax for an hour to figure it out. If you are unfamiliar with Ruby symbols to begin with then it's tough on the brain because there is no discernible pattern.
jhrobert 15y ago
name: value instead of :name => value makes as much sense as p->q instead of (*p).x in C As an historical note, here are the message (and matz’s response) where I made a proposal for the new syntax, back in 2002. It includes rationals. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/38391 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/... Matz’s response : http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/38402 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...

46 points by mshafrir 15y ago

tzs 15y ago

OnSwipe warning.

My issue with the new syntax is bringing other people up to speed. Two syntaxes for the same functionality can be confusing especially when it's similar to another language such as javascript. I, a rubyist for a whole year and a half now (sarcasm), thought it had something to do with only JSON at first glance. I myself will be sticking to the hash rocket.

jcromartie 15y ago

Clojure made me realize that both of these styles are silly. Why do you need hashrockets, colons, or even commas? Why do you need a key/value separator AND a pair separator? They might be useful as separators sometimes, but why are the absolutely required? They seem like noise. Anyway... I'll stick with hashrockets because the colon at the end is just confusing.

yock 15y ago
Not everything is about simplification or minimization. Much like serifs on fonts, syntax aids readability and therefore understanding. Not needing to study the wider context to determine if some collection declaration is a list or hash is invaluable to my time.
chc 15y ago
Clojure's Lisp roots make its minimalistic hashes possible. There is a possible reason for separators in a language that doesn't have special syntax for function application (e.g. function calls can be written as "foo bar" rather than "(foo bar)" or "foo(bar)"), but Ruby doesn't take advantage of it. Take this map: { foo: capitalize bar, baz: sanitize quux } Without the punctuation, it would be very ambiguous: { foo capitalize bar baz sanitize quux }
- rayiner 15y ago
  I cringe at the thought of whitespace as an infix operator...
  - chc 15y ago
    That's not really the right way to look at it. Function application is just the default interpretation of two juxtaposed symbols. It's not any worse than "new MyObject()", which has whitespace acting just as much like an infix operator. There's no inherent reason why you'd need a special operator to apply "capitalize" but not "-" or "new" or "def". That's just how C does it, and by an accident of history most mainstream languages just parrot C by default.
- jcromartie 15y ago
  I don't know about Ruby 1.9, but in 1.8, you can't do (for example): { :foo => rand 40 } It requires parens. So Ruby seems to enforce some limit where it's too ambiguous.

chc 15y ago

This is such a superficial argument — even more superficial than the feature it's criticizing. It's only possibly misleading if you aren't familiar with the syntax, and that's true of a whole boatload of things, such as block syntax. The hashrocket itself looks bizarre and excessively noisy to people coming from JavaScript or Python or pretty much anything but PHP. This really is just, "I am not used to this syntax, so it looks weird to me." It's the same argument some people make against calling methods without parentheses in Ruby. If you're the sort of person who writes "self.houses().map(){|house| house.sale_price()}.sort()", then I guess at least you're being consistent. If not, don't be that guy. More philosophically, Ruby is a TIMTOWTDI language. There are five different and largely interchangeable ways to create a Proc, half the core library methods are aliases for other methods, several keywords are just slight variations on each other for no purpose other than to give you options, you can take or leave parentheses, etc. The new hash syntax is just one more example of this ethos. If this embarrassment of ways to write any given program bothers you (and you're certainly in good company if it does), you'd probably be more at home with Python. (I don't mean to tell anyone their business, I'm just saying, "only one way to do it" is the Python philosophy.)

TylerE 15y ago
The function without () thing annoys the crap out of me. I much prefer Python's way of doing things, () is the no-argument call, and without parens is the actual callable object. It emphasizes that functions really _are_ first class values that can be passed around, instead of having to use some special-case syntax to get at the callable.
- tptacek 15y ago
  I felt the same way, until I wrote my first program that used DSL-style. The parens-optional syntax thing is immensely useful in DSLs; it has saved me from writing tens of parsers. I'll add the ()'s to intra-class method calls, though; the ambiguity between variable references and funcall expressions bothers the hell out of me, too. Optional parens are a net win.
  - 15y ago

jgavris 15y ago

long live the { :hash => :rocket } !

damncabbage 15y ago

My only misgivings about the new syntax is that these sorts of lists now look rather dumb: foo: :bar, baz: :quux, wub: :bozo (This is, admittedly, a very subjective complaint. We could start calling this new double-colon syntax collision "Paamayim Nekudotayim".)

deleted 15y ago

[deleted]

zapadapa 15y ago

ruby is retarded.

AmazingBytecode 15y ago
Is that the best unsubstantiated diss you can come up with? Here are four better sounding and equally valid ones. node.js killed my dog. CoffeeScript gives you diarrhea. a time-traveling Scala user killed JFK. using Erlang is an unforgivable sin.
- zapadapa 15y ago
  are you feeling insecure?

cheald 15y ago

I don't think I like it either, but I'm pretty sure it's just because colons are already very commonly used in hashes as symbol delimiters. {foo: :bar} just feels weird. It's not a world-ending issue - certainly not enough to make an effective difference in practical usage - but it's enough of a visual collision that it rubs me the wrong way.

nagnatron 15y ago

Just don't use it. I won't.

Argorak 15y ago

A bit of history: this syntax originally appeared in MacRuby and is used for the named parameters needed to call ObjectiveC methods: person.setFirstName(first, lastName: last) So, introducing it into Ruby 1.9 gave MacRuby the ability of hooking into valid ruby syntax to do its special thing. As a wild speculation, it may also be used for named parameters, should they ever be introduced in Ruby. Personally, i like it for exactly that case. I do not like it as a generic hash syntax for another reason: its easy to align the =>, but its hard to align the:.

euroclydon 15y ago

As someone with no Ruby experience, I was reading through the lasted RoR config files recently, and I encountering these key/vals separated sometimes by a comma, other times by a colon, sometimes by nothing with the colon on the wrong side. I had to research new Ruby syntax for an hour to figure it out. If you are unfamiliar with Ruby symbols to begin with then it's tough on the brain because there is no discernible pattern.

jhrobert 15y ago

name: value instead of :name => value makes as much sense as p->q instead of (*p).x in C As an historical note, here are the message (and matz’s response) where I made a proposal for the new syntax, back in 2002. It includes rationals. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/38391 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/... Matz’s response : http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/38402 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...