6 ms·

It really doesn't... After years using Ruby my mind never managed to parse its complicated grammar.

by batiste 4y ago

travbrack 4y ago
Any examples? I always found it easy to grok but I'm not at a very high level so I'm curious where it gets hairy.
- cycomachead 4y ago
  There's a bunch of things to pay attention to in Ruby. I wouldn't say these get too hairy, but they trip students up for very understandable reasons. * `a ||= b` is not just `a = a || b`, but `a || a = b` * The distinction between defaults arguments and hash arguments in functional signatures has many edge cases -- but it's much much better in Ruby 3. * There are still 2 pieces of syntax for hashes (`{a: 1}` and `{:a => 1}`) They are the same. * Curly bases show up a fair bit for a language that's not a braces language. :) They're in hashes, blocks, and % strings. e.g. `%w{a b c}` is the same as `%w|a b c|`. They're also used in string interpolation, e.g. `"Hello, #{name}"`. * There are sometimes many ways to do the same thing. There's Procs, blocks, and lambdas. % strings work with many characters. * `unless` for `if not...` and get wonky. * Overusing "surprise if" e.g. `do_thing if other_thing` can be hard to read. * It's so easy to monkey-patch and extend primitive classes, you might not realize when libraries do it. All of these are features that I actually find nice to use in the right contexts. But they can pop up when you don't expect, and they can definitely make Ruby a challenge to learn. That said with a little discipline (or just a linter ;)), I find a lot of Ruby code a joy to read and write.
  - greenpeas 4y ago
    I don't quite get the distinction in your first item: What's the difference between `a = (a || b)` and `a || (a = b)` ?
    - Jabbles 4y ago
      The rabbithole is here: https://stackoverflow.com/q/995593 https://stackoverflow.com/q/995593
      - greenpeas 4y ago
        wow, thanks. I worked with ruby for more than 5 years, and `||=` never surprised me. TLDR On the distinction between `a = (a || b)` and `a || (a = b)`: * There is no difference when `a` and `b` are local variables (unless `a` is undefined, but that's an edge case) * The distinction manifests when `a=` is a method. (It could be a `[]=` or some attr_accessor). Then `a = (a || b)` always invokes `a=`, whereas `a || (a = b)` only invokes `a=` when `a` is falsey. In essence however, `a ||= b` respects the intuitive definition that it sets `a` to `b` if and only if `a` is falsey.
        cycomachead 4y ago
        Yeah, it's not usually an issue in practice. But I do see students get confused trying things out...and it's likely because learning in an interpreter doesn't often look like "real" code does.
  - IshKebab 4y ago
    > `do_thing if other_thing` Yeah I don't get why you would deliberately make the flow control confusing and backwards like that. Python list comprehensions are the same. They make the information flow backwards. This also has the effect of making nesting really confusing.
    - greenpeas 4y ago
      > > `do_thing if other_thing` > Yeah I don't get why you would deliberately make the flow control confusing and backwards like that. I like to use this as function guards, where the first lines in the body of a function can be: return xxx if some_edge_condition? example: https://github.com/rails/rails/blob/f95c0b7e96eb36bc3efc0c5beffbb9e84ea664e4/activerecord/lib/active_record/relation/merger.rb#L85 https://github.com/rails/rails/blob/f95c0b7e96eb36bc3efc0c5b...
      - cycomachead 4y ago
        Guard clauses are great, and when used appropriately clean things up. This is pretty much my only use of the pattern. (Ending boolean-returning methods with a ? is also a great convention in ruby.)
      - bobbylarrybobby 4y ago
        if some_edge_condition: return x
        msbarnett 4y ago
        I’ve written both professionally and personally found Python makes it harder to see the early out, which makes it less valuable/explicit as a guard. The Ruby pattern is clear up front on what it is rather than being a bag of conditions that you have to get to the end of to discover what they trigger.
    - gls2ro 4y ago
      For me this fits more into how I think or how I say things in my mind. It might be that I am not an english speaker, but for example when I say to someone a list of instructions I usually say it like this: "Add more water if the dough is dry" and I don't usually say "If the dough is dry add more water" The same for saying for example: "stop mixing if the dough is starting to tear" or "put the bread in the oven when it is ready"
endorphine 4y ago
What does this mean, concretely speaking? Do you mean you can't remember the right syntax when trying to program in it? I know its syntax is complicated but I never felt this has caused me trouble. I guess writing a parser for it would be extremely hard, but that's another story.
- BiteCode_dev 4y ago
  The optional parenthesis kills it for me. It makes scanning the code impossible: you have to understand each line context.
  - endorphine 4y ago
    How long do you program in Ruby? I understand this coming from a newcomer but after a while it felt like second-nature to me. I was curious about parent poster, because they said they are using Ruby for years.
  - rubyist5eva 4y ago
    How? I’ve been writing Ruby and Rails for over a decade and I can’t really say it’s ever been a problem for me.
  - batiste 4y ago
    Yeah, the optional parenthesis is one my biggest complaint with the language. It just makes things less readable, with not other benefits than making the code look more clever than it is.
  - msbarnett 4y ago
    How does this make it confusing? What information do you feel () gives you? You might say: foo().bar().baz() Ah well these are clearly method calls, they have (). But this is Ruby: foo.bar.baz These are clearly method calls too, because in Ruby there’s nothing else they could possibly be. The ()s don’t actually disambiguate anything. Unlike C or Java or some other languages with some notion of bare access to internal fields, there are always and only method calls.
DonHopkins 4y ago
Guido van Rossum put it this way: "Again, the templating language seems a weird mixture of HTML and Ruby, and I find Ruby's syntax grating (too many sigils)." https://www.artima.com/forums/flat.jsp?forum=106&thread=146149 https://www.artima.com/forums/flat.jsp?forum=106&thread=1461... >Then I decided to have a look at Ruby on Rails, just to see what I could learn from the competition. I watched two fascinating movies, but they went a bit too fast to really understand what was going on, and there seemed to be a fair amount of sleight of hand in the examples (a lot of default behavior that just happens to do the right thing for the chosen demo). Again, the templating language seems a weird mixture of HTML and Ruby, and I find Ruby's syntax grating (too many sigils). I believe I heard Greg Stein say recently that if you are really good in Ruby, CSS, HTML and SQL, you can produce great websites quickly with Rails -- but if you don't, you produce lousy websites quickly (just like with PHP). I quoted Guido's point about Ruby syntax 15 years ago in this lua-l discussion about Lua, Python, Lisp, and Ruby syntax, and the importance of not naming programming languages after naughty bits: https://lua-l.lua.narkive.com/Ly6vITFE/justify-introducing-lua-at-my-workplace#post3 https://lua-l.lua.narkive.com/Ly6vITFE/justify-introducing-l... >Stephen Kellett 15 years ago >[...] A little story to explain why in house languages are bad: >Years ago I worked for a company that had an in-house language (90-94) called Lull. [...] >(*) Come be real, who uses Lisp for commercial projects? Great language, but too many parens and no one uses it. Its the equivalent of Esperanto. So much promise, so little delivery. [...] >Don Hopkins 15 years ago >I read your message about "Lull" and a Dutch guy sitting behind me laughed out loud when I said the name of your language. (My dictionary says "lul" means "prick" or "cock" in slang, so it's a bit more explicit than "dick"!) This just goes to prove that how you name a language is important (but not as important as designing the language so it doesn't suck...)! >On the "too many parens" excuse for disliking Lisp: so why do you use XML and HTML? They have TWICE the number of parens, which are pointy instead of rounded, but lots of people seem to use them anyway. So "too many parens" is just a convenient and shallow excuse for disliking Lisp that avoids examining the real issue. >The real problem that many people have with Lisp is because it's perceived as a homosexual programming language, which causes unconscious cognitive dissonance, so people have to grasp for more socially acceptable reasons for disliking the language (like "too many parens"). Nobody wants to just say "I hate Lisp because it sounds gay", so instead they say "too many parens", even though most other languages suffer from too few parens, and are much less readable than Lisp because of their insane hierarchies of precedence rules. Programming tips 101: ALWAYS use parens even if you're sure the precedence rules will make your expression do what you want, because 1) other people need to be able to read the code and 2) you may be wrong. Drop any copy of K&R on the table so it lands on the spine and opens to a commonly used page, and I bet it opens on the table of precedence rules, because that's the page everyone always turns to. Lisp code never suffers from this problem. >The first thing most typical homophobic Americans think of when they hear the word Lisp is the gay stereotype of speaking with a lisp, so it unconsciously terrifies them. And the fact that "lambda" signifies unity under oppression, and is used as the gay/lesbian/bisexual/transgendered symbol only reinforces that impression: http://en.wikipedia.org/wiki/LGBT_symbol#Lambda http://en.wikipedia.org/wiki/LGBT_symbol#Lambda ...And then there's the purple cover of Structure and Interpretation of Computer Programs, with the two gay dudes on the cover. >Anyway, millions of people program in Lisp every day with C syntax, but they just call it JavaScript, and suffer without macros, because of the inferior C syntax. >-Don >Fabien 15 years ago >@Don: your theory is fine for US people, but lack of love for Lisp is also observed in non-English speaking places. I learned quite recently that the word "lisp" also had another meaning than "nail clippings in oatmeal". >My guess would rather be that Lisp doesn't encourage common idioms and development approaches across people and teams, which makes it hard to: >- get into code you didn't develop >- work with more than a couple of teammates >- find a library that addresses your problem >- if you have several problems and find a lib to address each of them, get those libs to work together despite their incompatible macro hacks. >That, and Lisp took waaaay too long to acknowledge its platforms. It pretended to be OS independent, which meant many non-standard, non-compatible ways to interface with OSes, and therefore, plenty of platform issues as soon as you wanted to port or deploy a non-trivial solution. As written somewhere by Paul Graham, "Unix has won, get used to it". >Don Hopkins 15 years ago >Now that's some spot-on criticism of Lisp, much better than the "too many parenthesis" excuse that gets thrown around by linguistic homophobes suffering from cognitive dissonance. >I'm still waiting to hear somebody claim that they refuse to use XML and HTML because they have too many parenthesis (angled brackets). Or for somebody who hates Lisp's parenthesis but tolerates XML and HTML to explain why <foo>bar</foo> is easier to read than (foo bar). >Perl and C++ have way too much punctuation in general, and Ruby made a cargo cult design mistake in imitating Perl syntax. I agree with Guido van Rossum's comment on Ruby: "I find Ruby's syntax grating (too many sigils)". http://www.artima.com/forums/flat.jsp?forum=106&thread=146149 http://www.artima.com/forums/flat.jsp?forum=106&thread=14614... >Wow, in what language does lisp mean nail clippings in oatmeal, and where can I get some of that stuff? It sounds delicious! >"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -- Jamie Zawinski, on X-Windows toolkits. >-Don [...] >Fabian: http://en.wikiquote.org/wiki/Larry_Wall http://en.wikiquote.org/wiki/Larry_Wall look for "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in") [...]

It really doesn't... After years using Ruby my mind never managed to parse its complicated grammar.

travbrack 4y ago

Any examples? I always found it easy to grok but I'm not at a very high level so I'm curious where it gets hairy.

cycomachead 4y ago
There's a bunch of things to pay attention to in Ruby. I wouldn't say these get too hairy, but they trip students up for very understandable reasons. * `a ||= b` is not just `a = a || b`, but `a || a = b` * The distinction between defaults arguments and hash arguments in functional signatures has many edge cases -- but it's much much better in Ruby 3. * There are still 2 pieces of syntax for hashes (`{a: 1}` and `{:a => 1}`) They are the same. * Curly bases show up a fair bit for a language that's not a braces language. :) They're in hashes, blocks, and % strings. e.g. `%w{a b c}` is the same as `%w|a b c|`. They're also used in string interpolation, e.g. `"Hello, #{name}"`. * There are sometimes many ways to do the same thing. There's Procs, blocks, and lambdas. % strings work with many characters. * `unless` for `if not...` and get wonky. * Overusing "surprise if" e.g. `do_thing if other_thing` can be hard to read. * It's so easy to monkey-patch and extend primitive classes, you might not realize when libraries do it. All of these are features that I actually find nice to use in the right contexts. But they can pop up when you don't expect, and they can definitely make Ruby a challenge to learn. That said with a little discipline (or just a linter ;)), I find a lot of Ruby code a joy to read and write.
- greenpeas 4y ago
  I don't quite get the distinction in your first item: What's the difference between `a = (a || b)` and `a || (a = b)` ?
  - Jabbles 4y ago
    The rabbithole is here: https://stackoverflow.com/q/995593 https://stackoverflow.com/q/995593
    - greenpeas 4y ago
      wow, thanks. I worked with ruby for more than 5 years, and `||=` never surprised me. TLDR On the distinction between `a = (a || b)` and `a || (a = b)`: * There is no difference when `a` and `b` are local variables (unless `a` is undefined, but that's an edge case) * The distinction manifests when `a=` is a method. (It could be a `[]=` or some attr_accessor). Then `a = (a || b)` always invokes `a=`, whereas `a || (a = b)` only invokes `a=` when `a` is falsey. In essence however, `a ||= b` respects the intuitive definition that it sets `a` to `b` if and only if `a` is falsey.
      - cycomachead 4y ago
        Yeah, it's not usually an issue in practice. But I do see students get confused trying things out...and it's likely because learning in an interpreter doesn't often look like "real" code does.
- IshKebab 4y ago
  > `do_thing if other_thing` Yeah I don't get why you would deliberately make the flow control confusing and backwards like that. Python list comprehensions are the same. They make the information flow backwards. This also has the effect of making nesting really confusing.
  - greenpeas 4y ago
    > > `do_thing if other_thing` > Yeah I don't get why you would deliberately make the flow control confusing and backwards like that. I like to use this as function guards, where the first lines in the body of a function can be: return xxx if some_edge_condition? example: https://github.com/rails/rails/blob/f95c0b7e96eb36bc3efc0c5beffbb9e84ea664e4/activerecord/lib/active_record/relation/merger.rb#L85 https://github.com/rails/rails/blob/f95c0b7e96eb36bc3efc0c5b...
    - cycomachead 4y ago
      Guard clauses are great, and when used appropriately clean things up. This is pretty much my only use of the pattern. (Ending boolean-returning methods with a ? is also a great convention in ruby.)
    - bobbylarrybobby 4y ago
      if some_edge_condition: return x
      - msbarnett 4y ago
        I’ve written both professionally and personally found Python makes it harder to see the early out, which makes it less valuable/explicit as a guard. The Ruby pattern is clear up front on what it is rather than being a bag of conditions that you have to get to the end of to discover what they trigger.
  - gls2ro 4y ago
    For me this fits more into how I think or how I say things in my mind. It might be that I am not an english speaker, but for example when I say to someone a list of instructions I usually say it like this: "Add more water if the dough is dry" and I don't usually say "If the dough is dry add more water" The same for saying for example: "stop mixing if the dough is starting to tear" or "put the bread in the oven when it is ready"

endorphine 4y ago

What does this mean, concretely speaking? Do you mean you can't remember the right syntax when trying to program in it? I know its syntax is complicated but I never felt this has caused me trouble. I guess writing a parser for it would be extremely hard, but that's another story.

BiteCode_dev 4y ago
The optional parenthesis kills it for me. It makes scanning the code impossible: you have to understand each line context.
- endorphine 4y ago
  How long do you program in Ruby? I understand this coming from a newcomer but after a while it felt like second-nature to me. I was curious about parent poster, because they said they are using Ruby for years.
- rubyist5eva 4y ago
  How? I’ve been writing Ruby and Rails for over a decade and I can’t really say it’s ever been a problem for me.
- batiste 4y ago
  Yeah, the optional parenthesis is one my biggest complaint with the language. It just makes things less readable, with not other benefits than making the code look more clever than it is.
- msbarnett 4y ago
  How does this make it confusing? What information do you feel () gives you? You might say: foo().bar().baz() Ah well these are clearly method calls, they have (). But this is Ruby: foo.bar.baz These are clearly method calls too, because in Ruby there’s nothing else they could possibly be. The ()s don’t actually disambiguate anything. Unlike C or Java or some other languages with some notion of bare access to internal fields, there are always and only method calls.

DonHopkins 4y ago

Guido van Rossum put it this way: "Again, the templating language seems a weird mixture of HTML and Ruby, and I find Ruby's syntax grating (too many sigils)." https://www.artima.com/forums/flat.jsp?forum=106&thread=146149 https://www.artima.com/forums/flat.jsp?forum=106&thread=1461... >Then I decided to have a look at Ruby on Rails, just to see what I could learn from the competition. I watched two fascinating movies, but they went a bit too fast to really understand what was going on, and there seemed to be a fair amount of sleight of hand in the examples (a lot of default behavior that just happens to do the right thing for the chosen demo). Again, the templating language seems a weird mixture of HTML and Ruby, and I find Ruby's syntax grating (too many sigils). I believe I heard Greg Stein say recently that if you are really good in Ruby, CSS, HTML and SQL, you can produce great websites quickly with Rails -- but if you don't, you produce lousy websites quickly (just like with PHP). I quoted Guido's point about Ruby syntax 15 years ago in this lua-l discussion about Lua, Python, Lisp, and Ruby syntax, and the importance of not naming programming languages after naughty bits: https://lua-l.lua.narkive.com/Ly6vITFE/justify-introducing-lua-at-my-workplace#post3 https://lua-l.lua.narkive.com/Ly6vITFE/justify-introducing-l... >Stephen Kellett 15 years ago >[...] A little story to explain why in house languages are bad: >Years ago I worked for a company that had an in-house language (90-94) called Lull. [...] >(*) Come be real, who uses Lisp for commercial projects? Great language, but too many parens and no one uses it. Its the equivalent of Esperanto. So much promise, so little delivery. [...] >Don Hopkins 15 years ago >I read your message about "Lull" and a Dutch guy sitting behind me laughed out loud when I said the name of your language. (My dictionary says "lul" means "prick" or "cock" in slang, so it's a bit more explicit than "dick"!) This just goes to prove that how you name a language is important (but not as important as designing the language so it doesn't suck...)! >On the "too many parens" excuse for disliking Lisp: so why do you use XML and HTML? They have TWICE the number of parens, which are pointy instead of rounded, but lots of people seem to use them anyway. So "too many parens" is just a convenient and shallow excuse for disliking Lisp that avoids examining the real issue. >The real problem that many people have with Lisp is because it's perceived as a homosexual programming language, which causes unconscious cognitive dissonance, so people have to grasp for more socially acceptable reasons for disliking the language (like "too many parens"). Nobody wants to just say "I hate Lisp because it sounds gay", so instead they say "too many parens", even though most other languages suffer from too few parens, and are much less readable than Lisp because of their insane hierarchies of precedence rules. Programming tips 101: ALWAYS use parens even if you're sure the precedence rules will make your expression do what you want, because 1) other people need to be able to read the code and 2) you may be wrong. Drop any copy of K&R on the table so it lands on the spine and opens to a commonly used page, and I bet it opens on the table of precedence rules, because that's the page everyone always turns to. Lisp code never suffers from this problem. >The first thing most typical homophobic Americans think of when they hear the word Lisp is the gay stereotype of speaking with a lisp, so it unconsciously terrifies them. And the fact that "lambda" signifies unity under oppression, and is used as the gay/lesbian/bisexual/transgendered symbol only reinforces that impression: http://en.wikipedia.org/wiki/LGBT_symbol#Lambda http://en.wikipedia.org/wiki/LGBT_symbol#Lambda ...And then there's the purple cover of Structure and Interpretation of Computer Programs, with the two gay dudes on the cover. >Anyway, millions of people program in Lisp every day with C syntax, but they just call it JavaScript, and suffer without macros, because of the inferior C syntax. >-Don >Fabien 15 years ago >@Don: your theory is fine for US people, but lack of love for Lisp is also observed in non-English speaking places. I learned quite recently that the word "lisp" also had another meaning than "nail clippings in oatmeal". >My guess would rather be that Lisp doesn't encourage common idioms and development approaches across people and teams, which makes it hard to: >- get into code you didn't develop >- work with more than a couple of teammates >- find a library that addresses your problem >- if you have several problems and find a lib to address each of them, get those libs to work together despite their incompatible macro hacks. >That, and Lisp took waaaay too long to acknowledge its platforms. It pretended to be OS independent, which meant many non-standard, non-compatible ways to interface with OSes, and therefore, plenty of platform issues as soon as you wanted to port or deploy a non-trivial solution. As written somewhere by Paul Graham, "Unix has won, get used to it". >Don Hopkins 15 years ago >Now that's some spot-on criticism of Lisp, much better than the "too many parenthesis" excuse that gets thrown around by linguistic homophobes suffering from cognitive dissonance. >I'm still waiting to hear somebody claim that they refuse to use XML and HTML because they have too many parenthesis (angled brackets). Or for somebody who hates Lisp's parenthesis but tolerates XML and HTML to explain why <foo>bar</foo> is easier to read than (foo bar). >Perl and C++ have way too much punctuation in general, and Ruby made a cargo cult design mistake in imitating Perl syntax. I agree with Guido van Rossum's comment on Ruby: "I find Ruby's syntax grating (too many sigils)". http://www.artima.com/forums/flat.jsp?forum=106&thread=146149 http://www.artima.com/forums/flat.jsp?forum=106&thread=14614... >Wow, in what language does lisp mean nail clippings in oatmeal, and where can I get some of that stuff? It sounds delicious! >"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -- Jamie Zawinski, on X-Windows toolkits. >-Don [...] >Fabian: http://en.wikiquote.org/wiki/Larry_Wall http://en.wikiquote.org/wiki/Larry_Wall look for "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in") [...]