4 ms·

Positionally-significant colons is more nightmarish than significant whitespace. Speaking as a critic of significant whitespace. Put them at the front and make

Positionally-significant colons is more nightmarish than significant whitespace. Speaking as a critic of significant whitespace. Put them at the front and make them mean something, or put them at the back and make them mean something, Making both places mean something entirely different, or even allowing both as an allowable syntax, is horrible for readability.

softjobs 3y ago
The colon sigil denotes a Symbol class literal, and a trailing colon here denotes a Symbol used as a Hash object key.
rco8786 3y ago
Ruby uses symbols (strings prefixed with a semicolon) very liberally. It’s just a value literal. Ive never met anyone who writes Ruby that has an issue with the readability of it.
- leetrout 3y ago
  Selection bias
  - fnordpiglet 3y ago
    I’m a Perl guy, and I find Ruby bizarrely verbose. I don’t understand how people can enjoy their symbols with all those word things.
    - donw 3y ago
      Right? If it doesn't use the shift key and the entire numeric row of the keyboard, count me out.
  - rco8786 3y ago
    Would disagree. I write in other languages and I find things tough to read. There are things about ruby I find tough to read (like `unless`) and know many other people who agree. Symbols work just fine in practice.
- 38 3y ago
  https://wikipedia.org/wiki/Stockholm_syndrome https://wikipedia.org/wiki/Stockholm_syndrome
  - rco8786 3y ago
    Is it stockholm syndrome if I leave ruby and years later still wish I had symbols in other languages?
vidarh 3y ago
They mean "symbol" either way, except when trailing ":" also means they're a key. I'd be inclined to agree it's a wart, but not that it affects readability to any noticeable amount. In this case, though, the DSL looks just awful to me.
- lloeki 3y ago
  To expand on this: Contrary to constants which are fixed+ references to values, symbols are pure values: they're like integers but with a textual name. Explicitly they are not strings. They used to be very useful because a symbol takes little memory and comparing two symbols means comparing two integers; it's a bit like `#define FOO 42` in C, except `42` is automatically picked up and you don't care what the value actually is. They are less useful today because there have been a lot of improvements e.g with frozen string literals (which are now stored only once and thus can be compared much more efficiently). Still that has a lot to do as to why they're used for kwargs and hash keys and method names and a ton of other stuff, where without symbols you'd have a ton of the same strings showing up over and over, so instantiated and compared. The hash syntax used to be only arrow but it was so common to do `:foo => "bar"` that at some point Ruby (1.9) introduced `foo: "bar"`, which makes writing hashes look like JSON/YAML and kwargs more like other languages like Python. This does make it a bit surprising because suddenly there's a symbol that is not prefixed with `:` but it also makes things a ton more readable in many cases. I do use the "new hash syntax" liberally, but also still use arrow hashes a lot because it all depends on the way things are written around and sometimes one is more readable than the other. For example in general I don't like writing rake task target dependencies or Rails routes with the new syntax, the arrow one makes more sense to me. Or when one can have mixed keys that can be symbols or some other types, I find it more readable to have a consistent hash syntax, so I go to the old arrow one. + well, although frowned upon, constants can be reassigned, they're essentially just some variables albeit with a different scope and resolution system.
pdntspa 3y ago
It seems like you have the concept down pat. I don't see what's wrong with it? Like lots of languages use positionally-dependent symbols. In both Perl and VB various characters in the variable name implied things about its type. With C/C++ the position of * tells you lots of important things. How is this anything less than yet another random language quirk?

softjobs 3y ago

The colon sigil denotes a Symbol class literal, and a trailing colon here denotes a Symbol used as a Hash object key.

rco8786 3y ago

Ruby uses symbols (strings prefixed with a semicolon) very liberally. It’s just a value literal. Ive never met anyone who writes Ruby that has an issue with the readability of it.

leetrout 3y ago
Selection bias
- fnordpiglet 3y ago
  I’m a Perl guy, and I find Ruby bizarrely verbose. I don’t understand how people can enjoy their symbols with all those word things.
  - donw 3y ago
    Right? If it doesn't use the shift key and the entire numeric row of the keyboard, count me out.
- rco8786 3y ago
  Would disagree. I write in other languages and I find things tough to read. There are things about ruby I find tough to read (like `unless`) and know many other people who agree. Symbols work just fine in practice.
38 3y ago
https://wikipedia.org/wiki/Stockholm_syndrome https://wikipedia.org/wiki/Stockholm_syndrome
- rco8786 3y ago
  Is it stockholm syndrome if I leave ruby and years later still wish I had symbols in other languages?

vidarh 3y ago

They mean "symbol" either way, except when trailing ":" also means they're a key. I'd be inclined to agree it's a wart, but not that it affects readability to any noticeable amount. In this case, though, the DSL looks just awful to me.

lloeki 3y ago
To expand on this: Contrary to constants which are fixed+ references to values, symbols are pure values: they're like integers but with a textual name. Explicitly they are not strings. They used to be very useful because a symbol takes little memory and comparing two symbols means comparing two integers; it's a bit like `#define FOO 42` in C, except `42` is automatically picked up and you don't care what the value actually is. They are less useful today because there have been a lot of improvements e.g with frozen string literals (which are now stored only once and thus can be compared much more efficiently). Still that has a lot to do as to why they're used for kwargs and hash keys and method names and a ton of other stuff, where without symbols you'd have a ton of the same strings showing up over and over, so instantiated and compared. The hash syntax used to be only arrow but it was so common to do `:foo => "bar"` that at some point Ruby (1.9) introduced `foo: "bar"`, which makes writing hashes look like JSON/YAML and kwargs more like other languages like Python. This does make it a bit surprising because suddenly there's a symbol that is not prefixed with `:` but it also makes things a ton more readable in many cases. I do use the "new hash syntax" liberally, but also still use arrow hashes a lot because it all depends on the way things are written around and sometimes one is more readable than the other. For example in general I don't like writing rake task target dependencies or Rails routes with the new syntax, the arrow one makes more sense to me. Or when one can have mixed keys that can be symbols or some other types, I find it more readable to have a consistent hash syntax, so I go to the old arrow one. + well, although frowned upon, constants can be reassigned, they're essentially just some variables albeit with a different scope and resolution system.

pdntspa 3y ago

It seems like you have the concept down pat. I don't see what's wrong with it? Like lots of languages use positionally-dependent symbols. In both Perl and VB various characters in the variable name implied things about its type. With C/C++ the position of * tells you lots of important things. How is this anything less than yet another random language quirk?